Changelog

All notable changes to Gladex are documented here.

Format: `[version] - YYYY-MM-DD — description`

**Which version heading is "newest"? Three readings, three answers — never infer one from another.** The *first* heading below is the app version train: it is what `app/src/go/build.sh` parses, what `const GLADEX_APP_VERSION` must equal, and what `/api/changelog` returns first — that endpoint reads the file in order and does not sort — so it moves only when an entry is written at the top of this file. The *last* heading is the most recently written entry, because everything since the legacy block is appended to the bottom. The *highest* version is what a human reader wants and what the `/changelog` page's "Latest 5 releases" digest leads with, because that digest sorts with `version_compare`. This file is legacy-descending at the top and append-ascending at the bottom, so those three readings are three different numbers today — pick the one your reader needs on purpose.

isolated and validated — an endpoint that CONNECTS but does not greet `220 `

within the socket timeout (timeout / EOF / non-220) is a hard failure, never

an "ok" and never folded into `unreachable`. New per-result `banner_ok` /

`greeting_error` fields, top-level `greeting_failures`, human `[GREETING FAIL]`

marker, and **new exit code 4** with documented precedence `1 > 4 > 3 > 0`.

Motivation: while verifying the operator's "live relay probe after the

:25-greeting fix" item, the gap was visible — the probe only *reported* the

banner, so a greeting regression on ONE of the four default endpoints would

still have exited 0.

servers good / openrelay / silent / bad-greeting on ephemeral ports; live

postfix and the VPS forward path never touched): relay exit 0/1/3 contracts,

`--expect-open`, both greeting-failure shapes → 4 (and NOT folded into

unreachable), the mixed-run regression guard (1 silent among healthy → 4,

previously silently 0), JSON/human/CLI contracts, static never-send-DATA

guard, and **2 mutations** (banner_ok flag defeated / 220 assertion defeated —

both mutants must actually RUN and wrongly exit 0 vs real 4; the first draft's

non-executable mutants exited 126 and faked a pass — caught and fixed before

commit).

re-probe produced the old signature (zero bytes, postfix

`lost connection ... commands=0/0`) and mislead this run initially; root

cause is coreutils `head -c N` blocking in `full_read()` until N bytes —

the SMTP banner is exactly **48 bytes**, after which the server correctly

waits for a client command (no more bytes, no EOF on a live socket), so head

holds the received banner without printing it. Proof: `head -c 48` → instant

print/exit 0, `head -c 60` → rc 124; 40/40 python probes (≤15 ms), `nc`,

bash builtin `read -t`, python child on the bash fd, and `strace` all show

the `220`. Postfix logs `commands=0/0` for ANY client that hangs up without

commands — healthy probes log the same lines, so that signature alone never

proved a stall.

`smtp-relay-probe` → exit 0 — :587/:465 deny `554 5.7.1`, public path

`77.90.15.49:25` denies `454 4.7.1`, loopback `127.0.0.1:25` accepted by

design (mynetworks), all four endpoints `banner_ok=true`, `mailq` empty.

`CN=gladex.de` (Let's Encrypt, notAfter 2026-12-22), postfix + dovecot configs

both point at `/etc/letsencrypt/live/gladex.de`, `grep snakeoil` → 0 hits

(already recorded in STRUCTURE.md/DOMAIN.md — no drift).

source trees and what the envs actually serve, both directions:

`app/src/php ↔ src/php` and `examples/workflows ↔ examples/workflows` per env.

This exact gap had already bitten twice (operator hotfixed runtime `app.php`

needing a back-port; the templates below), but nothing checked it per run.

- Per-file sha256 → states `in_sync` / `differs` / `missing_in_runtime` /

`extra_in_runtime`, with an mtime-based action hint (`runtime newer → commit

runtime copy`, `repo newer → deploy repo copy`).

- Exit contract: `0` in sync, `1` drift, `2` bad args, `3` missing base dir

(a broken layout can never masquerade as "in sync").

- Test hooks `GLADEX_REPO_DIR` / `GLADEX_DEV_ROOT` / `GLADEX_PROD_ROOT` (same

pattern as `system-status`); read-only by construction — no write/exec API.

under `/tmp/opencode`, live trees never touched): both drift directions +

action hints, missing/extra states, workflows tree coverage, `--env` scoping,

JSON contract, `--help`→0 / bad-arg→2 / missing-dir→3, two static read-only

guards, and **one mutation** (sha comparison defeated → tool would exit 0 on

real drift; suite asserts the divergence real=1/mutant=0 — caught).

0.4.11 fix (`fa65307`, top-level step fields → canonical `config`) landed in the

repo only; the env copies (mtime 2026-09-22) were never refreshed, and the env

copy **shadows** the repo in both resolvers (`gladex_templates_dir()` first

candidate, `findTemplatesDir()` binary-relative). Live proof on 2026-09-24:

`gladex workflow validate --from /opt/startup/{prod,dev}/examples/workflows/*.json`

→ **8/8 INVALID** (7 errors on hello-workflow alone: missing names, config

keys), while all 8 repo copies were VALID — i.e. `gladex templates install`

was broken for users on both envs since 0.4.11. Deployed the committed fix

(`rsync -a --delete` repo → dev + prod, data-only, no restart needed — files

are read per request/invocation); re-verified **8/8 GREEN** via the

env-resolved path, `source-sync-check` → `exit 0` (42 files in sync),

`/templates` 200 on dev + prod (incl. public https with `Host: gladex.de`),

gallery suite 27/27.

d'être demonstrated in the same run it shipped. It now guards every future run.

rule from 2026-09-23** ("MX gladex.de is now set — adopt it: verify propagation,

keep serials sane"). The tool's `check_dns` guarded only **A records**, so mail

routing could drift (MX changed/removed at the resolver) or the SOA serial go

insane without any run noticing:

- **`MX:gladex.de`** — must be `10 gladex.de.` on **both** 1.1.1.1 and 8.8.8.8

(propagation check, two resolvers like the manual DOMAIN.md verification).

Wrong or missing answer on either resolver → **error, exit 1** — a wrong MX on

a public resolver is a mail outage, not a warning. Multi-record answers are

collapsed with `paste` so the JSON output stays valid.

- **`SOA:gladex.de`** — serial parsed from both resolvers: must be numeric, >0,

and identical (a split → **warning** "propagation lag", transient by

definition; garbage/missing → **error**). The known `MNAME` placeholder

(`a.misconfigured.dns.server.invalid.` — provider-panel-only fix, open

NEEDS-INVESTOR) is surfaced as a **warning** in the detail —

`serial=2026092305 consistent …; mname=placeholder (NEEDS-INVESTOR open)` — so

the open item is visible on every health run and **clears itself** the moment

the panel value changes.

`dig` stub is **scenario-driven per record type AND per resolver**, so MX/SOA

answers can be pinned per run (live-accurate fixtures verified 2026-09-24);

`GLADEX_DEV_DB`/`GLADEX_PROD_DB` point at absent DBs so the live message DBs are

never read. Covers: MX ok/missing/drifted-on-one-resolver (non-vacuity: the other

resolver correct), serial consistent/split/non-numeric/missing, placeholder↔real

MNAME verdicts, exit-code contract (error→1, warning→0), static wiring guards,

`--help`→0 / bad-arg→2.

true) makes drifted MX report `ok` — caught; removing the serial comparison makes

the "propagation lag" verdict disappear — caught.

REGISTRY): the git/Go checks resolve `REPO_DIR` from the script's own location,

so a **mutated copy run from a sandbox path** had no `.git` beside it and died at

the git check under `set -e` — silent empty output, which would have made mutation

checks pass vacuously (found the hard way: first mutation run returned `''`).

Same hook pattern as `GLADEX_DEV_DB`/`GLADEX_PROD_DB`.

24 → **27** (the `log.gladex.de` check from the Dispatcher shift was never

registered either), DNS line now names `log`, new MX/SOA contracts documented,

`GLADEX_REPO_DIR` hook + new test + its mutations listed.

20/20 — no regression from the new checks or the hook).

`MX:gladex.de ok — 10 gladex.de. on 1.1.1.1+8.8.8.8`;

`SOA:gladex.de warning — serial=2026092305 consistent …; mname=placeholder (NEEDS-INVESTOR open)`.

`/opt/startup/{dev,prod}` consumes `system-status`. No DNS write, no spend.

- **`#msgInput` had no accessible name.** A placeholder is not a label: it vanishes as soon as the user types, and assistive tech does not adopt it as the control's name, so the page's only input announced as an anonymous "edit text". Added a real `<label class="sr-only" for="msgInput">Your message to the Gladex team</label>` immediately before the control.

- **The send button was named only by `title=`** — the weakest naming hook and one browsers expose inconsistently. Now `aria-label="Send message"`, and the arrow SVG is `aria-hidden="true" focusable="false"` so AT reads the button name instead of an unnamed graphic.

- **Every outcome was signalled to pixels or via `alert()`.** A screen-reader user never learned that the thread refreshed, that their message sent, that a send failed, or that polling broke; and `alert()` is modal, focus-stealing and close to unusable on mobile. Replaced with one persistent line under the composer — `<p class="composer-status" id="composerStatus" role="status" aria-live="polite">` — that is *visible* (dim by default, `--red` when `is-error`) and announced politely. All state transitions route through `setStatus()`: empty thread, filtered-to-zero, rendered count + unread, poll failure, send success, HTTP send failure, network send failure. Failure copy now says **"your text is still in the box"** — the draft was always preserved, it just was never told out loud.

- **`.composer textarea:focus { outline: none; border-color: … }` removed the focus ring entirely** and the send button had no explicit indicator either (WCAG 2.4.7). Added `:focus-visible` rules giving both controls a 2px accent outline — declared *after* the `outline:none` rule, because the two selectors have equal specificity and source order is what decides which wins.

- **No-JS fallback unchanged**: still a native `<form>`, `required` textarea and `type="submit"`, so the browser posts it without a line of JS.

- **Structural**: repo == dev == prod byte-identity; label precedes `#msgInput` and carries real text; `.sr-only` utility actually defined (`position:absolute` + `clip-path`); `aria-label`; `aria-hidden` icon; one element carrying `id` + `role="status"` + `aria-live="polite"` together (not three separate greps that a stray attribute could satisfy); `.is-error` styling.

- **Source order**: the `:focus-visible` rule must sit *after* `outline:none` or it is silently overridden — position-compared, plus a regex proving both rules declare a real `outline: 2px` (not an empty rule).

- **JS wiring**: `setStatus()` defined, resolved by id, toggles `.is-error`, wired into all six transitions (≥7 sites), and **zero** `alert(` calls remain in the chat script.

- **Non-vacuity**: three stripper guards (HTML-comment round-trip, CSS/JS-comment round-trip proving real markup survives, and `/* Composer */` present raw / absent after stripping = stripping demonstrably ran) plus controls proving we are looking at the real composer and the no-JS form is intact.

No pixel capture was possible this shift — no desktop browser is attached to the session and the container has no headless browser — so the note is markup-level. Both variants were still extracted and served side by side (`git show 82d7396:app/src/php/app.php` vs `HEAD`, investor block sliced between `?>` and `<?php`, `php -S 127.0.0.1:8099`, `/api/messages` proxied to dev so both show the identical real thread: 17914 B before / 20415 B after).

| | BEFORE (82d7396) | AFTER (this change) |

|---|---|---|

| Textarea name | *(none — placeholder only)* | `<label class="sr-only" for="msgInput">Your message to the Gladex team</label>` |

| Send button name | `title="Send"` | `title="Send"` + `aria-label="Send message"`, SVG `aria-hidden` |

| Status/errors | `alert()` only — nothing on screen, nothing announced | `#composerStatus role="status" aria-live="polite"`, visible dim/red line under the composer |

| Keyboard focus | `outline: none` on the textarea, nothing on the button | 2px `--accent` `:focus-visible` ring on both |

| Visible layout | unchanged | + one ≤1.05rem status line (collapses to 0 while empty) |

- Fix: `$gladexPath = __DIR__ . '/../../bin/gladex';` — env-relative like `app.php`/`init_db.php`/the DB path: repo → `app/bin/gladex`, env → `/opt/startup/<env>/bin/gladex` (all three targets exist and are md5-identical today, so behavior is unchanged *now* and correct on any future divergence).

- **STATIC**: no deployed copy (repo, dev, prod) may contain the quoted literal `'/opt/startup/dev/bin/gladex'`; every copy must carry the `__DIR__`-relative assignment. **Line comments are stripped first**, so neither a stale comment nor a comment-gaming mutant that merely *documents* the fix can satisfy either check.

- **BEHAVIOURAL**: `stats.php` rendered as a script in a synthetic env tree whose `fixture/bin/gladex` is a **stub** printing `{"version":"9.9.9-fixture","commit":"c0ffee1234567890",...}`; the rendered `<td>Go CLI</td>` row must equal `9.9.9-fixture (sha: c0ffee1)`. Non-vacuity guards: the stub provably prints that JSON when executed directly, and live dev's binary provably renders a *different* row (`0.2.0 (sha: d545d47)`) — so "not dev's row" can never pass vacuously.

- Fix: `count_unread()` is issued against **both** `DEV_DB` and `PROD_DB` and the counts are **summed**; detail is now explicit — `0 unread dev=0 prod=0`, `2 unread dev=0 prod=2`.

- **An unreadable/missing DB reports `?` and forces `warning`** instead of being coerced to `0` (the old `|| echo "0"` did exactly that): an unverified mailbox is not an empty one, so it can never render as an all-clear.

- `agent_to_investor` rows are never counted — those are our own outgoing messages, not mail we owe a reply to.

- Healthy-path output is unchanged in meaning (`ok` when both are 0), so no alert noise was introduced.

- Fix: `$dbPath = __DIR__ . '/../../data/messages.db';` — resolved from the file's own location, exactly the idiom `app.php` and `init_db.php` already use. With the deployed layout `/opt/startup/<env>/src/php/`, `../../data` is **that env's** data dir, so the same bytes serve both envs correctly.

- **static**: none of the 3 copies (repo/dev/prod) may contain the hardcoded path, all must carry the `__DIR__` expression — a stale deployed copy fails the suite;

