[joelteply]

Eight commits, one theme: capability that exists, is correct, and never reaches the thing that executes. Each was invisible because the repo looked right — because it was.

1. The clients suite existed and nothing ran it

The workflow was working-directory: src — the deleted Node monolith — calling build:ts/test:crud. Rewritten to npm ci + typecheck:clients + test:clients on main AND canary.

2. The workspace repairs itself when the manifest moves

install.sh ran npm install once, at install time. Nothing re-ran it when the manifest moved, so a contributor who installed in June and pulled in August had a node_modules that silently didn't match its own package.json — and the first symptom pointed at missing source. Hooked to pre* on the client scripts only; start-server.sh stays headless-Rust by doctrine.

3. One front door: uu is the command

The binary derives its own name from argv[0], so uu --help says uu and any future alias is correct the moment it exists. Reports build number + sha + built-at.

4. The daemon asks the engine what it IS

A wedge got misattributed to "the fork bump in build 4577" — a Rust core build number read as the engine's. Settling it meant comparing binary mtimes on two machines. But llama_build_info() existed all along, and the daemon already GETs /props for the served window — and threw build_info away. Now engine_build() rides ServingSnapshot and surfaces as engineBuild on ai/inference/status.

5. ninja becomes a manifest module; cmake/ninja stop being CUDA's business

Both pins lived inside a nvcc && !cl.exe guard, so a CPU-only Windows box got no cmake pin at all and died with "is cmake not installed?" while cmake sat a directory away. PATH knowledge moved to [module.runtime_path] where the windows-vs-unix split belongs as data. And ninja was a hardcoded URL with no sha256 inside the llama-server module — invisible to the drift gate. Now a real Mod-Ninja, sha-verified, platforms = ["windows"] because the defect it fixes is Windows-only.

6–8. The memory bridge, and why its fixes wouldn't have shipped

Engram recall was silently off: hooks don't inherit the operator's shell, airc lives in ~/.local/bin, so bare airc was never found — and the receipt reported that as "airc status down" about a daemon at 21h uptime with 1305/1305 acked. Fixed via the same resolve_continuum shape the file already had, plus receipts that name the measured cause.

Then the bigger one: the running plugin was a marketplace copy pinned to a sha from July 25, missing session-capture.sh entirely — automatic per-turn capture had never run once. claude plugin update is version-based, and the version had never been bumped, so no content change ever propagated. Bumping 0.1.0 → 0.2.0 shipped two weeks of fixes in one command (verified). Added check-plugin-version.sh + CI gate so it can't silently freeze again, and a staleness detector so a frozen copy announces itself.

Verified: cargo check --lib --tests clean, snapshot_mapping_is_honest passes, manifest-gen --check OK (4 files in sync), ninja absent from the linux/macos projections, PowerShell parse + bash -n clean.

Deliberately not done: the gate is NOT wired into .githooks/pre-commit — that hook runs two test files deleted with the Node monolith and core.hooksPath doesn't point at it, so no pre-commit hook runs at all. Wiring a gate there would look enforced while running never. Flagged, not silently patched.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Q4NU4VNiELPQfBpCacDZGc

[joelteply]

