Nishi Debt Program

Eating the ecosystem’s technical debt from the first byte up — compiler first, because everything above it inherits its defects. Every number below is measured from the live hub, not asserted.

Measured 2026-07-25 · hub epoch 1785027879 · warden beat 1785026401 · workstream debt-eater · services 14/14 OK

The ledger, as measured

Law warden — live state and trend

Eleven mechanically-enforced laws, re-measured hourly with zero human involvement. 9/11 currently breaching; enforcement coverage 1000‰. The trend across three consecutive beats is the part that matters:

Read that carefully. Magic-number debt (L001, L006) is falling — it is being actively eaten. Gate-DRY debt (L009) is rising: new gates are being authored that do not inherit the shared verdict library, faster than old ones are migrated. L009 is therefore the highest-leverage target in the ecosystem, and it is now the top-severity row.

Rung closed: the compiler (seq715)

The deepest defect in the tree. obj.fn_field(args) compiled cleanly but emitted the function’s address and discarded the argument list — so the entire OOP vtable pattern was silently broken tree-wide. It failed open.

The filed diagnosis was wrong

The debt row said “restore the parse.c postfix TY_FN branch.” But parse.c:1498 already carries that branch, correctly. The real fault is a parity gap: the self-hosted runtime/nx_parse.nx never had it. A session following the row would have edited an already-correct file and proved nothing. Corrected in the workstream journal.

Four layers were wrong, not one

Regression proof

A compiler change has unbounded blast radius, so the oracle had to be established first: the compiler is deterministic (same input, same compiler, byte-identical output — verified), which makes byte-diffing valid.

Why it went unnoticed for two months

A monitor for exactly this defect existed — bench/nx_fn_ptr_struct_call_smoke.nx, the MONITOR pillar of the 2026-05-19 four-pillar fix. But bench/ is not one of the four directories the build driver probes, so it resolved to SOURCE-NOT-FOUND and was never once runnable.

Two false results caught by controls

1. The first hub probe bound the call with let r = p.f(1,2,3). That form compiles clean on the defective compiler (it silently binds the address) — the probe would have reported a fixed hub that was not fixed. The call must sit in an if condition, where the defect desyncs the parser and the build fails outright. Verified against the banked previous compiler before trusting any hub result.
2. A staged artifact left over from the earlier build read as a valid ELF and nearly passed as proof. A clean rebuild returned BUILD-FAILED with the real error.

Rung closed: a false sev 9

The ecosystem’s single highest-severity row (seq682, seg-store segment amplification, “a plane accumulating unbounded segments until reads OOM the host”) was measured against the live hub rather than inherited:

• The elaragram manifest carries 1 live segment, not the 93 recorded in the row.
• The warden logged L007 segamp = 0 CLEAN for three consecutive hourly beats.

The row was stale. Because nx_seat boot surfaces the top-severity row as every seat’s “eat most important first” pointer, every seat booting into the ecosystem was being aimed at a non-problem. Row eaten with the beat epochs as evidence; sev 9 count is now zero.

Rung closed: the L009 class-eater

L009 (gate-verdict DRY) was the top-severity row and the only one measurably growing. The filed remedy was MIGRATE-ON-TOUCH — hand-migrate ~2553 gate organs. Reading the detector, and then the offender it names, showed that framing was wrong.

What the detector actually counts

lw_gatedry flags any *_gate.nx that contains verdict= or GREEN but none of gv_head / gv_check / gv_verdict. So the question is simply: does this gate inherit the shared verdict library?

The offender is machine-authored

The worst offender the warden names, deployclass_gate.nx, opens with:

// AUTHORED BY nx_compose_builder (X-AUTH-EXT-001 composition shape) from a DATA spec.

nx_compose_builder.nx — 94 lines — stamps its own _p/_pn print helpers and a hand-rolled verdict line into every organ it authors. Every gate it emits is therefore an L009 custom-verdict breach and an L010 helperdup breach by construction.

