---
name: rung
description: Implement one rung of maxon-shv2/PLAN.md end to end — plan, contract, worktree-isolated implementer, independent review, optimization pass, gate battery, cross-target gate (all targets, non-native over ssh), rebase, fast-forward merge, push. Use whenever asked to implement a milestone, phase, or rung of the shv2 plan.
---

# Run one rung of the plan

You are the **coordinator**. You do not write the rung; you own the plan, the contract, the integration,
and the verification. Agents own layers.

> **The two rules that make parallel agents net-positive**
> 1. **One file, one owner, per wave.** Never let two agents hold the same file.
> 2. **The coordinator writes the PLAN and the CONTRACT before the wave launches** — the dialect ops
>    (`MaxonDialect` / `StdDialect` / `TargetDialect` + the `*OpMeta` backing) and a concrete golden-IR
>    example. **Agents coding against a contract that is still moving is the failure mode that makes
>    parallel agents net-negative.**

Integration is inherently serial and is the real limit on wave size: **beyond ~4–5 agents, integration
dominates and adding agents makes it slower.**

## ⛔ HALT AND ASK — the things that are NOT yours to decide

**This skill is built to run unattended, rung after rung (`/loop /rung` — the no-argument form in step 0
exists for exactly that).** That stays safe only if it stops at the right things. **The danger is never
one rung failing — it is a rung landing WRONG and the next rung building on top of it.** *(The scalar
core was **claimed** done at 126/0. Measured against the real corpus it was **48 of 2,746**. A loop would
have marched straight past that and built P1.1 on it.)*

**STOP, report, and ask when:**

- **Any gate is red** — a non-zero build, a non-green suite, exit **101**, or an unjustified **`M`** on a
  pre-existing fragment. **Never turn a gate green by narrowing what it tests.**
- **A reachable DEFECT in this rung's own mechanism — a WRONG ANSWER as much as a leak — even one the
  SUITE is GREEN over.** The leak gate ("no run exits 101") checks the *committed suite*; the defects that
  matter most are the ones a suite run never reaches — a `let m = f()` that exits **101**, or a correct
  program that compiles and returns the wrong number, only when *you* probe it. **Leaks are not ok, and
  neither are wrong answers you own**: a latent/reachable leak, or a construct this rung enables that
  miscompiles, is **FIXED**, or the causing construct is **REJECTED cleanly** (turned into a compile
  error), *before merge* — **NEVER deferred.** A defect lives in "your rung's
  mechanism" if a file you changed, a construct your rung enables, or a spec on your own acceptance path
  can reach it. **Deferring a task-related defect instead of fixing it is a habit this process exists to
  break.** *(Precedent: an owned-String RETURN leaked at P1.2; the option to "defer the leak to P1.4"
  was overruled, the convention pulled forward. At P1.3 Slice 1 a boxed-union RETURN leaked; it was
  rejected (E2015) symmetric with the already-deferred param, not shipped leaking. The suite was green
  over BOTH — only adversarial probing found them.)*
- **A DESIGN RULING is needed** — the corpus contradicts itself, the two references disagree and the plan
  cannot settle it, or the spec is genuinely ambiguous. **You must not guess.** *(`/specs` said both
  "lossy conversions are not allowed" **and** `takeInt(3.7)` ⇒ silently `3` — and the bootstrap passed
  BOTH. Either reading was defensible. It took a user ruling.)*
- **An agent reports the plan was wrong at the code** (step 5) — a wrong plan invalidates the wave, not
  just that agent.
- **A case would have to be disabled that the rung should pass** — the failure mode of this entire
  process. **A green suite that tests nothing is the most expensive lie a test runner can tell.**
- **The rung needs SLICING and the boundary is not obvious.**
- **`PLAN.md`'s next rung is ambiguous** — the no-argument form depends on that ladder being current. Say
  so; do not pick for yourself.

**Everything else runs unattended.** Landing a clean rung — the plan, the wave, the gates, the
**cross-target gate (step 10)**, the merge, **the push (step 11)**, and the `PLAN.md` update (step 12) —
needs no permission. Report what you did;
ask only when the list above fires.

## Deferred work lives in PLAN.md — there is NO separate backlog file