- **behavioural**: renders `stats.php` as a script inside a synthetic env tree (`fixture/src/php/{stats,db}.php` + `fixture/data/messages.db` seeded from the repo's own `schema.sql` with **known 7/3/4 rows**) and asserts the page prints **7/3/4** — i.e. its own DB — plus a **non-vacuity guard** (fixture 7 ≠ live dev 57, so "not reading the hardcoded path" is actually provable).

- pdo_sqlite's implicit default on this box is **60 000 ms** (probed: fresh `PDO('sqlite:…')` reads back `PRAGMA busy_timeout = 60000`), so a contended request could pin a worker for a full minute instead of failing fast — the opposite failure mode from the Go side's 0 ms.

- the Go-style DSN suffix **cannot** be used: pdo_sqlite does not parse query strings, so `sqlite:/path?busy_timeout=5000` opens a file literally named `/path?busy_timeout=5000` (reproduced: the probe created `probe3.db?busy_timeout=5000`). Hence a `PRAGMA`, which is connection-scoped — exactly right, as one PDO is one connection.

- New `app/src/php/db.php`: `gladex_pdo(string $path, bool $wal = false)` sets `ERRMODE_EXCEPTION` + `FETCH_ASSOC`, `PRAGMA busy_timeout = 5000` (`GLADEX_BUSY_TIMEOUT_MS`, mirroring Go's `dbBusyTimeoutMS`), and `journal_mode=WAL` **only** when `$wal` — i.e. exactly where WAL was and was not set before (trust-DB reads and stats stay non-WAL).

- All **6** call sites converted: `app.php` ×4 (`getDb`, `initDbIfNeeded`, trust-DB reads ×2), `stats.php`, `init_db.php`. `new PDO` now appears in **`db.php` only**, and that is asserted.

- readback `busy_timeout = 5000` (not the 60 000 ms default);

- control connection with `busy_timeout=0` fails in **<500 ms** → the lock scenario is genuine and shows what "no waiting" looks like;

- `gladex_pdo` **waits ~5 s then fails** `database is locked` → pins *both* halves of the contract: it blocks (0 ms would fail instantly) **and** the cap is 5 s (a 60 s-timeout connection would still be waiting when the holder releases at 6.5 s and would therefore *succeed* instead of failing);

- recovery: after the holder exits, writes succeed in ~3 ms with exactly the 2 expected rows;

- `journal_mode=WAL` only on request; `new PDO` only in `db.php`.

- New `commands/db.go`: `openDB(path)` wraps `sql.Open` and appends `?_busy_timeout=5000` to the DSN; `dbBusyTimeoutMS = 5000` is the single knob.

- All **26** production `sql.Open("sqlite", dbPath)` call sites across 11 files (`root` ×5, `workflow` ×6, `trust` ×5, `serve` ×2, `mcp_server` ×2, `context_diff`, `context_export`, `context_import`, `status`, `templates`, `doctor`) now call `openDB()`, so no command can silently reopen the pre-fix path. The now-unused `"database/sql"` import was dropped from the 6 files that only needed it for `sql.Open`.

- **Why the DSN and not a `PRAGMA` executed after opening**: `busy_timeout` is a per-connection property and `database/sql` opens a *new* underlying connection whenever the pool grows — a post-open exec would have covered only the first connection and failed exactly where it matters. `modernc.org/sqlite` applies DSN parameters on every `newConn` and strips the query off a plain filename, so no `file:` prefix is needed and the path itself is untouched.

- Deliberately **not** bundled in: a journal-mode change. `serve` already sets `journal_mode=WAL`; converting CLI-only workspaces to WAL is a separate, riskier change and was not part of the queued item.

- `root.go`: new `locateDB() (string, bool)` carrying the parent-walk, plus a shared `msgNoWorkspace` constant (`no gladex workspace found (run 'gladex init' first)`). `findDB()` is now a thin wrapper that keeps its **old fallback return value**, so the ~30 existing `findDB()` callers and every existing test are untouched.

- `status.go`: guards on `locateDB()` *before* opening the DB → `errors.New(msgNoWorkspace)`, exit 1.

- `config.go`: switched its hand-written duplicate of the same sentence to `msgNoWorkspace`, so the hint given by `status` and `config` cannot drift apart.

- `gladex version --json | jq` → empty stdin (JSON on stderr).

- `gladex templates list > file` → **0-byte file**, full table on stderr.

- `gladex context pull X --raw > out` → empty `out`, payload on stderr.

Fix is one line in `commands/root.go` `init()`: `rootCmd.SetOut(os.Stdout)`. It is inherited by every subcommand via cobra's `getOut()` parent walk, and per-command `SetOut(buf)` overrides in the tests still win.

Deliberately still on stderr, verified unchanged by the new test:

- errors (`main.go` → `fmt.Fprintln(os.Stderr, err)`, exit 1),

- `serve`/`mcp` server logging (`log.New(os.Stderr, ...)`),

- `workflow validate` human diagnostics (`fmt.Fprintf(os.Stderr, "INVALID: ...")` bypasses cobra, so it never moved),

- **`mcp --stdio`**, which owns stdout exclusively for JSON-RPC — it returns before any `Print*` call, and its response is byte-identical pre/post fix (diffed old vs new binary).

1. `stats.php` read `$j['git_sha']`, but `gladex version --json` emits `commit`.

2. It also ran the command with `2>/dev/null`, and **cobra's `Command.Print/Println/Printf` write to `OutOrStderr()`** — with `rootCmd.SetOut(...)` never called in production, the JSON never reaches stdout, so `runCmd()` returned `''`, the `if ($goVersion)` block never ran, and the cell was blank. Confirmed against the cobra v1.8.1 source (`command.go:1400 fmt.Fprint(c.OutOrStderr(), ...)`).

Now: capture `2>&1`, trust the value only if `json_decode` yields an array with `version`, render `0.2.0 (sha: fa65307)` (verified live on both envs), and surface anything else as a truncated `error: ...` instead of pretending it is a version. No longer possible for a failed subprocess to be rendered as a valid version.

- Loader `gladex_templates_dir()` mirrors `findTemplatesDir()` in the Go source: env-relative (`/opt/startup/{dev,prod}/examples/workflows`) then the canonical repo copy — one source of truth, no duplicated gallery data.

- Malformed/unnamed JSON files are skipped instead of fataling the public page; a missing gallery renders an honest error card that points at the CLI rather than a stack trace.

- Fully static server-rendered HTML — **no secure-context-only Web APIs** (LAN pages run over plain http; the `crypto.subtle` lesson from 2026-09-20).

- **`workflow create`** checked only step name + type, so `{"type":"shell","config":{}}`, `{"type":"http","config":{}}` and any typo'd key (`"commnad"`) **stored cleanly and only failed at `workflow run`** (or silently did nothing). This is precisely the gap that let a bad definition reach disk; it is what made the 0.4.11 template breakage possible.

- **`templates install`** validated only the step *type*, and auto-generated `step-N` names for unnamed steps — masking the missing-name error that `create` would have raised.

- **`POST /api/workflows`** checked only `len(steps) > 0`, so the API accepted definitions the CLI rejected (and stored step names the runner needs to attribute output/errors).

All four now reject the same bad input at authoring time with the same messages; validation runs *before* any DB write, so a rejected definition is never stored.

- **Fix**: capture now goes to `mktemp /tmp/identity-<id>.out.*` (outside the repo, where models don't browse), cleaned via `trap … EXIT INT TERM`. Non-zero `opencode` rc now also surfaces on stderr. Auto-commit made conditional so a no-op shift can't create empty commits. `IDENTITY_LOG` env override added as a test hook.

- **Second defect caught by the new test (case 6)**: the persona-mapping `case` had no default branch, so an unknown identity died under `set -u` with `PF: variable not set` and exit **2** instead of a clear message + exit 1. Both `case` branches now default to `unknown identity: <id>` / exit 1.

- **Root cause**: the tool was written for the original *dynamic home IP* design (2026-09-20). Topology then changed — WireGuard `AllowedIPs 0.0.0.0/0` sends **all** egress via the VPS, and DNS points `gladex.de` at the **static VPS IP `77.90.15.49`**, never at the home/LTE IP (CGNAT, no public v4).

- **Failure mode**: on any tunnel blip, `get_public_ip()` returns our NAT'd CGNAT egress instead of the VPS → drift reported → cron repointed `gladex.de` at an address that **cannot accept inbound connections**, turning a transient outage into a lasting one with no auto-recovery. It also rewrote only the **apex**, leaving the 6 subdomains split-brain.

- **Fix**: `ip-drift-cron` is now **detect + alert only** — it classifies the egress, logs a diagnosis, appends to `/data/agent-logs/ip-drift-ALERTS.log`, and **never calls any `pdns-api.py` write verb**. A VPS IP change stays an operator/investor decision.

- **Migration**: `UPDATE messages SET ts = strftime('%s', ts)` on non-epoch rows — dev 34 rows, prod 5 rows converted; row counts unchanged (57/22); pre-migration DB backups in `/data/shared/backups/messages-{dev,prod}-preTsFix-20260923-230104.db`.

- **Schema**: default `ts` is now `strftime('%s','now')` (was `datetime('now')`) so new rows can never be datestrings.

- **Query**: `ORDER BY CAST(ts AS INTEGER) ASC, id ASC` (numeric + deterministic tie-break).

- `gladex init` — workspace initialization with SQLite schema (contexts, workflows, trust_scores)

- `gladex context push/pull/list/delete` — CRUD operations on named contexts

- `gladex workflow create/list/show/delete/run/runs` — workflow engine with 5 step types (context, shell, set-var, print, http)

- `gladex trust record/list/get/confidence` — Bayesian trust scoring (accept/reject/partial outcomes)

- `gladex serve` — HTTP context server on configurable port (default :50051)

- `gladex mcp` — MCP-compliant JSON-RPC 2.0 server with 7 tools

- `gladex version` — build metadata (git SHA, build time via ldflags)

- JSON Schema validation for tool inputs

- Sliding-window rate limiting (100 req/60s per IP)

- Panic recovery (server never crashes)

- Request logging middleware

- Stress tested: 100/100 sequential tool calls, 0 errors

- Sidebar panel with context display

- 4 commands: context sync, context show, workflow run, status

- Auto-sync on file save (configurable)

- Status bar integration

- `domain-availability-check` — RDAP/DNS domain availability

- `budget-show` — parse/display BUDGET.md

- `dns-verify` — query DNS records via dig

- `healthcheck` — check dev/prod healthz endpoints

- `promote-dev-to-prod` — copy code to prod + restart

- `ip-drift-cron` — weekly drift detection + alert (detect only, never writes DNS)

Parked at the bottom of an otherwise newest-first file on purpose. Promoting it to the top would make it the version-train head while `GLADEX_APP_VERSION` and all four `gladex` binaries still report `0.4.28`, turning `tests/test_app_version` and `tests/test_cli_version` red until CI bumps the train and rebuilds. That bump is main-loop work and is not part of this fix.

Parked at the bottom of an otherwise newest-first file on purpose. Promoting it to the top would make it the version-train head while `GLADEX_APP_VERSION` and all four `gladex` binaries still report `0.4.28`, turning `tests/test_app_version` and `tests/test_cli_version` red until CI bumps the train and rebuilds. That bump is main-loop work and is not part of this fix.

Parked at the bottom of an otherwise newest-first file on purpose. Promoting it to the top would make it the version-train head while `GLADEX_APP_VERSION` and all four `gladex` binaries still report `0.4.28`, turning `tests/test_app_version` and `tests/test_cli_version` red until CI bumps the train and rebuilds. That bump is main-loop work and is not part of this fix.

Seventh run of the "documented contract not honored, zero tests" class — but this tool is the first one in the series whose **verdict** (`drift: true`, exit 1) is written to `/data/agent-logs/ip-drift-ALERTS.log` by a weekly cron, and it produced that verdict from data nobody validated. All five defects were captured against the pre-fix file `1f85703df809bafecbd56ab390a79fd3` (md5 of `git show HEAD:tools/ip-drift-check`; transcript `/tmp/opencode/ipdrift/pre-fix.log`):

**Evidence rule now enforced in code**: a drift verdict needs **two validated IPv4 literals** — the egress answer and a `dig` answer line. Unvalidated data is an error, never a vote.

Parked at the bottom of an otherwise newest-first file on purpose. Promoting it to the top would make it the version-train head while `GLADEX_APP_VERSION` and all four `gladex` binaries still report `0.4.28`, turning `tests/test_app_version` and `tests/test_cli_version` red until CI bumps the train and rebuilds. That bump is main-loop work and is not part of this fix.

Eighth run of the "documented contract not honored, zero tests" class, and the first where the *wrapper* — not the checker — was the blind spot. `tests/test_ip_drift_check.sh` had just hardened the verdict, but `tools/ip-drift-cron`, whose whole purpose is to turn that verdict into an alert in `/data/agent-logs/ip-drift-ALERTS.log` (the only escalation channel an investor/operator ever reads), had **no behavioural suite at all** — only the 16-assertion static guard `test_ip_drift_safety.php`, which checks that it never writes DNS. Pre-fix evidence captured this run against `git show HEAD:tools/ip-drift-cron` (replay: **54 passed / 32 failed**):

**Contract now**: exit `0` stays quiet (a healthy check must not noise up the alert file); exit `1` writes `DRIFT …` as before; **every other outcome writes exactly one `CHECK-ERROR <domain>: code=<error_code> detail=<error> checker_exit=<n>` line** and exits 3, with a diagnosis + action keyed on `error_code` (`no_a_records` → *the record is gone, inspect with `pdns-api.py records`* · `dns_lookup_failed` → *check dig/resolver/tunnel before trusting ANY verdict* · `public_ip_unavailable` → *no verdict can be trusted* · `unknown` → *run the checker by hand*), and the same `DNS NOT MODIFIED (deliberate)` / `NEEDS-INVESTOR` escalation lines as the drift path. Non-JSON output, empty output and a missing binary all degrade to `code=unknown` **with the checker's exit code preserved** instead of vanishing. A second positional argument is now an argument error (exit 2) rather than being silently ignored. The egress classifier receives its argument through the environment instead of Python string interpolation, and `--help` documents the alert behaviour and the hooks.

Parked at the bottom of an otherwise newest-first file on purpose. Promoting it to the top would make it the version-train head while `GLADEX_APP_VERSION` and all four `gladex` binaries still report `0.4.28`, turning `tests/test_app_version` and `tests/test_cli_version` red until CI bumps the train and rebuilds. That bump is main-loop work and is not part of this fix.

Ninth run of the "documented contract not honored, zero tests" class, and the first where the blind spot was **inside the tool that exists to see what a commit actually contains**. `repo-lint` lints COMMITTED blobs — it is the only check here that is not hostage to a dirty worktree — but for Go it ran `gofmt`, which takes **stdin with no file args and exits 0 for anything parseable**. A file that parses but does not build therefore passed every lint in this repo. Pre-fix evidence, captured this run against `git show HEAD:tools/repo-lint`:

```

cmd/gladex/commands/status_test.go:5:2: package json is not in std (...)

FAIL github.com/gladex/gladex/cmd/gladex/commands [setup failed]

```

**Contract now**: when the committed tree contains a `go.mod`, the Go module is **rebuilt from git blobs at the pinned `--sha` into a temp dir outside the repo** (the worktree is never read — same guarantee the per-file lints give) and compiled with `go test -exec=true ./... -run '^$' -count=1`: every test binary is **built and linked, then handed to `/bin/true`**, so nothing executes — a compile, not a test run (a future `TestMain` cannot slow it down or touch the network). Attribution is deliberately narrow: a go output line is a `failure` **only if it names a file this commit actually ships** (`.go`/`.mod`/`.sum`, resolved relative to the materialized module root, absolute temp paths stripped). Anything else — a missing `go` binary, a wiped `/tmp` module cache after a container restart, a toolchain that cannot be fetched with `GOPROXY=off`, a timeout — is **`error` → exit 3, "cannot verify"**: never a verdict on a file we did not write, and never a silent pass. A `.go` tree with no `go.mod` is reported as `no_go_module`, not guessed at. Exit codes stay `0/1/2/3`; `1` now means "does not parse **or does not compile**". The gate always runs `GOPROXY=off`, so the check can never reach the network, and `--go-timeout` (default 120s, matching `system-status`'s bound) bounds a hang without crying wolf on a 1-2s compile.

Parked at the bottom of an otherwise newest-first file on purpose. Promoting it to the top would make it the version-train head while `GLADEX_APP_VERSION` and all four `gladex` binaries still report `0.4.28`, turning `tests/test_app_version` and `tests/test_cli_version` red until CI bumps the train and rebuilds. That bump is main-loop work and is not part of this fix.

Tenth run of the "documented contract not honored, zero tests" class. This is the check that **runs** the Go tests — the complement of `[0.4.37]`, which compiles the COMMIT — and its verdict was a grep:

TESTS=$(cd ... && timeout 120 go test ./cmd/gladex/commands/... 2>&1 | tail -1 || echo "FAIL")
if echo "$TESTS" | grep -q "^ok"; then ok "passing"; else error "failing"; fi

Pre-fix evidence, all captured this run against `git show 6f2feb8:tools/system-status` (md5 `cda20f035bf320a22ecb2dc118738a5c`):

**Contract now — THE VERDICT COMES FROM THE EXIT CODE**, and the pattern is `./...` (the whole module; `go list ./...` resolves to exactly 2 packages here):

| exit | extra evidence | verdict |

|---|---|---|

| `0` | — | `ok` `passing` |

| `1` | a package-level `FAIL\t<pkg>` line | `error` `failing: <pkg>` |

| `124`/`137` | killed by our own budget | `error` `timed out after Ns - no verdict on the tests` |

| `1` | **no** such line | `warning` `cannot verify: go exited 1 without running a test package` |

| anything else | — | `warning` `cannot verify: go test exit N` |

| — | no `go.mod` / `go` not found | `warning` `cannot verify: ...` |

`error` still increments `ERRORS` (hung and broken suites fail the tool, unchanged exit `0/1/2`); a `warning` is loud in the detail but never fails the tool — **"we could not check" must not become "your code is broken", and must never become a pass.** The package name in a `failing:` detail is filtered to `[A-Za-z0-9._/-]` and capped at 80 chars, so test output can never break the JSON.

**Provenance is now stated on every verdict**: `passing (worktree)`, or `passing (worktree, N uncommitted Go file(s))`. This row measures the WORKTREE; the COMMIT is `repo-lint`'s job (`go_compile` of the blobs at `--sha`). Without the label a green `go-tests` row is easy to read as "HEAD is green" — precisely the disagreement between the two tools that `[0.4.37]` exists to prevent.

Parked at the bottom of an otherwise newest-first file on purpose. Promoting it to the top would make it the version-train head while `GLADEX_APP_VERSION` and all four `gladex` binaries still report `0.4.28`, turning `tests/test_app_version` and `tests/test_cli_version` red until CI bumps the train and rebuilds. That bump is main-loop work and is not part of this fix.

Eleventh run of the "documented contract not honored, zero tests" class, and the one `[0.4.37]` and `[0.4.38]` both queued verbatim — *"the dashboard does not yet carry the commit-side `go_compile` verdict as well — that 'assert both' step is queued, not done"*.

The two tools deliberately cover **different trees**: `repo-lint` rebuilds the COMMITTED module from git blobs at `--sha` (its `go_compile` gate), `system-status` runs `go test ./...` on the **worktree** and labels the verdict `(worktree)` accordingly. The label was the only protection: nothing on the dashboard reported the commit at all, so "is HEAD good?" required running a second tool and comparing two outputs by hand — and the split was invisible by construction. Pre-fix evidence, all captured this run:

Parked at the bottom of an otherwise newest-first file on purpose. Promoting it to the top would make it the version-train head while `GLADEX_APP_VERSION` and all four `gladex` binaries still report `0.4.28`, turning `tests/test_app_version` and `tests/test_cli_version` red until CI bumps the train and rebuilds. That bump is main-loop work and is not part of this fix.

Twelfth run of the "documented contract not honored, zero tests" class, and the queued next-candidate from `[0.4.39]` verbatim — *"`promote-dev-to-prod` ships REPO → prod behind **two** gates (reviewer verdict, dev-sync) and **neither asks whether the COMMIT builds or parses** — a broken HEAD can be promoted while `system-status` is already red for it."*

Both existing gates check *process*, not *code*: the reviewer gate proves a human/agent wrote `VERDICT: APPROVE` for the newest tree, and the dev-sync gate proves the dev env has nothing the repo lacks. Neither ever reads a file's contents, so **`395b9b5` — a commit whose Go test package could not be built, and which sat in `main` ~1h while every dashboard row was green — could have been promoted to prod without a single tool objecting**. The defect class `[0.4.37]` fixed in the *linter* and `[0.4.38]`/`[0.4.39]` fixed in the *dashboard* was still completely open at the one place that actually *ships* code.

Parked at the bottom of an otherwise newest-first file on purpose. Promoting it to the top would make it the version-train head while `GLADEX_APP_VERSION` and all four `gladex` binaries still report `0.4.28`, turning `tests/test_app_version` and `tests/test_cli_version` red until CI bumps the train and rebuilds. That bump is main-loop work and is not part of this fix.

Parked at the bottom of an otherwise newest-first file on purpose. Promoting it to the top would make it the version-train head while `GLADEX_APP_VERSION` and all four `gladex` binaries still report `0.4.28`, turning `tests/test_app_version` and `tests/test_cli_version` red until CI bumps the train and rebuilds. That bump is main-loop work and is not part of this fix.

date and the guard's "which child" gap are no longer queued here; `[0.4.43]`

carries the queue that replaced them.

Parked at the bottom of an otherwise newest-first file on purpose. Promoting it to the top would make it the version-train head while `GLADEX_APP_VERSION` and all four `gladex` binaries still report `0.4.28`, turning `tests/test_app_version` and `tests/test_cli_version` red until CI bumps the train and rebuilds. That bump is main-loop work and is not part of this fix.

Parked at the bottom of an otherwise newest-first file on purpose. Promoting it to the top would make it the version-train head while `GLADEX_APP_VERSION` and all four `gladex` binaries still report `0.4.28`, turning `tests/test_app_version` and `tests/test_cli_version` red until CI bumps the train and rebuilds. That bump is main-loop work and is not part of this fix.

Parked at the bottom of an otherwise newest-first file on purpose. Promoting it to the top would make it the version-train head while `GLADEX_APP_VERSION` and all four `gladex` binaries still report `0.4.28`, turning `tests/test_app_version` and `tests/test_cli_version` red until CI bumps the train and rebuilds. That bump is main-loop work and is not part of this fix.

Parked at the bottom of an otherwise newest-first file on purpose. Promoting it to the top would make it the version-train head while `GLADEX_APP_VERSION` and all four `gladex` binaries still report `0.4.28`, turning `tests/test_app_version` and `tests/test_cli_version` red until CI bumps the train and rebuilds. That bump is main-loop work and is not part of this fix.

Parked at the bottom of an otherwise newest-first file on purpose. Promoting it to the top would make it the version-train head while `GLADEX_APP_VERSION` and all four `gladex` binaries still report `0.4.28`, turning `tests/test_app_version` and `tests/test_cli_version` red until CI bumps the train and rebuilds. That bump is main-loop work and is not part of this fix.

Parked at the bottom of an otherwise newest-first file on purpose. Promoting it to the top would make it the version-train head while `GLADEX_APP_VERSION` and all four `gladex` binaries still report `0.4.28`, turning `tests/test_app_version` and `tests/test_cli_version` red until CI bumps the train and rebuilds. That bump is main-loop work and is not part of this fix.

`promote-dev-to-prod` has three gates — `verdict` (need-signal), `dev-sync` (repo == dev), `commit-lint` (repo vs `HEAD:`) — and then promotes. Nothing asked the last question: **once step 3 has copied the worktree into the dev sandbox, is what we are about to ship clean where it ships from?**

The three gates cannot see it, each for a structural reason:

So the gap was real and self-concealing: commit-lint and dev-sync both pass on a worktree whose `app/src/php` — the only tree `build-release` ships — is full of uncommitted edits, and the promote sails through. [0.4.40]'s ladder said it plainly: "the last two gates may be read as 'the code is fine' — step 3's `rsync --delete` … nothing asserts the worktree it copied was clean". Every promote suite sandbox was `mktemp -d`, i.e. **not a git repo at all**, so no test could have caught it: `git status` there exits 128 ("not a git repository"), which the naive implementation would read as *failure* and every sandbox as red.

`check_ship_tree_gate()` runs **after** step 3 has synced dev (call site `0d`), scoped to `PROMOTED_TREES` (`app/src/php`, `examples/workflows`) via one `git status --porcelain --ignored -- <trees>`:

Exit **8** (distinct from 4 commit-lint, 5 verdict, 6 dev-sync, 7 dead-letter) with its own `ship_tree_*` hints. `system-status` now expects **four** gates: its `promote-gates` row, its `ready` line and its `--help` contract all name `ship-tree`, and the ready-string needle `dev-sync OK | commit-lint OK` gained ` | ship-tree OK`. The `[0.4.40]` ladder's last item ("assert the worktree it copied was clean … none of it is asserted") is the item this closes.

Assertions first, against the `HEAD:` blobs kept at `/tmp/opencode/pre-fix/{promote-dev-to-prod,system-status}` (full tree in `/tmp/opencode/pre-fix-repo`), so the gap is reproducible rather than asserted after the fact:

Ten new mutations, each planted on a copy and each caught: M14 gate result ignored · M15 refusal recorded as pass · M16 failed `git status` read as a match · M17 `--ignored` dropped · M18 pathspec dropped · M19 `if not paths` → always clean · M20 `--force` bypass removed · M30 `ship-tree` dropped from `EXPECTED` · M31 ready line drops the 4th gate · (gate suite) Y-scope.

All promote-suite sandboxes are now **real git repos** (`git_init_sandbox`), because a gate that shells out to `git status` cannot be tested in a directory that is not one — the exact blind spot that hid the defect.

Parked at the bottom of an otherwise newest-first file on purpose. Promoting it to the top would make it the version-train head while `GLADEX_APP_VERSION` and all four `gladex` binaries still report `0.4.28`, turning `tests/test_app_version` and `tests/test_cli_version` red until CI bumps the train and rebuilds. That bump is main-loop work and is not part of this fix.

---

`[0.4.48]` added the fourth gate and `[0.4.46]` taught the dashboard row to re-ask the second gate's question itself — and then stopped one gate short. `[0.4.48]`'s own queue said it out loud: *"The divergence guard compares only `gates[1].child` (dev-sync) — extending it to `gates[3].child` (ship-tree) would apply `[0.4.46]`'s principle to the new gate."*

So `ship-tree` asked *do the trees step 3 rsyncs still equal HEAD?* exactly **once** per run. The gate answered, `gates[3].child` dutifully recorded which `git` answered, and no reader existed — the identical shape that made the first two pairs worth a guard each:

The row now asks the gate's own question itself, seconds apart, on the same repo: `git -C <repo> status --porcelain --ignored -- <PROMOTED_TREES>` — the gate's argv, not a re-derivation of it.

`promote-dev-to-prod` itself is unchanged — the third pair is evidence *inside* the existing `promote-gates` row, so the check count stays 29 and the gate's own semantics are untouched.

Assertions first, against the kept blob `/tmp/opencode/pre-fix/system-status` (byte-identical to `HEAD:tools/system-status`, md5 `a49c6466c15605554cd6bd756d10c8c1`), so the gap is replayable rather than asserted after the fact:

New sections **14f** (agreement both ways, both contradictions, four non-claim states), **14g** (same/different/unrecorded child evidence) and **15c** (argv contract + cross-file `PROMOTED_TREES` pin); git stub trio `git-wrap` (logs argv, `exec`s real git — the claim states must come from real `git status` semantics), `git-fail` (exit 128), `git-hang`.

Eight new mutations, each planted on a copy, precondition-asserted exactly once, `bash -n`-validated: M32 the guard block dropped (the mutant *ships past a dirty tree*) · M33 the hand-off dropped · M34 an unread sighting read as `dirty` · M35 the mirror (an unread sighting read as `clean`) · M36 the gate's `child` never read · M37 `-C "$REPO_DIR"` dropped (two halves, different repos) · M38 the mirror narrowed to one tree · **M39 `SHIP_RC` defaulted to `0`** — a child that never ran read as a clean sighting. **All 8 caught.**

Parked at the bottom of an otherwise newest-first file on purpose. Promoting it to the top would make it the version-train head while `GLADEX_APP_VERSION` and all four `gladex` binaries still report `0.4.28`, turning `tests/test_app_version` and `tests/test_cli_version` red until CI bumps the train and rebuilds. That bump is main-loop work and is not part of this fix.

Multiple identities append to this file, and the number in the heading is the only thing that tells two entries apart — `test_changelog_api` section 3 keys its own `$byVer` map on it. At 11:07 commit `6c98b18` published `## [0.4.49]` (the ship-tree divergence guard); at 13:17 commit `6e61874` appended a second `## [0.4.49]` (the QA pass) without seeing the first. Consequences, all silent:

- the real file: has `##` headings, **every `##` heading parses as an entry** (a malformed heading is skipped by the API's regex, i.e. it would be invisible to this very check), **no duplicated token**, `heading count == API entry count`, and `count($byVer) == count($actual)` — the exact collapse the duplicate caused;

- three synthetic fixtures exercise the detectors, so none of the above can pass vacuously: a duplicated-version fixture must be flagged, a clean two-entry fixture must stay quiet, and an undated `## [1.2.5]` heading must be reported unparseable rather than counted as an entry.

Parked at the bottom of an otherwise newest-first file on purpose: promoting it to the top would make it the version-train head while `GLADEX_APP_VERSION` and all four `gladex` binaries still report `0.4.28`, turning `tests/test_app_version` and `tests/test_cli_version` red until CI bumps the train. That bump is main-loop work and is not part of this fix.

`[0.4.51]` found the duplicate and renumbered it, then noted its own limitation verbatim: *"the uniqueness guard is a test, not a gate — nothing stops another identity appending a duplicate **today**"*. That is the same shape as the twenty defects before it — two readings of one fact with no arbiter — with the arbiter missing entirely on one side: `test_changelog_api` section 7 could *detect* a duplicate when it ran, but the commit path (`repo-lint` → promote's `commit-lint` gate) read nothing at all. Several identities append to this file, every one of them mid-flight while others commit, so a remembered rule cannot hold; and the harm is structural, not cosmetic — `version` is the key `/api/changelog` hands consumers, so a repeat makes one entry unreachable BY VERSION with the victim decided by file order.

Parked at the bottom of an otherwise newest-first file on purpose: promoting it to the top would make it the version-train head while `GLADEX_APP_VERSION` and all four `gladex` binaries still report `0.4.28`, turning `tests/test_app_version` and `tests/test_cli_version` red until CI bumps the train. That bump is main-loop work and is not part of this fix.

`[0.4.52]` widened `repo-lint`'s exit-1 contract to cover a repeated CHANGELOG version token, then queued its own consequence verbatim: *"promote's `commit-lint` detail still says 'committed file(s) fail to parse or compile: …', which a `lang: changelog` failure now contradicts (a duplicate is neither)."* Reproduced **before touching anything**, end to end with the real tools — a throwaway git repo carrying the same version token twice under `CHANGELOG.md`:

LINT REFUSED (exit 7): committed file(s) fail to parse or compile: CHANGELOG.md — fix the commit before promoting (prod is never shipped a red HEAD)

`CHANGELOG.md` is Markdown: nothing parses it, nothing compiles it. An operator reading that line hunts for a syntax error that does not exist, while the real reason `repo-lint` refused — `duplicate version 1.0.0 (first at line 3)` — sits in the child's own `failures[0].message`, unread. Two further copies of the same claim lived inside the tool (`--help`'s module docstring and its epilog: `7 … (HEAD does not parse/compile)`) and twice in REGISTRY, so the exit-7 *contract* disagreed with `repo-lint`'s own EPILOG, which has listed the changelog rule under exit 1 since `[0.4.52]`.

**Correction to the queue note**: the wording was *not* pinned by the two suites named there. `test_promote_lint_gate` pins the failing **path** (`app/src/php/b.php`), and `test_system_status_promote_gates` carries the sentence only as **fixture data** for the dashboard row — neither asserts the wording. Only `--help`'s exit-7 line was asserted, and only its prefix `7 commit lint gate refused`. That is why this landed as one coherent change instead of the contract-widening the note anticipated.

| what `failures[].lang` says | detail |

|---|---|

| every value in `{php, bash, python, json, go, go-compile}` | `committed file(s) fail to parse or compile: <paths>` — **unchanged**: the specific diagnosis is the most useful one *when it is true* |

| any other rule (today `changelog`) | `committed file(s) fail lint (<kinds>): <paths>` + `[<repo-lint message>]` **only when there is exactly one failure** |

| nothing to point at (exit 1 with no `failures[]`) | `committed file(s) fail lint: <paths>` — no cause claimed |

Parked at the bottom of an otherwise newest-first file on purpose: promoting it to the top would make it the version-train head while `GLADEX_APP_VERSION` and all four `gladex` binaries still report `0.4.28`, turning `tests/test_app_version` and `tests/test_cli_version` red until CI bumps the train. That bump is main-loop work and is not part of this fix.

Queue item **(1)** from `[0.4.53]`, verbatim: *"`_lint_failure_verdict` quotes repo-lint's message only for a **single** failure, so the common multi-failure refusal still names *what* is wrong but not *why* per file — one message per failure (or a `; `-joined list) would fix that, still single-line."* Harm, reproduced live before touching anything: a commit carrying a PHP parse error **and** a repeated `## [1.0.0]` made the real `repo-lint` report two `failures[]`, each with its own message, and the tool printed

`LINT REFUSED (exit 7): committed file(s) fail lint (changelog, php): app/src/php/bad.php, CHANGELOG.md` — every file named, **no reason for any of them**. The child had already said why twice; the parent threw both away. Two failures at once is the ordinary case (a broken file and a stale changelog land in the same commit), not an edge case, so the refusal an operator acts on was routinely silent.

The old rule was not arbitrary: *one message cannot honestly describe two failures*, and a bare reason dropped after a list of several files could be read as blaming the wrong file. **Choice made, not asked**: keep that guarantee by **attribution** instead of by silence — quote a `path: message` pair per failure, so no message can ever stand for two. Nothing was slipped in: this is the queued item, landed as its own step with its own tests.

`_lint_failure_messages(failures)` returns `"; "`-joined **`path: message`** pairs — **one format for a single failure and for many alike** (the single-failure case gained its `path:` prefix too, so there is no branch that quotes an unattributed reason):

Two failures in one commit: **before** → `LINT REFUSED (exit 7): committed file(s) fail lint (changelog, php): app/src/php/bad.php, CHANGELOG.md — fix the commit before promoting (prod is never shipped a red HEAD)`; **after** → `… CHANGELOG.md [app/src/php/bad.php: Errors parsing Standard input code | PHP Parse error: syntax error, unexpected token "{" … on line 2; CHANGELOG.md: duplicate version 1.0.0 (first at line 3)]` — each reason next to its own file, and `grep -c 'LINT REFUSED'` over the same run is **1**, so the detail is still one line. `tools/system-status --format human` unchanged: `promote-gates … dev-sync OK | commit-lint OK | ship-tree OK (commit 1bc106c)` under **ALL SYSTEMS HEALTHY**, exit 0.

**35 suites, 2682 assertions, 0 failed** — 19 shell = **1863** (**+30** over 1833, exactly `test_promote_lint_gate` 99 → 129, no other suite moved), 16 PHP = **819**, unmoved. Doc/contract suites after the appends: `test_repo_lint` **156/0**, `test_changelog_api` **86/0**, `test_app_version` **39/0**, `test_cli_version` **35/0**, `test_ts_ordering` **7/0**; `CHANGELOG.md` version tokens unique (`sort | uniq -d` → 0).

Parked at the bottom of an otherwise newest-first file on purpose: promoting it to the top would make it the version-train head while `GLADEX_APP_VERSION` and all four `gladex` binaries still report `0.4.28`, turning `tests/test_app_version` and `tests/test_cli_version` red until CI bumps the train. That bump is main-loop work and is not part of this fix.

Queue item **(1)** from `[0.4.54]`, verbatim: *"`--help`'s *Commit lint gate* prose still says the committed tree must show "every linted file parses and the committed Go module compiles", which `[0.4.52]`'s CHANGELOG rule also fails — the same "wrapper restates a contract it does not re-read" shape `[0.4.53]` fixed for the exit-7 line, this time in the prose block. Widening it is its own help contract (queued, not slipped in)."*

Harm, stated concretely: `--help` is the only copy of "clean" an operator sees without opening the child, and that copy was true when it was written — before repo-lint could exit 1 on a Markdown file. `[0.4.53]` already proved the runtime half of this (`committed file(s) fail to parse or compile: CHANGELOG.md`), but the refusal was only half the lie: the help *beside* it still implied that a parse or a compile failure was the only road to exit 7, so a duplicate `## [1.0.0]` refused a promotion with no sentence anywhere in the tool that could explain why.

A second copy of the same promise was broken differently: the module docstring's gate list has said `3. Commit lint gate (exit 7) — see below.` since the gate existed, and the docstring carries a section per gate — reviewer verdict, `Dev-sync gate (step 0b)`, `Ship-tree gate (step 0d)` — **except 0c**. The pointer had no target: "see below" pointed at the ship-tree section.

**35 suites, 2696 assertions, 0 failed** — 19 shell = **1877** (**+14** over 1863, exactly `test_promote_lint_gate` 129 → 143, no other suite moved), 16 PHP = **819**, unmoved. Doc/contract suites after the appends: `test_repo_lint` **156/0**, `test_changelog_api` **86/0**, `test_app_version` **39/0**, `test_cli_version` **35/0**, `test_ts_ordering` **7/0**; `CHANGELOG.md` version tokens `sort | uniq -d` → **0** (checked after this entry was written — no line in it begins with `## [` other than its own heading).

Parked at the bottom of an otherwise newest-first file on purpose: promoting it to the top would make it the version-train head while `GLADEX_APP_VERSION` and all four `gladex` binaries still report `0.4.28`, turning `tests/test_app_version` and `tests/test_cli_version` red until CI bumps the train. That bump is main-loop work and is not part of this fix.

**36 suites, 2770 assertions, 0 failed** — 19 shell = **1896** (**+19** over 1877, exactly `test_repo_lint` 156 → 175, no other shell suite moved), 17 PHP = **874** (**+55** over 819: **+53** the new `test_investor_heading.php` and **+2** from `[0.4.56]` — `test_main_landmark`'s `<main> opens before the <h1>` assertion is conditional on the page having an `<h1>` after `<main>`, and the promoted `/investor` heading now satisfies it in **both** envs; verified by counting that label's occurrences and by curling `/investor`, not inferred from the total). Every suite emits exactly one summary line (checked), so the aggregation is not double-counting. Doc/contract suites after the appends: `test_repo_lint` **175/0**, `test_changelog_api` **86/0**, `test_app_version` **39/0**, `test_cli_version` **35/0**, `test_ts_ordering` **7/0**; `CHANGELOG.md` version tokens unique (`sort | uniq -d` → **0**, extracted from the first bracket of each `## [` heading only — the naive `grep -o` picks up version mentions inside titles and reports false duplicates).

Parked at the bottom of an otherwise newest-first file on purpose: promoting it to the top would make it the version-train head while `GLADEX_APP_VERSION` and all four `gladex` binaries still report `0.4.28`, turning `tests/test_app_version` and `tests/test_cli_version` red until CI bumps the train. That bump is main-loop work and is not part of this fix.

Queue item **(2)** from `[0.4.47]`, verbatim: *"**`.chip` / accent link text on `/templates` measures ≈ 3.7:1** against its background — below 4.5:1 for normal text (WCAG 1.4.3)."* The number was close but it was an estimate, and it only counted two of the three failing pairs. Measured with the real stylesheet: `.chip` prints `var(--accent)` (#6c5ce7) at 0.7rem on the card surface (`--surface` #1a1a24) → **3.55:1**; `.contact a` prints the same colour on the page background (#0f0f13) → **3.94:1**; and the `footer` prints `--text-dim` at `opacity: 0.5`, which blends it halfway into the background before the eye ever gets it → **2.27:1**. The floor for text this size is 4.5:1, so three of the sixteen pairs on the page were under it.

`--accent` was picked for *fills* — the logo tile and the primary button — where white-on-accent sits at 4.86:1 and passes. Using it as a text colour on two different backgrounds is the whole defect: the same token cannot be right for both jobs.

Parked at the bottom of an otherwise newest-first file on purpose: promoting it to the top would make it the version-train head while `GLADEX_APP_VERSION` and all four `gladex` binaries still report `0.4.28`, turning `tests/test_app_version` and `tests/test_cli_version` red until CI bumps the train. That bump is main-loop work and is not part of this fix.

Parked at the bottom of an otherwise newest-first file on purpose: promoting it to the top would make it the version-train head while `GLADEX_APP_VERSION` and all four `gladex` binaries still report `0.4.28`, turning `tests/test_app_version` and `tests/test_cli_version` red until CI bumps the train. That bump is main-loop work and is not part of this fix.

`repo-lint: refusing to run - docstring section missing or empty (the epilog would print a label over nothing):` / ` 'env:' -> 'Environment:'` → **exit 3**.

Parked at the bottom of an otherwise newest-first file on purpose: promoting it to the top would make it the version-train head while `GLADEX_APP_VERSION` and all four `gladex` binaries still report `0.4.28`, turning `tests/test_app_version` and `tests/test_cli_version` red until CI bumps the train. That bump is main-loop work and is not part of this fix.

Parked at the bottom of an otherwise newest-first file on purpose: promoting it to the top would make it the version-train head while `GLADEX_APP_VERSION` and all four `gladex` binaries still report `0.4.28`, turning `tests/test_app_version` and `tests/test_cli_version` red until CI bumps the train. That bump is main-loop work and is not part of this fix.

Parked at the bottom of an otherwise newest-first file on purpose: promoting it to the top would make it the version-train head while `GLADEX_APP_VERSION` and all four `gladex` binaries still report `0.4.28`, turning `tests/test_app_version` and `tests/test_cli_version` red until CI bumps the train. That bump is main-loop work and is not part of this fix.

```

GATE OK: VERDICT-20260926-000744-promote-contrast-fix.md (VERDICT: APPROVE), 1 verdict file(s), age 139s

DEV-SYNC OK: dev tree (/opt/startup/dev) matches the repo

LINT OK: repo-lint verdict on HEAD clean (171 file(s) linted, exit 0)

SHIP-TREE OK: promoted trees match HEAD

Promotion successful! Prod is healthy at commit b6ac023c

```

All four gates ran and passed on their own merits; `--force` was never invoked.

Parked at the bottom of an otherwise newest-first file on purpose: promoting it to the top would make it the version-train head while `GLADEX_APP_VERSION` and all four `gladex` binaries still report `0.4.28`, turning `tests/test_app_version` and `tests/test_cli_version` red until CI bumps the train. That bump is main-loop work and is not part of this fix.

> "`tests/test_app_contrast.php` section 6 **silently omits** assertions when `--accent-text` is missing instead of failing or counting a skip — it produced a *green-er-looking* run (148 pass) precisely when the defect was present. The property it guards is unfalsifiable on a broken document. Either assert the token's presence unconditionally outside the conditional block, or make the branch a counted `skip()`."

Same harm shape as the twenty-eight `[0.4.5x]`–`[0.4.6x]` entries before it, one level down: not a tool that under-reports, but a **suite** that does. The three properties (`--accent-text` differs from `--accent`, clears 4.5:1 on `--surface`, clears 4.5:1 on `--bg`) sat behind `if ($accent !== '' && $text !== '')` with **no `else`**, so a document without the token lost 3 × 4 = 12 assertions from the arithmetic while the run still printed a tidy `Results:` line. `[0.4.63]` had to *reconstruct* that 173 + 12 = 185 by reading the source, because the run itself never said.

The "assert unconditionally" half of the suggested fix was **already satisfied**: line 507 asserted `parse_color($text) !== null` outside the branch and did fail. What was missing was that the other three *say* they did not run.

Building fixture **F2** (token present but unparseable, `--accent-text: not-a-colour`) to probe the boundary turned up the worse half: the branch's guard was `$text !== ''` while the assertion above it was `$text !== '' && parse_color($text) !== null` — **two different predicates**, so a garbage value passed the guard, entered the branch, and `contrast(parse_color($text), …)` threw

PHP Fatal error: Uncaught TypeError: contrast(): Argument #1 ($fg) must be of type array, null given … on line 512

→ **exit 255, no `=== Results:` line, 1 of 4 documents reported**. A suite that aborts is strictly worse than one that omits: the consumer gets neither a verdict nor a count, and the exit code says "crashed" rather than "the document is broken". The queue described a *quiet* loss; the guard could also produce a *loud* one.

1. **Counted skip, not a bare pass-through.** The three properties are genuinely unmeasurable without a parseable token, so failing them would say "this is wrong" about a check nobody could perform. Each becomes a `skip()` carrying the **same property text as the assertion** plus the reason (`NOT CHECKED (--accent-text is not declared)` / `… is not a parseable colour`). The run's arithmetic then always adds up, and `skip()` — already counting the HTTP-down branches in section 5 — stops being 0 by accident.

2. **One predicate, used twice.** `$accentOk` / `$textOk` are computed once, asserted on, and reused as the guard: the branch can no longer be *weaker* than the assertions above it, which is exactly how the TypeError got in. The second suggested fix ("assert unconditionally outside the conditional block") needed no code — it was already there — so the defect was never a missing assertion, it was a **missing else**.

3. **A skip can never hide a green run.** The guard being false implies at least one of the two token assertions is false, so skips are only ever *added to* a red document. That is asserted rather than argued (meta-suite: "every skipped document also carries its token failure").

New **`tests/test_app_contrast_meta.php`** written **before** the suite was touched — a property that vanishes cannot be caught by running the suite on healthy files, so the meta-suite **builds broken documents**: F1 removes all four `--accent-text` declarations from `:root` (the exact tree run 95 shipped — sites still reference `var(--accent-text)`, verified at all nine), F2 garbles all four values, F3 is the real `app.php`. Each run is made hermetic by patching a **copy** of the suite under test: the three `app.php` paths point at the fixture, the two served bases at ports **59999/59998, verified closed first**, so section 5 cannot answer. Section 6 is then read out of the output between the `=== 6.` heading and `=== Results:`.

**Baseline verified first**: committed suite → **185 passed / 0 failed / 0 skipped**, exit 0.

**Pre-fix red captured with the FINAL meta-suite** (suite md5 `b9d7dcd3c2aa159c33f5f7144cdbfb5a` from `git show HEAD:`, meta-suite md5 `261ad2b7608334b20743bfa25b926bcb`, log `/tmp/opencode/contrastfix/pre-fix-final.log`) → **33 passed / 15 failed**, and the capture was **re-taken deliberately**: an earlier red had been recorded with a pre-anchor draft of the meta-suite, so it was re-run against the committed suite rather than trusted. **33 + 15 = 48 = the post-fix total**, exact closure with nothing added between capture and fix.

**All fifteen are real** — F1: the four count/property failures (4); F2: exit 255, fatal, no Results line, the counts and doc coverage (9); section D: no `else`, no `skip()` (2). **Guards that passed pre-fix and thereby identify themselves**: F1's exit/no-fatal/Results/`FAIL=4`/all-four-docs, **F1's "no skip without a verdict" — vacuously true at 0 skips, the same vacuity `[0.4.60]`–`[0.4.63]` kept recording**, all seven of F3 (section ran, 0 skips, 0 fails, 4 docs, and each of the three properties **PASSING** 4× — the assertion that makes a skip a *real* loss rather than something the suite never did anyway), the fourteen setup assertions, and section D's three "the block is locatable" anchors.

Recorded rather than quietly corrected — a red that means the wrong thing is the trap this whole line of work exists for, and this run collected five:

1. **F2's fixture counted the wrong string.** The rewrite keeps `--accent-text:` in place (only the value changes), so `$before - $after` on that key was `4 - 4 = 0`, reported as "garbled 0 of 4" against a correct fixture. Re-based on the value's own token.

2. **F3's "no original survives the copy" check could never pass** for a fixture that *is* the original path — `str_replace` is a no-op, so the original correctly remains. Now skipped when `$to === $from`.

3. **The meta-suite's own section-6 extraction was unanchored**: `strpos($src, '=== Results:')` found my §6 **comment**, which quotes the marker, three lines *above* the `skip()` calls, so section D reported `skip() = 0` against correct code. Re-anchored on the two `echo "\n…"` statements, with both anchors asserted so a renamed report line fails loudly instead of silently re-scoping the block.

4. **The mutation driver hit the identical trap one layer down**: `strpos($s, ' } else {')` matched `measure_doc`'s eight-space `} else {` at ~line 333, not §6's at 524 — the resulting "mutant" would have deleted everything between them. Caught by its own precondition (`expected exactly 1 else and 3 skip(), found 1/1` … then `found 0`), not by looking at the file.

5. **The "surgery stayed inside section 6" check used the wrong offset**: after splicing, the tail's index in `$out` moves by the block's length delta, so comparing at `$s6end` (the offset in the *original*) failed **both mutations on correct splices**. Re-indexed at `$s6start + strlen($newS6)` — and since both mutations are now applied to the extracted **block** and spliced back, "outside §6 unchanged" holds by construction rather than by a search that has to be trusted.

`tests/test_app_contrast.php` §6: two `$accentOk` / `$textOk` predicates computed once and reused as the guard, and a new `else` with three counted `skip()` calls naming the same three properties plus the reason. Suite docblock's "Asserts" list gained the contract paragraph. → meta-suite **48 passed / 0 failed**, suite **185 passed / 0 failed / 0 skipped, exit 0 — unchanged**, which is the point: the fix adds no assertions on healthy documents, it only refuses to *lose* them on broken ones.

Both drivers precondition-assert `1 else / 3 skip()` in the original, `0/0` in the mutant, a non-identical md5, an unchanged §6 outside the splice, and `php -l` clean — the real suite's md5 (`3abb053a73c86dc2397c6329f50e1dab`) is unchanged before and after both runs.

`php tests/test_app_contrast.php` → **185 passed, 0 failed, 0 skipped**, exit 0 (identical to baseline). `php tests/test_app_contrast_meta.php` → **48 passed, 0 failed, 0 skipped**, exit 0, `suite under test: /data/repo/tests/test_app_contrast.php`, temp trees under `/tmp/opencode/contrast-meta-*` registered for shutdown-cleanup. Both `php -l` clean. `tools/system-status --format human` → **ALL SYSTEMS HEALTHY**, exit 0 (standing warnings only: SOA `mname=placeholder` NEEDS-INVESTOR, `investor-messages [OK] 0 unread dev=0 prod=0`).

**39 suites, 3203 assertions, 0 failed, 0 skipped, `BAD=none`** — **19 shell = 2012** (unchanged) and **20 PHP = 1191**. The movement over `[0.4.63]`'s 38/3155 closes exactly: **+1 suite and +48 assertions = `test_app_contrast_meta.php` itself** (3155 + 48 = 3203, 1143 + 48 = 1191), no other suite moved, and `test_app_contrast.php` stayed at **185**. Runner note: this repo has no committed regression runner, and a first parser missed **four different summary shapes** in the tree (`=== Results: …`, `… suite: …`, `Results: …`, bare `N passed, N failed`) — it reported 1854/0 and, worse, listed twelve **rc=0** suites as `no-summary` failures. Re-parsed format-agnostically from each suite's own summary line rather than by one guessed format.

Model spend **0.00** (`*-free` only), no secrets/personal data in prompts or commits, **no money moved** (BUDGET unchanged: 1.50 spent / 3.50 remaining), **no DNS write** (no resolver queried this run), **no service restart, no promote** — `/opt/startup/{dev,prod}` untouched except read-only STEP 0 queries; the message DBs were **read only** (0 unread, no reply owed); `/root/.pdns-token` never read; `noreply@gladex.de` never invoked. All fixtures, patched copies and mutants live under `/tmp/opencode/`; the suite under test and `app.php` were never written to.

Staged **explicitly**, never `-A` — the two changed/new source files plus the three docs this entry writes.

NEEDS-INVESTOR **#57 public investor-route gating A/B/C** and **SOA MNAME** (`a.misconfigured.dns.server.invalid.` — `system-status` reports `mname=placeholder`) — surfaced every run, cannot proceed unilaterally.

Parked at the bottom of an otherwise newest-first file on purpose: promoting it to the top would make it the version-train head while `GLADEX_APP_VERSION` and all four `gladex` binaries still report `0.4.28`, turning `tests/test_app_version` and `tests/test_cli_version` red until CI bumps the train. That bump is main-loop work and is not part of this fix.

> "this repo still has **no committed regression runner** — the counts in every entry depend on a throwaway parser, and this run's first parser mis-parsed **16 of 39 suites** (four summary shapes) while showing `0 failed`. Make it a tool with a `--help` and a REGISTRY entry, so '39 suites, 3203 assertions' is produced by something versioned."

The number every entry quotes was never produced by anything in the repo. It was written by whatever ad-hoc parser the reporting run happened to throw together, so the totals were unverifiable in the specific sense that no two runs had to agree — and the one that went wrong was wrong in the *safe* direction (`1854 / 0 failed` reads green), which is the direction nobody re-checks.

The four shapes are real and all four are live today: `=== Results: 185 passed, 0 failed, 0 skipped ===` (29), `repo-lint suite: 291 passed, 0 failed` (6), `Results: 19 passed, 0 failed` (2), and the bare `11 passed, 0 failed` (2). But "parse each suite's last *line*" — the obvious reading — is wrong: **seven suites print trailing noise after their summary**, six a `====` banner and `test_pdns_api.sh` a shell `Killed` message. So the rule is the last **match**, and matches are then ranked: a hit on an assertion line (`PASS:`/`FAIL:`/`SKIP:`/`ok`/`-`/`*`) loses to a hit on any other line, so a PASS line quoting numbers cannot steal the verdict. Both halves are pinned, because the first is wrong on 7 of 39 suites and the second would be wrong the day a suite logs a big number after its own summary.

Measured, not assumed: across all 39 suites there is currently **exactly one match per file**, so today the tie-break never fires — recorded as such rather than presented as a finding.

1. **A suite with no summary contributes nothing** and is `no_summary` → exit **4**. It is not `0 failed` and it is not a small number: the whole defect was a parser that reported green while unable to read a third of the tree.

2. **Verdicts are separated from the environment.** A suite that *reports* failures and exits 1 is `failed` (exit 1); a suite that reports none and exits non-zero is `crashed` (exit **3**), because its verdict cannot be trusted. Timeout (3) and an unknown extension (3) sit on the same side: "could not be verified" is never a pass and never a failure on files we did not read. Precedence `2 > 3 > 4 > 1 > 0`, with every suite's row printed regardless of which code wins.

3. **Sequential on purpose, no `--jobs`.** Several suites take locks, ports and git state (`test_php_busy_timeout` holds a SQLite handle; the promote suites touch the envs). Trading a reproducible total for a flaky one is the wrong trade for the tool whose whole job is reproducibility.

4. **The epilog has no prose of its own** — all four sections are `docstring_section()`-derived from the module docstring, following `repo-lint`, so `--help` and the docstring cannot drift; a missing or empty heading **refuses** (exit 3, naming the pair) rather than printing a label over nothing. One defect this run hit live: the `Summary parsing (…)` heading was written without its trailing colon while `EPILOG_PAIRS` carried one, and the refusal caught it on the first `--help`.

5. **One JSON key set, 13 keys, every path** — verdict, usage error and refusal — enforced by `emit_json`, which raises rather than printing a drifted shape.

Against the tree *before* this change: **39 suites, 3203 passed, 0 failed, 0 skipped**, exit 0 — the independently derived `[0.4.64]` figure, reproduced by a committed tool rather than re-derived by hand, with the shape histogram `bare=2, fence=29, results=2, suite=6`. After adding this suite: **40 suites, 3313 passed, 0 failed**, and the movement closes exactly — 3203 + 110 = 3313, `fence` 29 → 30, no other suite moved. Wall time 4m24s.

Recorded rather than quietly corrected:

1. **`format_of` leaked argparse's `usage:` + `error:` to stderr** for an unreadable `--format` — the exact leak `repo-lint`'s S section pinned. Now `redirect_stderr`-swallowed; stderr is one diagnosis line (E10–E12).

2. **The suite passed help *text* where `help_section` wanted a file**, so `awk` opened a paragraph as a filename and every A5 byte-comparison silently compared against nothing — a green-looking check that measured nothing. Now reads stdin.

3. **`jget` used `print(d)`**, so a dict field came back as Python's `{'fence': 1}` and a bool as `True` — not JSON. Now `str` raw, everything else `json.dumps`, so booleans read `true`/`false` (C9/C11/C12/D5/D8 assert the JSON spelling).

4. **The recursion guard was self-matching**: its own needle text sat in the assertion line it was scanning, so it could only ever fail. Replaced by extraction *by function* (`helper_line`) — the guard can no longer see itself.

5. **The G section was path-dependent**: `default_repo()` resolves relative to the script, so every mutant copied to `/tmp` reported `repo=/tmp/opencode`, found no suites and exited 5 — four reds per mutation that were **harness artifacts, not catches**. Fixed with `GLADEX_REPO_DIR` for the behavioral checks, while the path resolution itself is pinned separately (G6, shipped-binary only).

6. **The mutation driver's precondition used `grep -F` on a multi-line needle**, which `grep -F` splits into one pattern per line — it reported 3 occurrences of a genuinely unique needle and declared m3 unplantable. Counted in python instead.

Also hardened at the source: a status carrying no summary must not deposit a `None` key into `shapes`, because `sorted(shapes.items())` in the human report would raise on it.

Each mutant's reds are **confined to its own section** — the M-fix above is what made that true; before it, every mutant also lit up G1–G4 for path reasons. `m3`'s needle was first declared UNPLANTABLE by its own precondition (the same condition text appears in the human-report formatter); the needle was widened to two lines rather than the precondition relaxed.

New **`tests/test_regression_run.sh` → 110 assertions**, hermetic (throwaway fixtures under `/tmp/opencode/trr.*`, trap-cleaned): the `--help`/docstring byte-comparison for all four sections, the full exit-code contract (`0/1/2/3/4/5`) with precedence, all four parsing rules, the 13-key JSON contract including the usage-error and refusal objects, the flag contract (including "stderr is exactly one line"), the epilog refusal in both channels, live read-only proof, and the recursion guard. Test hook `REGRESSION_RUN_BIN` points the suite at a mutant copy.

`./tools/regression-run` → **40 suites, 3313 passed, 0 failed, 0 skipped**, exit 0. `tools/repo-lint` → exit 0, `files_total 174`, `linted {bash 24, go 43, json 11, php 32, python 11}`, `changelog_version entries 69, unique 69, duplicates []` (all pre-commit). `tools/source-sync-check` → in sync, 42 files, exit 0. `tools/system-status --format human` → **ALL SYSTEMS HEALTHY**.

Parked at the bottom of an otherwise newest-first file on purpose: promoting it to the top would make it the version-train head while `GLADEX_APP_VERSION` and all four `gladex` binaries still report `0.4.28`, turning `tests/test_app_version` and `tests/test_cli_version` red until CI bumps the train. That bump is main-loop work and is not part of this fix.

Every entry in this file ends in arithmetic performed in prose — `[0.4.65]` wrote **`39 · 3203 + 110 = 40 · 3313`** and `[0.4.64]` wrote **`3155 + 48 = 3203`** — and none of it was checked by anything versioned. `tools/regression-run` (built by `[0.4.65]`) fixed *where the totals come from* but still reported only totals: it could not say which suite moved, so "+110 somewhere" became "+110 in `test_regression_run.sh`" by reading the tree by hand, once per run, in prose. This is `[0.4.65]`'s queue item (1) as recorded in `PROGRESS.md` — *"a `--baseline FILE` mode that diffs two runs' per-suite assertion counts would turn `+110 somewhere` into `+110 in test_regression_run.sh` mechanically instead of by arithmetic done by hand"*.

1. **One `contrib()` decides what a suite contributes — and it decides it three times**: for the current run, for the baseline's stored records, *and* for `totals` themselves (the totals are now **derived** from the records after the loop rather than accumulated by a second rule inside it). Two rules for the same question is precisely how two sides of a diff disagree and report movement that never happened; mutation **M6** writes the second rule on purpose and is caught by closure alone.

2. **The exit code never moves because of a baseline.** A count delta is attribution, not a verdict: a comparison that failed green runs — a suite legitimately rewritten to fewer assertions would light up CI — is a check people learn to ignore, and `[0.4.61]`–`[0.4.63]` already taught this repo what a check everyone overrides is worth. The run's own verdict (`2 > 3 > 4 > 1 > 0`) stands alone, pinned by four assertions and by **M2** (which flips the code on any movement and goes 4-red).

3. **The baseline is validated before any suite runs.** A file discovered to be garbage after a 4-minute run has already cost the 4 minutes.

4. **A run that finished but could not be *recorded* still prints its whole report**, then exits 2 (precedence: 2 wins) with the reason — discarding a finished verdict for an error message would trade a real result for none.

5. **`--list` + either baseline flag → exit 2**: a list runs nothing, so there is nothing to compare or to record.

6. **A field that exists but is never read is a field that lies.** `format` was written into every record from the first version and *nothing checked it* — a future layout change would have been read as this one. It is now refused with both numbers named (`format 99, this tool reads 1`), and **M7** proves the check is load-bearing.

Three, all caught by **reading the draft before the first run** — which means, and is recorded here as, three assertions that have never been red:

1. **`I50` expected `-1` where the arithmetic gives `+1`** (`delta = current − baseline = 3 − 2`). The sign error is in the *expectation*, so had it survived to a run it would have looked like a tool bug rather than a test bug. It was corrected pre-run; its truth is argued from the fixture, not demonstrated. The neighbouring property on that same fixture *is* mutation-proven (M6 → I49).

2. **A call to a `json` helper that does not exist** in the test file (`json '{…}' > payload.json`) — it would have died mid-suite with `command not found`.

3. **The duplicate-suite fixture was `printf 'x'`** — i.e. it would have exercised the *non-JSON* refusal (already covered by I58) while labelled as the duplicate-name refusal. Replaced by a real document listing `test_gamma.sh` twice, so `I62`/`I62b` test what they say they test.

The broader gap behind them: a fixture written *for* an assertion is the case where the assertion is most likely to be wrong, because nothing has run yet to contradict it — the same reason the section's fixtures are **tampered copies** of a record the tool itself wrote rather than documents written from the format's description.

Every mutant's reds are **confined to section I**; sections A–H stay green under all seven.

`tests/test_regression_run.sh` **110 → 193 assertions** (0 failed), new **section I (80)** — counted by tallying the section's own `PASS:` lines rather than by subtracting: **193 = 110 + 3 (section A's three loops each gained the new pair) + 80 (section I)**. Hermetic throughout: every baseline case runs through `run_sandbox`/`jrun`, so **even the error-path checks carry `--tests-dir`** and can never point this suite at the live `tests/` directory — the recursion its header forbids. Fixtures are tampered copies built by an embedded python builder (count raised with totals reconciled, the same edit *without* the totals, a suite added and one the run never heard of, a suite recorded `no_summary` with `passed: null`, a duplicated name, a run payload, `format: 99`).

`./tools/regression-run` → **40 suites, 3396 passed, 0 failed, 0 skipped**, exit 0, 4m30s. Baseline exercised on the real tree: `--only regression_run --save-baseline` → a record of **193**; the same suite again → *"no movement; 1 of 1 shared suite(s) unchanged"*, closure OK; `--only ts_ordering --baseline` against it → `added test_ts_ordering.php`, `removed test_regression_run.sh`, **`totals delta -186` = `attributed -186`** (−193 + 7) `[CLOSURE OK]`, exit 0. `tools/repo-lint` → exit 0, `files_total 176`, `changelog_version entries 70, unique 70, duplicates []` (both pre-commit by construction). `tools/source-sync-check` → in sync, 42 files, exit 0. `tools/system-status --format human` → **ALL SYSTEMS HEALTHY**. Model spend **0.00** (`*-free` only), BUDGET unchanged at 1.50 spent / 3.50 remaining, message DBs read-only (STEP 0: 0 unread), `/root/.pdns-token` never read.

Parked at the bottom of an otherwise newest-first file on purpose: promoting it to the top would make it the version-train head while `GLADEX_APP_VERSION` and all four `gladex` binaries still report `0.4.28`, turning `tests/test_app_version` and `tests/test_cli_version` red until CI bumps the train. That bump is main-loop work and is not part of this fix.

From `0.4.40` to `0.4.66` **every** entry in this file carried its own `### Queue (next candidates, not actioned)` section **and** every run entry in `agent-logs/PROGRESS.md` carried a copy of the same list as a `Next-candidate queued` bullet — two lists, hand-maintained, in two files, in parallel, forever. They diverged exactly the way two hand-maintained copies always do:

The same version therefore carried **two different queues** — one of them the queue of an item that was never queued. Nothing compared them, so nothing noticed; `[0.4.66]` found it only by reading its own entry in both files. That is the harm shape this log keeps naming one level up: not a wrong number, but **two sources for one number, with no versioned arbiter between them**, which is only ever noticed by whoever happens to read both.

Measured on the live tree before the fix, this run:

$ ./tools/queue-source-check
queue-source-check: FAIL - 2 violation(s): [0.4.66] ### Queue lists 8 item(s) …;
  [0.4.66] ### Queue does not point at agent-logs/PROGRESS.md
$ echo $?
1
$ ./tools/system-status --format human | grep -E 'queue-source|Overall'
  queue-source              [FAIL] 2 violation(s): …
Overall: 1 CHECK(S) FAILED

Not a coin flip, and not "the shorter file":

1. **It is the copy that stayed right.** The baseline item was queued in `PROGRESS.md` and missing from this file; the divergence was always on *this* side. Making the incorrect copy authoritative would have migrated the defect.

2. **It is what the loop actually reads.** The constant task appends to `agent-logs/PROGRESS.md` every run and the queue is re-read from there — this file was a *report* of the queue, not its home, and a report that is copied by hand becomes a second queue the moment anyone edits only one of them.

3. **Striking stays where it already happens.** The `~~struck~~ — ACTIONED by [x]` convention has been applied to `PROGRESS.md` bullets for the last three runs. Keeping the live list there means the workflow does not move; only the duplicate does.

4. **The historical sections are not deleted.** The 111 item lines in the 25 sections from `0.4.40` to `0.4.66` are *history* — what each version deliberately declined to do — and stay as they are. What changes is that `### Queue` after `0.4.66` carries a **pointer**, so a reader of any entry older than this one is pointed at the live list instead of mistaking a snapshot for a work queue.

From this entry on, the shape of a `### Queue` section is:

### Queue -> agent-logs/PROGRESS.md
Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md` (the
`Next-candidate queued` bullet of the newest run entry) — never a second list.

A decision that only exists in prose re-drifts the first time someone writes an entry in a hurry, so the rule is a tool with `--help`, a JSON contract and a row on the dashboard.

**Availability rules decide exit 3, and 3 is never "ok":** `CHANGELOG.md` absent, no `### Queue` section in it, or `agent-logs/PROGRESS.md` absent. The first one that fails short-circuits, because a verdict about a file that was not read is a guess — and because a sandbox repo with no changelog must not be able to turn "not evaluated" into a green check.

**The five rules, all evaluated, all reported (exit 1):**

| | rule |

|---|---|

| R1 | total `- ` item lines across every `### Queue` section **== 111** |

| R2 | the **newest** `## [x.y.z]` entry owns a `### Queue` section |

| R3 | that section contains **no list item of any kind** (`-`, `*`, `+`, `1.`) |

| R4 | that section names `agent-logs/PROGRESS.md` |

| R5 | `agent-logs/PROGRESS.md` carries ≥ 1 `Next-candidate queued` bullet |

Design choices worth stating:

The repo's own standard: *"the guard existed as a TEST; nothing at run time checked the commit."* A suite is red for whoever runs the regression; the divergence above was invisible for eleven versions because nobody ran anything that compared the two lists. The row is a live gate on every `system-status` call (the STEP-0 guard tool, the stats page, the promote path), with the contract documented in `--help` and pinned in the suite: child `0` → `ok`, `1` → **`error` + `ERRORS++`** (the dashboard goes red on a second list), `3` → `warning "cannot verify"` (never ok, never an error on a tree that was not checked), missing/timed-out/unparseable child → `warning`. The hermetic hook `GLADEX_QUEUE_SOURCE_BIN` follows the `GLADEX_REPO_LINT_BIN` / `GLADEX_PROMOTE_BIN` precedent so sandbox suites never reach the real tree.

`tests/test_queue_source.sh` — **107 assertions, 0 failed**, new. Every case builds its own repo under a `mktemp` sandbox and passes `--repo`; the only cases that resolve a repo by themselves copy the tool into the sandbox first, so `/data/repo` is never read.

`queue-source-check` on the real tree: **exit 1 with 2 violations *before* this entry was written** (the measurement above, taken while `0.4.66` was still newest) → **exit 0, `one queue: [0.4.67] pointer-only, 111 item line(s) frozen across 26 section(s)`** after. `system-status`: `queue-source [FAIL] … Overall: 1 CHECK(S) FAILED` → `queue-source [OK] … Overall: ALL SYSTEMS HEALTHY`. `tests/test_queue_source.sh` → **107/0**. Model spend **0.00** (`*-free` only), BUDGET unchanged at 1.50 spent / 3.50 remaining, message DBs read-only (STEP 0: 0 unread), `/root/.pdns-token` never read, `noreply@gladex.de` never invoked.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since this entry. The 111 item lines already written into the 25 `### Queue` sections above are frozen history: strike them in place when they are actioned, never add to them, never delete them. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Parked at the bottom of an otherwise newest-first file on purpose: promoting it to the top would make it the version-train head while `GLADEX_APP_VERSION` and all four `gladex` binaries still report `0.4.28`, turning `tests/test_app_version` and `tests/test_cli_version` red until CI bumps the train. That bump is main-loop work and is not part of this fix.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the `### Queue` sections above this one are frozen history: strike them in place when they are actioned, never add to them, never delete them. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Parked at the bottom of an otherwise newest-first file on purpose: promoting it to the top would make it the version-train head while `GLADEX_APP_VERSION` and all four `gladex` binaries still report `0.4.28`, turning `tests/test_app_version` and `tests/test_cli_version` red until CI bumps the train. That bump is main-loop work and is not part of this fix.

Queue item **(3)** from `[0.4.47]`, verbatim: *"**`minmax(300px, 1fr)` / `minmax(280px, 1fr)` grids can overflow at a 320 px viewport** — the min track is wider than the narrowest supported width."* Carried unchanged through `[0.4.58]`, `[0.4.59]`, `[0.4.60]` and `[0.4.61]`'s queue sections; **struck in place in all five of those frozen lines by this entry** (the freeze keeps the line count, not the strikethrough — `queue-source-check` still reports **111 item line(s)**, exit 0).

Both grids live in `<main class="hero">`, whose content box at a 320px viewport is `320 − 24 − 24 = **272px**` — 257px behind a 15px classic scrollbar. A `minmax()` minimum is a floor the engine must honour and it does not consult the container, so `/templates` laid a **300px** track in a **272px** box and `/team` a **280px** track in the same box.

Measured, not assumed — headless Chrome (Chrome for Testing 154.0.8037.57), viewport sweep 272→768px, *before* = the `d362264^` blob rendered by PHP, *after* = the repo source rendered by PHP, plus both live envs:

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the 26 `### Queue` sections above are frozen history: this entry struck the five lines that carried item **(3)** of `[0.4.47]`, in place, adding no line and removing none. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Parked at the bottom of an otherwise newest-first file on purpose: promoting it to the top would make it the version-train head while `GLADEX_APP_VERSION` and all four `gladex` binaries still report `0.4.28`, turning `tests/test_app_version` and `tests/test_cli_version` red until CI bumps the train. That bump is main-loop work and is not part of this fix.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

- `ok` `<ip> on 1.1.1.1+8.8.8.8` — every resolver that answered agreed, both named;

- `warning` `<ip> on 1.1.1.1 (8.8.8.8 unreachable - single-resolver reading)` — one witness answered and agreed: loud, named, **exit 0**. The false red disappears without the row going green on a thin reading;

- `error` `no answer from 1.1.1.1/8.8.8.8 (both resolvers unreachable) - expected <ip>, DNS UNVERIFIED` — nothing was measured, so nothing is claimed and nothing passes;

- `error` `<resolver> answered '<ip>', expected <ip>` — a resolver that *did* answer disagrees. Real drift is still a hard error, and the detail now says which resolver said it.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

The 2026-09-26 mobile sweep queued *"/changelog and /docs `<pre>` overflow"* as one item. It is two defects with two different shapes, and re-measuring on 2026-09-27 in Chrome for Testing 154.0.8037.57 split them apart:

Two smaller mechanisms rode along on `/changelog`: a backticked 76-character prose token measured **584.5px** with `overflow-wrap: normal` everywhere (it overflows *invisibly* — overflowing inline text belongs to no element rect, so an element scan reports nothing and only `scrollWidth` sees it), and the version row: `82.73 (badge) + 12 (gap) + 204.5 (longest `.version-date` min-content) = 299.23px` in a 241px row, `32 + 299.23 = 331.23` against Chrome's own 331.3px right edge.

Three declarations in the changelog stylesheet of `app/src/php/app.php`, and nothing else on the page:

**`tests/test_changelog_mobile.php` — 125 assertions, `php tests/test_changelog_mobile.php` → 0 failed / 0 skipped.** It reads the changelog document out of `app.php` (splitting on `<!DOCTYPE html>`, so a second `.container` rule cannot hide from it), parses the stylesheet into rules and pins **declaration by declaration** the values `body`, `.container`, `.version-header`, `.version-tag`, `.version-date`, `.changelog-desc`, `.changelog-item`, `.section-label` and `h1.changelog-title` had *before* the fix, plus `rule_count(...) === 1` for `.container` and an explicit assertion that `.version-header` has **no** `flex-wrap`. The arithmetic in the header is re-derived from the real `CHANGELOG.md` at run time — the fence's longest line, the longest prose token — so a future entry that grows past the pins turns the suite red instead of invalidating it silently.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Queue item (34), verbatim in part: *"`exit_code = 3 if errors else (1 if failures else 0)` lets **one** unwired lang mask a **verified** failure … so an rc-only consumer (or a reader of the last line) is told 'cannot verify' about a tree that demonstrably fails lint — and `promote-dev-to-prod`'s `elif rc == 3:` branch builds its refusal out of `errors[]` **alone**. … Worth either one W-section assertion pinning today's verdict (keep exit 3, but let the closing line count both) or an explicit decision that verified failures outrank cannot-verify."* This run took the **first** option.

**Measured before touching anything** (throwaway repo, one committed `app.php` with a parse error *and* one committed `app.ts`, each run through a copy carrying the `.ts` `EXT_LANG` entry with no linter behind it — the same copy section W builds, because the real tool cannot produce `errors[]` here at all):

FAIL app.php:2 [php] … PHP Parse error: …
ERROR app.ts [typescript] no linter wired for lang: typescript
result: cannot verify - 1 lint error(s) (exit 3)

`rc=3`, JSON `failures` 1 / `errors` 1. **The JSON was never wrong** — both halves were always in it — so this is a human-channel defect, and only the human channel changed.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Measured at run start, on the committed tree, before anything was touched: `./tools/repo-lint --format json` → **exit 1**, `changelog_version` *95 heading(s), 94 unique, 1 duplicated* (`0.4.75` first at 2237, again at 2673), `failures` carrying exactly one entry; `./tools/queue-source-check` → **exit 1**, one violation, the R2 pointer; `./tools/system-status` → **exit 1** with `queue-source error` alongside `cloud warning` and `SOA warning`; `php tests/test_changelog_api.php` → **84 passed / 2 failed** (both the duplicate: *"no version names two entries"*, *"keying the API output by version loses nothing (94 keys for 95 entries)"*) and `bash tests/test_system_status_mx_soa_transport.sh` → **73 passed / 3 failed** (`baseline exits 0 (got 1)`, `single-resolver MX/SOA … exit 1`). The failure was a **one-line** append by another identity's QA shift, committed clean (`git status --porcelain` empty at HEAD), i.e. history — not open work — which is why repairing it in place is the same act as `[0.4.87]`'s repair of the identical defect.

Model spend **0.00** (`*-free` only), **no money moved** (`BUDGET.md` untouched: **1.50 spent / 3.50 remaining**, month 2026-09, allowance 5.00), **zero DNS writes**, no paid API key configured, **no secret read or printed** (`/root/.pdns-token` and every `*.secret` untouched — the STEP-0 probe only tested existence), **no service restarted, no certificate touched, no promote executed**, **Docker stacks and both investor apps untouched**. Live I/O was read-only apart from this file: the STEP-0 SQL counts and reply insert, health probes, `--help` runs and the test suites.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Measured on the tool before anything was touched: `[0.4.89]` fixed the *child's* closing line so a mixed run no longer ended `result: cannot verify - 1 lint error(s) (exit 3)` sitting under a `FAIL app.php:2 [php]` it never mentioned — and that entry's own queue item named the second sink, `tools/promote-dev-to-prod`'s `elif rc == 3:` branch, which builds its refusal out of `errors[]` **alone**. Reproduced here with a payload the stub can emit and repo-lint really does emit (one unwired linter *and* two files judged red): the refusal read `LINT REFUSED (exit 7): repo-lint cannot verify the committed tree: typescript has no linter wired — fix the commit before promoting (prod is never shipped a red HEAD)` — one environment complaint, **zero** mention of the two files the child had verified broken, in the human line *and* in `gates[commit-lint].detail` under `--format json`, i.e. the identical text both consumers read. That asymmetry is the argument: exit 3 is the verdict an operator is most likely to read as "nothing wrong", and this is the last gate before prod.

Model spend **0.00** (`*-free` only), **no money moved** (`BUDGET.md` untouched: **1.50 spent / 3.50 remaining**, month 2026-09, allowance 5.00), **zero DNS writes** (no `pdns-api.py` call), no paid API key configured, **no secret read or printed** (`/root/.pdns-token` and every `*.secret` untouched — the STEP-0 probe only tested existence; no credential and no message body in any prompt/thread/commit), **no service restarted, no certificate touched, no promote executed** (the stale reviewer verdict `promote-gates` reports still refuses it), **Docker stacks and both investor apps untouched**. Live I/O was read-only apart from this file, `tools/REGISTRY.md`, `tools/promote-dev-to-prod`, `tests/test_promote_lint_gate.sh`, `agent-logs/PROGRESS.md` and the STEP-0 reply insert: the suite runs are `--dry-run` by construction, so the tool can never restart the live prod service from a test.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Measured on the unmodified tool (md5 `0c93193cff93238c85f7dcd789548581`, script `/tmp/opencode/measure-rc3-prefix.py`) with payloads shaped the way the child *really* sends them, because the suite's stub did not have that shape: repo-lint's `errors[]` entries are **dicts** — `lint()`'s unwired/missing/timeout arms, the Go compile gate's `cannot_verify` and the changelog gate's `cannot_verify` all return `{"path", "lang", "error"}` — while every stub in this suite emitted plain strings, so no assertion had ever seen one. Two defects fell out of that one measurement, both on the last gate before prod: (a) `'; '.join(str(e) for e in errs[:3])` printed `LINT REFUSED (exit 7): repo-lint cannot verify the committed tree: {'path': 'CHANGELOG.md', 'lang': 'changelog', 'error': 'git failed: fatal: bad object HEAD'} — fix the commit before promoting …` — a Python repr in the human line **and** in `gates[commit-lint].detail` under `--format json`; (b) four causes printed three, the fourth (`go.mod: go toolchain missing`) gone with no trace, while `_lint_failure_paths` and `_lint_failure_messages` in that same sentence both announce `(+N more)` — the asymmetry `[0.4.54]` removed on the failure half of this very sentence.

Model spend **0.00** (`*-free` only), **no money moved** (`BUDGET.md` untouched: **1.50 spent / 3.50 remaining**, month 2026-09, allowance 5.00), **zero DNS writes**, no paid API key configured, **no secret read or printed** (`/root/.pdns-token` and every `*.secret` untouched — the STEP-0 probe only tested existence; no credential and no message body in any prompt/thread/commit), **no service restarted, no certificate touched, no promote executed** (the stale reviewer verdict `promote-gates` reports still refuses it), **Docker stacks and both investor apps untouched**, **no mail sent**. Live I/O was read-only apart from this file, `tools/REGISTRY.md`, `tools/promote-dev-to-prod`, `tests/test_promote_lint_gate.sh`, `agent-logs/PROGRESS.md` and the STEP-0 reply insert: the suite runs `--dry-run` by construction, so the tool can never restart the live prod service from a test, and the pre-fix measurement script drives `check_lint_gate` directly with a throwaway stub under `/tmp/opencode`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

`agent-logs/PROGRESS.md` has carried **NEEDS-JONAS** since the 2026-09-26T08:50Z dispatcher shift — *"Verify investor app UI still renders correctly after recent SSL vhost changes (photos./cloud. vhosts added, wildcard alias narrowed). Quick smoke on dev + prod"* — and it was still open three Jonas shifts later, because what it asks for is a **check**, and a check that exists only as prose is run by nobody. This entry turns it into a suite that `regression-run` discovers on its own (`tests/test_*`), so the next shift inherits it instead of re-deriving it.

Both halves of that vhost change can break while every individual `curl` still looks green, which is why one hand-run smoke would not have closed the item:

1. **The narrowing** — `gladex-ssl.conf`'s `ServerAlias` went from `*.gladex.de` to five exact names (`dev info log stats team`) so `photos.`/`cloud.` could own their vhosts. A narrowing is only meaningful in *both* directions: every name that still matters must still reach the app, **and** a name outside the list must stop reaching it — otherwise nothing narrowed at all. Measured before writing a line of the suite: the seven lineage names answer 200 with the page their `Host` header selects, and a name outside the list falls through to the default `:443` vhost. Nothing in the tree proved that; now something does.

2. **Two certificates on one port** — which one a visitor receives is decided by SNI alone, so a page can render perfectly while wearing the wrong certificate. A UI check with no cert check misses that; a cert check with no UI check misses a vhost answering 200 with an error page behind it. Section C asserts both, and asserts that the `photos./cloud.` lineage is a **different** certificate from `gladex.de`'s so neither can silently answer for the other.

- **A — both envs over HTTP**: `dev :8000` and `prod :8001` run the *same* table — `/`, `/team`, `/info`, `/stats`, `/changelog`, `/mailbox` each pinned to status **200** *plus* a marker only that page carries (`<title>Gladex — Team</title>` **and** all four names on `/team`), and the two gates that must **not** render: `/login` and an unknown path both answer **302**, `/healthz` 200 with `"status":"ok"`.

- **B — HTTPS per host**: the seven `gladex.de`-lineage names each render the page their `Host` header selects (`app.php` routes `info.`/`log.`/`stats.` on `Host`, so those three are asserted on their own hostname rather than on a path); `photos.` → Immich and `cloud.` → Nextcloud **plus an explicit negative that the app vhost is not swallowing them again** — the exact defect the 2026-09-26 change existed to fix, since Apache takes the *first* matching vhost and `sites-enabled` loads alphabetically; the no-SNI default `:443` vhost still answers; `http://gladex.de` still 301s to `https://`; and the narrowing itself, as a negative: an **unlisted** name must not reach the app.

- **C — SNI**: nine handshakes asserting `SAN contains <name>` for each of the seven lineage names plus `photos.`/`cloud.`, then lineage distinctness.

Model spend **0.00** (`*-free` only), **no money moved** (`BUDGET.md` untouched), **zero DNS writes**, no paid API key, **no secret read or printed** (`*.secret`, `.env` and every token untouched), **no service restarted, no certificate touched, no promote executed**, **both investor apps and the Docker stacks untouched** (read-only `curl` and `openssl s_client` against ports that were already listening), **zero mail sent** (0 unread, `noreply@gladex.de` never invoked), **investor web thread not written to** (no incoming message names me).

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

`[0.4.93]` queued item (38) as a *shape* and not a cause: `tests/test_system_status_go_compile.sh` came back **81 / 1** in regression runs A *and* B while being **82 / 0** standalone and in run C, and the assertion that failed was never written down, because `--log-dir` had only been used on a run that passed. Guessing at a flaky row is the "carried number" this repo keeps removing, so the first half of this step was to make the red happen **on purpose** and print it.

The line, captured verbatim by forcing HEAD to move between section 12's two live reads (throwaway clone, empty commit = the sha moves while the tree stays byte-identical, so *only* a provenance comparison can go red):

=== 12. live: real repo-lint on the real commit, both rows agree ===
  ok   - live repo-lint: HEAD's committed module compiles (exit 0)
  ok   - live system-status emitted JSON
  ok   - live go-compile row is ok
  FAIL - the row and the linter name the same commit (row: '45 module file(s) compile clean (1.681s) (commit 343037d)', linter: e7221f3)
  ok   - live detail reports a clean compile
  ok   - live dashboard carries BOTH Go rows

=== Results: 81 passed, 1 failed, 0 skipped ===

**81 / 1 — the exact totals regression runs A and B reported**, so the cause is measured, not inferred: section 12 ran `repo-lint --sha HEAD` here and then `system-status`, which resolves HEAD itself seconds later, and asserted the two short shas were equal. Several identities commit to `main` continuously; when one lands inside that window the assertion reports a contradiction between **two different commits that nobody made**. `tools/system-status` already knows this shape — its own divergence guard says *"different commits → HEAD moved between the checks: apparent contradiction is drift, nobody contradicted one commit"* — and this suite was the one place that rule had not been applied.

- **S1 normal** → **82 passed / 0 failed**, **0 notes** (the drift branch does not fire when nothing moved).

- **S2 forced drift — the pre-fix scenario, re-run post-fix** → **82 / 0 with the note**: `first read ae04bd2, row 2f96896 … both judge 2f96896`. Same-scenario pre-fix vs post-fix is **81 / 1 → 82 / 0**, and the pre-fix run above produced the captured line.

- **S3 row names an older existing commit** → section 12 **FAIL** (`row: '(commit f345dd3)', linter: …`), **no note** — the ancestor test refuses to call it drift. (Each of S3–S5 totals **79 / 3**: the other two reds are the mutation's own assertions in earlier sections, which fail because the plant rewrites the row everywhere by construction — not because the fix weakened them.)

- **S4 row names a *newer* commit that does not compile** → ground truth measured first (`Y(broken) go_compile.ok = False`, `X(clean) = True`), drift branch fires, and **assertion 1 goes red**: `live repo-lint: HEAD's committed module compiles (got ok=False, exit 1)`. That is the teeth: the pinned re-read carries the **verdict**, so the branch cannot wave through a broken commit.

- **S5 row names a commit that does not exist** → section 12 **FAIL**, no note (`cat-file -e` refuses).

Model spend **0.00** (`*-free` only), **no money moved** (`BUDGET.md` untouched: **1.50 spent / 3.50 remaining**, month 2026-09, allowance 5.00), **zero DNS writes**, no paid API key, **no secret read or printed** (`/root/.pdns-token` and every `*.secret` untouched — the STEP-0 probe only tested existence), **no service restarted, no certificate touched, no promote executed**, **both investor apps and the Docker stacks untouched**, **no mail sent**. The only live writes this run were this file, `tools/REGISTRY.md`, `agent-logs/PROGRESS.md`, `tests/test_system_status_go_compile.sh` and two STEP-0 reply rows; all five scenario clones lived under `/tmp/opencode`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

`[0.4.96]` captured the failing line by forcing HEAD to move between `tests/test_system_status_go_compile.sh` section 12's two live reads, fixed the guard, and verified the fix with five scenarios — but that verifier was a file under `/tmp/opencode/`. Its own closing note queued the consequence as **(40)**: a reboot deletes it, no `REGISTRY.md` entry can point at it, and nothing in the repo says the proof ever existed. The queue offered two answers (commit it as a tool, or shrink it into one deterministic in-suite case that would move the assertion count off 82 and force the arithmetic to be redone); this step takes the first.

The tool is deliberately **not** a test suite: it clones the repo five times and took **289s**, and `regression-run` discovers `<repo>/tests` only — so putting it in `tests/` would charge every run the cost and move the totals every CHANGELOG entry quotes, for a check nobody needs on every run.

Model spend **0.00** (`*-free` only), **no money moved** (`BUDGET.md` untouched: **1.50 spent / 3.50 remaining**, month 2026-09, allowance 5.00), **zero DNS writes**, no paid API key, **no secret read or printed** (`/root/.pdns-token` and every `*.secret` untouched — the STEP-0 probe only tested existence), **no service restarted, no certificate touched, no promote executed**, **both investor apps and the Docker stacks untouched**, **no mail sent**. The tool itself opens no network, writes no database and reads no secret; its only writes are its own scratch directory. Live writes this run: `tools/go-compile-drift-verify`, `tools/REGISTRY.md`, `CHANGELOG.md`, `agent-logs/PROGRESS.md` and two STEP-0 reply rows.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

The entry before it (`[0.4.97]`) had already been written when `INBOX.md` grew a 74th entry:

*"finish Immich setup via API NOW (no waiting)"* with the full recipe. It was unread, so the

STEP 0 duty was open again — an unanswered investor is a failed run regardless of other

progress — and the order itself removed the block that had parked `INBOX.md` line 452 since

2026-09-26. Executing it, reporting the result in the thread and recording the state change

are the substance of this run; the tool above is the other half of it.

only with zero users) seeded the first admin; the seven identities were created with

`POST /api/admin/users`, each password equal to its own email address **per the

investor's own declared scheme** — so no secret exists to store, and none is written in

`STRUCTURE.md`, `REPORT.md`, `INBOX.md`, `PROGRESS.md` or any commit.

answered `POST /api/auth/login` with **HTTP 201 + accessToken**; admin rights were

*proved* rather than inferred: the admin-only `GET /api/admin/users` returns **200 with

8 accounts** for `admin@`, **403 Forbidden** for `lena@`, **401** anonymous. Access

tokens lived in shell variables for the session only — never logged, printed, written to

a file or committed.

`POST /api/users` → **404 Cannot POST**; working routes are `POST /api/admin/users`

(create), `GET /api/users` (list), `DELETE /api/admin/users/:id` (remove),

`POST /api/auth/admin-sign-up`, and `POST /api/auth/login` → **201**, not 200. Recorded

so the next run does not re-derive them from 404s.

a connectivity probe with a throwaway address, and it consumed the first-admin slot (201,

`isAdmin=true`) because sign-up only works with zero users. Corrected in the same run —

`admin@gladex.de` created with the admin role, throwaway deleted (its login now **401**)

— so the end state matches the recipe exactly. It is written down because the

intermediate state existed.

results, the Nextcloud column still `not created — blocked`, plus the measured route

table and the deviation note; the "neither app has an admin yet" line corrected to

"Nextcloud still has none". `REPORT.md` §14 gained a **status paragraph shrinking the ask

to Nextcloud only**, so the open NEEDS-INVESTOR block does not contradict what was just

delivered. `INBOX.md` line 528 struck `~~HANDLED 2026-09-27T18:22:44Z~~` with a reply

block, and `agent_to_investor` rows **dev 92 / prod 57** carry the DONE report with the

user count, per the order's own "Report DONE with user count or FAILED with exact API

error bodies".

**Nextcloud**, which is still `status.php → {"installed":false}`. Not self-registering

and not extending the scheme to a second app unilaterally — §14 now states plainly that a

one-line confirmation extending password = email to Nextcloud is enough to close it.

`OK - nothing owed (0 unread, 1 open entries all replied)`, `INBOX.md` **74 entries /

73 handled / 1 open** (line 452, replied and blocked, not missed); unread

`investor_to_agent` = **0 dev / 0 prod** with the newest row in each my own reply,

`read=1`.

0 unmet, 0 unverified, 289s, exit 0**, md5 `21bcdc94e6c2604aa24573f7bd5b123b` unchanged

by the run.

`errors []`, `duplicates []`, `citations_missing []`**; `queue-source-check` → **exit 0,

`[0.4.98]`, 111 item line(s) frozen across 56 section(s)**; `inbox-status` → exit 0;

`source-sync-check` → in sync, 42 files / 2 envs; `test_changelog_api` → **86/0**,

`test_app_version` → **39/0**, `test_cli_version` → **35/0**, `test_queue_source` →

**122/0**, `test_repo_lint` → **420/0**.

**54 suites, 4593 passed, 0 failed, 0 skipped, exit 0** (`ok: true`, `conflicts []`,

timestamp `2026-09-27T18:23:49Z`) — **identical to the previous green baseline**, which

is the arithmetic this step needed: both halves add documentation and a tool under

`tools/`, **zero assertions**, so `4593 = 4593` with `54 = 54`.

half stays blocked on §14, and unilaterally extending a credential scheme to a second app

is exactly the "invent-and-forget" the investor forbade.

downstream job and needs the investor's own content decision, not just an admin session.

in this file, not in a prompt; only "password = own email", the investor's declared rule,

is recorded.

untouched, as does the rest of the carried queue.

Model spend **0.00** (`*-free` only), **no money moved** (`BUDGET.md` untouched: **1.50

spent / 3.50 remaining**, month 2026-09, allowance 5.00), **zero DNS writes** (no

`pdns-api.py` call), no paid API key, **no secret read or printed** (`/root/.pdns-token`

and every `*.secret` untouched), **no service restarted, no certificate touched, no promote

executed**, **both investor apps untouched apart from the Immich user table the order

directed**, **no mail sent**. The Immich API calls were `localhost:2283` only, all session

tokens discarded when the shell exited.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

The account work in `[0.4.98]` removed the first blocker, which left only the content

question — "which photo, keep or remove?" — to park item (41) a second time. That question

turns out not to need the investor: a test artifact generated here is nobody's content, so

the honest answer is *upload it, prove it, remove it*. The step also found a defect class

worth writing down: **a `204` from the delete route is not a deletion**, and the obvious

cleanup route would have destroyed another identity's real library.

`AssetMediaController` is `Controller('assets')` with a pathless `Post()`, and

`file-upload.interceptor.js` names the multipart field **`assetData`** with required form

fields **`fileCreatedAt`**/**`fileModifiedAt`**: `POST /api/assets` → **201

`{"id":"18899538-…","status":"created"}`**. (`/open-api.json` falls through to the SPA

HTML on this build, which is why the `.js` sources are the route table.)

asset back **200** with `exifImageWidth/Height 8/8, fileSizeInByte 145`, and the file at

`/opt/cloud/immich/data/library/upload/<admin-id>/2e/b6/….png` hashed to

**`77c0ca27abd49ffba7fe5e6dc298dcc1534fffd4` — byte-identical to the upload**, inside the

admin's own id from `GET /api/users/me`.

`DELETE /api/assets {"ids":[…]}` → **204**, and 80 seconds later the asset still read

**200 with `isTrashed: true`** and the original file was still on disk — it trashes, and

the file waits out the retention window. Reporting "removed" on the strength of that 204

would have been false.

`POST /api/trash/empty` exists, but empties trash **globally**, and this instance holds

real content — `43e01757-…` is `leon@gladex.de`, actively being written during this run.

`POST /api/search/metadata {"trashedAfter":…}` proved the trash held **exactly one**

asset (mine) before anything was considered; the route actually used was the **scoped**

one, `DELETE /api/assets {"ids":[…],"force":true}` → `AssetStatus.Deleted` +

`AssetDeleteAll` for **only the ids given**, so leon's data was structurally outside its

reach rather than merely believed safe.

**400 `{"message":"Not found or no asset.read access"}`** (this build's gone-shape, *not*

404 — recorded so 400 is never misread as a broken route; anonymous → 401);

`GET /api/assets/statistics` → **`{"images":0,"videos":0,"total":0}`**; metadata search →

**0**; trashed search → **0**; no file under the admin's library dirs; **0** leftover

`*.png`.

codes as measured, the `400`-as-gone gotcha, `force` vs `trash/empty` and why the global

route is refused, plus the `upload/<userId>/<a>/<b>/<uuid>.<ext>` storage layout);

`INBOX.md` line 424 gained a dated `UPD` block closing its test-photo half.

Model spend **0.00** (`*-free` only), **no money moved** (`BUDGET.md` untouched: **1.50

spent / 3.50 remaining**, month 2026-09, allowance 5.00), **zero DNS writes**, no paid API

key, **no secret read or printed** — the admin token lived in a shell variable for the

session only and was never logged, printed, written to a file or committed; the only

credential-shaped fact in any file is the investor's own declared rule "password = own

email". **No service restarted, no certificate touched, no promote executed, no mail sent**,

Nextcloud untouched (§14 still open), no image kept in the library.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

`[0.4.99]` closed the test-photo job and wrote its route facts into `STRUCTURE.md`, then

queued the obvious gap with its own words: *"the route facts now live in prose, but nothing

executes them"*. Prose cannot go red. An upgrade that moves `POST /api/assets` would leave

every gate in this repo green while `photos.gladex.de` broke for a human — so the contract

needed a runner, and the runner needed to be somewhere `regression-run` would **not** pick

it up, because it logs in as a real identity and writes to a real library.

The step earned its keep immediately: three of its own expectations were wrong on the first

execution, and every one of the three would have been reported as *"the contract moved"*

had they been written down as facts instead of measured.

default **read-only** mode proves the contract without writing: ping, login, user count,

the missing-id *gone* shape, the baseline statistics, and an **unauthenticated**

`POST /api/assets` that answers **401 while the route exists and 404 after an upgrade

removes it**, which is the route-table drift detector. `--execute` runs the full

round-trip: deterministic 8×8 synthetic PNG → `POST /api/assets` **201** → read back on

the API *and* on disk → `DELETE … {"force":true}` for **that id only** → gone →

statistics back to the recorded baseline.

top-level on v3.2.2 and is `null` inside `exifInfo` for a PNG, so the first

`asset-read` went red against a field that never holds it. Integrity now comes from

**`checksum`, measured as base64 of the sha1** — `b64decode(checksum).hex()` equals the

local sha1 exactly.

its own storage uuid sharded two levels deep (measured: asset `b9a90d4e…`, file

`4c929320….png` under `4c/92/`), so walking the library for `<asset-id>.png` searched

for something that cannot exist. The ground truth is the API's `originalPath`, and that

is a **container** path — `/data/upload/…` translates onto the host library dir because

`docker inspect gladex-immich-server` mounts Source

`/opt/cloud/immich/data/library` → Destination `/data`.

**200** a moment after the **204** and reads gone by ~2s, and `statistics` settles the

same way. Reading once would have reported the job's own latency as a broken contract;

both are now polled against `--wait` (default 15s).

which part did not execute is not a verdict about the part that did.

`POST /api/trash/empty` is never called (global; this instance holds other identities'

real content), the token is a local variable redacted from echoed bodies and absent from

the tool's own JSON output (grep against a live token: no match), and the credential is

**derived** — password = the account's own email, the investor's declared scheme — so no

secret literal exists to leak through world-readable argv.

exit-code table, the three corrected facts, safety, dependencies, live verification);

`STRUCTURE.md` gained the four-row **correction table** beside the route table plus the

drift-detector note, so no future run re-derives them.

`--help` **0**; `--bogus`, `--format xml`, `--wait -1`, `--timeout 0`,

`--expect-users -1`, `--base ftp://x` all **2**; unreachable base **3**;

`--expect-users 99` **1**; read-only run **6 met / 0 unmet / 1 skipped, exit 0**;

`--execute` **12 met / 0 unmet / 0 unverified, exit 0**. Baseline re-measured after three

write runs: statistics `{"images":0,"videos":0,"total":0}`, trashed search `total 0`,

**0** leftover `*.png`, `GET /api/users` still **8**, ping `{"res":"pong"}`.

Model spend **0.00** (`*-free` only), **no money moved** (`BUDGET.md` untouched: **1.50

spent / 3.50 remaining**, month 2026-09, allowance 5.00), **zero DNS writes**, no paid API

key, **no secret read or printed** (no password, token or credential in any prompt, log or

commit — only the investor's declared rule "password = own email" is recorded), **no

service restarted, no certificate touched, no promote executed, no mail sent**, Nextcloud

untouched (§14 still open), no image kept in the library.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

`[0.4.66]` opened this item with the observation that `--baseline` *"records counts but not

**why**"* — the exact defect its own `[0.4.65]` description had already named as the reason

the tool exists: *"every entry in this repo attributes its totals by hand … and hand

arithmetic is how '+110 somewhere' turns into an unverified 'no other suite moved'"*. The

tool closed the arithmetic half of that and left the prose half open for nine runs. Every

baseline this repo takes is taken *because something changed* — fixtures consolidated, a

suite split, a mutation added — and that reason lives only in whichever run entry somebody

remembered to write, so a baseline replayed weeks later prints `passed -2` and leaves the

reader to reconstruct the story from memory.

The fix had to satisfy the tool's own standing rule: **a field that exists but is never

read is a field that lies** (that rule is why `format` is validated before a baseline is

trusted, and it is quoted in `load_baseline`'s own comment). So `--note` ships with its

read half in the same step — write, store, report, refuse — rather than a key nothing ever

printed.

`note` key inside the baseline document (beside `timestamp`, so the *what* and the *why*

are read by the same path), and handed back by `--baseline` as `report["note"]`, which

`print_baseline()` renders as a ` note: <text>` line **directly under the report

header** — in the movement branch *and* in the `no movement` branch, because a baseline

taken for a reason that did not move anything still deserves its reason printed.

Human output is now *"gamma lost 2 assertions"* arriving beside *"note: consolidated

fixtures"* instead of a bare count.

**exit 2** (`"--note records why a baseline was written, so it requires

--save-baseline"`), and a blank/whitespace-only note → **exit 2**. Both sit with the

other flag-conflict checks, i.e. after argument parsing and before discovery, so the

refusal costs nothing. Under `--format json` it is still **one 14-key object** on stdout

with `exit_code: 2` and **empty stderr** — the D-section contract is unchanged.

written before this entry has none and must keep loading) but when present it must be

non-blank text, else exit 2 with `has a note that is not usable text` — the same

pre-run refusal position as `format`, `kind` and `totals`.

normally, reports `"note": null` in JSON (the key is always present, so a consumer sees

`null` rather than a key that appears and disappears) and prints **no** `note:` line at

all rather than an empty one.

its `Examples:` list carry the flag (all three are what `--help` renders — A5 still

compares them byte for byte), and `tools/REGISTRY.md` gains the option, the extended

exit-2 list, the `note` field in the baseline document shape and a **"Why, not just

what"** paragraph naming this entry as queue item (3).

`tests/test_regression_run.sh` **193 → 218 passed, 0 failed** — 23 new `I75`–`I94`

assertions covering the store, the human line, the JSON field, the note travelling with a

`moved[]` report, an old baseline (no line, `null` field), all three refusals and their

JSON shape, plus `A8`/`A9` pinning the usage line and the option's help — each one run

against the edited tool, never against the previous green. **Regression on the frozen

tree**: `./tools/regression-run --format json` → **54 suites, 4618 passed, 0 failed, 0

skipped, exit 0**, i.e. the green baseline `54 / 4593` plus **exactly +25** — this step's

own assertion count, nothing else moved. Behaviour probed by hand as

well as by the suite: `--note` stored and printed, `--note` alone → **2**, `--note` alone

under `--format json` → **2** with a **14-key** object and **0** bytes on stderr, blank

note → **2**, `--list --note` → **2**.

Model spend **0.00** (`*-free` only), **no money moved** (`BUDGET.md` untouched: **1.50

spent / 3.50 remaining**, month 2026-09, allowance 5.00), **zero DNS writes**, no paid API

key, **no secret read or printed**, **no service restarted, no certificate touched, no

promote executed, no mail sent**, Nextcloud untouched (§14 still open), the message DBs

touched only by this run's STEP 0 reply, and nothing under `/opt/cloud` touched at all.

`[0.4.101]` shipped `--note` and queued the question of bounding it in the same run, and

the queue item stated the defect exactly: *"the `note` is prose the runner supplies and

nothing constrains it"*. Two of its three examples are not style preferences. The report

prints ` note: <text>` at a **fixed two-space indent**, so a newline inside the text does

not produce multi-line prose — it produces a second line with **no prefix**, and the prefix

is precisely what makes a line read as this tool's own output: a note carrying `a\n` followed

by ` result: all suites green (exit 0)` yields a verdict a reader cannot distinguish from a

real one, in the report of the very tool whose job is trustworthy totals. A tab moves every

column the indent established. The third example, a note long enough to be a paragraph, is

the milder half of the same shape: the note is a **reason**, not a report, and there is no

length at which a reason becomes a report by being longer.

The bound is applied on **both halves of one field**, because this repo's standing rule —

*a field that exists but is never read is a field that lies* — cuts both ways, and the read

half of a lie is the same lie. A baseline document is JSON anyone can edit, so a note that

the write side refuses can still arrive on disk: `load_baseline` now holds a stored `note`

to the same two bounds, before any suite runs, at the position `format`, `kind` and `totals`

already occupy. Blankness was deliberately **not** folded into the new predicate: it has its

own message (`has a note that is not usable text`, pinned by `I93`/`I94`) and two rules

deciding whether one string is a note at all would be two places for them to disagree.

constants, so the `--help` text, the docstring prose and the refusal message cannot drift

apart from each other. `test_regression_run.sh` **A10** pins the single definition, **A11**

the option's rendered help (`at most 200 chars`, matched on one *unwrapped* line because

argparse wraps help text) and **A12** the docstring's own sentence (`at most NOTE_MAX

(200)`) — two renderings, one source. The suite reads the value out of the tool with a

fallback to the documented `200`, so when the constant disappears (which is what A10 goes

red on) the remaining bound assertions still *measure* a number instead of measuring the

empty string.

`127`, so newline, carriage return and tab included) → **exit 2**,

`--note must be a single line (no newline, tab or other control character)`; text past the

bound → **exit 2**, `--note must be at most 200 characters (got N)` with the real length in

it. Both sit with the existing `--note` checks — after parsing, before discovery — so the

refusal costs nothing, and under `--format json` it is still **one 14-key object on stdout**

with `exit_code: 2` and **empty stderr** (the D-section contract does not move).

the flag and the document, and `note_problem()` the single bound rule; a stored `note`

that breaks either → **exit 2**, `baseline <file> note must be a single line …` / `…

must be at most 200 characters (got N)`, raised from `load_baseline` before any suite runs.

A document with no note, or a short single-line one, keeps loading unchanged — every

baseline this repo has ever written still compares.

exit-2 line carry the bound (both are what `--help` renders — A5 still compares them byte

for byte), and `tools/REGISTRY.md` gains the extended `--note` option text, the extended

exit-2 list and a **"One line, at most `NOTE_MAX`"** paragraph under **"Why, not just

what"**, naming this entry as queue item (46).

`tests/test_regression_run.sh` **218 → 237 passed, 0 failed** — **19** new assertions

(`A10`–`A12`, `I95`–`I110`), each run against the edited tool: the newline and tab refusals

with their diagnosis and an empty stdout, the over-long refusal carrying both the bound and

the actual length, a note of *exactly* 200 characters accepted **and stored byte for byte**,

the JSON refusal's 14-key set with empty stderr, and the four read-side twins (stored

newline → 2 with `single line`, empty stdout, stored over-long → 2 with the length).

**Pre-fix replay, captured in place** (`git show HEAD:tools/regression-run` swapped over the

tool, old md5 `1f3f42137612a0e214de5b2408c2c9c2`, restored and re-verified byte-identical

against the new md5 `a334358a0e6b02031b7025968c1be31a`; log

`/tmp/opencode/note46/pre-fix.log`) → **222 passed / 15 failed**, i.e. `237 − 15`, every red

a finding: `A10` (no such constant), `A11`/`A12` (neither rendering exists), `I95`–`I98`

(the two control-character refusals were accepted, rc 0), `I99`/`I100`/`I103` (a 201-char

note and its JSON twin were accepted), `I106`–`I110` (the hand-edited documents all loaded

and ran). **Four guards passed pre-fix and thereby identify themselves**: `I101` (exactly

200 was always legal — the boundary must not move), `I102` (that note was always stored at

full length), `I104` (the usage verdict's key set) and `I105` (stderr empty on a refusal,

which pre-fix passed because nothing refused). **Regression on the frozen tree, before the

commit**: `./tools/regression-run --format json --log-dir /tmp/opencode/note46/regr` →

**54 suites, 4637 passed, 0 failed, 0 skipped, exit 0**, all 54 `ok`, no conflicts — the

green baseline **54 / 4618** plus **exactly +19**, this step's own assertion count, with no

other suite's count moving. Behaviour also probed by hand, outside the suite: the newline,

tab and 201-char notes each → 2 with the message above; the 200-char note → 0 and its

`note` field reads back at length 200; replaying that baseline prints the note; the three

tampered documents (newline, 201 chars, `42`) → 2 each, the last still with the pre-step

message `has a note that is not usable text`.

Model spend **0.00** (`*-free` only), **no money moved** (`BUDGET.md` untouched: **1.50

spent / 3.50 remaining**, month 2026-09, allowance 5.00), **zero DNS writes**, no paid API

key, **no secret read or printed**, **no service restarted, no certificate touched, no

promote executed, no mail sent**, Nextcloud untouched (§14 still open), Immich untouched

(library still `total: 0`, 8 accounts), the message DBs touched only by this run's STEP 0

reply (dev 97 / prod 63), and the only files changed are this entry, `tools/regression-run`,

`tests/test_regression_run.sh`, `tools/REGISTRY.md` and `agent-logs/PROGRESS.md`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

`[0.4.100]` closed its own entry by writing that the three corrections

`tools/immich-roundtrip` made *"are now pinned only by prose and a live run —

nothing **fails** when a future Immich image changes `checksum` to hex or moves

`originalPath`"*, and queued that gap as **(45)**: *"a `tests/` suite that

repeats the 201 → verify → delete → baseline round-trip and asserts the four

statuses"*. Run 256 did exactly that work — 996 lines of suite — and its

harness commit landed the suite and the tool fix together with **nothing

else**: no `agent-logs/PROGRESS.md` entry, no `CHANGELOG.md` entry, no

`tools/REGISTRY.md` line. Three documents were left asserting the opposite of

the tree, and none of them was wrong *before* that commit:

`## immich-roundtrip` while `tests/test_immich_roundtrip.sh` sat in `tests/`

and `regression-run` had already discovered it — the suite counts moved

**54 → 55** with no document saying so. Measured, not remembered:

`git grep -c test_immich_roundtrip HEAD -- CHANGELOG.md

agent-logs/PROGRESS.md tools/REGISTRY.md` → **no match** in any of the three.

the repo's own one-home list named work that was already history.

slipped in"* — sat unchanged above a landed change.

A change nobody can find is a change nobody can review, and this repo's own

rule for that shape — *a field that exists but is never read is a field that

lies* — applies to documentation exactly as it applies to a JSON key.

`## immich-roundtrip` `**Tests**` paragraph now names

`bash tests/test_immich_roundtrip.sh` → **150 assertions**, its sections

**A–J**, its mutations **M1–M6**, and the three independent hermetic layers

(a stub the suite starts on an ephemeral loopback port per run;

`GLADEX_IMMICH_BASE` pinned to the **closed** port `127.0.0.1:1` for every

invocation, so a run that lost `--base` fails with exit 3 in milliseconds

instead of reaching the live `:2283`; the live library

`/opt/cloud/immich/data/library` never opened, so no credential of any kind

exists in the file). The live-run readings that preceded the suite are kept

beside it rather than replaced — they are still true and they test something

the suite cannot (a real service).

actually means**: the *tool* is not a suite — it logs in as a real identity

and writes to a real library, so `regression-run` must never run it

unattended — while the stub-backed suite beside it is. Both facts used to be

one sentence, which is how the registry came to say "none" about a file that

existed.

40-char hex digest is accepted and is tested **first**, because hex digits

are a subset of the base64 alphabet and 40 is a multiple of 4, so

`b64decode` on a hex digest does *not* raise — it silently returns 30

unrelated bytes and fails a comparison against a value that was correct all

along. Base64-first is what made the tolerance dead code; run 256's own

**E2** and **J/M1** pin the ordering, which is the reason

`tools/immich-roundtrip` changed in the same commit as the suite.

file.** `768e5a6` (`[0.4.102]`) appended its pointer paragraph *above* the

one already there, so `CHANGELOG.md` ended with the same paragraph twice.

It was found by counting rather than by eye: `grep -c '^### Queue'` → **61**

against `tools/queue-source-check`'s reported **60**, because exactly one of

the 61 sits inside a fenced block by design (`[0.4.67]`'s quoted shape) and

the other extra was this duplicate — verified by parsing the file the way

the tool parses it (60 outside fences, 1 inside). Both duplicate paragraphs

were pointer-only (0 list items), so the frozen **111** item lines were

never at risk; the counted sections went **60 → 59** with the removal and

are back to **60** with this entry's own pointer.

passed, 0 failed**, exit 0 — every line read from that run.

(`/tmp/opencode/r257/test_immich_roundtrip.sh.log`) → **150 / 0**.

`./tools/regression-run --format json --log-dir /tmp/opencode/r257` →

**55 suites, 4787 passed, 0 failed, 0 skipped, exit 0**, `conflicts []`,

all 55 `ok` — the green baseline **54 / 4637** plus **exactly +150**, this

step's own measurement of a suite that was already in the tree

(`4637 + 150 = 4787`, `54 + 1 = 55`; split **31 shell = 3287 / 24 PHP =

1500**, PHP unmoved at 1500). The only files `768e5a6..HEAD` touched under

`tests/` and `tools/` are the two run 256 committed, so no other suite could

have moved — that is the closure, not a per-suite diff re-derived by hand.

tools/immich-roundtrip` → `d956dfd05455b6eac47b04c955cc5a22` /

`e2eb10b4f0061712dfa5aaf56b0895bb`, both **identical to `git show HEAD:<path>`**

— this step does not touch either file, it documents run 256's.

*"[0.4.103] pointer-only, 111 item line(s) frozen across 60 section(s), 66

PROGRESS bullet(s)"* (the section count returns to 60 after the dedup, the

bullets 65 → 66 is this entry's own). `bash tests/test_queue_source.sh` →

**122 / 0**; `bash tests/test_repo_lint.sh` → **420 / 0**;

`php tests/test_changelog_api.php` → **86 / 0**;

`php tests/test_app_version.php` → **39 / 0**;

`php tests/test_cli_version.php` → **35 / 0** — all five re-run against the

edited files, not carried from the run before them. `tools/repo-lint --format

json` pre-commit → exit 0, `ok true`, **`files_total 199`**, `changelog_version

entries 107, unique 107, duplicates [], citations_missing []` (the file count

is **199, not the 198 every earlier entry quotes**: `fc76ca7` added the suite

file, and `git ls-files | wc -l` agrees — a live number quoted from history

is the same defect this entry exists for): it lints **committed** blobs by

design, so the 107 → **108** movement and the new `[0.4.103]` citation inside

`REGISTRY.md` are asserted post-commit instead of carried here. `tools/source-sync-check` →

in sync, `drift false`, 42 files / 2 envs (`CHANGELOG.md` and

`REGISTRY.md` are not in the synced set, which is why no promote or sync

follows a documentation commit). `tools/system-status --format json` → rc 0,

`overall ok`, `errors 0`: 36 checks, 33 ok, the standing three warnings

(`cloud` — Nextcloud `installed:false`; `SOA:gladex.de` — MNAME

placeholder, NEEDS-INVESTOR; `promote-gates` — stale reviewer verdict).

"before" tool is `tools/immich-roundtrip` as of `768e5a6`, and the defect it

exists for is already reproduced *inside* the suite by its own **M1** mutant

(base64-first ordering, real `rc=0/met` vs mutant `rc=1/unmet`) — replaying

a tool against a suite that was written to catch that tool's defect would

restate M1 for the same bytes.

Model spend **0.00** (`*-free` only), **no money moved** (`BUDGET.md`

untouched: **1.50 spent / 3.50 remaining**, month 2026-09, allowance 5.00),

**zero DNS writes** (no `pdns-api.py` call), no paid API key, **no secret read

or printed** — this run created no credential of any kind and no password,

token or prompt-carried secret exists anywhere in it; the only

credential-shaped fact recorded remains the investor's own declared rule

"password = own email". **No service restarted, no certificate touched, no

promote executed, no mail sent**, Nextcloud untouched (`status.php` →

`{"installed":false}`, REPORT.md §14 still the open ask), Immich untouched

(`/api/server/ping` → `{"res":"pong"}`, 8 accounts, library baseline

unchanged), the message DBs touched only by this run's STEP 0 reply

(**dev 99 / prod 65**), and the only files changed are this entry,

`tools/REGISTRY.md` and `agent-logs/PROGRESS.md`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

`[0.4.103]` closed by *finding* the defect instead of fixing it: the duplicate

`### Queue` paragraph `[0.4.102]` had left at EOF was removed by hand and

queued as **(49)** — *"a rule asserting at most one `### Queue` section per

`## [x.y.z]` entry (plus 'raw headings = counted + fenced') would turn this

class into a red at commit time instead of a 3-line diff nobody looked at"* —

with the caution that it is a parser rule over a file five identities append

to, and so its own careful step.

The measurement that entry recorded is the argument. At `768e5a6` (the

`[0.4.102]` commit) `sed -n '/^## \[0.4.102\]/,/^## \[0.4.103\]/p'` showed the

entry owning **two** `### Queue` headings, and `grep -c '^### Queue'

CHANGELOG.md` → **61** against this tool's **60** sections — while

`tests/test_queue_source.sh` stayed **122 passed / 0 failed** and

`tools/repo-lint` stayed **exit 0**. Nothing was slow or missed by a lazy

check; the shape simply had no owner.

**No rule the tool had was wrong, and that is the point:**

pointer carries **none** — the freeze read **111** with the duplicate and

**111** without it.

last* `## [x.y.z]` heading. The stray paragraph sat in a **historical**

entry, so it was never examined; had it sat in the newest entry, the *other*

copy would have been the last one and the stray would still never have been

examined. Either way one of the two is unread by construction.

And the totals could not help either: raw **61 / sections 60 / fenced 1**

*before* the hand-fix and **61 / 60 / 1** *after* it — one duplicate removed,

one legitimate `[0.4.103]` pointer added, every aggregate unchanged. A rule

watching totals was guaranteed to see nothing; only the **distribution across

entries** moved (`[0.4.102]`: 2 → 1). That is (49).

`parse()` already records `section["version"]`, so the tally is

`sections[*]["version"]` counted per key: `duplicate_queue_sections` is the

number of **entries** offending (one entry with three sections → `1`; two

entries with two each → `2`), reported per entry as

*`CHANGELOG.md entry [x.y.z] owns N '### Queue' sections - one pointer per

entry`*. A `### Queue` written above the first `## [x.y.z]` heading has no

version and is keyed separately (`[?]`), so an unversioned section is never

silently merged into a real entry's count.

`count_queue_headings()` walks the file **again** with its own fence state

and answers *"what is written"*, where `parse()` answers *"what did I turn

into a section"*; the fenced term is what separates **quoted** from

**dropped**, since without it any dropped heading would read as a fence. The

heading **pattern** is deliberately shared (`QUEUE_RE`): "what counts as a

`### Queue` heading" is one definition, and the disagreement R7 is built for

is a heading **seen and not acted on** — a `### Queue` above the first

version heading that a future `parse()` stops reading. It is stated plainly

in `REGISTRY.md` that on today's `parse()` the two readers agree **by

construction**, so R7's green is a tripwire and not a finding; **M12** is

what proves it can go red. R7 does **not** catch duplicates — `parse()` read

both of `[0.4.102]`'s headings, so 61 == 60 + 1 held right through the

defect. R6 catches duplicates; R7 catches silence.

`queue_headings_fenced`, `duplicate_queue_sections`. The top-level object

stays at **11 keys** — the addition lives inside `rules`, which is the set

`A20` pins — and the **usage object (exit 2) now carries the same 11

`rules` keys**, `frozen_items_expected` stated as the constant it is and

every key the parse decides `null`, pinned by the new **H16**.

*("one entry owns two `### Queue` sections, or a `### Queue` heading was not

read as a section"*)* alongside the original three, and the docstring's

`Rules` list grew **R6**/**R7** — one copy, because `--help` renders the

docstring.

bullets (why R1–R4 are structurally blind; what the census can and cannot

prove), the JSON paragraph's `rules` key list, the exit-**1** bullet, and

both `Status` lines (`## queue-source-check`, `## test_queue_source.sh`).

**+33** = `H16` (1) + new section **N** (23) + **M11** (3) + **M12** (6),

with `A20` relabelled *8 keys → 11 keys* and otherwise unchanged. Section

tally read off the run's own `PASS:` lines: **A 21, B 8, C 6, D 6, E 6,

F 5, G 14, H 16, I 6, K 6, L 9, N 23, J 7, M 22**.

over the tool (old md5 `17541f05bb711bee1f7f4305d252eba4`, restored and

re-hashed to `dbde5b00333ff3e7f4b46c949ffc28e8`, log

`/tmp/opencode/q49/pre-fix.log`) → **129 passed / 26 failed**, first line

`A20 rules key set is exactly the documented 11 keys`. Every red is a

finding (`N5 … exits 1 (want rc=1 got 0)`, `N10 exactly one violation

(want 1 got 0)`, `M11 dropping R6 is caught (mutant exited 127, not

runnable)`, `M12b … (want rc=1 got 0)`); **eight are guards that passed

against the pre-fix tool and identify themselves** — N8 and N9 (the freeze

and pointer keys already existed, so those assertions only ever read a

number), N15, N16, N21, M12a, the M12 build (its needle is in `parse()`,

which this step did not touch) and M12e.

hidden by it**: `H16` was written to require the usage object's `rules`

values to be *all* `null` and failed on `frozen_items_expected`, which the

usage object has always stated as `FROZEN_ITEMS`. The assertion was wrong

and the tool was not; the fixed assertion states the constant explicitly,

and the correction is in `REGISTRY.md`'s **H** bullet instead of being

quietly rewritten.

`duplicate_queue_sections 0`, `queue_headings_raw 61`,

`queue_headings_fenced 1`, `queue_sections 60` — 61 == 60 + 1, i.e. the

tool now reports the exact pair `[0.4.103]` found by hand.

`bash tests/test_queue_source.sh` → **155 / 0**;

`php tests/test_changelog_api.php` → **86 / 0**;

`php tests/test_changelog_mobile.php` → **125 / 0 / 0**;

`php tests/test_app_version.php` → **39 / 0**;

`php tests/test_cli_version.php` → **35 / 0**; `tools/source-sync-check` →

in sync, 42 files / 2 envs; `tools/repo-lint --format json` pre-commit →

exit 0, `ok true`, `files_total 199`, `entries 108, unique 108, duplicates

[], citations_missing []` — it lints **committed** blobs, so the 108 → 109

movement and the `[0.4.104]` citations inside `tools/REGISTRY.md` are

asserted post-commit instead of carried from here.

records, so the fence logic, the freeze, `newest_section` and the `detail`

sentence all keep their bytes, and the 122 assertions that pinned them are

untouched.

R1–R7 while the source comments still carry an older R1–R9 layout

(frozen = "R4", the pointer rules = "R5 / R6 / R7", the bullets rule =

"R9") and `tests/` quotes *both* conventions. Normalising them is a rename

across three documents and two suites at once — queued as **(50)**, and the

new comments say `docstring Rn` until then so this entry does not add a

fourth scheme.

the original three exit-1 causes.** They are *paraphrases*, not copies of

the epilog (they already word it differently), and rewording another

tool's help is the same "four copies, nothing compares" family — queued as

**(51)** rather than half-done here.

no promote, no service restart, no certificate touched, **zero DNS writes**,

no mail sent, Nextcloud untouched (`installed:false`, §14 open), `/opt/cloud`

untouched, Immich untouched (`{"res":"pong"}`, 8 accounts, library baseline

unchanged).

Model spend **0.00** (`*-free` only), **no money moved** (`BUDGET.md`

untouched: **1.50 spent / 3.50 remaining**, month 2026-09, allowance 5.00),

**zero DNS writes** (no `pdns-api.py` call), no paid API key, **no secret read

or printed** — this run created no credential of any kind and no password,

token or prompt-carried secret exists anywhere in it; the only

credential-shaped fact recorded remains the investor's own declared rule

"password = own email". **No service restarted, no certificate touched, no

promote executed, no mail sent**, Nextcloud untouched (`status.php` →

`{"installed":false}`, REPORT.md §14 still the open ask), Immich untouched,

and the message DBs touched only by this run's STEP 0 reply (**dev 100 /

prod 66**).

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

`[0.4.104]` wrote down the defect it was deliberately *not* fixing, inside the

tool's own source: *"the docstring and `tools/REGISTRY.md` number these rules

`R1-R7`, while the source comments below still carry the older `R1-R9` layout

(frozen = `R4`, the pointer rules = `R5 / R6 / R7`, the bullets rule = `R9`) …

New comments say `docstring Rn` until that is normalized - queued, not fixed

here."* It queued that as **(50)**, calling it *"exactly the epilog-copy defect

`[0.4.59]` closed applied to numbering"*.

The queue item said three documents. Measured while doing it, it was

**four** — plus a fifth file straddling both conventions:

| where | what it said about the same seven rules |

|---|---|

| `tools/queue-source-check` module docstring | `A1`–`A3`, `R1`–`R7` |

| `tools/REGISTRY.md` → `## queue-source-check` rules table | `A1–A3`, `R1`–`R7` |

| `tools/queue-source-check` **source comments** | the freeze check labelled from the retired numbering, the pointer block as a run of three, the bullets rule as a number the docstring never declared, availability as two more |

| `tools/REGISTRY.md` → `## test_queue_source.sh` mutation list | the bullets rule under its retired number, in the middle of a list whose other entries already used the current one |

| `tests/test_queue_source.sh` | both at once: the retired number in `L`'s history and in `M9`'s label, the current one in `D`, `N`, `M11` and `M12` |

**Why nothing had noticed for twenty-two versions**: no assertion anywhere

compared a *citation* against the *declaration*. The rules themselves were

tested hard — 155 assertions of them — but "does this comment name a rule the

docstring actually declares?" was a question no code asked. That is the same

shape as `[0.4.59]` (two copies of one contract, neither compared) and as

`[0.4.102]` (two `### Queue` sections under one entry, no rule asking how many

an entry owns): a disagreement between two copies is invisible to any check

that only ever reads one of them.

verified by its own grep afterwards: the availability comment above the

changelog read → `# A1:`; the availability comment above the progress read →

`# A3:`; a **new `# A2:`** on the `if not sections:` branch, which was the

one declared availability rule that had *no* comment at all; the freeze

comment → `# R1:`; the three-in-one pointer comment → `# R2 / R3 / R4:`; the

bullets comment → `# R5:`; and both transitional `docstring Rn` comments →

`# R6` / `# R7`.

replaced by the invariant it used to describe: one scheme across docstring,

comments and registry, asserted by `tests/test_queue_source.sh` **section O**

rather than by a comment promising to fix it later.

`M9`'s label) and its `drop docstring R6` → `drop R6`; **`REGISTRY.md`'s

`## test_queue_source.sh` mutation list** gained the fourth rename. That last

one is the place the queue item had not counted: it is a *documented copy* of

the suite's own labels, in the file that also carries the rules table.

three files and prints one violation per line:

- every `[AR]n` token in the **tool** must be among the rules the module

docstring declares — declarations parsed as `^ R<n>` **inside the

docstring only**, where continuations are indented eight spaces and comments

start ` #`, so neither can be mistaken for a rule;

- every `R<n>` token in the **suite** must be declared;

- `REGISTRY.md`'s `## queue-source-check` **rules table** must carry rows

that are all declared *and* a row for every declared `R` rule, and its

`## test_queue_source.sh` section's `R` citations must be declared —

**scoped by heading**, because `REGISTRY.md`'s `## repo-lint` section

legitimately numbers a *different* suite's sections `R1`–`R19`, and a

file-wide scan would report that as this tool's defect;

- the retired transitional qualifier must be absent from all three;

- and the **pairing half**: every declared rule must be named by at least one

source comment, so a rule with no comment pointing at its code is red.

- **`A`-tokens are deliberately NOT checked in the suite**: section A numbers

its own assertions `A1`–`A21`, so an `A` number in that file is an

assertion id and has never been a rule citation. Checking it would report

the harness's own labels as defects. That prefix collision is queued as

**(52)** rather than papered over with a heuristic.

`O3` a retired citation appended to a copy of the tool · `O5` the same in a

copy of the suite · `O6` an undeclared row **inserted into `REGISTRY.md`'s

rules table** — inserted rather than appended, because a line appended at EOF

falls outside every `## ` section and would be invisible by construction ·

`O7` one rule line deleted from the docstring's declaration · `O9` the

retired qualifier planted back · `O11` a comment naming a rule deleted, so a

declared rule is left with nothing pointing at it.

`doc""string`): the suite is one of the three files the checker scans, so

writing the retired numbers or the retired phrase into it would make `O1` red

forever. The retired numbers are recorded in this entry and in `PROGRESS.md`

instead — neither file is scanned.

over `scheme_violations()`, `bash -n` clean) and run against the three `HEAD`

blobs: md5 `69b80ecf` (`REGISTRY.md`), `dbde5b00` (`queue-source-check`),

`dbdb7c50` (`test_queue_source.sh`) — the same three digests

`[0.4.104]`'s post-commit entry records, so these are genuinely the committed

pre-step bytes, not a reconstruction: **10 violations**, against **0** on the

worktree. The ten: the tool `cites R8` and `cites R9`; the tool `declares

A1` / `A2` / `A3` / `R2` but no source comment names any of them; the suite

`cites R9`; `REGISTRY.md` → `## test_queue_source.sh` `cites R9`; the tool

`carries 4 transitional qualifier(s)`; the suite `carries 1 transitional

qualifier(s)`.

**155** — exactly **+12** for `O1`–`O12`, section tally read off the run's own

`PASS:` prefixes — **A 21, B 8, C 6, D 6, E 6, F 5, G 14, H 16, I 6, K 6,

L 9, N 23, J 7, M 22, O 12** = 167.

`./tools/regression-run --format json --log-dir …` → **55 suites, 4832

passed, 0 failed, 0 skipped, exit 0**, `conflicts []`, all 55 `ok` — the

green baseline **55 / 4820** plus **exactly +12**, this run's own assertion

count (`4820 + 12 = 4832`), split **31 shell = 3332** / **24 PHP = 1500**

(`3320 + 12 = 3332`; PHP unmoved, because this step touches a shell suite, a

python tool and two documents).

the live tree proves it: `tools/queue-source-check --format json` →

**exit 0**, `ok true`, `violations []`, `frozen_items_actual 111`,

`queue_sections 61`, `queue_headings_raw 62`, `queue_headings_fenced 1`,

`duplicate_queue_sections 0`, `progress_bullets 67`.

`bash tests/test_repo_lint.sh` → **420 / 0**;

`bash tests/test_queue_source.sh` → **167 / 0**;

`php tests/test_changelog_api.php` → **86 / 0**;

`php tests/test_changelog_mobile.php` → **125 / 0 / 0**;

`php tests/test_app_version.php` → **39 / 0**;

`php tests/test_cli_version.php` → **35 / 0**; `ast.parse` on the tool and

`bash -n` on the suite both clean; `tools/source-sync-check` → in sync, 42

files / 2 envs; `tools/repo-lint --format json` pre-commit → exit 0,

`ok true`, `files_total 199`, `entries 109, unique 109, duplicates [],

citations_missing []` — it lints **committed** blobs, so the 109 → **110**

movement and the `[0.4.105]` citations inside `tools/REGISTRY.md` are

asserted post-commit instead of carried from here.

**A comment naming a DECLARED rule above the wrong block.** After this step

`# R1:` sits above the freeze check — but nothing in `O` proves that pairing,

because which code a rule owns is a human judgement, not a parse. Before the

fix that gap was filled by the retired numbers and by the qualifier, so the

replay above is red either way; a future misplacement that used only declared

numbers *and* kept every comment present would be green. Queued as **(53)**

rather than closed by pinning the comment wording: a wording pin would make a

harmless reword a red while proving nothing about ownership.

`count_queue_bullets()`, `count_queue_headings()`, `FROZEN_ITEMS`, the

epilog and every `violations[]` sentence keep their bytes, so the 155

assertions that pinned them are untouched — only comments, two documents and

a new suite section moved.

existed and already ran; it simply had no label pointing at it.

by name in `REGISTRY.md` (`A20 rules key set is exactly the documented 11

keys`) and across several `PROGRESS.md` entries; renaming 21 labels to free a

prefix nobody currently confuses would be a larger diff than the defect, so

it is queued as **(52)** with the reason spelled out.

**(51)**, untouched by this step.

no promote, no service restart, no certificate touched, **zero DNS writes**,

no mail sent, Nextcloud untouched (`installed:false`, §14 open), `/opt/cloud`

untouched, Immich untouched (`{"res":"pong"}`, 8 accounts, library baseline

unchanged).

Model spend **0.00** (`*-free` only), **no money moved** (`BUDGET.md`

untouched: **1.50 spent / 3.50 remaining**, month 2026-09, allowance 5.00),

**zero DNS writes** (no `pdns-api.py` call), no paid API key, **no secret read

or printed** — this run created no credential of any kind, and no password,

token or prompt-carried secret exists anywhere in it; the only

credential-shaped fact recorded remains the investor's own declared rule

"password = own email". **No service restarted, no certificate touched, no

promote executed, no mail sent**, Nextcloud untouched (`status.php` →

`{"installed":false}`, REPORT.md §14 still the open ask), Immich untouched,

and the message DBs touched only by this run's STEP 0 reply (**dev 101 /

prod 67**).

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

`[0.4.105]` closed queue item (50) and queued **(51)** in its *Deliberately

not done*: *"the exit-1 sentence now has **four** copies —

`tools/queue-source-check`'s epilog (updated), `tools/REGISTRY.md`'s exit-1

bullet (updated), `tools/system-status`'s `--help` prose and its source comment

(**not** updated, both naming only the original three causes) — and nothing

compares them, so the next exit-1 cause will leave two of the four quietly

stale."* Measured this run rather than repeated:

| copy | what it said about the same list |

|---|---|

| `queue-source-check` epilog (`EPILOG`) | **five** causes |

| `REGISTRY.md` → `## queue-source-check` exit-1 bullet | five, worded differently (`A violation`, `one \`## [x.y.z]\` entry owns **two**`) |

| `system-status --help`, `error` row | **three** causes |

| `system-status` source comment, `child exit 1 ->` line | **three** causes |

`grep -rn "a second list exists" tests/` → **nothing**: no assertion anywhere

read that sentence, so twenty-two versions could pass while half the copies

described a different tool. Two collateral facts were found by doing the work

and had to be fixed before the sentence above could honestly be called closed:

derived from the module docstring, so `--help` and the source cannot

disagree"** — **false for this tool**: `EPILOG` is one literal

(`tools/queue-source-check:175`) and the module docstring declares no exit

codes at all. That is the worst shape of a stale copy: a reassurance that

tells the reader not to check.

(`the 25 … historical sections`): live `rules.queue_sections` reads **62**.

The number grows with **every** CHANGELOG entry, so it is stale by

construction — a *correct* copy would only be correct until the next run.

`--help` `error` row now says the child's own `detail` already carries every

cause and that the list is deliberately not restated here, naming

`violations[]` as the place to read it; the `child exit 1 ->` source comment

says the same and records *why* (three causes written where the child

reported five, nothing comparing them). The `ok` row's section count is gone

too, replaced by "the live numbers are the child's `rules` object".

Neither copy is allowed to enumerate again — **P9** forbids the enumeration,

**P10** separately requires a pointer in **each** copy, so an edit that merely

deletes the sentences is not a fix.

replaced.** The exit-1 bullet now carries the epilog's cause list word for

word (its hint kept, plus a sentence saying the list is compared and by

what); the `--help` bullet states that the epilog is **one literal, not

derived**, and that agreement with this file is section **P**'s job; the

`Purpose` paragraph drops the section count.

`after [0.4.66]` paragraph and the reason is written in its place (three

copies said 25 while `rules.queue_sections` read 62, the day this entry

removed them). `EPILOG`, `parse()`, `count_queue_bullets()`,

`count_queue_headings()`, `FROZEN_ITEMS` and every `violations[]` sentence

keep their bytes — **the tool's behaviour did not change**, and

`--help`'s rendered exit-code block is byte-identical to before.

<registry> <system-status>`, which prints `key=value` lines: both exit-1

blocks extracted (**scoped to `## queue-source-check`** — the registry holds

**23** same-shaped ``- `1` - `` bullets, one per tool, so a file-wide scan

would compare this tool against somebody else's exit code), normalized

(whitespace collapsed, markdown stripped, the trailing hint cut at the first

` (`), and compared; per-file counts of `<digits> historical sections`

taken over the file's **prose**, which for a shell script means the

concatenated contents of its `echo "..."` lines as well as raw text.

(two `<none>`s compare *equal*), `P5` pins where the epilog block starts,

`P7` requires both copies to enumerate the same **five-or-more** causes —

the count alone was never the defect, since the pre-step registry bullet

already listed five; only `P6`'s word-for-word comparison sees `A violation`

vs `a violation`.

in place** (`ab56a1a8` tool / `67c4204c` registry, the digest

`[0.4.105]`'s post-commit entry records / `ea8e82e2` system-status; backups

of the worktree taken first and `md5`-verified identical after the restore;

log `/tmp/opencode/q51/pre-fix.log`): **175 passed / 6 failed** of 181. The

six reds are **P6** (the two cause lists differ, printed in full), **P9**

(system-status still enumerates), **P10** (`help=0 comment=0` — neither copy

pointed anywhere), **P11** (a stale section count), **P13** (the plant lands

as **2**, because the real `25` was still there — the defect reported twice)

and **P14**. The **eight guards** — `P1`–`P5`, `P7`, `P8`, `P12` — are green

against the defect, which is what identifies them as guards.

historical sections` on raw lines finds **0 of 3** copies (the number and the

words sit on different lines, behind `"` and `echo "` noise in

`system-status`); whitespace-collapsed text finds the docstring's and the

registry's, and the `echo`-contents view is what finds `system-status`'s —

**3 of 3**. `P13` replants it inside an `echo` pair and requires the rule to

fire.

`ok true`, `violations []`, `queue_sections 62`,

`duplicate_queue_sections 0`, `raw 63 == sections 62 + fenced 1`;

`system-status --format json` → rc 0, `overall ok`, `errors 0`, 36 checks

with the standing warnings only (`cloud`, `SOA:gladex.de`, `git-tree` — this

run's uncommitted files —, `promote-gates`).

0** (was **167**, exactly **+14**; section tally **A 21, B 8, C 6, D 6, E 6,

F 5, G 14, H 16, I 6, K 6, L 9, N 23, J 7, M 22, O 12, P 14** = 181);

`bash tests/test_repo_lint.sh` → **420 / 0**; `php tests/test_changelog_api.php`

→ **86 / 0**; `php tests/test_changelog_mobile.php` → **125 / 0 / 0**;

`php tests/test_app_version.php` → **39 / 0**; `php tests/test_cli_version.php`

→ **35 / 0**; `ast.parse` on the tool and `bash -n` on the suite and on

`system-status` clean; `tools/source-sync-check` → in sync, `drift false`,

42 files / 2 envs; `tools/queue-source-check` → exit 0; every `[x.y.z]` token

this entry cites pre-grepped against the heading list (`0.4.59`, `0.4.65`,

`0.4.66`, `0.4.67`, `0.4.102`, `0.4.104`, `0.4.105` each exist once,

`0.4.106` is this heading).

**A rewording of BOTH remaining copies at once.** A comparison has two sides;

the most a test can do is compare the two copies that exist. That is why the

other two were *deleted* rather than brought into line: four copies compared

pairwise still leave the pair nobody wrote an assertion for. Second, the

summary lines of exit `0`/`2`/`3` are **not** compared — they are one-line

summaries, not cause lists, and `REGISTRY.md` deliberately adds context to

them that the epilog does not carry.

from its docstring; doing the same here would mean adding an `Exit codes:`

block to this tool's docstring plus the refusal machinery a missing heading

needs (`[0.4.60]`'s lesson) — a second change with its own blast radius.

The false *claim* of derivation is corrected instead, and the guarantee is

supplied by section P.

renumbered, no `rules` key added, no `violations[]` sentence touched** —

the 167 assertions that pinned them are unchanged.

no mail sent, Nextcloud untouched (`installed:false`, REPORT.md §14 still the

open ask), `/opt/cloud` untouched, Immich untouched (`{"res":"pong"}`, 8

accounts), and the message DBs touched only by this run's STEP 0 reply

(**dev 102 / prod 68**).

Model spend **0.00** (`*-free` only), **no money moved** (`BUDGET.md`

untouched: **1.50 spent / 3.50 remaining**, month 2026-09, allowance 5.00),

**zero DNS writes** (no `pdns-api.py` call), no paid API key, **no secret read

or printed** — this run created no credential of any kind; the only

credential-shaped fact recorded anywhere remains the investor's own declared

rule "password = own email", quoted in this entry's STEP 0 reply and nowhere

else.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

**Anything the eight probes do not report.** The script asserts the *verdicts* the repo's own tools publish, not the rules behind them — a tool that returned `ok` without checking would satisfy every assertion here, which is what `tests/test_repo_lint.sh`, `tests/test_queue_source.sh` and the PHP suites exist for. It also cannot see a warning `system-status` still classifies as a warning: `overall ok` is asserted, the standing `WARN` rows are deliberately **not** enumerated, so a fourth warning does not turn this monitor red while the tool that owns the verdict still calls the run healthy.

Model spend **0.00** (`*-free` only), **no money moved** (`BUDGET.md` untouched: **1.50 spent / 3.50 remaining**, month 2026-09, allowance 5.00), **zero DNS writes** (no `pdns-api.py` call), no paid API key, **no secret read or printed** — the only credential-shaped fact recorded anywhere remains the investor's own declared rule "password = own email".

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

**The copies are compared to each other, not to the code.** All three could say `124 → ok` in unison and 11b would be green; the `case "$GO_RC"` branch is pinned by sections 1–9 and by mutants M1–M6 instead. The maps also abstract over *how* a condition is worded: `killed by the budget (124/137) - not a verdict` and `124 / 137 (killed)` both classify as `killed` and so agree, which is the right call across two registers and is also exactly the seam along which wording could still drift unnoticed.

Model spend **0.00** (`*-free` only), **no money moved** (`BUDGET.md` untouched: **1.50 spent / 3.50 remaining**, month 2026-09, allowance 5.00), **zero DNS writes** (no `pdns-api.py` call), no paid API key, **no secret read or printed** — the only credential-shaped fact recorded anywhere remains the investor's own declared rule "password = own email".

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

The half of the 2026-09-26 mobile-sweep item that `[0.4.88]` handed over rather than shipped: *"`/docs` … its `<pre>` already scrolls, the real offenders are two tables (DNS Records 4-column, 390.3 px; Trust Scoring, 307.4 px) causing 102 px of document overflow at 320. Diagnosis, measurements and the wrapper-div recipe are written up in `agent-logs/identity-jonas.md`."* The recipe was written down and deliberately left untried, together with two recipes that were tried and rejected. This entry runs it.

Measured before touching anything, against the then-served dev page with chrome-headless-shell 154.0.8037.57 (`documentElement.scrollWidth - clientWidth`, each offender classified by whether it sits inside a scrollable ancestor):

| width | document overflow | elements past the edge outside a scroller |

|---|---|---|

| 305 | **117 px** | 32 — every one a `TABLE`/`TBODY`/`TR`/`TH`/`TD` |

| 320 | **102 px** | 26 — same |

| 360 | 62 px | 14 — DNS only |

| 414 | 8 px | 14 — DNS only |

| 768 / 1200 | 0 / 0 | 0 |

That last column is the whole diagnosis: **not one** element outside a scroll box was anything but a table or its cell, so the tables were the *entire* cause — the page's `<pre>` blocks already scrolled correctly.

`<div class="table-wrap" tabindex="0" role="region" aria-label="…">`, the label taken from the `h2`/`h3` directly above each table, so every table owns a horizontal scroll box **and** is reachable by keyboard when it scrolls (a scroll container nobody can focus is a keyboard trap's mirror image). Wrapping all nine rather than two is the difference between a rule and an anecdote: a tenth column added next shift inherits the guard.

**`tests/test_docs_mobile.php` — 70 assertions, 0 failed, 0 skipped** (`php tests/test_docs_mobile.php`), in seven sections:

1. **Structure, comment-stripped**: 9 `<table>`, 9 wrappers, every table between an *opening* wrapper and *its own* close (a regex that looks at the text before and after each table, not just a count).

2. **Wrapper contract**: `tabindex="0"`, `role="region"`, a non-empty `aria-label`, 9 distinct names, every name present as an `h2`/`h3` **on the page**, and each name being the heading *directly above* its wrapper — an invented region name reads worse than none.

3. **CSS**: `.table-wrap` parses as exactly one rule in comment-free source and declares `overflow-x: auto` **and** `0.75rem 0`; `table` declares **no** margin and keeps its width/border/font; the two rejected recipes are asserted to stay rejected; `pre` still scrolls.

4. **`repo == dev == prod`** byte-identical (md5 `3cb750b3cf3e08b234ed213d22e75eed` ×3).

5. **Served pages**: both envs answer 200 and their HTML carries 9 wrappers, focusable named regions, and the same CSS shape.

6. **5 mutants, all must be caught**: one table unwrapped · a wrapper that cannot scroll · the rhythm margin planted on `table` as well · the `.table-wrap` rule parked in a CSS comment · all 9 wrapper blocks parked in closed HTML comments. The shipped source is first asserted to pass *every* rule the mutants are judged by, so a mutant cannot "pass" by the rules being empty.

7. **Browser, optional by design** (`regression-run` must stay runnable on a box with no browser — it SKIPs, it never passes vacuously): the live dev page must measure **overflow 0 / 0 outside a scroller** at 320, exactly the two wide tables must scroll inside their wrapper (DNS **390 > 256**), and the same page with the wrappers stripped must measure **> 0** again — it measures **102**, the handover's own number.

**Pre-fix replay** (original `c15799a55f792bd4b7f3214a74de88cb` swapped in, then restored md5-verified): **43 passed / 27 failed, exit 1**, every structural and CSS rule red, byte-identity red against the deployed fixed copies. No PHP warnings on either run (stderr 0 bytes).

Two defects in the *first draft of this suite* were found by running it, not by reading it, and are recorded in the file so they are not reintroduced: the comment stripper used `!` as its PCRE delimiter and `<!--` contains an exclamation mark, so `!<!--.*?-->!s` closed after one character, returned `null`, and **silently stopped stripping** — every comment assertion behind it was green for free; and `preg_match('!margin\s*:', …)` was missing its closing delimiter, which made the "table keeps NO margin" assertion and one mutant check pass vacuously (`preg_match` returns `false` on a bad pattern, and `!false` is `true`). Both are now guarded by an explicit stripper non-vacuity probe.

Model spend **0.00** (`*-free` only), **no money moved** (`BUDGET.md` untouched), **zero DNS writes** (no `pdns-api.py` call), no paid API key, **no secret, `.env` or token read or printed**, **no certificate touched**, **no service restarted**, **no promote executed** — `promote-gates` still reports the reviewer verdict stale (`VERDICT-20260926-000744` is REFUSED/stale, i.e. "re-review required"), that was the state when this shift started and the direct-`cp` path above is what `[0.4.88]` used under the same state; **zero mail sent** (0 unread, `sendmail` never invoked, `noreply@gladex.de` never used); **investor web thread not written to** (STEP 0: 0 unread dev / 0 prod, no incoming message names me).

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Two queued items, both about the same failure mode: a contract written down in more than one place with **nothing reading the copies against each other**, so any one-sided edit stays green by construction.

**(57)** `tools/system-status` carries `# Contract (pinned by tests/test_system_status_go_compile.sh):` above the `go-compile` row — and `grep -rn "pinned by" tests/` matched **nothing at all**. The sentence claiming this suite pins the contract had no reader. `grep` per child, measured before writing anything: the `queue-source` claim *is* machine-checked (section P of `test_queue_source.sh` compares that comment against `--help` and the epilog), the `go-tests` claim was made true by `[0.4.108]`'s section 11b, and **go-compile + promote-gates pinned behaviour but never read their own comment's text**.

**(58)(a)** `08b2dbf` prepended a 7-line QA entry **above `# Changelog` itself**. That single prepend both duplicated `0.4.29` (the 2026-09-24 `landing.php` entry already owns it) and moved "the changelog top" to `0.4.29` while `GLADEX_APP_VERSION` and all four binaries still report `0.4.28`.

Entry count 115 before and after the re-homing — moved, not duplicated. Every historical `[0.4.29]` citation (they live in `agent-logs/identity-mia.md` and point at the `landing.php` entry) still resolves, which is why the repair renumbers instead of deleting.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Same failure mode as `[0.4.108]` (go-tests) and `[0.4.111]` (go-compile), one child further along: `tools/system-status` says `# Contract (pinned by tests/test_system_status_promote_gates.sh):` above the `promote-gates` row, and **nothing in that suite read the sentence**. Measured per child by (57): the suite reads the tool's source in sections 15/15b/15c/18/18b, but only for invocation strings, env tokens and mailbox stamps — so the `promote-gates verdicts` block in `--help`, the contract comment, and this suite's own `# The contract under test:` block were three hand-maintained renderings of one contract with **no assertion comparing any two of them**, and a one-sided edit of any copy changed nothing the suite could see.

Only the suite changed in `tests/`; `tools/system-status` is **byte-unchanged** — both of its copies were already correct and already agreed, which is the whole point of (57): the readers were missing, not the text. `tools/REGISTRY.md`'s promote-gates bullet carries the new count and the section-20 description. Item **(59)** struck; **(60)** and **(54)** (the `REGISTRY.md` evidence table / exit-code bullets — compare or declare) remain open.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

The brief's BOOTSTRAP block says *"Register every tool in /data/repo/tools/ (name, purpose, usage, exit codes)"* and *"Prove it"*, but **nothing read `tools/REGISTRY.md` as a coverage claim**: the four suites that mention the file each grepped their own section for their own keywords. So a script dropped into `tools/` with no section, a section that lost one of its four fields, and a section left behind by a renamed file were all invisible by construction — the same shape as the `pinned by this suite` comments `[0.4.108]`, `[0.4.111]` and `[0.4.112]` found unloved one child at a time, and the compare-or-declare gap already parked as (54)/(56).

Measured before writing anything: **20** files in `tools/`, **24** `## name` sections in `REGISTRY.md`, **0** unregistered, **20/20** answering `--help` with exit 0 and a non-empty body. The invariant **already held**, so this step is a guard, not a repair — it adds no fix and touches no tool's behaviour.

No tool's behaviour changed: `tools/system-status` is byte-unchanged, and the only other edit is the three-field completion of one `REGISTRY.md` section. No queue item was struck — this run executed a new observation rather than a carried candidate. **Spend 0.00** (`*-free` only), `BUDGET.md` untouched at 1.50 / 3.50 for 2026-09, **zero DNS writes**, no paid API key, no secret read or printed, no service restarted, no certificate touched, no promote executed, no mail sent. INBOX line 468 remains open and still blocked on REPORT.md §14 (Nextcloud `{"installed":false}`) — answered in this run's STEP 0 reply (**dev 106 / prod 72**) rather than pretended executed.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

`[0.4.113]` queued (64) as *"the `--help` claims exit 2 for unknown arguments and D2 measures it, but the tools side of the same claim (every registered tool's documented exit-2 line vs. its actual behaviour) is unchecked — `run_check` proves `--help` exits 0, not that the table under it is true"*. The fourth BOOTSTRAP field, `Exit codes`, was being asserted for **presence** only: a `tools/REGISTRY.md` section could promise `2 - Invalid arguments` while its tool returned `0` for the same argument, and every suite in the tree would stay green — the same shape as the unloved `pinned by this suite` comments (55)/(57)/(59), one child further along, this time inside the suite that was written to close that class.

Measured before writing anything, so the step knows what it is: **20/20** tools answer exit **2** on an unknown flag, fast (validation before any I/O — the whole sweep runs in ~2s), and **20/20** tables list a code 2, including the two shapes a naive parser misses — `immich-roundtrip`'s **wrapped header** (`**Exit codes** (precedence …` over two lines) and `smtp-relay-probe`'s **non-sequential list** (`1 4 3 0 2`, first-match-wins). The invariant already held, so this entry is a **guard, not a repair**: no tool changed, `tools/system-status` is byte-unchanged.

**No tool edited**, no service restarted, no certificate touched, no promote executed, **zero DNS writes**, no paid API key, **no secret read or printed**, **spend 0.00** (`*-free` only), `BUDGET.md` untouched at 1.50 / 3.50 for 2026-09. Item **(64)** struck; INBOX line 468 remains open and still blocked on REPORT.md §14 (Nextcloud `{"installed":false}`) — answered in this run's STEP 0 reply (**dev 107 / prod 73**) rather than pretended executed.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

A keyboard sweep of every public route — tab every stop at a 320px viewport and compare each focused element against **its own** unfocused computed style, so "the border changes" is measured rather than assumed — found exactly **one** family of controls left behind on the whole site: `/trust`'s `#src`, `#tgt` and `#outcome`. Each one goes `outline: none` → *nothing*, changing only `borderTop`/`borderLeft` from `--border` (`#2a2a38`) to `--accent` (`#6c5ce7`): a 1px colour swap. Every other stop gained a real ring — links and buttons through the UA's `outline: auto`, the chat composer and the mailbox composer through the `:focus-visible` rules added for them on 2026-09-24 — because the cause here is one line that predates them all: `.form-row input, .form-row select { outline: none; }` with a `:focus` rule that only swaps the border. That exact pattern is already rejected *in this same file* for the composer (*"the border-colour swap above is invisible on a dim monitor"*); `/trust` was simply never given the recipe.

The same three fields were also the last **unnamed** ones: `#outcome` is a `<select>`, which has no placeholder to fall back on, so its accessible name was the **empty string** (measured: `accname=""`), and `#src`/`#tgt` leaned on `placeholder=` — a hook most screen readers do not expose as a name. `[0.4.109]`-era `tests/test_chat_a11y.php` closed the same two defects for the investor composer and `tests/test_mailbox_a11y.php` for the mailbox composer; this entry closes them for the third and last form.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

`tools/REGISTRY.md` is where this repo writes its own numbers, and it carried **six** `<N> suites` figures: `- Live: ./tools/regression-run → **40 suites, 3396 passed**` with no date on the line, `**Status**: Green ✅ 2026-09-27 (… 52 suites / 4267 …)` in `repo-lint`'s section, `**Status**: Built ✅ 2026-09-26 (… 41 suites / 3503 …)` in `regression-run`'s own, a `54 suites / 4593` measurement inside `system-status`'s with no date at all, and two dated-narrative figures in `regression-run`'s Purpose and Summary-parsing prose. Measured, not assumed: **2 of those 6 lines were undated** and **3 presented a total as current**, while `regression-run --list` discovered **59** — the bullet a reader would quote was five suites and roughly 700 assertions short of the tree, and no suite in the repo read that line or the tool it claims to summarise. That is the (55)/(57)/(59) shape one child further along, except the claim here is the number every CHANGELOG entry quotes.

The fix is a reader, not a refresh: writing `59` over `40` by hand would leave the same line to rot again the next time a suite is added.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

`(64)` proved every tool refuses an unrecognised flag — and that was the easy half. A tool can reject `--regcov-not-a-real-flag` all day and still accept a value of a flag it declares, which is the argv a caller actually types. Measured 2026-09-28 across the 17 tools whose `--help` advertises `--format`: **15 refuse `--format xml` with exit 2** (argparse `choices`, or a `case` that names them) and **2 do not** — the two hand-rolled bash parsers.

The `--timeout` half was measured the same way and needed no repair: of the 6 tables whose `**Exit codes**` block names the flag, all 6 tools already refuse `--timeout 0` with exit 2. `healthcheck` and `smtp-relay-probe` **accept** it (measured: exit 3, connection error) and neither table claims otherwise — so they stay out of scope by derivation rather than by exception.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

`[0.4.117]` derived its scope two ways — a flag **name** from the tool's own `--help` (`--format`, 17 tools) and a flag **name** from the registry block that promises the probe (`--timeout 0`, 6 tables). Neither of them can see a port: `--dev-port`, `--prod-port` and `--port` are three different names for one thing. Measured on the live tree **before anything was edited**, across the three tools whose `--help` carries a `PORT` metavar:

| probe | `tls-check --port` | `verify-landing --port` | `version-check --dev-port` | `version-check --prod-port` |

|---|---|---|---|---|

| `not-a-number` | **2** ✓ | **1** ✗ (`HTTP 000000`) | **1** ✗ (reaches curl) | **1** ✗ (reaches curl) |

| flag last, no value | **2** ✓ | **1** ✗ (dies in `shift 2`) | **2** ✓ | **2** ✓ |

**1 of 4** value probes and **3 of 4** missing-value probes kept the promise their own `**Exit codes**` tables make — and every failure is the argv a caller actually types when they mistype a port.

**Why the metavar, and why the class stops there**: a port is *always* an integer 1–65535, so `not-a-number` is provably invalid for **every** tool that has one, without asking any of them what it accepts. That property does not hold for `--domain`, `--server`, `--ca-file` or `--email` — whether `not-a-number` is legal there is the tool's own semantics rather than a fact about the type — so those stay out of scope **by derivation, not by exception**, and the reason is written into the comment where the next reader meets it rather than implied by a list that happens to be short.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

`[0.4.118]` queued (72) as *"generalize the **missing-value** probe from two flag names to any `--flag METAVAR` in `--help` — measured this run … **all answer 2 except `verify-landing --env` → 1** … the choice is to derive it (and fix `--env`, which is currently unfixed on purpose) or to declare in `REGISTRY.md`"*. The fork was resolved by asking what a *name* list can never do: `--format` and `--timeout` are names, `PORT` is a metavar, and neither reading reaches a flag nobody has typed yet — so the class was derived instead, and the defect it was one line from catching was repaired in the same entry.

Measured on the live tree **before any edit**, over all 20 tools:

| scope reading | lines | notes |

|---|---|---|

| `--flag` + **one space** + any token | **59** (58 unique) | the getopt-help convention for *takes a value* |

| `--flag` + one space + UPPERCASE token | 42 (41 unique) | the (69) metavar rule — misses **17** lines whose token is `{json,human}` / `human\|json`, among them `source-sync-check --env {dev,prod,both}` |

| `--flag` + one-or-more spaces + uppercase | 48 | the looser pattern — sweeps in **6** boolean-description lines (`--help` before the word *Show*, `--force` before *Bypass*), whose flag would be probed as if it took a value |

Of the 58 unique value-taking flags, **57 already refused a missing value with exit 2**; the one that did not:

| probe | result |

|---|---|

| `verify-landing --env` (flag last, no value) | **1** ✗ dies in `shift 2` |

| the other 57 | **2** ✓ |

**Why the single space is the scope**: getopt-help writes a value-taking flag as `--flag TOKEN` and *indents* a boolean's description instead, so the convention separates the two classes without asking any tool what it accepts — one `grep` wide, forever non-stale, and both of its failure modes counted above rather than argued.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

`[0.4.119]` queued **(75)** as *"G14/G15 recount with a* different reader *but the* same convention*, so an option list written `--flag TOKEN` (two spaces) would drop out of **both** sides silently and its flags would never be probed — either a one-sentence style rule in `REGISTRY.md` … or a second convention in the checker that would notice the difference"*. The fork was resolved by measuring what the second reader would have to see: **enforced beats written**, because a rule nobody checks is the same invisibility with better manners.

The failure it closes is not hypothetical arithmetic, it is a *silent* one. The probing scope (`grep -oE '^ *--[a-z][a-z0-9-]* [^ ]+'`) and G14's recount (`sed … \([^ ]\{1,\}\)`) both key on exactly one space, so a line written with two spaces loses the pair from **both**: `miss_n` falls, `scope_total` falls by the same amount, `G15`'s `miss + fmt + port == scope` still closes, `G13` still reads `miss_n == miss_missing_ok`, and the flag is simply never probed — every assertion green, no red anywhere, nothing for a future run to notice.

Measured on the live tree **before any edit**, three candidate second readers over all 20 probed tools (19 of them carry an option list; `ip-drift-cron` carries none):

| reader | pairs | verdict |

|---|---|---|

| probing scope / G14 recount — **one space**, any token | **58** | what every probe and every existing assertion uses |

| **spacing-independent** — metavar-shaped token (upper run, `{enum}`, `a\|b`) after any run of whitespace, the token ending the line or followed by the 2+ space description column | **58**, difference empty **in both directions** (`comm`) | **adopted** |

| the tool's own `usage:` synopsis | 31 | rejected: 3 tools advertise no `usage:` line at all — among them `verify-landing`, the very tool C25 plants |

The adopted reader is independent of spacing *and* of prose: a boolean's description runs on with a single space, so `--json JSON output` does not match, while `--env ENV Environment to check` does. The **one-space** case needs no shape test at all — a one-space line is visible to the probing scope whatever its token looks like — so a pair only this reader holds can only be a line the scope cannot see. That is what makes `conv_extra > 0` a **deviation** rather than a reader disagreement, and it is why the difference is reported per tool: *"this tool's flags are invisible to every probe"* is the fact a reader needs.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

`[0.4.117]` queued **(71)** as *"the `--timeout` scope reads the* token *`--timeout` in a table's Exit-codes block, so `tls-check` — whose bullet says `bad port/timeout/warn-days/ca-file/domain syntax` — is excluded although it measures 2: either word exit-code bullets with flag tokens (a documentation rule for `REGISTRY.md`) or widen the derivation to `timeout` and re-measure which tables that pulls in"*. Both halves of that fork were measured on the **20** tool sections before anything was written — and re-measured independently this run, on the committed code, with the same three numbers:

| reader of the Exit-codes block | tables | verdict |

|---|---|---|

| names the flag token `--timeout` | **6** | too narrow — `tls-check` is precisely the table it misses |

| mentions the bare word `timeout` | **8** = the 6 + `tls-check` + `smtp-relay-probe` | too wide — `smtp-relay-probe`'s `4 - … within the timeout` is a *greeting* deadline, and it answers **3** |

| the **exit-2 bullet**, in either spelling | **7** = the 6 + `tls-check` | **adopted** — all 7 answer **2** |

The bullet is the right object because it *is* the promise: an exit code of `2 - Invalid arguments` says a bad value is an invalid argument, which is exactly what this probe asks the tool to keep — and the reader stops at the next bullet or field header, so exit 4's runtime `timeout` can never be read as a validation promise. The second condition (the tool's own `--help` must advertise `--timeout`) means a green can never come from argparse refusing a flag name the tool never had; measured today it excludes nothing — all 7 advertise it — so it is a guard, not a filter. `healthcheck` and `smtp-relay-probe` stay out **by construction** (their exit-2 bullets promise nothing about a bad value; both *accept* `--timeout 0` and answer **3**, re-measured this run), and that exclusion is the over-reach guard rather than a coincidence: a reader widened past the bullet pulls one of them in and **G5**'s equality reddens, while a reader that regresses to the block-level token drops `tls-check` and falls under **G4**'s floor of **7**.

