Back to Feed
article 4m read

Every new supplier cost me a copy of the same rules file and a hand-typed run ID

Three bits of glue came out of supplier onboarding in the ordering system: copied rules files, a next command built by hand, and log noise in machine output. Every check stayed, and the risk moved onto the supplier lookup.

Article DepthPractice

Flow

From pasted sheet to draft

  1. 1Paste the sheet

    One command, with the shared rules and the ready stage as defaults.

  2. 2Look up the supplier

    The shared rules are only safe if exactly one supplier matches.

  3. 3Run the checks

    Every stage still runs and saves a checkpoint.

  4. 4Get the next command

    Only when there is something to order.

  5. 5Make the draft

    Checks the saved checkpoint first; a person still reviews it.

Flow

Where the draft step gets its plan

  1. 1Plan file given

    Use it; a broken file gets its own error.

  2. 2No file, finished run named

    Use the plan saved in that run's ready checkpoint.

  3. 3Neither

    Stop with a clear missing-plan error.

  4. 4Before writing anything

    Compare against the saved checkpoint and refuse any difference.

Every new supplier I added to the ordering system cost me a new rules file, and the new file was an old file with one list changed. That was one of three slow spots I cut from adding a supplier, and none of them was a check.

The chain I didn't want to touch

When a supplier joins, I paste their product sheet into a command-line tool, and it moves a run through stages in order. It reads the sheet exactly as pasted, reads the columns with a set of reviewed rules, proves the product list is complete, sets things up, and finally proves it could build a test order. Each stage saves a checkpoint. The last one can lead to a draft order, but only a draft that a person still has to review, and nothing gets sent.

I didn't touch the checks. The steps around them were the problem.

The same rules file, again

The rules say which column holds what, how the store columns repeat, and how the sheet spells things. Each rules file also listed which suppliers it could serve, and any other supplier got refused.

Several of my suppliers send the same layout, so their rules files were copies with different name lists, and the same day I built this, one more copy showed up. Nobody truly reviews a copy. It just waits to drift.

Now one shared rules file covers that layout. It serves whichever supplier the tool looked up, instead of a fixed list. The old kind still exists, and a test makes sure it still refuses a stranger. If you build something like this, know where the risk moved: the shared file only stays safe if the lookup finds exactly one supplier. I didn't change the lookup, so I'm trusting it. A mistake in the shared file also hits every supplier that uses it, not just one.

One wart: the format still wants a name list, so the shared file carries a placeholder name.

Retyping the run ID

A run used to stop at the ready stage, and then I had to put the next command together by hand from the supplier, the run ID and the person acting. The draft step also wanted a saved plan file. Every hand step was a chance to paste the wrong run.

Now the ready checkpoint records two things: whether the plan can actually be ordered, and whether there's demand right now. If it can, the result includes the exact next command. If there's nothing to order, there's no command.

The draft step takes its input in order: a plan file if you gave one, otherwise the plan saved in the finished run, otherwise a clear error.

In short, it uses the plan file if there is one and otherwise the run's saved plan.

That one-liner hides the error case, so don't copy it as is. A missing plan and a broken plan should fail with different errors. The draft step still checks the saved checkpoint before it writes anything, which makes the suggested command a shortcut, not a permission slip.

The tool now defaults to the shared rules and runs all the way to ready. Preview is still the default, so a plain run changes nothing.

One JSON document on standard output

This tool is built for small models to drive, not just me. In JSON mode, the output should be one clean document, but some parts of the tool print progress to that same stream. Now, in JSON mode, those messages go to the error stream instead. I have no record of the old way breaking anything, so this is just a guard. The price is that no warnings show up in the main output in JSON mode.

No stopwatch, no live supplier

The speed claim rests on counting hand steps, not on a clock. None of the tests is a run against a brand-new supplier, so for now this is a shortcut I've read and tested, not one I've watched work.

Keep reading

Pick up a connected idea or branch into a nearby one.

5 paths forward