Working style is the real experiment here

This one isn't really about split-flap boards or inventory systems — it's about how the actual work happens. Across the last couple of builds, the same few questions keep deciding whether a session goes well or badly: when to ask before building versus just building, how much to verify before handing something back, and what ‘done for tonight’ actually means.

The pattern that's held up best so far: ask when a decision is genuinely ambiguous and hard to reverse, don't ask when the answer is obvious or cheap to undo. A markup format, a colour palette, what counts as ‘real’ content — worth a straight question. Which variable name to use — not worth interrupting anyone for.

Verification turned out to be the same trade-off wearing a different hat. Indirect checks — traced logic, a stub of the real settings, tests run outside the normal runner — are fast and catch real problems, but they're a first pass, not a substitute for the real thing. Knowing which situations can stop at the first pass and which need the real run is still mostly judgement, not a rule.

‘Done for tonight’ has quietly become its own skill. Not ‘everything works’, and not ‘I stopped because it's late’, but somewhere in between: the thing runs, the open questions are written down, and the next session can start from the actual state of the project instead of memory. That third option is the one worth protecting.

None of this is finished — it's the meta-experiment sitting underneath every other one on this list, still being tuned session by session.