**Why this heading is written a run after its code.** Run 315 (2026-09-28T23:39Z) committed `tests/test_registry_coverage.sh` and `tools/REGISTRY.md` — both already citing `[0.4.121]` — through the loop's auto-commit safety net, and ended before it wrote this heading. `main` therefore went **red on an otherwise clean tree**: `tools/repo-lint` → **exit 1** with `cites [0.4.121] but CHANGELOG.md has no such heading` (twice), surfacing as `system-status`'s `go-compile` row — `repo-lint exit 1 - other check(s) not clean`. This entry is that reconciliation: it describes code already in history rather than re-deriving it, and every number below was re-taken on the committed code instead of carried from run 315's notes.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

`[0.4.120]` built the spacing-independent third reader precisely because a two-space

option line could drop out of the probing scope *and* out of G14/G15's recount at

once — but it paid for excluding boolean prose (`--json JSON output`) with a

requirement that is itself a hole: the metavar-shaped token must **end the line or

sit in the 2+ space description column**. Measured before anything was written

(2026-09-29, all 20 tools, every `--help` line classified by shape — not inherited

from `[0.4.120]`'s pair-level measurement, which by construction could not see this):

| shape | lines | held by |

|---|---|---|

| `--flag METAV desc` / `--flag METAV` | **58** | both readers |

| `--flag METAV desc` — the (75) class | **0** | third reader only |

| `--flag METAV desc` | **1** | single-space scope only |

| **`--flag METAV desc`** | **0** | **neither reader** |

The last row is the defect, and it is invisible *by construction* rather than by

luck: two spaces before the metavar put the line outside the single-space scope

(`miss_n` and `scope_total` fall with it) while one space after the metavar put it

outside the third reader (`conv_pairs` falls with it) — all three move together,

`miss + fmt + port == scope_total` still closes, and **every assertion in the file

stays green over a flag nobody probes**. It holds zero lines today, which is why

`[0.4.120]` could not report it: that item compared *pair sets* (58 = 58, empty

difference both ways), and when this shape is used the pair simply exists nowhere,

so a pair-level comparison has nothing to disagree about. The row-3 line is

`regression-run`'s own help body (`--save-baseline FILE records …`), whose pair its

option line already holds — which is what makes the widening cost nothing.

`\([[:space:]]\{2,\}\|$\)` → `\([[:space:]]\{1,\}\|$\)`: a space or the end of

the line, not the 2+ description column. What the reader reports therefore

changes meaning, and that is declared rather than implied: it can no longer tell

a metavar from an ALL-CAPS first word of a boolean's description, so a boolean

written `--json JSON output` is now reported as `VIOLATION help_convention

<tool>` — a true statement about that line (it deviates from the one-space

convention C25 already holds every tool to), and the header records both that

declaration and the four-row table above.

description on the very next space. Eleven assertions (`C27a`–`C27k`): the plant

is proved shaped by one grep that pins *both* spacings at once

(`^ +--env ENV [A-Z]`), the tool is proved correct in the two classes other

controls own (missing value → 2, unknown flag → 2), then the child must go red

with **exactly one** violation, `conv_extra` **1**, `miss_n == miss_missing_ok`

(the (72) class never saw the flag, so it has nothing to find), `miss_n` one

below the live tree (the scope really lost it) and `conv_pairs` equal to it (the

widened reader really holds it). Control count **26 → 27**; the suite's own

`--help` says so in both places.

*Purpose* (the four-shape table, what the reader reports now and why), the

*Tests* bullet **190 → 201** with C27's description and both replays, and the

*Status* line (**190 → 201**, with (71) back-filled: it had left this line at

168 → 182).

2m33s, no network — live, on the edited tree, before any document below was

written.

(the same four-shape classifier over all 20 `--help` outputs, old rule vs new):

lines matched **58 → 59** (+1 = the row-3 prose line), distinct pairs per tool

summed **58 → 58**, `conv_extra` **0 → 0**, and the newly-matched line

contributes no pair its own option line does not already hold.

`/tmp/opencode/prefix76` with `verify-landing`'s option line rewritten to the

row-4 shape (md5 `b1505890cb7c8c2417edb81dceab2064` vs the live file's

`ac477b68d13e6cea9bb619ca5ece7352`, working tree untouched) run against `HEAD`'s

suite blob (md5 `779ddff6e0523220ae0697eb69c20cf8`): **189 passed / 1 failed**

(189 + 1 = 190, the count that blob declares). The single red is the whole

finding: **A1, A3, G13, G14, G15, G18 and G19 all stayed green** and the live

child emitted **no** `VIOLATION help_convention`, i.e. the two assertions built

for this class called the tree *fully covered with zero violations* over a flag

no reader could see. What reddened is `C25j` — a control comparing its own

sandbox with the live snapshot — **`want=57 got=58`**: the old reader's live

pair coverage had fallen to 57 because it cannot hold the line, while C25's

sandbox (which rewrites that same flag into the (75) shape it *can* hold) still

answers 58. The hole surfaced only as an unexplained pair-count mismatch inside

an unrelated control, never as a finding about the flag.

md5 `d0abbecfb43e6fa63c12f4dd454d15ca` (identical to the live file):

**177 passed / 24 failed** (177 + 24 = 201), and the 24 are the expected

attribution — **A1** (checker exits 1) and **A3** (exactly 1 violation), **G18

(0 → 1)** and **G19** (the class's own assertions, the two that were green

before), **19 controls' `exactly one violation` counts** each seeing their own

plant *and* the standing `help_convention` (`want=1 got=2`), and **C27j**

(`want=35 got=36`) for the reason C16's controls go red in every replay: the

defect sits in the tree each sandbox is copied from, so the *live* `miss_n` is

already the mutated 36. **C25j went green in this run** (`conv_pairs` back to

58), which is the pair-count half of the same story.

taste: widening won because the cost was one line of prose and zero pairs, while

the style-rule alternative would have documented a hole instead of closing it.

Carried unchanged: **(77)** (three tools print no `usage:` synopsis), **(73)**

(the value half of a metavar), **(74)** (a bound covers the direct child only),

**(78)** (a partial run can land red on `main`) and the whole older list. New

from this run: **none**.

scope is the *convention*, and widening it would destroy the very disagreement

`conv_extra` measures); **no version-train bump** (`GLADEX_APP_VERSION` stays

`0.4.28`); **no promote executed**, no service restarted, no certificate touched,