Fixed at the source, proven end to end

The generator now emits import "nx_gate_verdict.nx" and gv_ctr/gv_head/gv_check/gv_verdict, with no per-organ helpers. It can no longer author a non-DRY gate.

This stops the inflow. The existing backlog still needs migrating — but regenerating the generated share now migrates in bulk rather than one file at a time.

Rung closed: the second compiler defect was already fixed

seq521 (sev 8) held that nx_cc laid out nx_int-aliased struct fields as size 0, collapsing field offsets — with an exposure of 2292 alias field declarations across 337 organs. Re-measured rather than acted on, three ways:

The row’s own stated ROOT FIX — “resolve type aliases to concrete size BEFORE computing field offsets” — is exactly what that pass does. Row eaten. That is the third stale premise this session caught by re-measuring first.

The class had no guard, so one was built

The artifact that proved seq521 only prints. No verdict means no judge and no build driver can ever fail on it — the same shape as the seq715 monitor that sat unreachable in bench/. So the probe became a real gate, shipped complete:

source → /api/build → /api/promote → /api/tools/register → /api/cap/mint → reconcile → run it

6/6 GREEN on the hub. That run matters beyond the gate: when seq521 was eaten, the hub evidence was source plus binary inspection, and was labelled as such. This gate is compiled by the hub compiler and executes on the hub, so the fix is now proven functionally there rather than inferred.

Its teeth are discriminating by construction — every one reads raw i64 offsets off the struct base, which is precisely what collapses under the defect. T4 is a deliberate negative control: pointer-first layout survived even under the bug, so it proves the gate exercises layout rather than passing everything. The fn-pointer half is left to nx_fnptr_call_gate and referenced, not copied.

Rung closed: the ledger can now close its own rows

The stale sev 9 above had a mechanism behind it. The warden autofiles a debt row when a law breaches, but nothing ever closed one when the law went clean. Reading the source showed why, and it was worse than “missing feature”.

Filing was a one-way door

lw_filed_has tested whether a FILED frame existed anywhere in law_filed.jrnl. Two consequences:

• A law that went clean kept its debt row open forever — the stale sev 9.
• Once that row was eaten, the law could never be re-filed on re-breach, because the original FILED frame still matched. Appending a CLOSED frame would not have helped.

Fixed by comparing the last FILED offset against the last CLOSED offset, so FILED → CLOSED → FILED cycles correctly. Position decides rather than count, which also makes it robust to the duplicate frames already in the live journal (L006 is filed twice at one timestamp).

The close handle was being thrown away

nx_debt answers an add with DEBT-ADDED seq=<n>, and nx_debt eats by id only. The warden was capturing that reply and discarding it — so no reconciler could ever have had a handle to close a row. The id is now parsed and stamped as a fifth column, returning -1 when absent so a frame is never stamped with a wrong id (a wrong id would eat another lane’s row). Additive, so existing four-column readers are unaffected.

Grade by layer

The seg-store can give memory back

The cache invalidation leak is closed — and closed in the shape that is sound by construction rather than sound by auditing ~180 callers.

Why the obvious fix was refused

The stale-signature branch re-opened the store and overwrote the cached handle, orphaning an entire mapping set on every edit. Dropping a close into that branch would have been one line — and would have converted a bounded leak into an unbounded use-after-free, because the cached open hands back a raw handle with no refcount and no generation. The sibling who built the cache had already flagged exactly this in their own comment and deliberately deferred it.

Retire, then reap

• Retiring never frees, so it cannot fault. The orphan is merely remembered instead of lost.
• Reclamation is explicit and opt-in — a consumer calls it where it structurally holds no handle, such as the top of a request loop.
• Until a consumer opts in, behaviour is byte-for-byte unchanged, so this cannot regress any caller.
• Overflow fails toward leaking: a full ring drops the pointer rather than freeing it, degrading to exactly today's behaviour, never to a free that might still be in use.