**A finding that genuinely cannot ride this rung becomes a numbered entry on `PLAN.md` — a future rung or
an accepted-debt note — and putting it there is YOUR call, made in the plan, never an agent's mid-rung
escape.** *(There used to be an `OPEN.md` ledger. It was retired 2026-07-21: a standing backlog **invites**
deferral, and nearly every entry in it turned out to be a defect a rung had tripped over and filed instead
of fixing. Its live findings were folded into `PLAN.md` — each into the section it belongs to, so a step's
open work sits WITH the step.)* Agents (implementer, optimizer, reviewer) trip over bugs constantly; that
is the corpus doing its job. **What happens next is the whole game, and the default is FIX, not FILE.**

> **⭐ A STEP WITH RESIDUALS IS NOT COMPLETE.** If a rung generates a residual it does not close, the rung
> is **not done** — however green its suite — and its `PLAN.md` status says so (**◑**, not ✅). *"Core
> landed"* is not *"complete."* The residual lives with the rung (or its workstream), and the rung stays on
> the ladder until it closes. (Accepted debt measured linear-in-practice and a deliberate divergence are
> DECISIONS, not residuals — they do not hold a rung open.)

- **A defect in the rung's own mechanism is FIXED, or cleanly REJECTED, before merge** (see the HALT
  list). It is never deferred. *"I found it while doing something else"* / *"it wasn't what I was asked to
  do"* is **not** a reason to defer — it is the reason the bug is now yours.
- **Only four kinds of finding legitimately become a future rung**, and each has a real reason it cannot
  ride along on this rung. Each has a specific home in `PLAN.md`:
  1. a **bootstrap (`maxon-sharp`) bug** — it needs the full C# suite as its gate (unless this IS a
     bootstrap rung) ⇒ the **"Bootstrap oracle bugs"** list beside PLAN.md's "Traps that survive";
  2. a **distinct feature** that needs its own contract / IR ops / spec-port list ⇒ its own **numbered
     rung on the ladder** (the "Future rungs" list until it is sequenced);
  3. a **correctness-neutral perf debt the optimizer has MEASURED linear-in-practice** — a superlinearity
     you can still *trigger* on a realistic input is fixed, not filed ⇒ the **"Measured debt"** list in
     PLAN.md's Workstream O, WITH the measurement and the re-measure trigger;
  4. a **follow-on slice this rung's plan sanctioned UP FRONT** (e.g. the P1.5 async residuals held for
     B1c) — sanctioned by you, in the plan, before the wave ⇒ a **named residual on the rung / its
     workstream** (and the rung is **not** marked complete while it is open).
- **An agent that trips over anything else STOPS and reports it to you** — the same reflex as a wrong plan
  or an out-of-file-list edit. **You triage: fix-now is the default for anything the rung's own specs
  would exercise.** An agent never writes a deferral into PLAN.md on its own authority.

This is the leak rule (*"leaks are not ok"*) generalized: a leak may not be deferred because it is a
defect the rung owns — and **a wrong answer the rung owns is no different.** The only change from the old
regime is the DESTINATION of a legitimate deferral: a **numbered future rung in PLAN.md**, decided by the
coordinator up front — not a row in a backlog file that anyone could quietly append to.

## 0. Which rung, and orient

**If an argument was given** (`/rung P1.2`, `/rung structs`, `/rung fix the divide-by-zero trap`), that
is the rung. **If NOT, pick the next one from `maxon-shv2/PLAN.md`'s ladder** — it is the source of
truth for what is next, and it is kept current precisely so that the no-argument form works. State which
rung you picked and why **before** doing anything, so the user can redirect you cheaply.

Then read `maxon-shv2/ARCHITECTURE.md` (design pillars, core invariants) and the relevant PLAN.md
sections.

`git fetch origin` and rebase — **optimization work runs in a different repo in parallel** and lands
upstream, so local `main` goes stale between rungs.

## 1. Establish the baseline YOURSELF

Never start from a claimed-green tree. Build and run:

```
mkdir -p temp
./bin/maxon.exe build maxon-shv2
./maxon-shv2/.maxon/maxon-shv2.exe spec-test > temp/shv2-spec.log 2>&1; echo "exit=$?"
grep -n '^FAIL' temp/shv2-spec.log               # expect no hits
```