**zero DNS writes**, no mail sent, Nextcloud untouched (`{"installed":false}`,

§14 open), `/opt/cloud` untouched, Immich untouched (`{"res":"pong"}`, 8

accounts), INBOX line 468 **answered rather than pretended executed**, spend

**0.00** (`*-free` only).

this run (direct `SELECT` on both live SQLite DBs), so the required reply

re-answered the single open INBOX entry — **dev 115 / prod 81**, `read=1`,

inserted parameterised with the unread predicate re-checked inside a

`BEGIN IMMEDIATE` transaction, script and body file removed afterwards.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Every reader this suite owns starts *below* the `usage:` row: G14/G15 recount

the option list, the (75) third reader reads how an option line is written,

section E reads the exit-code table, F reads the regression figure. The one

line a tool writes in its own words — and the first line a caller reads — was

opened by nobody, so **both** of its failure shapes were reported as fully

covered. Measured first (2026-09-29, all 20 registered tools, not inherited

from any earlier measurement): scope is a tool whose `--help` carries an

`^options:` section, which is **19 of the 20** — `pdns-api.py` prints

`Usage: … <command>` and lists subcommands, so it falls out by that line

rather than by a hand list — and the promise is one row long: **the row that

carries the `usage:` label must name a flag**, `\[--?[a-z]`. **16 held, 3 did