Teeth were added to the sibling's existing cache gate rather than built as a second gate. 8/8 GREEN on the hub.

First consumer wired — and why no number is claimed

The hub gateway now calls the reap at the top of its accept loop, immediately before accepting a connection. That point was chosen because it is structurally quiescent, not because it was convenient: the previous request's frames have all returned, the next has not begun, and both of this daemon's store readers bind their handle to a function-local binding that never escapes into a static, a struct, or a return value. Reaping anywhere a handle is held would be the exact use-after-free the design exists to avoid — so the reason is written into the call site, to stop anyone moving it.

It compiles (416 955 B). In steady state the call returns zero and costs nothing; orphans appear only when a store's manifest changes — a roles or maturity edit — and then it hands back the whole previous mapping set instead of leaking it for the life of the daemon.

How the sev 9 was re-scoped

The remaining sev 9 says the seg-store loads an entire store into anonymous RAM per open and nothing ever frees it — and asks for ss_close to be built. Before building it, the state was re-measured. It already exists, written by a sibling lane, and it is careful work: sizes derived from the handle so no layout change, merged-index interior-slice detection so it cannot free three sub-slices of one mapping as three mappings, frees the reported blob size rather than the padded one so it can never release a neighbouring mapping, pointers nulled as freed, handle released last.

None of it was rebuilt. That is the fifth time this session that measuring before acting avoided duplicating a sibling's work.

One figure in the row is also stale: the headline 6.58 GiB leak on one daemon came from re-opening the store twice per HTTP request, and native-config reads now route through a cached open. That number should not be quoted forward.

What actually remains — and why the obvious fix is a trap

ss_close has zero production call sites: its only two callers are inside a selftest. The live leak now sits in one precise place — the cache's stale-signature branch re-opens the store and overwrites the cached handle without closing the previous one, orphaning an entire mapping set every time that store's manifest changes.

The correct shape is recorded instead: per-slot generation and refcount, acquire/release for readers, and a gate that invalidates while a caller still holds the old handle and asserts no fault — mutation-proven by removing the refcount check and watching it crash.

The deeper lesson: the row was right that this must not be bolted onto the end of another task, but the reason is sharper than "it is big." The dangerous part is not writing ss_close. It is deciding who is allowed to call it.

The compiler is landed

The deepest defect in the program — the one every other layer inherits — is now fixed on the hub, proven by behaviour rather than inspection:

The pipeline was entirely sovereign, with no shell transport: pack on ext4 (never the 9p mount, which is documented to corrupt about 1% of the time) → round-trip verified byte-identical locally before sending → upload over TLS 1.3 with a minted session token → /api/unpack → /api/deploy target=toolchain.

The new compiler immediately found a real leak

The first regression rebuild failed with a message the old compiler could never have produced:

module const used before its declaration: SS_MF_MAGIC
-- it would silently read 0; move the const ABOVE its first reader

In nx_seg_store.nx the writer segs[mc] = SS_MF_MAGIC sat ~29 lines above the constant's declaration. Under the old compiler it stamped 0, while ss_manifest_free compared against the real 0x53534D46. The sentinel could never match, so the stashed manifest buffer was never unmapped — a leak on every manifest read, in the most-shared primitive in the ecosystem, in the same memory class as the open sev 9 that this file's own comments already reference.

Not a compiler regression — the compiler refusing to silently read 0 is what surfaced it. Fixed by hoisting the constant above its first reader; the failing organ then built clean. Blast radius was checked first: the affected free path has exactly one caller.

How the toolchain capability was built

seq891 is closed and live. The supervisor carrying the new toolchain-deploy path was deployed over the sovereign API and came back DEPLOYED-GREEN, with health 14/14 and zero services down before and after. The management log records it plainly:

[hostctl] selfswap: atomic-install new supervisor (sites.elf untouched)
  install rename rc=0
  killed old supervisor procs=2
  new supervisor daemonized (re-exec'd live binary as `supervise`)

Rows eaten: seq891, seq983, seq992, seq998.

The missing piece was a rename bridge

/api/build stages <target>.sov.elf.new, but the deploy plane wants per-target names, and nothing reachable over the API bridged them. That is why the established workaround was to build off-hub and upload — i.e. to leave the sovereign API. So nx_stage_alias was built as the narrowest thing that closes the gap:

• target sanitized to [A-Za-z0-9_], so a separator or .. can never appear;
• source is always <t>.sov.elf.new, destination always <t>.<suffix> — neither is a caller-supplied path;
• suffix is an allowlist of {new, elf.new};
• the source must begin with the ELF magic, so a 0-byte failed build can never be staged for a deploy.

Shipped complete — build, promote, register, cap, reconcile, and a hub selftest at 6/6 GREEN.

Order was the whole safety argument

The seq992 fail-safe guard had to be inside the binary being deployed, and the deploy itself had to be made safe first by staging nx_hostctl.new through the bridge — because deploying with it absent is precisely the brick. The staged binary was proven to carry the guard by grepping its string table for the REFUSED literal before promoting.

What remains for the compiler is now mechanical: place a proven nx_cc_sovereign.elf at buildroot/runtime/nx_cc_sovereign.elf.new, run /api/deploy target=toolchain, and prove the landing by /api/build target=nx_fnptr_min_probe returning BUILT instead of BUILD-FAILED.

How seq891 looked before it landed

The toolchain deploy path is now written and compiling on the hub — cmd_toolchaindeploy and cmd_toolchainrollback, built clean at 195 949 B. They reuse hc_promote_to, the same primitive the torrent and gallery cross-dir promotes already use, which:

• no-ops when nothing is staged (a partial ship can never half-install a toolchain),
• banks the current binary as .prev,
• copies rather than renames — cross-subvolume EXDEV caused a real outage here once, and the code says so,
• chmod 0755, so the promoted compiler stays executable.

That last point is why this is the right mechanism and the tempting /api/unpack shortcut is not: nx_treepack writes 0644 and unlinks, which would strip the executable bit off the live compiler and break every build (seq903).

A second finding shrank the job considerably: a new deploy target needs only a config row, not a mgmt-API rebuild. md_resolve_target reads deploy_targets.conf and the file wins over the compiled-in table — the file’s own header says that is precisely what lets a target be registered without root.

Why it is not flipped yet

/api/build stages <name>.sov.elf.new, but cmd_selfswap renames a hardcoded nx_hostctl.new. There is no API-reachable rename or copy to bridge them: nx_fs_write is text-only, md_promote_staged only maps <n>.new → <n>, /api/promote maps to <t>.elf, and /api/unpack writes only under buildroot/runtime at 0644.

Staging is never-brick; flipping the supervisor without room to verify and roll back is not. The work stops at the staged, reversible boundary by choice.

The most important thing found: the supervisor could brick itself

Pursuing seq891 surfaced a latent sev 8 hazard in the supervisor’s own self-update path. cmd_selfswap does this:

sys_renameat(HC_SELF, HC_SELF_PREV)          // live -> .prev
let rr: i64 = sys_renameat(HC_SELF_NEW, HC_SELF)   // .new -> live
... kill the running supervisor ...
... re-exec HC_SELF ...

There is no existence check on HC_SELF_NEW before the live binary is moved away. If nothing is staged under that name, the live supervisor is moved to .prev, nothing is installed, the running supervisor is killed, and the re-exec targets a path that no longer exists — no supervisor, and it cannot respawn itself.

It is reachable by the documented sequence

/api/build stages <target>.sov.elf.new. The deploy row names nx_hostctl.new. No API-reachable rename bridges them. So the natural, documented API-first sequence — build hostctl, then /api/deploy target=hostctl — runs selfswap with the staged binary absent. Any seat following the standard pattern hits it. It is a plausible real cause of the standing fact that no hostctl deploy has landed since 07-09.

The fix is written into the source: resolve the staged binary before touching the live one, accept the /api/build name as a fallback, otherwise print REFUSED and return non-zero with the live binary untouched. That closes the naming trap permanently as a side effect.

The original framing of seq891

The proven compiler fix cannot be landed API-first. /api/upload gates on md_upload_target_ok, a hardcoded service basename allowlist. buildroot/_offc/nx_cc_sovereign.elf is not in it, and /api/build stages to nishihost/ with no allowlisted route into buildroot/_offc.

The ecosystem can build and deploy every service over its own API, but cannot update the compiler that builds them. Closing it means a never-brick toolchain deploy target mirroring the proven gallery/torrent recipe. That path touches nx_hostctl — the supervisor — which is operator-gated and is itself one of the 29 divergent dual copies, so it is sequenced behind source reconciliation rather than rushed.

RACI

Method and surfaces

Operated API-first over the sovereign control plane — no ssh, scp, curl-to-shell plumbing for ops. Tools driven as MCP tools/call against the sovereign edge with a least-authority scoped capability token.

Reproduce the compiler result

./_offc/nx_sov_build_run.elf nx_fnptr_slot_probe     # RED on a defective compiler
./_offc/nx_sov_build_run.elf nx_fnptr_call_gate      # 13/13 GREEN on a fixed one
bash ./_regress_fnptr.sh                             # 464-file old-vs-new byte diff
bash ./_verify_fnptr.sh                              # arity ladder + self-host fixpoint

Re-measurement caught a near-duplication

The next rung in the plan was seq701 — reconcile the divergent dual-copy sources, starting with nx_hostctl, the supervisor. Earlier in this same session the detector read 44 basenames / 33 divergent, and that reading was used to sequence the whole compiler-landing chain.

Re-measured before touching anything:

nx_hostctl.nx no longer exists as a source file in the shadow tree — it has been renamed .dupe-reconciled, along with three nx_connect_* organs. A sibling lane ate the seq701 hazards while this workstream was running. Acting on the earlier reading would have duplicated or clobbered in-flight work.

Consequence for the compiler chain: seq701 was named as the gate on seq891 precisely because nx_hostctl was divergent. It is not divergent any more, so that gate is cleared. What remains on seq891 is its blast radius, not its ordering.

A second finding fell out of the same re-measurement: nx_dup_source_check’s own self-test is flaky — one run failed T6b (“expected exactly 1 DIVERGENT, got 0”, verdict RED) and three immediately after passed. The only instrument for the whole dual-copy debt class intermittently declares itself broken; fixed-name fixtures in the shared working directory race between concurrent runs. Filed as seq963.

A method note: check the generator before you migrate

Two of the three rungs closed here were mis-filed, and in both cases following the row would have wasted the work:

• seq715 named parse.c, which was already correct. The fault was a parity gap in a different file.
• seq682 was ranked the ecosystem’s worst problem and had already been clean for three hours.
• D001 prescribed hand-migration of thousands of files when a 94-line generator was manufacturing the debt.

The common thread: a debt row records what someone believed at filing time. Re-measure before acting on one. When a count is rising, look for a producer — rising debt is almost never a backlog problem.

What is next, in order

1. seq899 warden→ledger reconciler — makes the ledger a measurement rather than a filing cabinet, so no seat is ever again aimed at a stale row.
2. L009 backlog — inflow is stopped; now regenerate the generated share and migrate the hand-written remainder, gate-still-green.
3. seq701 then seq891 — reconcile the divergent nx_hostctl copies first, then add the never-brick toolchain deploy target on the reconciled file, then land the compiler fix.
4. seq521 — the second compiler defect: nx_int struct fields lay out SIZE-0.
5. seq727 — the quadratic seg-store writer still under the eaten sev 9.