⚠ **REDIRECT EVERY SUITE RUN TO A FILE — never pipe one through `head`/`tail`/`grep`.** A pipe decides
what to keep *before* you know what failed, so the failure detail is gone by the time you want it and the
only way back is a **second full run**. Redirected, the whole run is on disk the instant it ends: grep it
for the verdicts, then **Read it** at each hit for the full reason (a golden mismatch is a multi-line
diff; a failed compile carries the compiler's whole stderr). The C# runner's marker is `[FAIL]`, shv2's
is a leading `FAIL`. `temp/` is gitignored. This holds for every suite run in every step below.

**Never pass `--workers`** — the default pool is 12 (`SpecWorkerPool.maxon:140`) and that is the only
count this process runs the suite at.

**Kick this off in the BACKGROUND and start step 2 in the same beat.** The reference survey reads source —
it does not need a built compiler — so the baseline build/suite and the survey agents overlap for free.
Just confirm the baseline came back green before you commit to the plan.

## 2. PLAN IT — read BOTH reference compilers before you design anything

**Write a detailed implementation plan BEFORE the contract and before any agent launches, and state it
to the user.** A wrong approach caught here costs a paragraph; caught in the wave it costs the wave.

**Delegate the READING; keep the JUDGMENT.** The survey is big — 191k lines of v1, the bootstrap, ~2,700
spec cases — and doing it inline eats the context you will need for **integration, which is the serial
bottleneck.** So fan out **read-only** survey agents (one per reference, one over `/specs`) and have them
return **FACTS**: file + line ranges, how it works, what it costs, which specs exist and what they cover.
**The decisions stay yours** — take vs leave, the IR ops, the spec port list, the slicing call — because
an agent deep in v1 is the *worst* placed to judge whether shv2 should copy it, and because **you** are
the one who must state this plan to the user and integrate against it. **You own what it says.**

> ### Survey agents run on SONNET. The three rung agents do not.
>
> **Spawn the survey agents as `Explore` with `model: "sonnet"`.** They have no frontmatter file of their
> own, so this line is the only place that fact lives — say it here, not in each brief.
>
> **The reason is the paragraph above, not the price.** This role has already had its judgment removed by
> design: it returns citations, and *you* decide. It is also the one delegation whose output you can
> CHECK — a wrong `file:line` fails the moment the implementer opens the file, and a wrong spec port list
> fails when the specs do not go RED before the wave (step 2's ⭐ section). A cheaper model on a
> judgment-free, verifiable, highest-volume job is the trade this step was built for.
>
> ⚠ **Do NOT extend this to `maxon-rung-implementer`, `maxon-rung-optimizer`, or
> `maxon-rung-reviewer`.** Their model is declared in their own frontmatter and it is not Sonnet —
> **the reviewer least of all.** It runs LAST (step 7), and it is the gate that has actually fired: a
> reachable SEGFAULT at P1.4b Wave 2c, a reachable PANIC at P1.7, a bug an 8th rung running at P1.7a,
> the owned-String leak at P1.2 — every one of them in code an Opus implementer had just called done.
> **A weaker auditor over a stronger author is the one arrangement guaranteed not to catch what the
> author missed.**

> **Two reference compilers already implement what you are about to build. They answer DIFFERENT
> questions, and the plan must consult BOTH.**
>
> | | |
> |---|---|
> | **`maxon-selfhosted` (v1) — the closest CODE** | **191,487 lines of working, debugged Maxon**, same language, same `stdlib/`, closest to shv2's shape. Its bugs are already paid for. ⚠ It does **NOT build** — you can read it, never run it |
> | **`maxon-sharp` (bootstrap) — the RUNNABLE ORACLE** | Different language (C#), but it **builds, runs, and is canonical for `/specs`**. It is the one you can execute on a sample program, `dump_ir` (`dumpStages: true`, csharp-only), and diff behaviour against. **When the question is "what should this actually DO?", the bootstrap answers by RUNNING — v1 can only answer by reading** |
>
> **Where the two disagree, that IS the design question** — resolve it in the plan, not in the wave.
>
> ### ⚠ READ them for the knowledge. Do not BLINDLY COPY them.
>
> Their knowledge — the mechanism's real shape, the edge cases, the traps — is expensive and already
> paid for, and **none of it is worth re-deriving.** But **shv2 is a deliberate rewrite, and a number of
> things it does are BETTER.** Where shv2 departs, **the departure IS the thesis**, and the reference is
> merely how the old one happened to do it. **So the plan must justify BOTH directions:** a divergence
> needs a reason, and **a copy needs one too** — *"it works in v1"* is not one. Two concrete traps:
> **v1 is debugged, not FAST** (its regalloc was ~74% of self-compile; port an algorithm and you port its
> cost curve), and **the bootstrap's code cannot be transliterated** (it borrows and retains-on-store
> where the self-hosted tier consumes — same stdlib, different obligations).

The plan must name, per layer:

- **the v1 file + line ranges** that already implement this, and **the `maxon-sharp` file(s)** — plus,
  for each, **what to TAKE and what to LEAVE, with the reason.** Both are decisions.
  *(⚠ The clearest "leave it": the register allocator ports **LESSONS, not code** — shv2's is a
  deliberately different, linear, SSA-chordal design. Keep v1's correctness traps, not its reactive
  spill loop.)*
- **the shv2 differences — the rewrite's THESIS, which the reference will not have** — block args, not
  phi nodes; parser-minted `ValueId`s, not name strings; **Maxon → Std → Target** (3 tiers, no MIR);
  static ownership from commit 1; the flat `StdOp`; `project.diagnostics` first-class;
  `FileParseArtifact` staging. **A port that reintroduces one of these is a regression, not a port.**
- **the new IR ops needed** → these ARE the contract (step 3).
- **the exclusive file list per agent** → steps 4–5. One file, one owner.
- **the RED baseline for every BUG the rung fixes** — reproduced by you, captured as a failing spec → 5(e).

### ⭐ The SPEC PORT LIST — name the `/specs` files, and what each one unlocks

**The plan MUST list the exact `/specs` files this rung ports into `specs-shv2/`**, and per file, **which
cases the rung UNLOCKS versus which stay `disabled-test:`, and on which later rung.** That list is the
rung's acceptance criteria *and* its deliverable (step 12).

**It is the COORDINATOR's call, not the agent's.** An agent left to choose its own coverage tests what it
remembered — which is exactly how a "finished" scalar core scored **48 of 2,746** (see the closing
section). Survey `/specs` yourself and hand the list down.

- **Port REAL specs, never invented ones.** The corpus is **not** bulk-ported: the rung copies exactly the
  files it needs, **byte-identical**, and the agent's only sanctioned edit is the marker flip → 5(d).
- **The list must go RED before the wave.** Run the candidates against today's compiler and watch them
  fail — that IS the rung's red baseline, and **the rung is DONE when they go green.**
- **Never plan to disable a case the rung should pass.** For each one that stays disabled, name the
  **missing mechanism** and the rung that supplies it.

**A rung may be too big for one wave, and the survey — the length of that spec list included — is what
tells you.** If it is, **SLICE it and say so**: land the cheap, high-unlock, low-risk part first (P1.0d's
front-end slice unlocked 1080 corpus cases with no new IR ops and no codegen), and keep the deep part (a
new register bank for floats) as its own slice. **Each slice runs the full loop below.**

## 3. Write the contract (if the rung needs new IR ops)

Land the dialect ops **before** launching the wave. Hand agents a golden-IR example for a sample
program. If the rung is purely front-end, say so and skip.

## 4. Set up isolation

```
git worktree add ../maxon-<rung> -b <rung>-<slug>
cp -r bin ../maxon-<rung>/bin        # bin/ is GITIGNORED — a worktree has no compiler without this
```

## 5. Implement — `maxon-rung-implementer`

**The brief is the PLAN, sliced per agent.** The reference survey is already done (step 2) — hand each
agent its share of it rather than making it re-derive one.

Every brief MUST carry:
- **(a) the reference targets from the plan** — the specific **v1 file + line numbers** to READ, the
  **`maxon-sharp` file** that shows the behaviour running, **what to TAKE and what to LEAVE**, and the
  **shv2 differences to design to**. Say plainly where the reference is *wrong for shv2*, so the agent
  does not "fix" its own correct code to match it;
- **(b) the exclusive file list**, and the files it must NOT touch;
- **(c) the traps** for that area;
- **(d) its share of the plan's SPEC PORT LIST** — the exact `/specs` files to copy in, and **which cases
  it must unlock vs which stay `disabled-test:`** (on demand — the corpus is **not** bulk-ported). The
  agent executes this list; it does not get to choose its own coverage, and **a case it should pass is
  never disabled**;
- **(e) reproduced evidence** for every bug it is asked to fix, **captured as a failing spec wherever
  one can be** — hand the agent the RED, so its contract is "make this spec green," not "fix, then stash
  to prove you fixed it." Never hand an agent a symptom you have not seen yourself.

**If an agent finds the plan is wrong when it reaches the code, it STOPS and reports** — it does not
silently redesign. The plan is a contract too, and a plan that survives contact only because nobody said
otherwise is worth nothing.

## 6. Optimize — `maxon-rung-optimizer`

Hunts **unscalable (superlinear) algorithms**, read off `scale-test`'s doubling ladder. Commits separately
on the same branch.

**Scope the pass to the rung.** A rung that adds a new pass, a new IR op, or a new collection the compiler
indexes by gets the full superlinear hunt. A pure front-end slice that adds none of those gives the hunt
structurally nothing to find — there `scale-test` is informational, so the optimizer confirms no new
superlinear structure crept in, reads one `scale-test`, and is done. It still runs; it just does not
over-invest where there is nothing to invest in.

## 7. Review — `maxon-rung-reviewer`

Hunts **duplication** first, then latent bugs. Commits separately on the same branch.

> **⚠ Optimize BEFORE you review, and never the other way round.** An optimizer *rewrites code*, so it
> can introduce exactly the duplication the review exists to catch — a fast path forked from a slow one,
> a helper inlined at three call sites. **The duplication-focused review must be the LAST quality gate
> before the merge**, and it reviews the optimizer's diff as well as the implementer's.

**Both are mandatory, and both must be agents that did not write the code** (user directive). The
independence is the point: the P1.0a review found two resource leaks and a cross-process duplicated
selection rule that the author, re-reading their own work, had not seen.

## 8. VERIFY THE AGENT'S CLAIMS YOURSELF

**Do not trust the report.** Re-run the gates in the worktree, and read the crux files. An agent in this
project once left work uncommitted in a worktree based on a stale parent; another claimed a green build
by grepping for a success string.

**This is the ONE authoritative full battery, and it runs here — once.** It is your independent
verification and the pre-merge gate at the same time, not a second run stacked on top of the agents'. The
agents iterate on `--filter` and prove their own slice; the full suite, the `scale-test` read and the leak
gate are yours, run once on the final tree. If it comes back red, an agent goes back — that is the trade
for not running this battery four times.

**There is NO worker-count invariance gate.** `--workers=1` is a **debugging tool**, not a step of this
process — reach for it when you are chasing a suspected nondeterminism or want serial output while reading
a failure, and never as a routine pre-merge pass. It was costing a slow single-threaded suite run on every
rung to re-prove something the runner holds **structurally**: `--workers=1` is the same pool with one worker
in it, not a separate serial branch, and the parent never prints a result as it arrives — it buffers and
reports in fixed order (`maxon-shv2/Testing/SpecWorkerPool.maxon:17-34`). Ordering cannot vary with the pool
size, so the check was re-deriving a known answer at full suite cost. Run the suite parallel and move on.

**Check exit codes. Never grep for success.** Exit **101** = memory leak.

## 9. The gate battery

| Gate | |
|---|---|
| Build | exit 0, zero warnings |
| shv2 suite | all green, **including every pre-existing test** |
| Fragments | `git status --short specs-shv2/fragments/` — **additions only**. An **`M`** is a codegen change: justify or fix. Empty diff after a spec run **proves byte-identical codegen** |
| `scale-test` | ⚠ **NOT A GATE — it is an INSTRUMENT with no verdict.** Run it after any change to a pass, the IR, or a data structure the compiler indexes by, and **read it**: the per-rung memory numbers are exact and bit-for-bit reproducible, so any movement is real. **Explain and attribute what moved**, and record the reason in `docs/optimization-log.md` — the trend table is the deliverable. There is nothing to "pass"; do not chase one, and never touch the instrument to make a number look better |
| If `maxon-sharp/` was touched | C# suite green (**2883+**) **AND codegen neutrality**: `git status --short specs/ specs-shv2/` EMPTY |
| Leak gate | no run exits **101** — **and no reachable leak, including one found only by adversarial PROBING** (a `let m = f()` no committed test runs). A probed/latent leak is FIXED, or the leak-causing construct cleanly REJECTED, before merge — **never deferred as a live leak** (see the HALT list — *"leaks are not ok"*). A green suite is not proof of no leak; it is proof no *committed test* leaks |
| Cross-target | **step 10** — every target the compiler claims, not just this host's. Unreachable ⇒ SKIP (say which); ran-and-failed ⇒ **RED** |

## 10. The CROSS-TARGET gate — every target the compiler claims, once, before it lands

**Step 8's battery proved the rung on exactly ONE target: whichever one this host happens to be.**
Everything else the compiler emits — `arm64-macos`, `arm64-linux`, `x64-linux`, `wasm32-wasi` — stays
unverified until somebody eventually runs it, and *"somebody eventually"* is how **317 stale
`specs/fragments-arm64-macos/` goldens** came to sit on `main` unnoticed, through a run of rungs that
were all green on x64-windows. **A green suite on one target is evidence about one target.**

```
scripts/cross-target-gate.sh --mac-host=user@mac > temp/cross-target.log 2>&1; echo "exit=$?"
tail -20 temp/cross-target.log        # the matrix; the FIVE suites behind it are in the same file
```

Add `--csharp` if the rung touched `maxon-sharp/`. **Redirect it** — this one runs five suites, so a
piped run that goes red costs *minutes* to re-run just to read what a file already had. Here `tail` is
fine for the matrix precisely *because* the file is there for everything behind it.

It builds both compilers, then runs the shv2 suite **per target**, each behind the runner that target
needs — WSL for the Linux ELF, the vendored wasmtime for the wasm component, and `ssh` to a macOS host
for the two arm64 targets (natively for `arm64-macos`, inside OrbStack for `arm64-linux`). It prints a
matrix, one row per target.

**Run it ONCE, here — on the final tree, after review and optimization, before the merge.** It does not
belong on every commit: it is minutes of work whose answer only changes when the rung is finished.
Running it *before* the merge is the point — the branch tip is shipped to the Mac as a **`git bundle`**,
so nothing has to be pushed to be tested and no rung branch leaks onto `origin`.

| | |
|---|---|
| **Unreachable ⇒ SKIP, and the gate still passes** | A laptop asleep in another room must not block a rung. |
| **But a SKIP is reported, never folded into the green** | It means **UNVERIFIED**, not *proven good*. **Name the skipped targets in the rung report** — the one thing worse than not testing arm64 is believing you did. |
| **A target that RUNS and FAILS is RED** | A rung-halting gate — **HALT AND ASK**, exactly like any other red gate. No flag softens it, and you never turn it green by dropping a target. |

⚠ **Golden churn from this gate is real and belongs in the commit** — a non-native fragment that moves
is a codegen change on that target. ⚠ **But a FILTERED run's fragments are not authoritative:** the
runner batches tests into a shared module and slices the IR per test, so literal-pool indices
(`__str_N`, `__static_lit_N`) depend on *which* tests are in the batch. The gate excludes fragments on
filtered runs for exactly this reason — **regenerate goldens only from an unfiltered run.**

## 11. Land it — linear history, then push

```
git fetch origin
git rebase --onto main <old-base> <branch>     # rebase the branch, do NOT merge-commit
git checkout main && git merge --ff-only <branch>
```
`merge.ff=only` is configured, so a non-fast-forward merge **errors** rather than making a merge commit.

**Re-run the suites on the merged tree ONLY if the rebase actually replayed onto an advanced `main`** — i.e.
`origin/main` moved while you worked, so `<old-base>` is behind it, and the merged tree is now code your
step-8 battery never saw. **If `<old-base>` was already `main`** (nothing landed upstream), the fast-forward
leaves main byte-identical to the branch tip you gated in step 8, so the re-run would only re-derive a
known-green tree — skip it. Either way, then **`git push origin main`** — the parallel repo consumes it.
Remove the worktree and delete the branch.

## 12. Close the loop

Update `maxon-shv2/PLAN.md`: a rung's deliverable is the set of `disabled-test:` markers it flipped to
`test:`. **Mark the rung done ONLY if it has no open residuals** — if the plan sanctioned any deferral in
step 2, the rung is **not** complete (status **◑**, not ✅), and each residual must be written into the
appropriate PLAN.md section (a future rung, a workstream residual, or the bootstrap-oracle / "Measured
debt" notes), not left implicit. Record anything durable in memory.

---

## The thing this process exists to catch

shv2's 126 spec tests were written **by shv2, for shv2**. Run against `/specs` — the accumulated
definition of the language, written by people who were not trying to make shv2 look good — the "finished"
scalar core scored **48 of 2,746**. *Not one of the 126 had ever used a parenthesis.*

**So: port real specs, not invented ones. Expect bugs — that is the point. And never let an agent
disable a case it should pass.**