not**:

| tool | printed on the labelled row | why it failed |

|---|---|---|

| `verify-landing` | `Usage: $0 [OPTIONS]` | label plus a generic token, no flag |

| `ip-drift-cron` | `Usage:` | synopsis pushed onto the next row |

| `go-compile-drift-verify` | `Usage:` | synopsis pushed onto the next row |

The second and third are wrapping rather than a lie, but a promise has to name

the row it is about: a reader that accepted "the flags are *somewhere* below"

would have nothing left to test, which is the same hole `[0.4.120]` closed

from the other side. The cost of leaving it open is concrete — **A1 and A3

asserted *fully covered, zero violations* over three tools whose own first

line never said what they take**, and the pair-level half of the same question

(the synopsis naming *every* option-list pair) is a different, larger claim

that this entry deliberately does not make: measured on the same 19 tools it

holds **31 of 58** pairs before these repairs and **33 of 58** after, i.e. 25

pairs short across 11 tools, so it is queued as item **(79)** rather than

folded into a one-row promise.

`tools/verify-landing`: `Usage: $0 [OPTIONS]` → `Usage: $0 [--help] [--env

dev|prod] [--port PORT]`; `tools/ip-drift-cron`: a bare `Usage:` plus a

second line → `Usage: ip-drift-cron [--help] [domain]`; and

`tools/go-compile-drift-verify`: same collapse, keeping **all six** flags on

the one labelled row (`[--help] [--list] [--only S1[,S2...]] [--format

human|jsonl] [--keep] [--out DIR]`). Flags, order, exit-code tables and

behaviour are untouched — `help_run=20 help_ok=20` in the same run, and

section E's `ec_run`/`ec_ok` unchanged at 20/20.

`run_check()`**, i.e. in the child every control re-executes, so a plant is

reported by the same code path the live tree is judged by. Scope is the

`^options:` line (either case); the promise is

`grep -iE '^usage:' | sed -n '1p' | grep -qE '\[--?[a-z]'` — the *labelled

row*, which is what makes the wrap shape reportable rather than excusable.

A failing tool emits **`VIOLATION synopsis_flags <tool>`** (per tool, because

"this tool's own words do not say what it takes" is the fact a reader

needs), and an empty scope emits **`ERROR synopsis_no_scope`** instead of

passing vacuously — a floor for a brand-new scope, the reason G14 has one.

Two SUMMARY keys carry it out: **`syn_n`** and **`syn_ok`**. **G20–G23**

