tally: the kit becomes a runtime-read, git-tracked file (ruling 4)

[mecattaf]

What

Ruling 4 (2026-09-16 evening): "Coordinator switching must NOT be required every time a Tally flow is added. A new kit entry / flow must load without a home-manager or NixOS switch. … The kit path must become a runtime-read, git-tracked location, not a store path baked at switch time."

FT-3 (#361, TL-18 / D-B18, #304) shipped the box's argv table as a pkgs.writeText store file, so every new flow cost a coordinator switch. This PR moves it out of the store.

• home/dot_config/tally/kit.json — the committed 603-entry table, installed at ~/.config/tally/kit.json by config.lib.file.mkOutOfStoreSymlink into the dotfiles checkout (the motion home/home.nix already performs for every raw dotfile). The pinned lake's readKit is a readFileSync per pass, so an edit is live at the next timer wake.
• services.tally-uplink.kit = "${config.home.homeDirectory}/.config/tally/kit.json" (the option is nullOr str). Rendered ExecStart carries --kit /home/tom/.config/tally/kit.json, and still no --plan.
• tools/render-tally-kit.py renders the LOCAL-SMOKE trio plus the 3N CUBS entries (N = 200 as cubs-halogen-probe-1: cubs-iteration executable and kit entries (FRONT-12 bootstrap) #402, --dry NOT appended) deterministically; --check diffs the committed bytes. Supersedes the nix-rendered cubsEntries.
• Every argv[0] is a stable per-user profile path — /etc/profiles/per-user/tom/bin/{tally-local-smoke,cubs-iteration}. A hashed store path inside a git-tracked file goes stale on the next rebuild, and refreshing it would be the very switch the ruling removed. pkgs/tally-local-smoke promotes FT-3's localSmoke writeShellScript to a writeShellApplication (bytes unchanged, runtimeInputs deliberately empty so it runs under env -i); both packages join home.packages and are exposed as flake packages so the probe can realise the argv before the switch.
• flake.nix tally-uplink-topology asserts flipped: hasPrefix "/home/tom/.config/tally/" cfg.kit, !(hasPrefix "/nix/store/" cfg.kit), builtins.pathExists ./home/dot_config/tally/kit.json, builtins.fromJSON (builtins.readFile …) parses and carries build:LOCAL-SMOKE + build:CUBS-1 and still not claude:headless, and ExecStart carries --kit /home/tom/.config/tally/.
• tests/tally-uplink/probe-FT-3-kit.sh: K1/K3/K5 inverted, new K0 (the committed bytes are the rendered bytes and hold no store path), K2 reads the checkout file through the pinned lake's own readKit, K4 kept. tests/tally-uplink/probe-cubs-iteration.sh follows the kit to the checkout and to the stable argv[0].
• Docs and ledgers: docs/local-ai/tally-uplink-input.md rewritten for the runtime-read kit (a new flow is a JSON edit + a commit); DECISIONS.md cites ruling 4 and records that Rule 9 (claude-transcript-mirror is two hand-written unit files and an untracked script — declare it (Rule 9) #293) yields for this file — the review moves from the store path to the git object, and the path on the box is a symlink into the checkout, so editing it is editing the repository — plus four "default, unruled" lines; DEFERRED.md gains DF-KIT-1 [OPERATOR], DF-KIT-2 [OTHER-REPO], DF-KIT-3 with the inherited red tails.

Why

~/.local/state/tally-rewrite/ledger.jsonl has 0 lease_grant rows ever. Adding a Tally flow or kit entry must never require a coordinator switch (ruling 4), and until this lands it did.

Base and ordering

Contains #402 (campaign/cubs-iteration, local head 25fe0dbb) by merge. Merge #402 first, then this shows only its own diff. It supersedes the nix-rendered cubsEntries that #402 added to home/tally-uplink.nix — the same 600 CUBS entries, same stdin pointer contract, same cwd, rendered by the checked-in tool instead. pkgs/cubs-iteration and the campaign's STDIN contract are untouched.

Oracle — rc and tails (MEASURED 2026-09-17, on this branch)

$ python3 tools/render-tally-kit.py --check
render-tally-kit --check: home/dot_config/tally/kit.json matches (603 entries)     rc 0
$ test "$(grep -c /nix/store home/dot_config/tally/kit.json)" -eq 0                rc 0
$ nix build --offline --no-link .#checks.x86_64-linux.tally-uplink-topology        rc 0
$ bash tests/tally-uplink/probe-FT-3-kit.sh                                        rc 0
  ok  K0 kit.json is the rendered output and names no store path
  ok  K1 kit = /home/tom/.config/tally/kit.json (runtime-read, git-tracked)
  ok  K2 readKit(pinned lake) over the CHECKOUT file: 603 refs; resolves the
         LOCAL-SMOKE / CUBS-1 / CUBS-200 trios; refuses claude:headless and CUBS-201
  ok  K3 argv[0] set is stable: /etc/profiles/per-user/tom/bin/{tally-local-smoke,cubs-iteration}
  ok  K4 one usage line, execution_id = exec-probe, under env -i
  ok  K5 ExecStart carries --kit /home/tom/.config/tally/… and no --plan
  ok  K6 nix build .#checks.x86_64-linux.tally-uplink-topology
  ENV K7 test-tally-uplink-input.sh red at clause A ONLY (see below)
$ bash tests/tally-uplink/probe-cubs-iteration.sh                                  rc 0  (C1–C11)
$ bash tests/tally-uplink/probe-u-d14-uplink.sh                                    rc 0

Runtime-read proved, no nix invoked. Adding build:HAND-EDITED-DEMO to the committed JSON and re-resolving through the pinned lake's readKit with the store paths already in hand printed REFS=604 and the new argv immediately; render-tally-kit.py --check then went rc 1 on the drift (the intended friction) and rc 0 again after revert.

The reds, verbatim, not laundered

Two oracles are rc 1 on this branch and byte-identically rc 1 on main 202d9c3 in a clean worktree — inherited, not introduced:

$ nix flake check --offline --no-build          # branch: rc 1   main: rc 1
       … while checking the derivation 'checks.x86_64-linux.nas-topology'
       error: assertion '(! ((builtins).elem 8731 (coordinator).networking.firewall.interfaces.wlp192s0.allowedTCPPorts))' failed

An earlier pass died first at the other one, which is an evaluation-order difference, not a second cause:

       … while checking the derivation 'checks.x86_64-linux.nas-personal-tailnet'
       error: path 'pl6rmijq3dkwqw9cf16wzpycsc7gb9m2-86byf0qaz7f0vgj7x4km4zc9q446skd0-source' is not valid

• tests/tally-uplink/test-tally-uplink-input.sh — rc 1, clause A only (that flake check). Every other clause [P]. Same on main.
• tests/tally-uplink/probe-FIX-E12.sh — rc 1, clause S5 only (the same assertion). Same on main. Not fenced: it is rc 1 here exactly as it is rc 1 on main.

probe-FT-3-kit.sh clause K7 carries one narrow [ENV] fence, recorded in DECISIONS.md as "default, unruled" and in DEFERRED.md DF-KIT-3 with both tails: it fires only when the suite's failing set is exactly {A}. A second failing clause is a hard FAIL, so a real regression cannot hide behind it. The alternative — a kit probe that can never be green while an unrelated repo-wide check is red — would retire it as an oracle for every later change.

What is left out (all written down)

• DF-KIT-1 [OPERATOR] — the one coordinator switch that installs the symlink and the two executables. No overnight lane may home-manager switch / nixos-rebuild. Until it lands, services.tally-uplink.kit names a path that does not yet exist and the uplink fails legibly ("cannot read the kit …") rather than running with no argv table. After it, adding a flow is a JSON edit plus a commit and never a switch again.
• DF-KIT-2 [OTHER-REPO] — ruling 4's second step: a kit.d/ directory (needs the lake's --kit <dir>, tally-ts-sdk#135, then a pin bump here), and per-item stdin for eval(...) entries (the same seam; the evaluator cells stay declared no-ops until G7 rules a mechanical verdict).
• DF-KIT-3 — the two inherited flake-check reds above.
• Not touched, by constraint: modules/tally-b.nix, home/seat-feeder.nix, home/dot_local/bin/tally-seat-feeder, tests/tally-b/**, docs/local-ai/tally-b-input.md (D-B owns them); pkgs/cubs-iteration and the campaign's STDIN contract.

Nothing was switched, started, armed or deployed; no live state under ~/.local/state/ was written; no credential was read.

🤖 Generated with Claude Code