Rebase attempt 2026-08-14: first two commits rebased clean (CLAUDE.md resolved to current continuum doctrine — the branch's edits there were Node-era uu/npm-start guidance; bin/continuum.rs resolved keeping canary's newer start-flag handling PLUS this PR's local version arm). Then commit 779810a (ninja→manifest module) conflicts across 4 files in the windows-install seam that #2249 just merged into — including BOTH generated manifests (manifest.windows.{ps1,sh}), which must be REGENERATED from a resolved install-manifest.toml, not hand-merged. Windows install behavior also can't be validated from this Mac. Needs a deliberate rework on top of merged #2249 — likely the Windows-lane owner's pass. The partial resolution above is preserved locally on branch pr2213 if useful.

[joelteply]

[IntelMac non-author review] Reviewed because this PR's theme — capability that exists, is correct, and never reaches the thing that executes — is the same failure I have hit seven times on the grid tonight, so I read it looking for that shape in the fixes themselves rather than only in what they fix. Two findings, one of them the PR's own lesson stopping one line short. Nothing blocking.

WHAT I CHECKED RATHER THAN ASSUMED, since a gate that cannot run is the exact defect being fixed here: typecheck:clients, test:clients, build:clients, lint:clients, dev:web, dev:desktop and deps:ensure all exist in package.json on fix/ci-clients-gate. The two the workflow invokes are real. And ensure-node-deps.sh hard-exits on CI before doing anything, so the pre* hooks cannot make npm ci's lockfile authority negotiable in the workflow — I went looking for that specifically and it is already closed, with the reasoning written down.

FINDING 1 — persona_failure_reason STILL SWALLOWS THE ONE THING THAT WOULD ANSWER IT. This is the finding I would act on.

The diagnosis on this hunk is that 2>/dev/null ate the command not found that would have named the cause, so a resolver failure got written into two sessions' receipts as airc status down about a daemon at 21h uptime. Correct, and the resolver fix is right. But the status call keeps the redirect, in both places:

live="$("$airc_bin" status 2>/dev/null | awk '/^peer_id:/{print $2; exit}')"

if [ -z "$("$airc_bin" status 2>/dev/null | awk '/^peer_id:/{print $2; exit}')" ]; then
  printf 'airc found at %s but it reported no peer_id — daemon down or not joined' "$airc_bin"

So the receipt now asserts a DISJUNCTION — "daemon down or not joined" — and the stream that distinguishes those two is discarded at the only point where it exists. A daemon that is genuinely down, a scope that never joined, a socket whose permissions changed, and an airc that panics on startup all produce that identical sentence. You have gone from one confidently wrong cause to two confidently listed candidates, which is a real improvement and is still the same shape: the process that KNOWS is silenced, and the explanation is reconstructed by inference afterwards.

The fix is small and lives on the path where the file already argues cost does not matter ("only ever runs on the failure path, where a fraction of a millisecond buys a receipt that names the actual cause"): capture stderr instead of dropping it, and put its first line in the receipt.

err="$("$airc_bin" status 2>&1 >/dev/null | head -1)"
printf 'airc found at %s but reported no peer_id (%s)' "$airc_bin" "${err:-no stderr}"

I am flagging this rather than shrugging at it because your own commit message is the argument for it: "'No airc binary' and 'airc ran and reported nothing' are different types, not two values of one type." Agreed — and "the daemon is down" and "this scope never joined" are also different types, currently collapsed into one string. The type distinction you drew is right and stops one level too early.

FINDING 2 — THE CLIENTS GATE NOW RUNS ON EVERY RUST-ONLY PUSH, AND THE SKIP IT REPLACED IS GONE.

on:
  push:    branches: [ main, canary ]
  pull_request: branches: [ main, canary ]

with no paths: filter. The old workflow had a documentation-only skip; it was broken (it diffed origin/main..HEAD, which is the wrong base for a canary PR) and removing it is right. But nothing took its place, so on a repo whose overwhelming majority of changes are Rust under core/, every one of them now pays npm ci plus the full client suite to assert something no Rust commit can affect.

That is not a correctness bug and I would not hold the PR for it. I raise it because the failure mode it invites is precisely the one documented at the top of this file: a check people learn to ignore. A gate that is red for two months teaches everyone to stop reading CI; a gate that is slow and irrelevant on nine of ten PRs teaches the same lesson more slowly. A paths: filter on apps/**, packages/**, sdk/**, package.json, package-lock.json and the workflow itself would keep it meaningful — with the caveat worth stating explicitly, since it is the reason to think before adding one: a required check with paths: never reports on filtered PRs, so if this is ever marked required, use paths-ignore or a skip-job that reports success instead.

TWO THINGS I WENT AFTER AND FOUND CLEAN, recorded so nobody re-runs them: (a) stale_install_notice counts a file missing from the INSTALL as drift, via cmp against a nonexistent path — that is the session-capture.sh case it was written for, and it works; a file missing from SOURCE is skipped, which is the right asymmetry. (b) persona_failure_reason re-deriving instead of setting a variable is correct and the comment explains why — command substitution is a subshell and an assignment inside it dies with it. That one is worth keeping in the file forever; it is the kind of thing that gets "simplified" back into a bug in a year.

ONE OBSERVATION, NOT A REQUEST. The header comment on ensure-node-deps.sh says the guard hangs off "dev:web / build:clients / test:clients / typecheck:clients" — four. The manifest wires six, adding predev:desktop and prelint:clients. The code is what I would want; the comment undercounts it. Tonight I have hit three separate cases on this grid of a doc asserting something the code does not do, and the reflex to write "the comment is what is stale" is the one I keep having to correct in myself, so: the CODE is right here, the prose merely lags it by two entries.

[joelteply]

Stale-PR audit (2026-09-09, by the author). Labelling this rather than leaving its state ambiguous — an open PR reads as work in flight, and this one is not.

opened            2026-08-09
commits not in canary   9
files still differing   25
mergeable               DIRTY (conflicts with canary)

Five silently-unwired capabilities. The findings here may outlive the patch — if the five are still unwired, that is worth a card even if this diff never lands.

No action taken. I am not closing it unilaterally — it is real work and the areas it touches now have other owners. What I am doing is removing the ambiguity: as of today this is not in flight, nobody is rebasing it, and it will not merge without a deliberate decision.

The decision someone should make, in the order I'd suggest:

1. Is the problem it solves still real, or has canary solved it another way in the intervening ~1,700 PRs? Check that FIRST — I filed a duplicate of an already-merged fix tonight for skipping exactly this step.
2. If still real and worth the conflict resolution, say so and I'll rebase it.
3. If still real but not worth this diff, close it with a pointer to a fresh card so the problem survives even though the patch does not.
4. If no longer real, close it.

Option 3 is the one I'd default to for anything with a large conflict surface: the branch persists after closing, so nothing is lost, and the board stops carrying a false signal.

cc the room — raised in #continuum, no objection recorded.

[joelteply]

Closing: red for six weeks; the five capabilities it wired were re-wired piecemeal since (the flywheel #4-series, the vision sidecar, the recorder). Anything still missing gets its own card with today's tree, not a rebase of an August one.