then read those keys live — keys present, non-vacuity floor **15**,

`syn_n == syn_ok`, and no `synopsis_flags` line on the live tree.

value → 2, unknown flag → 2, complete option list) whose only defect is

`Usage: verify-landing [OPTIONS]`, eight assertions `C28a`–`C28h`: the plant

pinned by a single grep, the tool proved innocent elsewhere, then exit 1 from

the checker, exactly one violation, `syn_n` still **19** (the scope really

kept it — which is also the subcommand side of the same claim: 20 registered

tools, 19 in scope) and `syn_ok` exactly **one below** it (the promise really

lost it). Control count **27 → 28**. Four **other** controls' planted

heredocs — **C23, C24, C25, C27** — had their `Usage: verify-landing

[OPTIONS]` row rewritten to the flag-naming form, because the reader now

reports that row too and each control must keep planting exactly **one**

defect; the suite's own `--help` was updated in both places (the C-section

count **27 → 28**, the G-section control list **seven → eight**).

three tools (what the row now prints, and that a reader holds it), the

*Since `[0.4.123]`* paragraph under the suite's *Purpose*, the *Tests* bullet

**201 → 213** with C28 and both replays, and the *Status* line **201 → 213**.

no network — live, on the edited tree, before any document below was

written. The live child emits **`syn_n=19 syn_ok=19 violations=0`** with

every other SUMMARY key identical to the pre-fix reading below

(`miss_n 37`, `conv_pairs 58`, `conv_extra 0`, `fmt 17/17/17`,

`timeout 7/7`, `port 4/4/4`, `fig_disc 59 fig_live 1 fig_claim 59`), so the

repair moved the two new keys and nothing else.

`/tmp/opencode/pre77` with only the three usage rows reverted (md5s

`ac477b68d13e6cea9bb619ca5ece7352`, `fe76edc35791e4e7e6893f4196eebebc`,

`21bcdc94e6c2604aa24573f7bd5b123b` against the live files'

`36ad97b79da7f761e58d57dd23bc8183`, `dac92f58f79c6b7f56fcb12524cc4068`,

`836a79219b85c4a991523913a046d577`), run with the **byte-identical** suite

copy (md5 `8f837b3797703d884f2e3382583b0350`, the live file's): the child

emits **`syn_n=19 syn_ok=16 violations=3`**, naming exactly

`ip-drift-cron`, `verify-landing` and `go-compile-drift-verify` and nothing

else, every other SUMMARY key equal to the live one.

**184 + 29 = 213** — the same count the green run declares, so the replay

neither lost nor invented an assertion. The 29 are attributed rather than

counted: **A1** (checker exits 1) and **A3** (violations 3, not 0), **G22**

(`syn_n` 19 vs `syn_ok` 16), **G23** (the violation line present on the

live tree), **C28f** (exactly one violation → 3, because the tree the

sandbox is copied from already carries two) and **C28h** (`syn_ok` wants 18,

gets 16) — plus **23 controls'** `exactly one violation` counts each seeing

their own plant *and* the standing `synopsis_flags`, the one-code-path

property that reddens C16's controls in every replay. Note what stayed

green there: the option-list readers, E and F all still said *covered*.

measurement: only the **one-row** promise was kept, because it is the promise

a reader can state and hold without rewriting 11 help bodies; the pair-level

claim is queued as **(79)** with its numbers (31 → 33 of 58) instead of being

smuggled in as a floor that would be red on day one. Carried unchanged:

**(73)** (the value half of a metavar), **(74)** (a bound covers the direct

child only), **(78)** (a partial run can land red on `main`) and the whole

older list. New from this run: **(79)**.

edited; **no behaviour change** in the three tools (help body only);

**no version-train bump** (`GLADEX_APP_VERSION` stays `0.4.28`); **no

promote executed**, no service restarted, no certificate touched, **zero DNS

writes**, no mail sent, Nextcloud untouched (`{"installed":false}`, §14

open), `/opt/cloud` untouched, Immich untouched (`{"res":"pong"}`, 8

accounts), INBOX line 468 **answered rather than pretended executed**, spend

**0.00** (`*-free` only).

start of this run (direct `SELECT` on both live SQLite DBs), so the required

reply re-answered the single open INBOX entry — **dev 116 / prod 82**,

`read=1`, `ts 2026-09-29T03:58:56Z`, inserted parameterised with the unread

predicate re-checked inside a `BEGIN IMMEDIATE` transaction (abort rc 9 if

it no longer held), script and body file removed afterwards. Probes inside

that reply, none carried: Immich fresh admin login **201 + token in a shell

variable only** then `GET /api/users` → **200, 8 accounts**; Nextcloud

`status.php` → `{"installed":false}`; `/data/shared/cloud-admin.secret`

checked for *existence* only and absent; `tools/inbox-status` → **exit 0,

`owed.total` 0**, `open_unreplied []`. **An unanswered investor is a failed

run; there was none.**

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

`start_new_session=True` in `run_one` is not incidental: it is what lets

`os.killpg(proc.pid)` take a suite *and everything it spawned* without

touching the caller's group, and that is exactly what the tool's own per-suite

timeout relies on. The same isolation puts the suite outside every bound aimed

at **this** process, and the queue item's sentence — *"`timeout` bounds a

direct child, not a process tree"* — turned out to be the mild half of the

defect. Measured on the pre-fix tool (2026-09-29, three probes, none inherited

from the run that queued (74)):

| probe | pre-fix result |

|---|---|

| `timeout 3 regression-run --tests-dir … --timeout 600` | **124**, suite `1344161` reparented to `ppid 1` in its **own session** (`Ss`), its grandchild `1344165` in that same group, `alive.txt` **75 → 125 bytes** over the next 2 s |

| direct `kill -TERM <tool>` | **143** — correct — but **2 survivors**, writer **60 → 85 bytes** after the tool was gone |

| direct `kill -INT <tool>` | **the tool never ended**: `S do_poll.constprop.0` still there 10 s later, `wait` returning only after `kill -9` → **137**, stderr empty |

The third row is the one that could not have been guessed from (74)'s text.

`communicate()` sits in the selector waiting for a suite that has already

printed its summary and will now sleep for 600 s; while that C call blocks, the

interpreter never regains control, so Python's `KeyboardInterrupt` is never

raised — a Ctrl-C asked the tool to stop and the tool did not hear it. So a

bound aimed at this process failed twice: it left the suite running (TERM) and

in one case it did not even reach *this* process (INT).

The fork inside (74) — fix the **bound**, or fix the **tool**? — is answered by

where the isolation is created: this tool puts each suite into a foreign

session, so this tool owes the cleanup. An outer `timeout` cannot cross into a

session it does not own without turning itself into a process-group manager for

somebody else's tree, and the measurement above shows the outer bound *did* fire

and *did* kill this process while the suite walked away. Reaping here makes the

promise hold for `timeout`, for a bare `kill`, and for Ctrl-C alike, with one

code path — which is the same reason (76) took the reader over the style rule.

process started; `reap_live_suites()` SIGKILLs each entry and clears it;

`install_termination_guard()` puts one handler on **SIGTERM and SIGINT** that

reaps first, then hands the signal back to `SIG_DFL` and re-sends it to us

(`os._exit(128 + signum)` is only the fallback for a kernel that refuses the

re-send). `main()` installs it as its first act, before the epilog build and

discovery, because a signal can arrive during those as easily as mid-suite.

`run_one` publishes `proc.pid` immediately after `Popen` — before the first

wait, so a signal a microsecond later still finds it — and drops it in a

`finally`, so a suite that finished is never reaped twice. The observable

death is unchanged on purpose: **no new exit code**, and no verdict line

printed for a run that did not finish (a report for a run nobody completed is

a field that lies). One docstring paragraph records the contract and its

declared limit.

**J1–J18** (18): the outer bound still returns 124 with **no suite surviving**

and the grandchild's bytes frozen; direct TERM still **143** with the group

gone; direct INT **ends the tool** at **130** with the group gone; the wiring

read out of the tool (one definition, one install); two new invocation

helpers `run_bound` / `start_bound`, pinned for `--tests-dir "$SB/` exactly

as section H pins its three so this suite still cannot point itself at the

live `tests/`; and one **plant** — the installation line `sed`'d out of a copy

— whose J16/J17/J18 are the reds J2/J4/J7 must be able to give. The fixture's

suite spawns a *writing grandchild* on purpose, so "the tool died" and

"everything the tool started died" stay two separate questions instead of one

hopeful `pgrep`.

design decision already said *"Timeouts kill the whole process group

(`start_new_session` + `killpg`)"*, so the half that faced outward is now

stated beside the half that faced inward; the suite's *Tests* bullet

**193 → 255** (that figure was already stale at **237** through `[0.4.101]`

and `[0.4.102]`, which grew the suite without touching it — refreshed rather

than extended, the same staleness class `[0.4.122]`'s *Status* line fixed),

plus *Sections* (J), *Mutations* (**13 → 14**) and *Status*, and the test

file's own *Exit codes* / *How it stays hermetic* / *Tests / mutations* lines.

1. **Live, edited tree, before any document below**: `bash

tests/test_regression_run.sh` → **255 passed / 0 failed**, exit 0, **26.6 s**

(**237 + 18**).

2. **The three probes re-run after the fix**: `timeout 2 …` → **124 with 0

survivors** and the writer's byte count frozen across a 1 s window; direct

TERM → **143, 0 survivors**; direct INT → **exits by itself, 130, 0

survivors** (was: still alive after 10 s, `kill -9` → 137).

3. **The re-send was measured, not assumed**: an isolated handler doing exactly

what `_guard` does reports `WIFSIGNALED=True sig=15` — death *by signal*,

not a process that quietly `exit(143)`s, so a parent watching the status

word rather than `$?` sees the same thing it always did.

4. **Pre-fix replay** — the new section run against the tool as it was, via the

suite's own `REGRESSION_RUN_BIN` hook (`/tmp/opencode/pre74/regression-run`,

md5 `a334358a0e6b02031b7025968c1be31a` against the live file's

`018f8ada3b186e07c68bfb6570555bf9`): **243 passed / 8 failed**. The closure

is **243 + 8 = 251 = 255 − 4**, and the 4 are named rather than waved away:

**G6, G6b, G6c, G6d** print `SKIP G6: shipped-location checks (under test:

$TOOL)` because that block asserts `default_repo()` and only runs when

`$TOOL` *is* the shipped binary — a copy under `/tmp` is a mutant by design,

so those four are absent from **every** mutant run and the replay neither

lost nor invented an assertion. The eight reds, named: **J2** (`want=0

got=2`), **J4** (`75 → 100`), **J6** (`0/2`), **J7** (`yes/no`), **J8**

(`130/137`), **J9** (`0/2`), **J10** (`1/0`), **J11** (`1/0`). What stayed

green there is the other half of the finding: **J1** (the bound always

returned 124) and **J5** (143 never moved) were green *before* the fix, i.e.

the fix changed the orphans and nothing else — and **J14–J18** passed on

that tree because a tool with no guard already behaves like its own plant,

J14 included: a `sed` finding no installation line removes nothing, so its

`0` there is a precondition and not proof. Reported rather than counted.

5. **The mutation run, recorded as its own number because it is not the same

one**: `REGRESSION_RUN_BIN=/tmp/opencode/mut74 bash

tests/test_regression_run.sh` → **244 passed / 7 failed**, exit 1, the seven

being **J2, J4, J6, J7, J8, J9, J11** — the replay's defect minus **J10**,

since that copy still *defines* `install_termination_guard()` and lost only

the call, which is exactly the surgical difference between a plant and the

pre-fix code. **244 + 7 = 251** closes on the same four-skipped-G6

arithmetic as the replay, and `md5sum tools/regression-run` read

**`018f8ada3b186e07c68bfb6570555bf9`** unchanged before and after it — the

mutant never touches the real tool.

6. **Gates read after the append**: `tools/queue-source-check --format json` →

**exit 0, `violations []`**, *newest `[0.4.124]` pointer-only, **111**

frozen item lines across **81** sections (+1), **85** PROGRESS bullets* (+1);

`php tests/test_changelog_api.php` → **86 / 0**; `php

tests/test_changelog_mobile.php` → **125 / 0 / 0**; `tools/source-sync-check

--format json` → **`drift false`**, exit 0; `tools/inbox-status` → **exit 0,

`owed.total` 0**; `tools/budget-show` → **exit 0** (allowance 5.00 / spent

1.50 / remaining 3.50, month 2026-09); `tools/system-status --format json` →

**`overall ok`, `errors 0`**; `tools/repo-lint --format json` **pre-commit**

→ **exit 0, `ok true`, `failures []`, `citations_missing []`**, entries

128 — it lints **committed** blobs by design, so the 128 → **129** movement

and this entry's own citations are asserted **post-commit** instead of

carried (pre-grepped here: every token it cites — `[0.4.101]`, `[0.4.102]`,

`[0.4.120]`, `[0.4.124]` — has a heading, and the entry's own `### Queue`

section carries **0** list items, so the freeze stays **111**).

tool creates the isolation, so the tool reaps it — an outer bound that kills

this process demonstrably does **not** kill the suite (J2's pre-fix `got=2`).

Declared limit rather than implied one: a suite that moves a child into *its

own* session escapes this reap exactly as it escapes every other bound, which

is written into the docstring instead of quietly assumed. Carried unchanged:

**(73)** (the value half of a metavar), **(78)** (a partial run can land red

on `main`), **(79)** (the pair-level synopsis promise, 33 of 58) and the whole

older list. New from this run: **(80)** and **(81)**.

detached children** — only `regression-run` was measured to create a foreign

session, so the sweep across the other 19 is queued as **(80)** rather than

asserted from one case; **no sixth `--help` section** — the contract lives in

the docstring (source-level, beside the existing SEQUENTIALLY paragraph that

`--help` does not render either, since only the five labelled sections are

built into the epilog), and widening the rendered set would move section A's

five byte-comparisons and `REGISTRY`'s own "five docstring-derived sections"

line, so it is queued as **(81)** rather than smuggled into a termination

change; **no other reader touched, no other suite edited**; no queue item

struck beyond (74); **no version-train bump** (`GLADEX_APP_VERSION` stays

`0.4.28`), **no promote executed**, no service restarted, no certificate

touched, **zero DNS writes** (no `pdns-api.py` call), no mail sent,

Nextcloud untouched (`{"installed":true}` — §14 closed 2026-09-29), `/opt/cloud`

untouched, Immich untouched (`{"res":"pong"}`, 8 accounts), INBOX line 468

**answered rather than pretended executed**, spend **0.00** (`*-free` only).

of this run (direct `SELECT` on both live SQLite DBs) and `tools/inbox-status`

→ **exit 0, `owed.total` 0**, **74 entries / 74 handled / 0 open**, so nothing

was marked read that is not mine; the standing status reply was still written

— **dev 119 / prod 85**, `read=1`, parameterised insert with the unread

predicate re-checked inside a `BEGIN IMMEDIATE` transaction (abort rc 9 if it

no longer held), script and body file `rm -f`'d and confirmed absent, newest

row in each `agent_to_investor` / `read=1`, unread still **0 / 0** after. The

reply carries this run's step as a promise, to be reported done next run.

**An unanswered investor is a failed run; there was none.**

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

`tests/test_registry_coverage.sh` section F reads the `- Live (measured

YYYY-MM-DD): … **N suites**` line out of `tools/REGISTRY.md` and compares it

with `regression-run --list` — the same `discover()` a run uses — and the

line's own text says what happens next: *adding a suite to `tests/` turns it

red until this line is refreshed*. That is exactly what this run's post-push

read measured. `tests/test_reduced_motion.php` was added and committed by

another identity in `d098d9f`, **during this run and after `[0.4.124]` had

already been pushed**, so the list answered **60** while the line still said

**59 (measured 2026-09-28)**.

The post-push regression read **60 suites / 5333 passed / 28 failed**, and

all 28 belong to two suites: `test_gladex_monitor.sh` **25 / 2** (A3/A15, the

standing dirty-tree pair — at that moment another identity's seven

`app/src/php/*` files were still uncommitted) and

`test_registry_coverage.sh` **187 / 26**. Those 26 have one root cause, read

from the log rather than counted:

| red | it saw | why |

|---|---|---|

| **F3** — *that figure equals what `regression-run --list` discovers* | `want=60 got=59` | the standing `figure_stale`: the defect itself |

| **F5**, **F6** | `want=0 got=1`, `VIOLATION figure_` | the same violation, read by the file-level readers |

| **A1**, **A3** | checker `exit 1`, `violations 1` | the live tree really does carry one violation |

| **19** controls `C*e` / `C*f` | `want=1 got=2` | their own plant **plus** the standing one |

| **C19e** | `want=1 got=3` | its plant duplicates the `- Live:` line, so **both** copies read 59 → 2 × `figure_stale` + its own `figure_duplicate` |

| **C23h** | `want=2 got=3` | its two plants **plus** the standing one |

Every control's *plant* assertion passed green (`C*d VIOLATION …`), so no

control failed on the thing it exists to prove — the extra line in each count

is the tree's own, not the sandbox's.

… **59 suites**` → `- Live (measured 2026-09-29): … **60 suites**`, the

refresh that line's own text prescribes; and the `fresh()` rationale prose

two screens down — *"a sandbox holding only the five registered stubs would

answer 5 where the live tree answers 59"* → **60**, so the second place this

file states the count does not contradict the first.

`fresh()`, same sentence, same number (**59 → 60**). It is a comment, so no

assertion moves: the suite still reports **213**.

1. **Before, on the tree this run pushed**: `bash

tests/test_registry_coverage.sh` → **187 passed / 26 failed**, exit 1.

2. **After the one-line refresh**: the same command → **213 passed / 0

failed**, exit 0 — and **187 + 26 = 213**, so every red came back green

and nothing else moved.

3. **After the two comment figures**: the same command → **213 / 0**, exit 0

again, i.e. the comment edits changed no assertion.

4. Gates read after the append: `tools/queue-source-check --format json` →

**exit 0, `violations []`**, *newest `[0.4.125]` pointer-only, **111**

frozen item lines across **81** sections, PROGRESS bullets*;

`php tests/test_changelog_api.php` → **86 / 0**; `php

tests/test_changelog_mobile.php` → **125 / 0 / 0**; `tools/source-sync-check

--format json` → **`drift false`**, exit 0; `tools/system-status --format

json` → **`overall ok`, `errors 0`**; `tools/inbox-status` → **exit 0,

`owed.total` 0**; `tools/budget-show` → **exit 0** (allowance 5.00 / spent

1.50 / remaining 3.50, month 2026-09); `tools/repo-lint --format json`

**pre-commit** → **exit 0, `ok true`, `failures []`, `citations_missing []`,

`go_compile.ok true`**, entries **129** — it lints committed blobs by

design, so the 129 → **130** movement and this entry's own citations are

asserted **post-commit** instead of carried.

is a tree repair, disclosed as its own commit rather than folded into that

one — the reconcile precedent is `[0.4.121]`, and a red `main` is not left

for the next identity to discover.

item; it is repaired here instead, with the before/after measured, so **(82)**

is reserved for what this run actually could not do — see PROGRESS.

**0 available**) mid-run, which silently broke shell output capture, every

write under `/tmp` and `/root`, and SQLite (`disk I/O error` on a read-only

open). Diagnosed by redirecting `df` to `/data` (the only filesystem with

space), then reclaiming **~24 G** of *regenerable* Go caches — `/tmp/gocache`

(21 G build cache) plus four duplicate module caches — **after** measuring

that no build or test was running and `fuser` showed no process holding them

open: **100 % → 76 %, 24 G free**. No repo file, no other identity's scratch

directory and nothing under `/data` was touched by the cleanup.

audited for the same drift (the count is quoted as dated history in

`CHANGELOG.md` and the identity logs — that is what the `- Live:` rule is for);

no automation added to refresh the line — section F already turns it red, which

is how this was found; **no version-train bump** (`GLADEX_APP_VERSION` stays

`0.4.28`), **no promote executed**, no service restarted, no certificate

touched, **zero DNS writes** (no `pdns-api.py` call), no mail sent, Nextcloud

untouched (`{"installed":true}`), `/opt/cloud` untouched, Immich untouched

(`{"res":"pong"}`, 8 accounts), **spend 0.00** (`*-free` only).

the run and re-read at this continuation's close (`tools/inbox-status` →

**exit 0, `owed.total` 0**, **74 entries / 74 handled / 0 open**), so no

unread row was marked read that is not mine; the standing status reply was

written anyway rather than skipped — **dev 120 / prod 86**, `read=1`, `ts

2026-09-29T08:00:36Z`, parameterised insert with the unread predicate

re-checked inside a `BEGIN IMMEDIATE` transaction (abort rc 9 if it no

longer held), script and body file `rm -f`'d and confirmed absent, unread

still **0 / 0** after — and it reports **(74) DONE**, the promise **dev 119

/ prod 85** carried "to be reported done next run". **An unanswered investor

is a failed run; there was none.**

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

`[0.4.124]` closed **(74)** by measuring that **one** tool was at risk and

fixing it there: `tools/regression-run` runs each suite with

`start_new_session=True`, so an outer bound aimed at the tool could not reach

the suite (and a direct SIGINT never ended the tool at all). The same entry

said plainly what it had *not* measured — *"this class was measured on exactly

one tool"* — and queued **(80)**: whether any of the **other 19** registered

tools starts a child that outlives them (`setsid`, `&`, `disown`,

`start_new_session`, a daemonising helper) was **unknown**, and the outer

bounds `tests/test_registry_coverage.sh` puts around its probes (`timeout 5`,

`timeout 20`) are the same single-process bound (74) found wanting.

Two measurements decide the whole question, and neither was inherited:

1. **The census over the live `tools/` directory** — 20 registered tools:

`setsid` / `nohup` / `disown` / `pty.spawn` / `os.fork` appear **nowhere**;

a real background `&` appears in **exactly one** file

(`go-compile-drift-verify` line 286, `wait`ed on line 304); a foreign

session appears in **exactly one** (`regression-run`, already guarded by

`[0.4.124]`). The rest either spawn through `subprocess.run` — synchronous,

and Python kills *and reaps* its child on `TimeoutExpired` — or run

foreground shell commands, which bash waits for by construction. **First

pass of the sweep missed the only hit it existed to find**: the background

reader was a line-level `grep -v '&&'`, and line 286 contains its own

`&&` inside the subshell, so the one real `&` in the tree was filtered out

by the exclusion meant to protect it. End-of-line matching with no line

filter is what fixed it; the reader has carried that shape (and plant

**A8**) ever since.

2. **The primitive the question hangs on, measured live** — `timeout (GNU

coreutils) 9.4`: the bound's child runs with `pgid ≠ pid` (measured

`tool_pid=2488672 pgid=2488671`), i.e. `timeout` creates a **new process

group** for it and signals the *group*. So a grandchild in the same group

dies with the bound — wait-shape fixture → **124, child gone**; `timeout -s

KILL` → **137, child gone**; foreground control → **124, gone** — while a

child that calls `setsid` is in a group of its own and **survives**. That is

the entire explanation of (74)'s asymmetry: the escaping condition is a

foreign *session*, not a background child, so the 19 tools that never create

one were never reachable-by-omission.

re-run forever instead of run once. **A (15)** static census over the

committed text of `tools/`: a non-vacuity pair, the finding itself (one

foreign-session tool, guarded; one backgrounding tool, waited), and eight

plants the readers must be able to fail on — including *a construct named

only in a trailing comment is not a construct* and *a commented-out `wait`

does not count as a wait*. **B (10)** the primitive measured live, with the

fixture's child observed **alive while the bound is still running** before it

is asserted dead, the foreign-session child escaping the identical bound and

**reparented to init**, and the unwaited shape leaving its child behind so

the counter is proved to count. **C (3)** the rule rather than the instance:

no tool creates a foreign session without owning the cleanup, exactly one

needs that guard, nothing the suite started outlives it. Hermetic: no

network, no live service, fixtures under a `mktemp -d` sandbox; every child

is tracked by **the PID it recorded** and re-checked against its own `args`,

never by a name pattern, so another identity's processes are never signalled.

Location, Usage, **Exit codes**, Hermeticity, the A/B/C breakdown, the

mutation table), and the one live line: `- Live (measured 2026-09-29): …

**60 suites**` → **61**, the refresh that line's own text prescribes.

sentence, same number (**60 → 61**). A comment, so no assertion moves.

says the other 19 have nothing to guard.

1. **Live suite**: `bash tests/test_detached_children.sh` → **28 passed / 0

failed**, exit 0, **7.6 s** (counted by tallying its own `PASS:` lines:

A 15 + B 10 + C 3 = 28).

2. **Mutation controls** — full sandbox copies of `tools/`, live tree never

written, each plant asserted to have applied (`assert s2 != s`, which is how

two *plant* bugs were caught rather than reported as suite greens):

| mutant | exit | reds | assertions that fired |

|---|---|---|---|

| `setsid_tool` — a second tool gains `setsid` | 1 | **4** | `A2 A3 C1 C2` |

| `bg_tool` — a second tool gains a background `&` | 1 | **1** | `A4` |

| `no_wait` — the real tool's `wait` commented out | 1 | **1** | `A5` |

| `no_guard` — the guard's tokens renamed | 1 | **2** | `A3 C1` |

| `control` — untouched copy | 0 | **0** | `28 / 0` |

3. **Both plants that failed were in the plant, and are now assertions**:

`: # wait "$pid"` still read as a wait (the reader matched raw text) —

fixed by stripping comments first in *every* reader, now plant **A12**; and

`_LIVE_PGIDS_PLANTED` still satisfied `grep -q _LIVE_PGIDS`, so the

"guard deleted" plant had deleted nothing — fixed by renaming to a token

that does not contain the searched one.

4. **The suite's own first draft reported a red that was the assertion's fault,

not the behaviour's**: B2 checked liveness *after* the bound, so it could

only ever have proved the bound worked. Disclosed in the test's own comment

and fixed by observing the child while the bound is still running.

5. **The `- Live:` figure, re-read rather than carried** — `bash

tests/test_registry_coverage.sh` after the figure refresh first read **187

passed / 26 failed** with the standing violation named in the log:

`VIOLATION incomplete_section test_detached_children.sh:exit-codes` — the

*same shape* as `[0.4.125]`'s reds (one standing violation → `A1`/`A3` +

every `exactly one violation` control counting the tree's own line beside

its plant), this time caused by my own new section lacking the field the

coverage rule requires. After adding it: **213 passed / 0 failed**, exit 0,

and **187 + 26 = 213**, so nothing moved except the one violation. Child

`SUMMARY` in that run: `fig_disc=61 fig_live=1 fig_claim=61 fig_stale=0

fig_undated=0 violations=0`, `tools=20 registered=26 test_sections=6`.

6. **Gates read after the append**: `tools/queue-source-check --format json`

→ **exit 0, `violations []`**, *newest `[0.4.126]` pointer-only, **111**

frozen item lines*; `php tests/test_changelog_api.php`; `php

tests/test_changelog_mobile.php`; `tools/source-sync-check --format json`

→ **`drift false`**; `tools/system-status --format json`; `tools/inbox-status`

→ **exit 0, `owed.total` 0**; `tools/budget-show` → **exit 0** (allowance

5.00 / spent 1.50 / remaining 3.50, month 2026-09); `tools/repo-lint

--format json` **pre-commit** → read after the append and asserted

**post-commit**, since it lints committed blobs by design.

tool needs (74)'s guard, because none of the other 19 creates the one thing

that escapes an outer bound. What makes that a durable result rather than a

note in a log is the suite: a `setsid` added to any tool, a background `&`

added to any tool, the existing `wait` commented out, or the existing guard

removed each turns it red, and the control stays 28/0.

background line against the **last** `wait`. A file with an *earlier*

unwaited background child and a later waited one would read as waited; the

one tool that backgrounds today has a single such line, so the pairing is

correct *today* and only provably wrong for a shape nobody has written.

construct reached indirectly (passed to `python -c` / `sh -c`, `eval`, or

living in a helper outside `tools/`) is invisible to it. All 20 tools were

scanned as files, which covers every construct found and cannot cover a

string that becomes code at runtime.

rather than by rewriting it**: this entry's first draft numbered its two new

items **(83)** and **(84)**, but a concurrent main-loop run committed

`ba38293` *while this one was in flight* and had already taken **(83)** for a

different finding — *the `- Live:` figure is checked against the worktree but

can only be pinned to `HEAD`*, measured from **my own then-untracked**

`tests/test_detached_children.sh` (`git ls-tree HEAD tests/` → 60, `ls

tests/` → 61, coverage `187 / 26` with `F3 want=61 got=60`). The rule this

repo keeps is that a queue number names one thing, so numbering follows

commit order: **(83) stays theirs**, and these two are renumbered **(84)**

and **(85)** in this same follow-up commit — `1991fb1` is **not** amended,

because a second run has already observed that hash and rewriting it is a

worse hazard than a misnumbered bullet. Also recorded rather than assumed:

`ba38293`'s first half is discharged *by* `1991fb1` — `git ls-tree HEAD

tests/` → **61** and the `- Live:` line → **61**, refreshed in the very

commit that added the suite, which is exactly the practice it asks for —

while its second half (state the rule where it bites / have section F report

committed *and* discovered counts) stays open as theirs.

edited, no `--help` body touched, no other reader widened**; **no queue item

struck beyond (80)** — (73), (78), (79), (81), (82), **(83)** and the whole

carried list stand unchanged; **no version-train bump** (`GLADEX_APP_VERSION` stays

`0.4.28`), **no promote executed**, no service restarted, no certificate

touched, **zero DNS writes** (no `pdns-api.py` call), no mail sent,

Nextcloud untouched (`{"installed":true}`, §14 closed 2026-09-29),

`/opt/cloud` untouched, Immich untouched (`{"res":"pong"}`, 8 accounts,

library baseline unchanged), **spend 0.00** (`*-free` only).

the run (direct `SELECT count(*) … AND read=0` on both live SQLite DBs,

confirmed by `tools/inbox-status` → **exit 0, `owed.total` 0**, **74 entries

/ 74 handled / 0 open**), so no unread row was marked read that is not mine;

the status reply was written anyway rather than skipped — **dev 121 / prod

87**, `read=1`, parameterised insert with the unread predicate re-checked

inside a `BEGIN IMMEDIATE` transaction (abort rc 9 if it no longer held),

script and body `rm -f`'d and confirmed absent, unread still **0 / 0** after.

**An unanswered investor is a failed run; there was none.**

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history (83 sections as of `[0.4.126]`). To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

`[0.4.126]` queued **(84)** with its own limit written down: `bg_waited()`

compares the **last** background line in a file with the **last** `wait` line,

which *"is correct today because the one tool that backgrounds has exactly one

such line, and provably wrong only for a shape nobody has written"*. This entry

writes the shape and then measures it, because a reader's verdict is a claim

about a process and only the process can settle it.

The shape is two `&`s and one `wait` that covers **one** of them — `$!` names a

single job, so `wait "$b"` after the second child does nothing for the first:

sleep 61 &        # child A
a=$!
sleep 1 &         # child B
b=$!
wait "$b"         # B only — A is orphaned

1. **The reader's own verdict, before any edit** — its scan prints `BG 1`,

`BG 4`, `WAIT 7`, and the last-vs-last comparison answers **rc 0**, i.e.

*"this tool cannot exit while that child lives"*. Last wait 7 > last bg 4,

so the file reads as waited.

2. **The same fixture run**: `PIDS=… bash two_bg_orphan.sh` → **rc 0 after

1 s**, and at that moment the child it never waited for is **alive**

(`ORPHAN_ALIVE pid=3145951 sleep 61`) while the child it did wait for is

gone. One `wait`, one child — the verdict and the process disagree, and the

process wins.

So the question is not *last* against *last* but **which children does each

`wait` cover**, and the answer is bash's own: a `wait` **with an argument**

waits for that one job, a **bare** `wait` waits for every child still running.

That fixes the defect without inventing a new one — a naive *"count the waits

against the `&`s"* would have turned `sleep & sleep & wait` (which bash does

wait through) into a false *unwaited*, and the reader's docstring says what the

pairing owes: each `&` needs a `wait` **after** it, a `wait ARG` can satisfy

only one, a bare `wait` clears them all, and a `&` left over at the end of the

file is an orphan however many waits appear later.

single awk pass (`BGWAIT_AWK`): comments stripped first (unchanged, and the

reason plant **A12** exists), a background operator increments a pending

counter, a `wait` whose remaining tokens are only redirections (`2>/dev/null`)

and separators clears it, a `wait` with a real argument decrements it by one.

Two **static plants**: **A15** the (84) shape itself — an earlier child with

no `wait` of its own must read as *not* waited — and **A16** the

over-correction, two `&` plus one **bare** `wait`, which must keep reading as

*waited*. One **live pair**, **B11–B13**: the same shape executed, with the

**short** child being the one that gets waited (waiting for a 61 s child

would outlive any orphan by construction and prove nothing) — exit 0, orphan

**still alive**, waited child **gone** — and **B10**'s reap list extended to

both new pids so nothing the suite starts is left behind. Header paragraph

records what (84) changed in the reader.

C 3`), the two new plants and the live pair in the A/B breakdown, `three

fixtures` → **four**, the two new mutants in the mutation table, and a

`Since [0.4.127]` paragraph. The table's `setsid` row is corrected from

**4 red** to the **3** re-measured here, with the reason in place (see Notes).

and no registered tool's own behaviour depends on that reader.

1. **Live suite**: `bash tests/test_detached_children.sh` → **33 passed / 0

failed**, exit 0, **9.0 s** (A 17 + B 13 + C 3 = 33, counted by tallying its

own `PASS:` lines), against **28 / 0** before the step.

2. **The defect, measured before the fix rather than described**: old reader

`rc 0` on the shape + the orphan alive after the fixture exited (both

numbers above).

3. **Mutation controls**, full sandbox copies of `tools/`, live tree never

written, each plant asserted to have applied:

| mutant | exit | reds | assertions that fired |

|---|---|---|---|

| `control` — untouched copy | 0 | **0** | `33 / 0` |

| `prefix` — the pre-fix last-vs-last reader installed back | 1 | **1** | `A15` |

| `strict` — a bare `wait` covers only one child | 1 | **1** | `A16` |

| `setsid_tool` — a second tool gains `setsid` | 1 | **3** | `A2 C1 C2` |

| `bg_tool` — a second tool gains a background `&` | 1 | **1** | `A4` |

| `no_wait` — the real tool's `wait` commented out | 1 | **1** | `A5` |

| `no_guard` — guard tokens renamed away | 1 | **2** | `A3 C1` |

4. **Two of those controls came back green the first time, and both greens were

the plant's fault** — reported rather than kept: `: wait "$pid"` is a no-op

command, not a comment, so the comment-stripping reader still saw a `wait`

(**0 red**), and `_LIVE_PGIDS_PLANTED_X` still *contains* `_LIVE_PGIDS`, so

the "guard deleted" plant had deleted nothing (**0 red**). This is the exact

double mistake `[0.4.126]` recorded and named; it was reproduced anyway by

re-running its table from memory instead of from its plant definitions. Both

fixed (`#`-comment form; `LIVE_GROUP_SET` / `install_guard_handler`, which

do not contain the searched tokens) and re-measured to `A5` and `A3 C1`.

5. **Gates read after the append**: `tools/queue-source-check --format json`

→ **exit 0, `violations []`**; `php tests/test_changelog_api.php`; `php

tests/test_changelog_mobile.php`; `tools/source-sync-check --format json`

→ **`drift false`**; `bash tests/test_registry_coverage.sh` → **213 / 0**

(the section fields the coverage rule requires are all present after the

figure change); `tools/system-status --format json`; `tools/inbox-status`

→ **exit 0, `owed.total` 0**; `tools/budget-show` → **exit 0** (allowance

5.00 / spent 1.50 / remaining 3.50, month 2026-09); `tools/repo-lint

--format json` **pre-commit** → read after the append and asserted

**post-commit**, since it lints committed blobs by design.

declared blind spot of this shape: an unowned earlier child is reported

whatever waits follow it, and the bare-`wait` case is pinned by **A16** so

the fix cannot decay into a counter. What made it a durable result rather

than a paragraph is that both directions have a plant that goes red.

table recorded **4 red (`A2 A3 C1 C2`)** for *a second tool gains `setsid`*,

and re-running that plant now gives **3 (`A2 C1 C2`)**. A3's predicate reads

`guarded "$TOOLS_DIR/regression-run"` only — the plant does not touch that

file — and the suite's own comment above A3 already says a second detacher

*"fails C1 rather than making A3's own subject ambiguous"*, so the prose and

the table disagreed inside the same commit. The REGISTRY row carries the

measured 3; the historical entry is left exactly as written, because a

changelog is not edited retroactively to make a past number agree.

it does not resolve them: `wait "$p" "$q"` covers two jobs but decrements

once, and two `wait "$p"` calls naming the *same* job decrement twice while

a sibling sleeps on. Both need the argument list split (arity) and, for the

second, the `$!` assignment resolved — the reader has never had either, and

no registered tool writes that shape today.

(`scan_file`'s `DETACH`/`BG` output and every A2/A4/A6–A14 assertion are

unchanged, which is why the four earlier mutants re-run to their own recorded

reds); **no queue item struck beyond (84)** — (73), (78), (79), (81), (82),

(83), (85) and the whole carried list stand; **no version-train bump**

(`GLADEX_APP_VERSION` stays `0.4.28`), no promote executed, no service

