scenario: fill the corpus until both coverage axes are green

[Yaraslaut]

scripts/scenario/scenario_coverage.py measured a surface nothing filled. This fills it: the corpus goes from 4 files to 72, and the report now exits 0 on both axes.

Rung	Files	Actions	Workflows (floor)
pastebin	12	6/6	8/8
polls	10	9/9	10/10
bookmarks	14	17/17	12/12
ledger	15	17/17	15/15
kanban	21	22/22	20/20

71/71 actions dispatched. 8/8 envelope kinds. 11/17 refusals asserted, the remaining 6 exempt with written reasons.

Every journey is named after what it does and sourced from its rung's own README — pastebin's first file is the definition of done's create → list → open → burn → delete verbatim; polls' undo file is the A-votes-B-votes-A-undoes interleaving the README calls that rung's headline design record.

Verification

Every file was run against a real ladder_<rung>_server, re-run against the database the first pass left behind, and mutation-tested. 71 files, zero surviving mutants. test_morph_scenario.py passes 118 cases; ladder_kanban_tests passes 137.

python3 scripts/scenario/run_scenarios.py --twice     # exit 0
python3 scripts/scenario/run_scenarios.py --mutate    # exit 0, no survivors
python3 scripts/scenario/scenario_coverage.py         # exit 0

scripts/scenario/run_scenarios.py

The server lifecycle morph_scenario.py deliberately does not own, and which the workflow-axis spec already anticipated as run_all.sh. One server per rung, on a fresh SQLite database in its own working directory with the port bound to 0; runs the directory; tears the process group down. --twice proves every file is re-runnable, --mutate proves its assertions are load-bearing.

The blocker: kanban could not be driven at all

KanbanAuthorizer inherited SigningAuthorizer without the anonymous carve-out BookmarksAuthorizer carries, so authorize() demanded a bearer token for AuthModel/Login — the only action that mints one. Every action a fresh remote client could send was answered err "unauthorized", login included. ladder_kanban_headless says so in its own comment: it takes the token on its command line, because it cannot ask the server for one.

bookmarks documents this exact deadlock, and records that it was found by driving a real server from a client. kanban was written later and inherited the shape but not the fix. It gets the identical carve-out — one model type, one action type, compared exactly. Login still refuses the reserved system: namespace, so an anonymous caller can mint a token for a name it chooses and nothing more. All 137 kanban tests still pass.

Without this the rung's 22 actions and floor of 20 were unreachable.

What the corpus found

Three defects, each asserted as it behaves so the gate stays green, each with its issue named in the file that pins it:

• ledger: StoreTransaction posts legs onto accounts belonging to another book #367 — StoreTransaction posts legs onto another book's accounts. The journal files under the named ledger, the foreign balance moves, and every read stays scoped — so the two books disagree and neither says so. A leg naming no account at all is refused, which shows the lookup runs and simply does not check the book. UndoTransaction makes the equivalent check.
• kanban: an unattached BoardModel replies "stoull", and two guards written to prevent that never fire #368 — an unattached BoardModel replies stoull, the what() of std::invalid_argument. Two actions have a guard with exactly the right message that never fires, because the optional is engaged with an empty string.
• kanban: GetRules requires a projectId and then ignores it #369 — GetRules requires a projectId and then queries the attached board instead.

Four defects in the test apparatus itself, fixed here:

• the driver never drained server stdout, so servers wedged in write(2) on a full pipe about sixty mutant reruns in — the corpus passed and --mutate died with "no data within 10.0s" on a server that was neither crashed nor refusing;
• kanban writes its action log to current_path(), so runs accumulated it in the caller's directory and GetActivity replayed a previous run's project 1 as this one's;
• the pre-existing paste-lifecycle.scenario asserted a new paste appears in a bare ListPastes — true only while the database holds fewer than twenty public pastes with larger ids. It was passing by luck, and failed about half the time under repetition;
• morph_scenario.py correlated strictly by callId, which made the decode-failure path unassertable: a frame the server cannot decode has no envelope to read a callId from, so it answers with 0. Client.rpc now accepts that in exactly that shape and nowhere else.

Deviations from the plan, and where they are recorded

The design spec said "no change to the example applications". Two boundaries were crossed deliberately — the kanban authorizer fix, and the callId rule above — and both are now written into the spec where it said otherwise, rather than left to be found in the diff. Neither the coverage thresholds nor the workflow floors moved.

scenario_coverage.py's own canary test, which pinned exit 1 and said in its comment that authoring the corpus was later work, is flipped to 0 with that history recorded.

Not filed, deliberately

ImportLedgerChunk's per-row commit leaves earlier rows posted when a later row is malformed. That looked like a defect until the code was read: execute(ImportLedgerChunk) records it as a ruling and gives the reason — a SqlTransaction nested around the loop would have storeJournalImpl's inner Commit() end the outer one, since SqlTransaction toggles SQL_ATTR_AUTOCOMMIT on the connection directly. The scenario pins it and now cites that ruling instead of implying a bug.

🤖 Generated with Claude Code

https://claude.ai/code/session_01GnSnsebJ92Kti1D7m3RwYJ

[codecov]

Codecov Report

❌ Patch coverage is 50.00000% with 2 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
...s/kanban/include/kanban/auth/kanban_authorizer.hpp	50.00%	1 Missing and 1 partial ⚠️

📢 Thoughts on this report? Let us know!