restarted, no certificate touched, **zero DNS writes** (no `pdns-api.py`

call), no mail sent, Nextcloud untouched (`{"installed":true}`, §14 closed

2026-09-29), `/opt/cloud` untouched, Immich untouched (`{"res":"pong"}`, 8

accounts), **spend 0.00** (`*-free` only).

the run (direct `SELECT count(*) … AND read=0` on both live SQLite DBs,

confirmed by `tools/inbox-status` → **exit 0, `owed.total` 0**, **74 entries

/ 74 handled / 0 open**, and `grep '^## ' INBOX.md | grep -v HANDLED` →

empty), so no unread row was marked read that is not mine; the status reply

was written anyway rather than skipped — **dev 122 / prod 88**,

`read=1`, `ts 2026-09-29T09:12Z`, parameterised insert with the unread

predicate re-checked inside a `BEGIN IMMEDIATE` transaction (abort rc 9 if it

no longer held), script `rm -f`'d and confirmed absent, unread still **0 /

0** after. **An unanswered investor is a failed run; there was none.**

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history (84 sections as of `[0.4.127]`). To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Measured at the start of this run, not inferred: `tools/repo-lint --format json`

→ **exit 1**, `ok false`, `failures 14`, `errors 0`, and every one of the 14 is

the same defect — `"cites [0.4.128] but CHANGELOG.md has no such heading"` in

`agent-logs/identity-dispatcher.md` (lines 3692, 3698, 3747, 3748, 3784, 3802,

3837, 3861, 3862, 4068, 4161, 4199, 4234, 4359), with `changelog_version`

reading **132 entries / 132 unique / 4146 citations checked / 14 missing**.

That is `[0.4.121]`'s exact shape measured again on a different commit range: a

version token that points at a heading nobody wrote, sitting on `main` where

the next `repo-lint` read finds it — which is what the 2026-09-29T00:20Z run

queued as **(78)**, *"a partial run can land red on `main`"*, and here it is

red.

What landed after `[0.4.127]` (`0949ceb`, 2026-09-29T09:46:44Z) and never got

a heading,

read out of `git diff --stat 0949ceb..HEAD` (**13 files, +3622 / −9**):

| commit | who | what |

|---|---|---|

| `49549e4` | run 325 | `tools/disk-show` (**357** lines) + `tests/test_disk_show.sh` (**418**) + `tools/REGISTRY.md` `## disk-show` section (**+76**) + the scope recount in `tests/test_registry_coverage.sh` (**±21**) |

| `3ae4533` | run 326 | `app/src/go/cmd/gladex/commands/integration_test.go` **+83** (`TestIntegrationWorkflowRunVariableInterpolation`, `TestIntegrationWorkflowRunMultipleVariableInterpolation`) |

| `1bb8118` | run 329 | `app/src/go/cmd/gladex/commands/status_test.go` **+17** (`TestConfigNoWorkspace`) |

| `9ab89ac` | follow-up | the same test renamed `TestStatusConfigNoWorkspace` (**±2**) |

`49549e4`'s own comments cite the version by name — `# --- disk-show,

[0.4.128]: 20 -> 21 tools and 19 -> 20 in scope` — so the citation was written

at the same time as the code and the heading was the only half missing. The

repair that followed made `main` green by moving the **citation** instead of

writing the **heading**: `7c7224a` rewrote both comments to `[0.4.127]`, whose

own entry is `0949ceb` (*"the `bg_waited()` pairing"*, 09:46:44Z) — **73

minutes before** `49549e4` (11:00:12Z) — so the citation was made to exist by

pointing at a change that predates it, and it left the 14 citations in

`agent-logs/identity-dispatcher.md` untouched. `25344ed` then removed the brackets from

one dispatcher log line to *"avoid repo-lint false positive"*; the linter's

citations are **`[x.y.z]` tokens** (`repo-lint`: *"every `[x.y.z]` token found

while walking the committed blob"*), which is why the bare `0.4.128` on line

4200 is **not** in the failure list while the bracketed `[0.4.128]` on line

4199 — the very line above it — is. Dropping the brackets did not fix anything;

it only made the same citation invisible to the one check that reports it.

So the honest fix is the `[0.4.121]` one: write the heading from the code that

is actually committed, and put the two citations back where they are true.

above, attributed in the table rather than claimed as this run's own work.

are restored to **`[0.4.128]`** (line 1630 *"`disk-show`, [0.4.128]: 20 → 21

tools and 19 → 20 in scope"*, line 1823 *"19 of 20 before `disk-show`

landed, `[0.4.128]`"*): with the heading written, `[0.4.128]` is now both

green **and** true, whereas `[0.4.127]` was only green. Comment-only — no

assertion, no reader and no figure in that suite changes.

this entry writes the missing record and corrects two comment tokens.

1. **The red, before the fix**: `tools/repo-lint --format json` → **exit 1**,

`ok false`, **14** failures as listed above, `go_compile.ok true` (45 Go

files, 2.525 s), `changelog_version` **132 / 132 / 4146 / 14 missing**.

2. **The work being recorded is green, measured on this run rather than

assumed**: `bash tests/test_disk_show.sh` → **80 passed / 0 failed**, exit

0; `GOPATH=/tmp/gopath GOMODCACHE=/tmp/gopath/pkg/mod GOCACHE=/tmp/gocache

go test ./... -count=1 -short` in `app/src/go` → both packages `ok`

(`cmd/gladex 0.949s`, `cmd/gladex/commands 24.242s`), exit **0**;

`./tools/regression-run --list` → **62 suites**, matching the `- Live

(measured 2026-09-29): … 62 suites` line, so recording `[0.4.128]` moves no

suite figure.

3. **The red, after**: `tools/repo-lint --format json` **post-commit** →

**exit 0**, `ok true`, `failures []`, `errors []`, `citations_missing []`,

`changelog_version` **133 entries / 133 unique** — the 132 → **133** and

14 → **0** movements are this entry itself, read from the committed blob

(repo-lint lints committed blobs by design, so this line is asserted

*after* the commit rather than carried from before it).

4. **Gates read after the append**: `tools/queue-source-check --format json`

→ **exit 0, `violations []`**, *newest `[0.4.128]` pointer-only, **111**

frozen item lines across **85** sections*; `php tests/test_changelog_api.php`;

`php tests/test_changelog_mobile.php`; `tools/source-sync-check --format

json` → **`drift false`**; `bash tests/test_registry_coverage.sh`; `bash

tests/test_queue_source.sh`; `tools/system-status --format json`;

`tools/inbox-status` → **exit 0, `owed.total` 0**; `tools/budget-show` →

**exit 0** (allowance 5.00 / spent 1.50 / remaining 3.50, month 2026-09).

What landed here was someone else's committed code with a missing record;

the queue's own **(82)** is *not* closed by this entry: its `disk-show`

half is now documented, but the second half of that candidate — a

**free-space preflight in `regression-run`** — is still absent

(`grep -n disk tools/regression-run` finds no free-space check), so (82)

stands, narrowed rather than struck.

range**, and the fix chosen is content-side rather than loop-side: writing

the heading makes the citations true, whereas the alternative (strip the

brackets, as `25344ed` did) makes them unreportable without making them

right. **(78)** itself still stands — gating the loop's auto-commit on

`repo-lint` exit 0 changes the loop's commit path, not this repo's content.

it does not re-review *whether* the four commits were correct work — that is

the owning runs' claim, and the numbers above are the ones this run actually

executed.

citation swept** — the 14 were all the failures reported, and no bare

`x.y.z` token anywhere was re-audited (the linter does not count them);

**no queue item struck** — (73), (78), (79), (81), (82), (83), (85), (86)

and the whole carried list stand; **no version-train bump**

(`GLADEX_APP_VERSION` stays `0.4.28` — this entry is appended below the

legacy descending block, so `build.sh`'s *"top `## [x.y.z]`"* parse still

reads `[0.4.28]` at line 7), no promote executed, no service restarted, no

certificate touched, **zero DNS writes** (no `pdns-api.py` call), no mail

sent, Nextcloud untouched (`{"installed":true}`, §14 closed 2026-09-29),

`/opt/cloud` untouched, Immich untouched (`{"res":"pong"}`, 8 accounts),

**spend 0.00** (`*-free` only).

the run (direct `SELECT count(*) … AND read=0` on both live SQLite DBs,

confirmed by `tools/inbox-status` → **exit 0, `owed.total` 0**, **74 entries

/ 74 handled / 0 open**, `open_unreplied []`), so there was no question to

answer — and the status reply was written anyway rather than skipped:

**dev 124 / prod 90**, `read=1`, `ts 2026-09-29T14:24:53Z`, 2610-byte body,

parameterised insert with the unread predicate re-checked inside a

`BEGIN IMMEDIATE` transaction (abort rc 9 if it no longer held), script and

body `rm -f`'d and confirmed absent, unread still **0 / 0** after. **An

unanswered investor is a failed run; there was none.**

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history (85 sections as of `[0.4.128]`). To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

**(82)** was queued by `[0.4.125]` with the failure already measured: the root

filesystem reached **100 % (98 G, 0 available)** and the damage was *silent* —

shell output discarded at exit 0, writes failing, sqlite reporting

`disk I/O error` on a **read** — and the space was consumed by regenerable

caches that nothing prunes. The item offered two candidates: a `disk-show` /

`disk-guard` tool, *"and/or a free-space preflight in `regression-run`, which

is the tool whose own logs and `mktemp` sandboxes are a large part of what

fills `/tmp`"*. `[0.4.128]` recorded that run 325's `disk-show` had landed

while the preflight half was **absent**, and left the item open rather than

half-struck.

This entry is that second half, and the measurement that says it was needed is

on the old tool: `git show HEAD:tools/regression-run | grep -n

"statvfs\|disk_usage\|free-space\|MIN_FREE"` → **no hits**, i.e. the runner

would start, discover 62 suites, run for four minutes and only then discover

it could not write the last log — with the verdict of a run that never

finished.

Three decisions, each for a reason that was measured rather than inherited:

1. **An absolute MB floor, not `disk-show`'s percentage.** The two tools watch

different things: `disk-show` reports *how full* each mount is plus which

reclaimable caches explain it; this gates a *run* on *bytes left*, because

a disk at 79 % with 21 G free (this container, today) is healthy and one at

90 % with 0 bytes is not. The default is 512 MB — the floor below which a

run of 62 suites writing logs and sandboxes stops being cheap — and

`GLADEX_MIN_FREE_MB=0` is the documented off switch, not a hidden one.

2. **Watch the paths the run actually touches**: repo root, tests dir,

`TMPDIR` (default `/tmp`), and with `--log-dir` the nearest **existing**

ancestor of it. The ancestor walk is not a convenience: the directory is

created *after* the check, so `statvfs` on the path itself could not run —

and a check that cannot measure must refuse rather than pass, which is the

same "silence is not green" contract this tool exists for. An override path

that does not exist is exit 6, never a pass.

3. **Refuse before the first suite, and prove it by line order.** The call

sits after the `--list` branch and before `os.makedirs(args.log_dir)`

(pinned by K28), so exit 6 never competes with 1/3/4 — it is a refusal

like 2, decided before any work. The human channel prints **one ERROR line

on stderr with empty stdout** (no half-printed table); the JSON channel

prints the same **14-key** object a verdict would, with `suites: []`,

`ok: false`, and `suites_discovered` still naming what discovery had

already found — measured, because a refusal that nulls out the context it

decided about is a less useful object for no gain.

`PREFLIGHT_DEFAULT_MB = 512`; three new functions — `_nearest_existing()`

(the ancestor walk), `watched_paths()` (ordered, de-duplicated: the first

short path is the one named), `preflight_free_space()` (env parsing →

`_UsageError` for an unusable value, `statvfs` per path, fixture override,

the refusal message carrying path + measured MB + floor); `die()` gains

keyword-only `repo` / `tests_dir` / `discovered`, used only by callers that

are already past discovery; the call site in `main()`. Docstring: `Exit

codes` gains **6** and the precedence line becomes `2 > 6 > 3 > 4 > 1 > 0`

with the "decided before the first suite" clause, `Environment` gains the

three hooks and the preflight paragraph — **five epilog sections remain

five**, so `(81)`'s "a sixth rendered section" is untouched by design.

(K1–K33 with lettered sub-assertions), a `pf/` fixture suite that **writes a

marker file** so "no suite was started" is a file rather than an inference

from an exit code, and a `k/mutant` plant with the call `sed`'d out.

string, a **Free-space preflight** paragraph, the three test hooks, and the

Tests bullet (`255 → 298`, the contract now `0/1/2/3/4/5/6`, section K

described); `## test_regression_run.sh` — hermetic-fixture list (`pf/`,

`k/mutant`), exit codes `255 → 298`, the export discipline for the three

hooks, the **K** entry in Sections, `Tests / mutations` and **Status**.

hooks are env-only, so the option-coverage readers `(79)` walks are

untouched), no JSON key added (the 14-key contract is asserted by K11).

0 failed**, exit 0. The delta over the previous **255** is this section's 43.

HEAD:tools/regression-run`, i.e. the tool without any of this entry):

**264 passed / 30 failed**, and **every one of the 30 reds is in section K**

with **zero reds outside it** (`grep '^FAIL' | grep -v ' K[0-9]'` → empty).

264 + 4 = 268 + 30 = 298: the four absent assertions are G6/G6b/G6c/G6d,

which by design skip when `$TOOL` is not the shipped binary.

`refusal = None`, docstring intact): **267 passed / 27 failed**, again

**all 27 in K, none outside** — including K27 (the call is gone) and K28

(the placement order now has no middle line), while K29/K30 stay green

because the *documentation* survived the plant, which is exactly the

difference between this plant and the pre-fix replay.

→ **0** (`totals 7 passed`, `ok true`); `GLADEX_MIN_FREE_MB=999999999` →

**6** with `error: "free-space preflight failed: /data/repo has 105076 MB

free, 999999999 MB required (GLADEX_MIN_FREE_MB); no suite was started"`,

**0 stderr bytes** in JSON mode; `GLADEX_MIN_FREE_MB=abc` → **2**

(`GLADEX_MIN_FREE_MB is not an integer: 'abc'`); `=-5` → **2**;

`GLADEX_PREFLIGHT_PATHS=` → **2** (`names no path`);

`GLADEX_PREFLIGHT_PATHS=/nonexistent-pf-check` → **6** (`does not exist,

so its free space cannot be measured`); `--list` under the impossible floor

→ **0**.

line **1137** < the preflight call at **1167** < `os.makedirs(args.log_dir)`

at **1176**.

/tmp/opencode/regression-129 --timeout 900` → recorded in Notes below.

as landed by `[0.4.128]`; this entry closes the item. Nothing was pruned or

deleted: `disk-show` stays read-only by design, and neither tool touches a

cache — reclaiming space is the operator's decision, not the runner's.

name*: `bound_count()` is `pgrep -cf 'test_bound_orphan.sh'`, which matches

**any** process with that name, so two runs of this suite running at the

same time count each other's fixtures. Measured this run: the first attempt

at both controls ran them **in parallel** and produced J2/J6/J9/J17 reds

(`want=0 got=2`/`got=3`) that **disappeared on a sequential re-run**

(264/30 and 267/27 with **zero** reds outside K). The suite is green when

run alone — the shipped 298/0 was always sequential — but the red it would

produce is *another* run's presence, i.e. an artefact shaped exactly like a

leaked child. Candidate = scope the census to the sandbox (pid + `args`

match, the way `test_detached_children.sh` refuses a name-pattern `pkill`)

or make the fixture's name unique per run. Disclosed rather than smoothed

over: this entry's controls were re-run to get numbers that are about the

code under test and not about concurrency.

reclaim/prune path (that is `disk-show`'s read-only job); no new CLI option

and no new JSON key; **no sixth `--help` section** — `(81)` stands

untouched; no `wait`-arity work — `(86)` stands; no bare-token linter work —

`(87)` stands; **no version-train bump** (`GLADEX_APP_VERSION` stays

`0.4.28`), no promote, no service restarted, no certificate touched, **zero

DNS writes**, no mail sent; `BUDGET.md` untouched (1.50 spent / 3.50

remaining, month 2026-09), model spend **0.00** (`*-free` only).

before the work (direct `SELECT count(*) … AND read=0` on both live DBs,

`tools/inbox-status` → `owed.total 0`, **74 entries / 74 handled / 0 open**,

`grep '^## ' INBOX.md | grep -v HANDLED` → empty), so the standing status

reply was written anyway rather than skipped: **dev 125 / prod 91**,

`read=1`, `ts 2026-09-29T15:20:05Z`, parameterised insert with the unread

predicate re-checked inside a `BEGIN IMMEDIATE` transaction, script `rm -f`'d

and confirmed absent, unread still **0 / 0** after. **An unanswered investor

is a failed run; there was none.**

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history (86 sections as of `[0.4.129]`). To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

**(88)** was queued by `[0.4.129]` from a red it had already produced by accident: two runs of this suite overlapping in section J made `bound_count()` report processes belonging to the *other* run, and the entry called the artefact *"another run's presence, shaped exactly like a leaked child"*. The defect is not the overlap, it is the **scope**: `bound_count()` and `bound_kill()` both matched the bare name, so the census had no idea which run a process belonged to — and a `kill -9` that reaches outside your own sandbox is worse than a miscount, because it changes *another* run's verdict while making this one look clean.

Measured on the shipped reader before this run touched the file, with a deterministic stand-in for "another run" (a `bash …/f2/test_bound_orphan.sh` living in a different directory, started by nobody in this suite):

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history (87 sections as of `[0.4.130]`). To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

**(81)** was queued by `[0.4.124]` — the run that *installed* the termination guard — with its own measurement already in hand: `--help` renders five labelled docstring sections built from `EPILOG_PAIRS`, and the paragraph describing the guard's contract sits in the docstring with **no heading of its own**, so nothing rendered it. Measured again on the shipped tool before this run touched it, three needles that should have been visible and were not:

| needle | in `--help` before | after |

|---|---|---|

| `start_new_session` (the suite runs in its own session) | **0** | 1 |

| `143 / 130` (what the caller still sees) | **0** | 1 |

| `escapes any other bound` (the declared limit) | **0** | 1 |

and `grep -n "^[a-z][a-z ]*:$" <(regression-run --help)` listed exactly five epilog labels (`exit codes: summary parsing: baseline: environment: examples:`), the sixth docstring block never among them. This is the *green comes from the wrong place* class in its quietest form: nothing was failing, because no assertion asked `--help` a question only the docstring could answer — section J pins the guard's **behaviour** (SIGTERM/SIGINT really sent, group really reaped), while `--help`, the one surface a user reads, said nothing at all. The fix is one tuple entry, because the epilog has no prose of its own: `docstring_section()` already reads the heading, and `build_epilog()` already refuses (exit 3) if a heading is missing or empty, so a sixth pair inherits the refusal path, the byte-comparison and the `RawDescriptionHelpFormatter` verbatim rendering for free.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history (88 sections as of `[0.4.131]`). To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

**(90)** was queued by `[0.4.131]` from the step that added the sixth pair: `A3`'s label loop, `A4`'s heading loop, `A5`'s heredoc **and** `help_section()`'s terminator list each carried their own literal copy of the six entries. The consequence is not a red today, it is a *missing* red tomorrow — the tuple gains a seventh pair, `--help` renders it (the renderer is generic), and **no assertion in the suite is in a position to compare it**, because the three loops still iterate six literals. Coverage that only grows when a human remembers four places is coverage that grows late, and `[0.4.131]` had already paid the tax: adding one section meant editing a tuple, a heading, three lists and a terminator set.

The defect is invisible by construction, which is why it sat queued rather than failing: `grep -c seven $(git show HEAD:tests/test_regression_run.sh)` → **0** is not a red, it is the absence of one. Measured on the other side — a tool with a seventh pair, run against the **pre-edit** suite reconstructed from `git show HEAD:tests/test_regression_run.sh` (cut at `############ B.`; the whole subject is section A, and B–K need nothing from it) → **30 passed / 0 failed, exit 0**. Green, with a section rendered that nothing compared.

Deriving the lists trades that blind spot for two smaller ones, and both are asserted rather than argued:

| blind spot | why a derived list has it | assertion |

|---|---|---|

| the extractor understands the tuple no more | `mapfile` + one `sed` pattern yields an **empty** array, and every loop below then asserts *nothing* — a suite reporting fewer reds because it stopped asking | **A16** `>= 1` |

| a pair is deleted from the tuple | derived loops stop iterating over a section that is gone, so `A3`/`A4`/`A5` all stay green while the contract loses its only rendering | **A17.1–A17.6**, one per pinned section |

`EPILOG_REQUIRED` (the six labels) is therefore the one list that stays hand-written here, and it is deliberately *not* derived: it is the expectation the derivation is checked against. Its asymmetry is the point — a pair **added** is covered for free, a pair **removed** goes red.

| suite | result |

|---|---|

| pre-edit section A (from `git show HEAD:`) | **30 passed / 0 failed, exit 0** — green, `grep -c seven` on it → 0 |

| this suite | **311 passed / 2 failed, exit 1** — `A4.1 docstring section 'Seven:' non-empty (want>=1 got=0)`, `A5.1 --help 'seven:' differs from docstring 'Seven:'` |

Both reds are rows the literal lists had no slot for. Arithmetic: 314 + 3 (the seventh row in each of `A3`/`A4`/`A5`) = 317, − 4 (the same `G6*` block) = **313 = 311 + 2**.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history (89 sections as of `[0.4.132]`). To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Investor order 2026-09-29 (*VISIBLE-OUTPUT SPRINT*, T1): *"Public changelog page: /changelog already exists — fill it from CHANGELOG.md latest 5 versions (features, dates, test counts), verify 200 dev+prod, link it in landing nav."* Measured before the edit: the page answered **200** on both envs and was **1,057,161 bytes** of every release ever written — **141** version badges, `0.4.28` (2026-09-24) on the first screen because `CHANGELOG.md` is a legacy *descending* block followed by an appended *ascending* one, and the actual newest entry (`[0.4.132]`, 2026-09-29) at the far end of a megabyte. Nothing was missing; the newest five — the thing a visitor comes for — were simply nowhere near the top. `/` (landing) measured **1,690 bytes** with **zero links in it**, so the changelog was reachable only by URL.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

M4 asks for a "getting-started guide (5-minute setup)". `GETTING-STARTED.md` existed, but

only as a repo file: `grep -rl GETTING-STARTED app/src/php` returned nothing, so no served

page linked or rendered it (the binary link in it was still an unfilled placeholder). Of the

unbuilt MVP surface this was the highest-value item left: a visitor landing on `/` had no

path to a 5-minute setup.

nav, no skip link, no `id="main"`), that loads `GETTING-STARTED.md` — env-local copy first,

then `/data/repo/GETTING-STARTED.md` — and renders its Markdown (headings, fenced code,

ordered/unordered/bullet lists, `code`/`strong`/`em`, links allow-listed to `https?`, `/`,

`#`, `mailto:`), with inline `<style>` and the shared dark palette. Guide content stays a

single source of truth; the page is a renderer, not a copy.

the catch-all's exclusion list.

when available)` placeholder comment; Resources now point at `/docs` and `/changelog`.

one `<h1>` + its `##` sections, escapes `<script>` in fenced code, keeps links/text in the

allow-list, output is non-empty and free of placeholders, dev serves `/start` 200 with a

single `<h1>`, prod serves it only after promote (the 1 skip).

`$files`, `$expected`, `$noNav` and `$bare`; route table `'/start' => ['start.php', 200]`.

deliberately public, like `/`, `/pricing`, `/download`.

the figure was last taken, five of them mine) plus a `## test_start_page.php` section.

`gopath/`, `gocache/`. The Go module cache was the one path in that family left unignored,

so any run whose `go build` populated it (this run's, 573 MB at `app/src/go/gomodcache`)

left `git status --short --branch` printing nine `??` lines under the branch header — and

`test_gladex_monitor.sh` **A3** requires that output to *equal* `## main...origin/main`,

while **A15** requires system-status to report `[OK] clean`. Both went red from build

output alone, with nothing of the product touched.

check that clears on promote).

are prod presence/byte-identity (`start.php present in repo, dev and prod`,

`app.php`/`landing.php` `repo == dev == prod`), i.e. the unpromoted state.

repo=dev=prod`, same cause).

fig_stale=0` (the previously red `VIOLATION figure_stale 63` is cleared).

no placeholder text; `GET /` → 200, 3,651 bytes, includes `<a href="/start">Quickstart</a>`.

reviewer approves.

`#^(…|#|…)#i` and closed at the inner `#`, so every link rendered as plain text; and a

premature `}` guard in `start.php` caused `Cannot redeclare gladex_start_guide()` on the

second include.

footer also links LAN-only `/docs` and `/changelog`) instead of repeating it, as

`download.php` — the model for this page — is.

was the only unchecked deliverable behind a checked box.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

- `ok` `clean` — nothing uncommitted at all.

- `warning` `<n> uncommitted changes` — **unchanged, both text and verdict**, and deliberately so: changes exist and **none is staged** is the normal state of a run in progress, and flipping it would make the closing measurement of every future run red for the crime of editing a file. Staged-vs-not is read from the **porcelain first column** (` M` and `??` are not staged; `M `, `MM`, `A `, `R `, `UU` are).

- **`error` + `ERRORS++`** `<n> uncommitted change(s), <m> STAGED and not committed - parked step: no gate that reads HEAD can see it` — the row that exists because of this queue item: `errors 1`, `overall error`, **exit 1**, and the human verdict line becomes `Overall: 1 CHECK(S) FAILED` instead of the healthy one.

- `warning` `cannot verify: git status could not be read (exit n) - tree NOT checked` — `REPO_DIR` is not a work tree git can read. Never `clean` (the pre-step code printed `clean` for a non-repo directory, because `wc -l` counted an empty string — an unread tree is not an empty one), and never a red on a tree that was not checked, which is this repo's own rule for unverifiable inputs.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

- `tests/test_gladex_monitor.sh` **A3** is an exact-equality assertion over the *whole* `git status --short --branch` output (`is "## main...origin/main"`), so any status line fails it, staged included. It cannot *distinguish* staged from worktree-only — which is exactly why `[0.4.162]`'s row had to, and why A3 was never the fix.

- **`.githooks/pre-commit`** writes the **index** to a tree (`git write-tree` → `git commit-tree`) and lints that, so a staged append is linted at the only moment it can become a commit — `tests/test_commit_gate.sh` pins it at 41 assertions.

- **`tools/promote-dev-to-prod`'s ship-tree gate** refuses with exit 8 unless `git status --porcelain --ignored` over the promoted trees reports no difference from HEAD.

- Git side, measured in a throwaway repo: staged → `git status --short --branch` prints `## master` **plus** `M f.txt` (porcelain first column `M `, confirmed with `od -c`), while worktree-only prints ` M f.txt`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

- **A date floor** — newest heading's date against today — reads **green over `a88f56c`**, the very incident it exists for: that commit (2026-10-01T20:51:55Z) touched `CHANGELOG.md` **alone**, 23 minutes after `PROGRESS.md`'s own last touch (`7cb3b9e0`, 20:28Z), and both fall on **the same UTC day**. The only day such a rule can catch is tomorrow's.

- **A clock comparison** — heading date against the commit time of the `PROGRESS.md` append, or against now — **false-reds every normal run**: a heading is written moments before its own append is committed. A rule that reddens on the healthy shape is a rule everyone learns to read past.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

explicit *"no dedicated suite yet — honest gap, queued"* note; `(116)` queued

exactly that. A probe run once by the run that wrote the tool is a memory, not

a guard: **nothing in the tree would have reddened when that tool broke.**

The suite is hermetic by construction — every scenario points

`REDWATCH_LOG_DIR` at a `mktemp` sandbox and `REDWATCH_MONITOR_BIN` at a stub

written into it, each stub recording its own invocation, which is how the

*before-any-I/O* assertions read "the monitor never ran".

**A** argv validated before any I/O (`--help` → 0; unknown option, bad

`--format` value, missing `--format` value, non-numeric and zero

`REDWATCH_MONITOR_TIMEOUT` → 2, each with an empty `invocations` file *and*

an empty log dir) · **B** green is quiet (one dated line, **no** `ALERTS`

file at all, the five state fields) · **C** red is warn-only (exit 0), alerts

once, stays silent on a repeat, alerts `RED-SET` on a changed failing set

while keeping the original `since` epoch — plus **both directions of the red

predicate** (`rc != 0` with a clean summary → red, `rc == 0` with a failing

summary → red) · **D** `RECOVERED after=<n>s` with `previously_failed=` ·

**E** all four *cannot-verify* paths (missing monitor, no `summary:` line,

timeout, unwritable log dir) → exit **3** + `CHECK-ERROR` with the previous

verdict **kept**, and a green run after an error gap still reads as a

recovery · **F** JSON: exactly **15 keys**, `exit_code` == the process code,

`ok: false` on a red verdict at exit 0, the 6-key pre-I/O failure payload ·

**G** the caps (12 / 600 / 400), `"` → `'`, python3-only/no-network/no-DNS

static guards, a real-log-dir token check, the registry contract.

(31 s)**: control H0 green, then nine mutants — alert suppressed · quiet

success alerts · warn-only broken · check error reported as success · kept

verdict overwritten · no `summary:` line read as 0/0 · `ok` reporting the

tool instead of the tree · `RED-SET` removed · caps removed — each asserted

to have **applied exactly once**, to **parse** (so the red comes from

behaviour, not a syntax error), to **redden this suite**, and to redden it

**on its own intended assertion**. M5 and M6 guard the two promises that

existed only as prose: *"an input that was not read is never a pass"* and

*"the previous verdict is kept so a later green reads as a RECOVERED"*.

the `red-watch` section's **Tests** block rewritten from the gap note to the

suite's own section map.

have been in the payload since `[0.4.172]` and in no documentation — the

suite's `F11` asserts the exact 15-key set, and the registry now lists all

15. The `[0.4.172]` prose ("all 13 keys") stays as written: it is history,

and the record of the correction is here.

module docstring's, so `--help` and the source cannot disagree"*. Measured:

`red-watch --help` prints **argparse's own usage and description only** — no

exit-code block at all. The same sentence is **true** for `inbox-status`

(which renders `exit codes:` from its docstring) and for

`template-sync-check` (which renders its epilog), so this was one tool's

missing epilog, not a house rule; the bullet now says what the tool does and

where the exit codes really live, and `A2–A6`/`G27` pin both halves. The

tool itself is **unchanged**.

refresh `tests/test_registry_coverage.sh` section F requires of the run that

adds a suite, in the same commit that adds it.

`bash tests/test_red_watch.sh --mutations` → **213 / 0, 31 s**; the

tally is 176 = A 24 + B 19 + C 34 + D 12 + E 33 + F 27 + G 27, counted from

the run's own `== … ==` headers: C's 34 is `C` 28 + `C-extra` 6, and G's 27

is `G` 8 + `G-static` 11 + `G-registry` 8. (The first draft of this line

split the same 176 four ways wrongly — C 33, E 32, F 26, G 30 — and still

summed to 176, so only the per-section recount could catch it.)

edits (it is the file that reads it): figure **81 → 82** on the `- Live:`

line, sections **35 = 24 tools + 11 suite sections** (B4), every dated, no

duplicate, none stale.

asserted the alert length with `grep -qE '^.{1,700}$'` over a 680-char line

and took **22.1 s** on it (GNU grep, bounded repetition against a line

longer than the bound); three such assertions were the suite's whole 51 s

runtime. Length claims are now counted with `assert_le` and the reason sits

in the helper's comment, so nobody re-introduces the regex.

itself is byte-identical to `[0.4.172]`'s copy — only its documentation and

its new suite moved.

(`regression-run --list` → 82, matching the single `- Live:` figure).

`GLADEX_APP_VERSION` untouched at **0.4.28** (the changelog's *first*

heading did not move).

writes**; **no mail sent**; no history rewrite; model spend **0.00** (free

`*-free` models only).

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

into `/data/agent-logs/` and **nothing read any of it**: `(117)` recorded the

measurement (`grep -rln "red-watch" /data … | grep -v '^/data/repo/'` →

empty, `tools/healthcheck` and `system-status` named it nowhere,

`crontab -l` held only the writer), so the verdicts reached only a human who

opened `red-watch-ALERTS.log` by hand. **This is that reader**, and it is a

dashboard row rather than a notifier because every run, the monitor itself

(`sys` / `sysj` probes) and the reviewer already look at this output.

`GLADEX_REDWATCH_STATE`, default `/data/agent-logs/red-watch.state`,

deliberately **absolute and outside the git tree** so a scheduled run can

never dirty the tree it watches — and reports **four verdict families**:

`state=red` → **`[WARN]` always**, whatever the age (red-watch is warn-only

by construction and the `git-tree` / `queue-source` rows grade the tree

itself; this row exists so the verdict is *seen*, not so the dashboard fails

twice) · `state=green` fresh → **`[OK]`**, the only passing verdict ·

`state=green` older than `GLADEX_REDWATCH_STALE` (default **3600 s**) →

`[WARN] stale green …` — the cron rewrites the file every 15 min, so an old

green is a green about the past, i.e. the missed-schedule signal · anything

unreadable (file absent, no `state=` line, unknown state, an `updated=` that

is absent / not a date / postdating now) → **`[WARN] cannot verify`**, never

`ok`: *an input that was not read is never a pass*.

row can never increment `ERRORS` — staleness only ever **downgrades a green**

and never masks a red. The `fails=` line is sanitized (`"` and `\` stripped,

cut to 600) before it is interpolated, because it lands in hand-built JSON

*and* in the human renderer's own `grep -o '"detail":"[^"]*"'` — one quote

would truncate the row in both channels (`[0.4.106]` class).

both variables; the default path is asserted **absolute, not repo-relative**,

and a sandbox suite gets the absent-path verdict by pointing the hook at a

path it never creates.

suite does not pin are stubbed on `PATH`, every run is handed a sandbox repo

through `GLADEX_REPO_DIR`, and the state file is always a fixture path the

suite writes — **the live `/data/agent-logs/red-watch.state` is never read

here**, and section 13 reads the *source* to assert the default path is

absolute. Sections (tallied from the run's own `=== … ===` headers): **1**

absent state file → 10 · **2** fresh green → 10 · **3** red warn-only, the

`fails=` line surviving into JSON → 14 · **4** stale green → 9 · **5** stale

*red* (staleness downgrades a green, never masks a red) → 8 · **6–9** every

un-ageable input is `cannot verify` → 37 · **10** the staleness bound is a

real, overridable input → 28 · **11** the row is always present → 2 ·

**12** source contract (absolute default, both hooks in `--help`) → 5 ·

**13** mutations → 13.

this suite, and to redden it on its own intended assertion**: absent state

file reported `ok` · a **red** verdict reported `ok` · the staleness bound

defeated. All three are the promises that existed only as prose before this

entry; the tool is re-read byte-identical after the battery (mutants are

applied to a copy).

**35 → 36**), the `system-status` section's **Red-watch** bullet + env hooks

+ Tests block, `**Checks performed (37 total)**` (the row is the 37th

check), and the **`- Live:` suite figure refreshed 82 → 83** on its own

dated line — the refresh `tests/test_registry_coverage.sh` section F

requires of the run that adds a suite, in the same commit that adds it.

`bash tests/test_registry_coverage.sh` → **280 / 0**, re-run *after* the

`REGISTRY.md` edits (it is the file that reads it); `bash

tests/test_repo_lint.sh` → **463 / 0**; `./tools/regression-run --list` →

**83 suite(s)**, matching the single `- Live: 83` figure;

`./tools/queue-source-check` → **exit 0, `violations []`** before this

heading existed.

`red-watch [WARN] red, failed=7, since 2026-10-02T19:31:37Z, 11m old; FAIL

A3 …` · JSON → `{"name":"red-watch","status":"warning","detail":"red,

failed=7, …"}` — i.e. the row read the **real** state file written by the

cron job and reported it as a warning with **`errors` unchanged**, which is

the whole point of `(117)` landing as a reader rather than as a second gate.

entry documents were found **staged and uncommitted** at this run's start —

`run-20261002-211002-531.log` ends `Error: Rate limit exceeded. Please try

again later.`, and runs 532–555 are all that same 153-byte failure, so the

session that wrote `(117)`'s code stopped before its CHANGELOG heading, its

`PROGRESS.md` entry and its commit. This run re-verified the code from

scratch (suite 136/0, registry 280/0, lint 463/0, live row in both channels)

before writing this heading — the work was *checked*, not adopted.

(`regression-run --list` → 83). `GLADEX_APP_VERSION` untouched at

**0.4.28** (the changelog's *first* heading did not move). **No

`app/src/php` edit → no reviewer gate and no promote**; **no service

restarted** (`agent-loop` still queue item **(99)**); **no cron change**;

**zero DNS writes**; **no mail sent**; no history rewrite; model spend

**0.00** (free `*-free` models only).

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

`- Live:` bullet quoted the greedy-parse trap as *"**5** phantom duplicates

… 0.4.31/0.4.40/0.4.44/0.4.49/0.4.62"* and worded it as a fact about *"this

tree"*. Re-measured on the pushed tree at `[0.4.174]`: the same pipeline

(`grep '^## \[' CHANGELOG.md | sed 's/.*\[\([^]]*\)\].*/\1/' | sort | uniq -d`)

prints **14 lines**, not 5. The sentence now carries **13 version values**

(the original five plus 0.4.70/0.4.75/0.4.80/0.4.96/0.4.102/0.4.110/

0.4.162/0.4.172) **plus one empty-string line**, and says plainly that the

figure is a dated measurement rather than a constant — with the instruction

to re-run the pipelines instead of quoting the prose.

first**: the bullet opened `- Live: HEAD → exit 0 (176 files …)` — a

present-tense claim about *today's* HEAD that has been wrong since the tree

passed 176 (it is **270**, measured 2026-10-03). The opener now points at

the live figure (`files_total` in `repo-lint --format json`, with the

measured value and date) and keeps **176 files** explicitly labelled as the

`[0.4.65]`-era (2026-09-26) count, so the history below it still reads as

history.

`[0.4.83]`, `[0.4.86]`, `[0.4.89]`, `[0.4.93]`, `[0.4.168]` — end on a

`failures[]`, so the greedy capture is the empty string and all six collapse

into **one** duplicate line. That is why `14 lines ≠ 14 headings`, and it is

the reason neither number may be quoted from memory: **14** lines of

`uniq -d` output = **13** version values + **1** empty, over **6** headings

that produced `""`.

CHANGELOG.md | sed -E 's/^## \[([^]]+)\].*/\1/' | sort | uniq -d` →

**empty**, **0** real duplicates across **179** headings — unchanged by this

entry, because the trap is in the greedy pattern, not in the file.

`failures []`, `files_total 270`**; `tests/test_registry_coverage.sh`,

`tests/test_repo_lint.sh`, `php tests/test_changelog_api.php` and

`tools/queue-source-check` all re-run on the edited tree. No tool source,

no test, no `app/src/php` file changed — **no reviewer gate, no promote**;

`- Live:` suite figure untouched (**83**); `GLADEX_APP_VERSION` untouched

(**0.4.28**, the changelog's *first* heading did not move).

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

- `source-sync-check` said **42 files across dev+prod in sync**; the tool prints **44** (`8 examples/workflows + 14 src/php` per env × 2 envs). Its line already carried a date — of a *fix*, not of the measurement — so a date alone would not have caught it: the figure is now 44, dated to the run that re-read it, and the line records that it said 42.

- `disk-show` quoted **`/` at 77.5 % / `/data` at 5.1 %**; measured **73.5 % / 6.0 %** (`df -h /` agreed at 74 % the same day). The bullet now says plainly that its percentages are a dated observation, not what its suite asserts — the suite pins the exit code, the two watched mounts and one name/path/note per reclaimable row.

- `promote-dev-to-prod --dry-run` said exit 5 "while `reviewer-to-main/` is empty"; `mailboxes/reviewer-to-main/` holds **five** verdict files and the refusal that actually fired is the gate's *third* branch — `GATE REFUSED (exit 5): verdict VERDICT-20260930T022500-team-sofia.md is STALE … re-review required`. The bullet now names all three exit-5 branches and which one was measured.

the registry prose: `^- Live` bullets only. Measured before declaring it —

five `Live:` lines are indented inside section bodies and therefore outside

the reader: **two carry no digit at all** (`Live transcript …`, `Live:

repo-lint --format json --sha HEAD …`) and **three carry a digit with no

`YYYY-MM-DD`**, each anchored instead to a changelog citation (`[0.4.46]`,

`[0.4.47]`, `[0.4.49]`). Whether a version citation counts as attribution —

and whether the `^- Live` restriction should be machine-checked rather than

prose, so a claim written on an indented line cannot be invisible to every

reader — is queued as **(120)**, not decided inside this step.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

```

[2026-10-05T01:51:59Z] DRIFT gladex.de: egress=not-an-ip dns=77.90.15.49 class=unparseable

[2026-10-05T01:51:59Z] DIAGNOSIS: egress is a public IP but differs from DNS.

[2026-10-05T01:51:59Z] ACTION: verify VPS IP 77.90.15.49 is still correct BEFORE touching DNS.

```

i.e. the log asserts the egress **is** an address for the `class=` token on the line above saying it could not be read as one, then sends the operator to verify the VPS — the wrong fault, described confidently, in the one channel (`ip-drift-ALERTS.log` + dated log) every reader trusts. A third branch now writes `DIAGNOSIS: egress is NOT an IP address (public_ip could not be parsed).` and `ACTION: run 'ip-drift-check --format json' by hand and read its public_ip.` The two existing classes are byte-identical to before, and the `DNS NOT MODIFIED (deliberate).` rail is untouched — this changes what a human is told, never what is done to DNS.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the newest run entry's `Queue — next small step` bullet — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the newest run entry's `Queue — next small step` bullet — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the newest run entry's `Queue — next small step` bullet — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the newest run entry's `Queue — next small step` bullet — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the newest run entry's `Queue — next small step` bullet — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

- **m43a / m43b** — group 2's, resp. group 3's, quote class widened `([^"]*)` → `([\s\S]*)`, a TRUE superset (the only loosening here that is one in the set-inclusion sense): one match swallows the assertions behind it, so the extraction returns **0 rows** → **311 passed / 2 failed**, both reds inside step 1 — the count (`found 0 presence + 0 absence read(s), expected 3 + 6`) and the contract (`… not the contract — 1,9c1;…`) — and nothing else: step 4 skips an empty `ROWS30`, and §23 reads `PY30X`'s own lowercase `pat`, which these edits do not touch;

- **m43c** — var class `[PCU]` → `[A-Z]*[PCU]` → **335 / 5**: the two step-1 reds plus step 4's three `the extraction returned a target this block does not know ($CED…)` rows (the probe's own predictor: **12 rows**, 6 has + 6 lacks, `$CED*` unknown, where the contract holds 9);

- **m43d / m43e** — the trailing `\n` anchor dropped, and the backslash-newline widened to `\s*` → **337 / 0, invisible**: the same nine rows come out (3 + 6, contract equal), so there is no mutant to plant — a mutant that reddens nothing proves nothing ((al)'s rule) — recorded and not planted;

- **m44a / m44b** — `SELF30` retargeted to a path that does not exist, and to the reader suite → **310 / 3** on both: step 1's two verdicts plus `control30 §23`, because `PY30SRC` and `PY30X` open the SAME file with the SAME shape, so step 1's extraction and §23's `len(a)` cannot move apart.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the newest run entry's `Queue — next small step` bullet — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

- **M45** — `THEIRS_BODY`'s first entry dropped (the M40 span trick: dict head + entry + trailing newline, because the bare entry line is not unique in this file) → `len(b)` = **6**, not the bullet's **8**: a body carries **3** rows, one per class (measured), while **8** is what ONE retargeted ROW costs (M38). **336 / 1**, single red `control30 §23: the reader suite extracted 6 of its nine diagnosis reads`, the `die` at **872**;

- **M46** — `THEIRS_VAR`'s two class labels swapped in ONE edit: the probe **asserted** the multiset argument (al) used for M42 instead of inheriting it — `pa == pb` → **True**, both blocks carrying the identical `{has ×1, lacks ×2}` per class — so 870/872/875 pass and **four** `PAIR23` rows go missing → **336 / 1**, single red `control30 §23: §23 lost its pair-guard row(s): …`, the `die` at **884**;

- **M47** — `theirs()`'s own body class widened across lines: the filter is an exact `in`, so a widening can only DROP rows, and the greedy class starts at the file's first `grep -qF` and swallows forward → `len(b)` = **0**. The bullet's "more or fewer — the probe judges which" answered **fewer**. **336 / 1**, single red `control30 §23: the reader suite extracted 0 of its nine diagnosis reads`, the `die` at **872**.

Three single reds, three DIFFERENT pins, each on exactly the `die` its own plant reaches; M45's and M47's share M38's phrase but not its digit, and M46's runs past M39's shorter pin of the same assertion — which is what keeps the three teeth redirects apart.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the newest run entry's `Queue — next small step` bullet — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the newest run entry's `Queue — next small step` bullet — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

- **M48** — `mine()`'s body class widened across lines: the SECOND `([^"]*)` of that lowercase `pat`, the one feeding `if m.group(3) in MINE_BODY`, became `([\s\S]*)`, so one greedy match swallows the rows behind it and the exact-`in` filter sees nothing it knows → `len(a)` = **0** (the bullet predicted 0; the predictor ran `PY30X` directly against the planted file and agreed) → **336 / 1**, single red `control30 §23: this file extracted 0 of the nine class-internal reads, want 9`, the `die` at **870** — the pin carries the digit **0**, which M40's pin of the same assertion (6) does not;

- **M49** — `MINE_VAR`'s `$DCU` and `$DCP` labels exchanged in ONE edit: bodies untouched so `len(a)` stays **9**, and the kind/class multiset argument (al) used for M42 was **asserted by this probe** rather than inherited — `pa == pb` → **True**, both blocks carrying the identical `{has ×1, lacks ×2}` per class — so 870/872/875/884 all pass and **four** rows lose their prefix match → **336 / 1**, single red at the `die` at **888**, its unmapped-row detail **produced by the probe rather than guessed** as the bullet demanded (`has/public/egress is NOT an IP address …; has/unparseable/…; lacks/public/…; lacks/unparseable/egress is NOT an IP address …`).

Both pins measured to run past M42's shorter pin of that assertion: `PY30X` was re-run with M42's own replacement applied on a throwaway copy and M42's line tested for M49's pin → **not contained**. Collateral, the reader suite over both planted trees and the clean tree → **759 / 0, rc 0** each.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the newest run entry's `Queue — next small step` bullet — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

- **M50** — `PY30SRC`'s FIRST `BODIES` entry dropped WHOLESALE (the M40/M45 head+entry+trailing-newline span: the bare entry line counts **2** here, `PY30X`'s `MINE_BODY` carrying the same bytes). The exact-`in` filter loses that body's three rows — a body carries **3** rows, one per class, always {has ×1, lacks ×2} — the counts fall to **2 + 4** and BOTH step-1 verdicts redden → **327 passed / 2 failed, rc 1** (`control30 src: found 2 presence + 4 absence read(s), expected 3 + 6` + the contract ` — 2d1` header). The bullet **predicted** this two-red and the probe confirmed it; the pin is the COUNT half — the verdict that runs first — whose digits **2/4** carry neither M37's **3/6** on the same assertion nor M40's **6** / M48's **0** on the §23 count. The second red is disclosed, not hidden: it is the sibling verdict reading the same `ROWS30`.

- **M51** — the same entry RETARGETED to the public class's ACTION body in ONE edit. The kind/class multiset argument (al) was **asserted by this probe, not inherited**: whichever body sits in the set carries {has ×1, lacks ×2}, and the predictor read `bodies=3 rows=9 has=3 lacks=6` off the PLANTED file, so the count pin stays **green** while the contract pin reddens with its own ` — 2c2` diff header (apart from M36's bare phrase and M43's `1,9c1`) plus **three step-4 rows**, whose worlds cannot satisfy a non-contract body → **333 passed / 4 failed, rc 1**. Pin = the CONTRACT half. This is the count-green ∧ contract-red split (am) proved unreachable for `PAT` edits and reachable here.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the newest run entry's `Queue — next small step` bullet — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

- **M52** — `PY30PLANT`'s FIRST entry dropped WHOLESALE: the map loses a key `ORDER` still names, so `own = LINE % BODIES[cls]` raises `KeyError` for that class and `borrow`'s join raises it for the other two → **310 passed / 9 failed** live-free (**313 / 9** plain): three `the plant did not apply` rows whose message opens with a Python TRACEBACK — an uncaught exception, which no `SystemExit` path in that heredoc can print — plus six step-4 `no planted log to read (its plant failed above)`, two per class, because `[ ! -s "$BORROW30" ]` gates a class's two absence rows together.

- **M53** — the first two class KEYS swapped (values left in place): all three plants still SUCCEED (every guard counts the arms it expects, the plant's own `ok` rows stay green), but the ALSO-append lands on the WRONG arm for `public` and for `private-or-cgnat`, whose executed arms stay clean → **333 passed / 4 failed** live-free (**336 / 4** plain): four `did not bite` — private-or-cgnat's pair printed first, `public`'s second — while `unparseable`'s two rows stay **GREEN** because its own arm is the one this plant rewrites. The (al) multiset argument is **asserted here, not inherited**: a borrow log carries exactly `BODIES[cls]` plus the other two entries, so a key swap moves two classes' content and never one class's (the planted file reads `bodies=3 rows=9 has=3 lacks=6`).

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the newest run entry's `Queue — next small step` bullet — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the newest run entry's `Queue — next small step` bullet — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

- **M54** — `PY30PLANT`'s `LINE` widened by ONE character (a space before the closing quote): `own = LINE % BODIES[cls]` can no longer match an arm, so the writer's first guard raises `this class's DIAGNOSIS line occurs 0 time(s), want exactly 1` — a `SystemExit`, so unlike M52 the message carries NO traceback — for all three classes → **310 passed / 9 failed** live-free (**313 / 9** plain): three `the plant did not apply` rows whose message is that count-0 `SystemExit`, plus six step-4 `no planted log to read (its plant failed above)`, two per class, because `[ ! -s "$BORROW30" ]` gates a class's two absence rows together.

- **M55** — `PY30SWAP`'s `LINE` widened the same way: `a, b, c = LINE % PUB, …` counts **0/0/0**, so the swap's own guard raises `a class DIAGNOSIS line occurs 0/0/0 time(s), want 1/1/1` and the ONE swap never runs → **320 passed / 4 failed** live-free (**323 / 4** plain): the single `control30 swap: the plant did not apply` row plus the three step-4 `no swapped world to read (its plant failed above)`. The borrows are untouched by this shape, so `M5[23]`'s ten `ok` rows all still land over it.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the newest run entry's `Queue — next small step` bullet — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

- **The pure reorder — a MEASURED SURVIVOR, recorded like M44 rather than planted**: `('unparseable', 'public', 'private-or-cgnat')`, all three entries kept, public merely no longer first → default **340 / 0** plain, **337 / 0** live-free, rc **0**, reader suite **759 / 0**, `grep -c M56` → **0** in every one of those outputs. `report_sorted` is a *stable* sort keyed on the class rank alone, so with every row already inside one class the swap re-orders nothing control30 can see — the ordering is real but nothing in this suite is load-bearing on it. It is written down as a survivor the way M44's was, not smuggled into the battery as a plant that could never redden.

- **M56 — the entry DROP, the shape that reddens**: `('public', 'private-or-cgnat')`, the `unparseable` entry removed → **338 / 2** plain, **335 / 2** live-free (rc 1), and the two reds are both the step-4 teeth-proofs that name it: `control30 private-or-cgnat: 'drift_cgnat → does not borrow the unparseable class's diagnosis' did not bite …` and its `control30 public` twin `drift_pub → …` — the class's rows fall out of the report, so the two borrows that must NOT carry the unparseable diagnosis stop being able to prove they do not. Reader suite over all three trees → **759 / 0, rc 0** on each (those plants edit only THIS file, which that suite never reads this way), and `M56_blind` → **0** in every probe output.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the newest run entry's `Queue — next small step` bullet — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the newest run entry's `Queue — next small step` bullet — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the newest run entry's `Queue — next small step` bullet — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the newest run entry's `Queue — next small step` bullet — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the newest run entry's `Queue — next small step` bullet — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the newest run entry's `Queue — next small step` bullet — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

| shape | input | result | rc |

|---|---|---|---|

| clean control | — | **122 passed, 0 failed** | 0 |

| `M1_FIND_break` | M1 find | 120 passed, 1 failed | 1 |

| `M1_REPL_false` | M1 repl | 121 passed, 1 failed | 1 |

| `M2_FIND_break` | M2 find | 120 passed, 1 failed | 1 |

| `M2_REPL_noop` | M2 repl | 121 passed, 1 failed | 1 |

| `M3_FIND_break` | M3 find | 120 passed, 1 failed | 1 |

| `M3_REPL_noswap` | M3 repl | 121 passed, 1 failed | 1 |

| `M4_FIND_break` | M4 find | 116 passed, 1 failed | 1 |

| `M4_REPL_noop` | M4 repl | 116 passed, 6 failed | 1 |

| `W500_to_200` | M4 world | 116 passed, 6 failed | 1 |

| `W200BAD_to_ok` | M1 world | 121 passed, 1 failed | 1 |

| **`M3_DEAD_empty`** | **M3 port** | **120 passed, 0 failed** | **0** |

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the newest run entry's `Queue — next small step` bullet — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

| tree | input | result | rc |

|---|---|---|---|

| `base` | healthy | **155 passed, 0 failed** | 0 |

| `mutant` | `F3A=""` (pid file never written) | **155 passed, 0 failed — B16 `PASS`, suite green** | **0** |

| `fixed` | `F3A=""` + the non-vacuity arm | 135 passed, 20 failed, `FAIL: B16 the pid file … never wrote` | 1 |

| `fixonly` | healthy + the non-vacuity arm | **155 passed, 0 failed**, B16 `PASS` | 0 |

| `bgbase` | healthy `tests/test_budget_show.sh` | **89 passed, 0 failed** | 0 |

| `bgmut` | `SRC=""` (the static scan's whole input) | **89 passed, 0 failed — `PASS: static guard: tool contains no write/exec API`** | **0** |

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the newest run entry's `Queue — next small step` bullet — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

| suite | site(s) | source-level mutation | before → verdict |

|---|---|---|---|

| `test_budget_show` | M (`:349`) | `SRC=""` | **89 / 0, rc 0**, guard `PASS` → **FIXED** (now 88 / 1, rc 1) |

| `test_disk_show` | K1/K2/K3 (`:357`) | `SRC=""` | **90 / 0, rc 0**, all three `PASS` → **FIXED** (now 87 / 3, rc 1) |

| `test_source_sync_check` | L×2 (`:153`) | `SRC=""` | **40 / 0, rc 0**, both `PASS` → **FIXED** (now 38 / 2, rc 1) |

| `test_cache_show` | L1/L8/L9 (`:359/381/386`) | `SRC=""` | 101 / 4, rc 1 — **L3, L4, L5, L6** count exact substrings of `$SRC` → **rejected** |

| `test_pdns_api` | `:597` / `:602` | `SRC=""` / empty tool file | 171 / 4, rc 1 (**4× `assert_has`**) / 65 / 100, rc 1 → **rejected** |

| `test_system_status_unread` | `:203` | `SRC=""` / empty tool file | 24 / 2, rc 1 (**197, 199** `\|\| bad`) / 5 / 21, rc 1 → **rejected** |

| `test_smtp_relay_probe` | `:233` | empty tool file | 4 / 34, rc 1 → **rejected** |

| `test_system_status_ip_drift` | `:1127/1262/2018/2960` | `$WLOG` truncated before the read block | 733 / 26, rc 1 → **rejected** |

| `test_vhost_ui_smoke` | `:226` | `: > "$BODY"` on the shared fetch | 84 / 1, rc 1 (`FAIL cloud.gladex.de missing 'Nextcloud'`) → **rejected** (the site itself still printed `ok`) |

| `test_vhost_ui_smoke` | **`:254`** | `: > "$BODY"` after its own fetch | **85 / 0, rc 0** while it printed *`ok — unlisted … does not reach the investor app (HTTP 200)`* → **LIVE, queued as (be)** |

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the newest run entry's `Queue — next small step` bullet — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the newest run entry's `Queue — next small step` bullet — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the newest run entry's `Queue — next small step` bullet — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

| # | layout | result | wall | write-through |

|---|---|---|---|---|

| 1 | control, `tests/`+`tools/` real | **155 / 0, rc 0** | 276 s | none (5/5 md5 OK) |

| 2 | `tools/` → symlink | **133 / 22, rc 1** | 270 s | **4 live tools** |

| 3 | `tests/` → symlink | **121 / 34, rc 1** | 141 s | **the live suite file** |

| 4 | control, edited bytes | **155 / 0, rc 0** | 274 s | none (5/5 md5 OK) |

| 5 | `tools/` → symlink, edited | **rc 1, refusal** | 14 s | none (5/5 md5 OK) |

| 6 | `tests/` → symlink, edited | **rc 1, refusal** | 14 s | none (5/5 md5 OK) |

Run 1 is the harness's own control: it reproduces the in-tree **155 / 0** before anything is planted, so the layout is measured rather than assumed. Both pre-fix runs also close their own arithmetic, **133 + 22 = 155** and **121 + 34 = 155**.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the newest run entry's `Queue — next small step` bullet — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

| # | bytes | plant | result |

|---|---|---|---|

| 1 | control (root-pin only) | none | **115 / 0, rc 0** — reproduces in-tree, so the layout is a control |

| 2 | pre-fix | F6's own read → `""` | **115 / 0, rc 0**, F6 printed `PASS` → **LIVE** |

| 3 | pre-fix | `json_eval` returns nothing for every F-expression | **98 / 17, rc 1** — F2/F3/F4/F5 **FAIL**, **F6 still `PASS`** → masked at input level, vacuous at site level |

| 4 | post-fix | same as 2 | **114 / 1, rc 1** — `FAIL: F6 … (source is EMPTY - nothing was read)` |

| 5 | post-fix | none | **115 / 0, rc 0** — count unmoved |

| 6 | **in-tree, edited bytes** | none | **115 / 0, rc 0**, `PASS: F6 …` |

Run 2 → run 4 is (bc)'s verdict rule applied to this site: *un-teeth'd = the suite still exits 0 on the mutation*, and it did. Run 3 is the honesty row the queue's own note ("masked by F5 in the same branch") predicted — measured, not assumed, and recorded so the next run does not re-derive it.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the newest run entry's `Queue — next small step` bullet — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

| # | bytes | source | result |

|---|---|---|---|

| 1 | pre-fix | real (`/data/repo/tests`) | **346 / 0, rc 0**, `$ISO/tests` a **real dir** — layout control |

| 2 | pre-fix | **symlink** | **346 / 0, rc 0** while `test -L "$ISO/tests"` **true** and `-ef` **true** → **LIVE defect** |

| 3 | post-fix | **symlink** | **rc 1, 6 s**, `FAIL: isolation copy refused: … or /data/repo/tools is a SYMLINK …`, **no `$SB/iso`** |

| 4 | post-fix | real | **346 / 0, rc 0**, `$ISO/tests` a **real dir** — the guard does not fire on healthy sources |

| 5 | post-fix, **in-tree** | real | **346 / 0, rc 0** (60.6 s), `G7` and `G12` pass — count unmoved |

Run 2 → run 3 is (bc)'s verdict rule applied to this site: *un-teeth'd = the suite still exits 0 on the mutation*, and it did — **346 / 0** while the control it was proving was the shipped tree. Two further readings: `./tools/regression-run --tests-dir runs/postplant` → `no_summary … -> no 'N passed, M failed' line in output` → **exit 4** (the refusal is red at the tool level too), and the documented mutant-mode figure still holds with the guard present — `REGRESSION_RUN_BIN=<copy>` in-tree → **342 / 0 / 4 skipped** with `SKIP G6` printed.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the newest run entry's `Queue — next small step` bullet — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

| # | mutation | result |

|---|---|---|

| 1 | `if false` — never refuses | **346 / 1, rc 1**, `FAIL: G13 … (want=1:1 got=0:0)` |

| 2 | cause line dropped, rc kept | **346 / 1, rc 1**, `FAIL: G13 … (want=1:1 got=1:0)` |

| 3 | `if true` — always refuses | no `Results:` line, rc 1, `FAIL: G14 the refusal stays silent on a real source (rc=1 out=FAIL: isolation copy refused: …)` **then** the call site's refusal — both halves observably red |

Each mutation was applied to a copy of the suite, run through the run-799 harness's four disclosed header edits (`TESTS_DIR`/`REPO`/`SELF` pinned, parent trap disabled) with a private `TMPDIR`; `bash -n` OK on all three. Plant 3 is the one that justifies the ordering: a fourth variant put the readings **after** the call site and applied the same `if true` mutation → rc 1 with **0 `G14` lines**, no `Results:` line and only the call site's refusal (`/tmp/opencode/probe800bj/runs/after.out`) — i.e. the quiet half printed nothing at all there, which is why the readings sit first. Measured this run, not reasoned.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the newest run entry's `Queue — next small step` bullet — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

| plant | what empties/poisons | pre-fix site state | post-fix site state |

|---|---|---|---|

| P5 | human stdout = `""` | **C6 D9 H5b H6b all PASS** (sync, 105 / 8 with 8 siblings red, none in H) — drift **105 / 10** with C6/D9 PASS | sync **101 / 12**, **C6 D9 H5b H6b FAIL**; drift **103 / 12**, **C6 D9 FAIL** |

| P6 | stderr = `""` | **E4 PASS** while E3/E7 red (drift 113 / 2, sync 111 / 2) | **E4 FAIL** (+1 red: drift 112 / 3, sync 110 / 3) |

| P1–P4 | needle present, haystack non-empty | site red as designed (C6 / D9 / E4 / C7+H6b) | **identical counts** — the arm costs nothing when a byte was read |

P5→post minus P5→pre is exactly **−2** (drift: C6, D9) and **−4** (sync: those two plus H5b, H6b); P6 is exactly **−1** in both shapes (E4). The arm fires only where the haystack was empty, which is the whole claim, and P1–P4 staying byte-identical is the proof it does not fire anywhere else.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the newest run entry's `Queue — next small step` bullet — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

| phase | suite bytes | result at site 315 | suite total |

|---|---|---|---|

| healthy | edited (post-fix) | `PASS` (non-empty, delegate) | **89 / 0, rc 0** |

| pre-fix plant | original (pre-fix) | **`PASS` vacuously** (empty `$OUT` satisfies "no WARN") | **89 / 0, rc 0** ← the hole |

| post-fix plant | edited (post-fix) | **`FAIL: … (haystack is EMPTY - nothing was read)`** | **88 / 1, rc 1** |

Pre-fix is the claim the whole item rests on: the suite stayed **green (89 / 0, rc 0)** over a tool that printed **nothing** for the fresh ledger, with site 315 printing `PASS` from an empty haystack. Post-fix is the same plant against the edited suite: the empty arm fires first, the site reddens, and the suite goes **88 / 1, rc 1** — the exact shape `[0.4.268]` produced for `test_template_sync`. The healthy run is byte-identical in count to the pre-edit baseline (89), confirming the swap costs nothing when a byte was read.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the newest run entry's `Queue — next small step` bullet — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

| cell | suite bytes | tool | result | at E14 |

|---|---|---|---|---|

| A healthy baseline | original | shipped | **347 / 0, rc 0** | `PASS` |

| B **pre-fix plant** | original | planted | **343 / 0, 4 skipped, rc 0** | **`PASS` vacuously** ← the hole |

| C post-fix plant | edited | planted | **342 / 1, 4 skipped, rc 1** | **`FAIL: … (haystack is EMPTY - nothing was read)`** |

| D healthy after fix | edited | shipped | **347 / 0, rc 0** | `PASS` |

**B is the whole claim**: the suite stayed green (rc 0, zero failures) over a tool that printed **nothing** for an unknown flag, with `E14` printing `PASS` from an empty haystack. C is the same planted binary against the edited bytes — the empty arm fires first, exactly at E14, and the suite reddens. The `4 skipped` in B and C are the documented `G6*` block, which runs only when the binary under test *is* the shipped one (`REGISTRY.md` already pins that run at **343 / 0 / 4** since `[0.4.267]`, so cells B/C are comparable to a recorded baseline rather than to a fresh number); A vs D is the count proof — **347 == 347**, `PASS + FAIL + SKIPN == 347` both times.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the newest run entry's `Queue — next small step` bullet — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

| cell | tree | suite bytes | tool | result | at I83 |

|---|---|---|---|---|---|

| A healthy baseline | in-tree | pre | shipped | **347 / 0, rc 0** | `PASS` |

| PA baseline | probe | pre | shipped | **331 / 0, 15 skipped, rc 0** | `PASS` |

| **PB pre-fix plant** | probe | pre | planted | **323 / 8, 15 skipped, rc 1** | **`PASS` vacuously** ← the hole |

| **PC post-fix plant** | probe | planted bytes | planted | **322 / 9, 15 skipped, rc 1** | **`FAIL: … (haystack is EMPTY - nothing was read)`** |

| PD healthy after fix | probe | post | shipped | **331 / 0, 15 skipped, rc 0** | `PASS` |

| D healthy after fix | in-tree | post | shipped | **347 / 0, rc 0** | `PASS` |

**PB is the claim:** `I83` printing `PASS` while `$OUT` held 0 bytes — proved by **PC reddening at exactly that site with the empty-arm message**, which only fires on an empty haystack. Count proof: **347 == 347** in-tree (A vs D) and **331 == 331** in the probe tree (PA vs PD), so the swap costs nothing when a byte was read.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the newest run entry's `Queue — next small step` bullet — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

| cell | tree | suite bytes | tool | result | at the 5 sites |

|---|---|---|---|---|---|

| A healthy baseline | in-tree | pre | shipped | **199 / 0, rc 0** | PASS |

| PA probe baseline | `probe/pre` | pre | shipped | **199 / 0, rc 0** | PASS |

| B plant 1 refusal-scoped | in-tree | pre | silenced in `refuse()` | **129 / 70, rc 1** | PASS — haystack **345/346 B, not empty** |

| C plant 1 refusal-scoped | in-tree | post | silenced in `refuse()` | **129 / 70, rc 1** | PASS — non-empty, helper delegates |

| **E plant 2 total silence** | `probe/pre` | pre | silenced at `_promote()` entry | **123 / 76, rc 1** | **PASS vacuously** ← the hole |

| **F plant 2 total silence** | `probe/post` | post | same plant | **118 / 81, rc 1** | **FAIL … (haystack is EMPTY - nothing was read)** ×5 |

| D healthy after fix | in-tree | post | shipped | **199 / 0, rc 0** | PASS |

**E vs F is the claim**: the same plant, the only difference being the five swaps — **123 − 5 = 118 passed, 76 + 5 = 81 failed**, the delta landing exactly on `M7 M9 M10 M11 M12` with the empty-arm message, which can only print on a 0-byte haystack. A vs D is the count proof (**199 == 199**), PA shows the probe tree is equivalent to the tree (199 == 199 there too), and C is the no-false-fire control: with 345 bytes read the helper delegates and the numbers match B exactly (129 / 70).

| class | n | sites | verdict |

|---|---|---|---|

| **paired** — a positive reader on a sibling stream in the same block | **10** | `promote_lint_gate` `M7 M9 M10 M11 M12` (**closed here**), `repo_lint` `R2 R7 R9f R18d R12b` | per-site hole; **no green plant possible** — the pair reddens first |

| derived field (`$DETAIL` from `item_field "$OUT"`) | 3 | `system_status_promote_gates` L919 / L927 / L1049 | bound: the same block asserts `item_field "$OUT" … = "ok"` |

| non-stream haystack | 5 | `disk_show` J3 (`$SB`), `registry_coverage` C42r (`$c42_a_sec`), `regression_run` H5/H6 (source lines), `verify_landing` F3 (`$TOOL`) | outside the rendered-stream class |

| scan false positive (implicit-`$OUT` reader) | 2 | `repo_lint` W2 (`json_ok`), X4 (`x_last=$(…)` reads the same bytes) | protected |

| **unreviewed** — file-derived stream | 1 | `immich_roundtrip` L800 `$JSON_OUT` (+ its `$(…)` siblings L679/L683) | **queued (bo)** |

The scan is a *candidate finder*, not a verdict: it under-counts readers that reach `$OUT` through a helper (`json_ok`, `sget`, `has_v`) or through a boundary statement, which is why every hit was read by hand before anything was touched.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the newest run entry's `Queue — next small step` bullet — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

| cell | suite bytes | tool | result | at the 5 sites |

|---|---|---|---|---|

| A healthy baseline | pre | shipped | **473 / 0, rc 0** | PASS |

| **B healthy + the proposed swap** | `swap` | shipped | **468 / 5, rc 1** | **FAIL ×5 `haystack is EMPTY`** ← the swap is wrong here |

| C plant 1 refusal-scoped | pre | `die()`'s human path silenced (`400468b7`) | **455 / 18, rc 1** | **PASS ×5** |

| D plant 2 total silence | pre | both streams → `/dev/null` from import (`848c287f`) | **263 / 210, rc 1** | **PASS ×5** |

**B vs A is the whole decision**: the only cell that moves the five sites is the fix itself, and it moves them in the healthy tree. **C and D are the protection proof**: the five never change (their haystacks are empty in *every* cell), while their blocks redden on a sibling — **D** (the only plant that can reach all five streams at once) reddens `R3` (`R2`'s block), `R6` (`R7`'s), `R9b R9c R9d R9e R9g` (`R9f`'s), `R18b` (`R18d`'s) and `R12` (`R12b`'s) — **all five blocks, sibling for sibling**; **C**, which by construction cannot reach the healthy path, reddens the three refusal-path blocks (`R6 R12 R18b`) plus `G`/`L`/`U4`, every consumer of `die()`'s human branch.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the newest run entry's `Queue — next small step` bullet — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

| cell | suite | tool | result | section G (8 assertions) |

|---|---|---|---|---|

| A baseline | pre | shipped | **160 / 0, rc 0** | 8/8 PASS |

| M pre-screen | pre + probes | shipped | **160 / 0, rc 0** | haystacks measured (0 B / 0 B) |

| **PA** | pre | P1 password | **159 / 1** | **8/8 PASS** — blind, real stdout `pw_OUT=1` |

| **PB** | pre | P2 token | **159 / 1** | **8/8 PASS** — blind, real `tok_OUT=1`, `tok_ERR=1` |

| **E1** | pre | P3 mute | **79 / 81** | **8/8 PASS** — blind while the tool printed *nothing* |

| D after fix | post | shipped | **160 / 0, rc 0** | 8/8 PASS |

| **B** | post | P1 | **157 / 3** | 2 password sites **FAIL** (`unexpected: "password"`) + `JSON key set` |

| **C** | post | P2 | **155 / 5** | 4 token greps **FAIL** (`want '0' got '1'`) + `stderr is clean` |

| **E2** | post | P3 | **75 / 85** | 4 stdout sites **FAIL** (`got 'EMPTY'` ×2, `haystack is EMPTY` ×2) |

**E1 vs E2 is the whole claim** — same plant, the only difference is this fix: **8/8 PASS → 4 red**, and the four that redden are exactly the four that read stdout. **PA/B** and **PB/C** give the same delta for the two real defects (**159/1 → 157/3** and **159/1 → 155/5**). **A == D == 160** is the count proof, so `tools/REGISTRY.md`'s *160 assertions* is untouched by the two helper swaps (definitions add no assertions). The one red that moves in *every* P1/P2 cell — `JSON key set`, `stderr is clean` — is a **different assertion catching the same plant before and after**, disclosed as collateral, not as the claim.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the newest run entry's `Queue — next small step` bullet — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

| cell | suite bytes | tool | result | at the 3 sites |

|---|---|---|---|---|

| A healthy baseline | pre (`6cc3ddba`) | shipped | **323 / 0, rc 0** (×2) | PASS, haystack 85 B |

| M pre-screen | pre + probes | shipped | **323 / 0, rc 0** | PASS, `MEASURE` 85/85/85 |

| **B pre-fix plant** | pre | P1 empty detail | **193 / 130, rc 1** | **PASS ×3 from 0 bytes**, siblings green |

| **C post-fix plant** | post (`86fb49fc`) | P1 | **190 / 133, rc 1** | **FAIL ×3 `haystack is EMPTY`** |

| D healthy after fix | post | shipped | **323 / 0, rc 0** | PASS |

**B → C is the claim:** the same plant, the only difference is this fix — **193 − 3 = 190 passed, 130 + 3 = 133 failed**, the delta landing exactly on L919/L927/L1049 with the empty-arm message that can only print on a 0-byte haystack. **A == D == 323** is the count proof (the helper's definition adds no assertion), so `tools/REGISTRY.md`'s *323 assertions* is untouched; **line 1060's site reads `ok` in cell C** while its block's positive reader reddens — the pairing the bare helper rests on, seen in the same run.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the newest run entry's `Queue — next small step` bullet — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

| cell | suite bytes | tool | result | at the two M16 sites |

|---|---|---|---|---|

| A healthy baseline | pre | shipped | **199 / 0, rc 0** | PASS, haystack 788 B |

| M pre-screen | pre + probes | shipped | **199 / 0, rc 0** | PASS, `MEASURE M16a/M16b bytes=788` |

| **P pre-fix plant** | pre | plant `6cfabdee` | **118 / 81, rc 1** | **PASS ×2 from `bytes=0`**, block siblings `$MUT16_OUT` red |

| **Q post-fix plant** | post (`a1ae4402`) | plant | **116 / 83, rc 1** | **FAIL ×2 `haystack is EMPTY - nothing was read`** |

| R healthy after fix | post | shipped | **199 / 0, rc 0** | PASS |

**P → Q is the claim**: same plant, only difference is this fix — **118 − 2 = 116 passed, 81 + 2 = 83 failed**, the delta landing exactly on `M16: real refusal never shows a repr` and `M16: real tool still drops the fourth cause`, the two lines that could only fail on a 0-byte haystack. **A == M == R == 199** proves the count did not move, so `tools/REGISTRY.md`'s *199 assertions* for `tests/test_promote_lint_gate.sh` is untouched by the helper's definition, and the pre-screen's healthy figure (788 B) is a measurement rather than an assumption.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the newest run entry's `Queue — next small step` bullet — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the newest run entry's `Queue — next small step` bullet — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the newest run entry's `Queue — next small step` bullet — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the newest run entry's `Queue — next small step` bullet — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the newest run entry's `Queue — next small step` bullet — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the newest run entry's `Queue — next small step` bullet — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the newest run entry's `Queue — next small step` bullet — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the newest run entry's `Queue — next small step` bullet — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the newest run entry's `Queue — next small step` bullet — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the newest run entry's `Queue — next small step` bullet — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the newest run entry's `Queue — next small step` bullet — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the newest run entry's `Queue — next small step` bullet — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the newest run entry's `Queue — next small step` bullet — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the newest run entry's `Queue — next small step` bullet — it is not duplicated here, and has not been since `[0.4.67]`. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.