Public floor tasks

This is the public task board for the Bridlewise development floor. It is a working list, not a release schedule. Each row names one outcome; the detailed exit criteria live in the build roadmap.

Each row is one item file in docs/trackers/items/ (format bridlewise-tracker-item/v1, read by engine/src/workflow/failure-owners.ts). The board below is generated from those files by harness sync: a row changes only by editing its item, and harness check refuses a board that differs from its items.

Flaky burn-down owners. Each row owns at least one entry in the tracked flaky burn-down list. The owner is the task that must reproduce, fix, or explicitly retire the entry; a row re-owns an entry only by the commit that adds it (engine/src/workflow/flaky-burn-down.ts entryAddedWithOwner).

Private web lanes. The public snapshot does not publish the private web run history, so these lanes own no entry here. They remain the private floor’s workstreams — ordinary work, not a claim that a private failure still exists.

Open

Bring the supported suite under the calibrated-work cap — the old raw-CPU row is SUPERSEDED, not rescaling its numbers. Two full runs on 2026-10-20 measured 2124.7 and 2183.7 ms/file against a 2032.2 ms/file cap, but those figures are in the retired raw-cpu-ms/v0 unit: the runs were measured with NO calibration reading, so they are INCOMPARABLE with the current declaration and no arithmetic converts them. The red was the box, not the suite: the same tree moved to 2124.7 ms/file under load ~9-10 against the 1926 ms/file floor, and raw CPU is not invariant at saturation. The metric now judges calibrated work (calibrated-work/v1): each run pairs its CPU delta with a fixed start/end calibration benchmark (256 KiB working set, six fixed chunks, --no-opt, median chunk; engine/src/shared/run-cpu.ts computeRunWork) and judges workUnitsPerTestFile = (runCpuMs / calibrationMs) / testFileCount — computed once, read by the verdict, the reporter, the engine runner and the pages. The declaration is in ACCUMULATION (0 of 12 clean judged full runs); the retired 1926 ms/file at 521 files is recorded under legacy with incomparable: true and its two ledger rows carry no metric, so they never feed the new window. Next: run the full suite twelve times inside the instrument lock; npm run budget:measure -- --check must stop answering migrating, then the window's clean median is derived into the floor from the calibrated rows alone (later floors go through npm run budget:measure -- --write). Measured residual on a four-file/68-test subset (2026-10-20, 12-core WSL2): among runs inside BOTH declared bounds (drift <=15%, load5 <=1.7/cpu), units/file spread 1.1% and the eight-burner step +1.1%, against raw 7.0% spread and +7.3%; the two runs outside the drift bound (26.2% and 17.9% start/end drift) are DEFERRED, never judged. Evidence: docs/floor/evidence.md.
No clean judged run in calibrated-work/v1 yet — No clean judged run in calibrated-work/v1: 0 of 12 recorded; the retired raw-CPU window is incomparable, so the cap is derived from new runs alone.

Roadmap

Flaky burn-down owners

FLAKY-PUBLIC-ENGINE-GUARD-REDS-ON-ROUND-TREES — public re-owning of FLAKY-ENGINE-GUARD-REDS-ON-ROUND-TREES; needs private history, still owned. Keeps the three entries whose tests are green at HEAD: engine/test/verification/test-surface-conservation.test.ts (two arms, 11/11) and engine/test/workflow/harness-commands.test.ts. The private row says these guards were red on the committed round tree of 2026-10-07 23:59Z and fixed by a later commit of the same round — "not flakes … the coordinator decides". Their schema-v2 records (b1cf5ba8…, 0cc4dff2…, 50c8c4ef…) name parent 7f319afc → fix a12dccb8 at one run per side, but they are ignored by the current door and have no attempts/ files here; the fix's exact bytes are not at HEAD either (a12dccb8's conservation blob 3e8a0765… and harness blob 9ec78f88… differ from HEAD, because later work moved both files). The already-Done FLAKY-WEB-GUARD-REDS-ON-ROUND-TREES row covers 18 tests/prevention/* identities — the same "round-tree guard red, fixed by the next commit" mechanism but a disjoint identity set (none of the three engine files appears there), so it does not cover this lane. Missing artifact: the private coordinator's decision (E-01/GC-0) on the three entries, or current-door records/attempts that explain them. Guarded by engine/test/prevention/flaky-test-memory.test.ts.
FLAKY-PUBLIC-ENGINE-UNDIAGNOSED — public re-owning of the private lane FLAKY-ENGINE-UNDIAGNOSED; needs private history, still owned. The identity is engine/test/repository-root-capability.test.ts Linux test adapter is explicit, path-closed, and has typed unavailable outcomes (the title is present at HEAD; the file is 26/26 green in the 2026-10-20 focused run). The private floor's row records the red three times on 2026-10-07 (17:13Z–20:19Z, one digest) and says cause not found. The only record here, engine/traceability/flake-reproductions/9971023809fa1b13bd0845c6.json (recorded 2026-10-08T06:24:49Z), is schema v2; the current door refuses v2 by version before it reads the attempt log (engine/src/shared/flake-reproduction.ts), so the record explains nothing. Its parent cf352060 → fix 50130fbb, one run per side, is not a current-door reproduction; 50130fbb's change to the test (the mount point comes from this system's mount table) is present at HEAD (2660a069…), but the lane owner has not accepted it as the cause. Missing artifact: a schema-v3 reproduction record plus its attempts/ file for this identity (or the private lane's accepted cause/record); until one exists the entry stays owned. Guarded by engine/test/prevention/flaky-test-memory.test.ts.
FLAKY-PUBLIC-ENGINE-UNLOGGED-RECORDS — public re-owning of FLAKY-ENGINE-UNLOGGED-RECORDS; needs private history, still owned. Covers engine/test/evaluation/matrix-executor.test.ts evaluation/matrix-executor: tokens accumulate from run usage and engine/test/mcp/transport.test.ts streamable http: a server ping on the answer stream is answered and never resolves the client's request (H-1); both files are green at HEAD (160/160 in the 2026-10-20 focused run). The private row says the causes are reproduced and fixed (matrix: the stall after the first response, fix 2d2b58e2; transport: the late ping answer, fix 7305adbf), but the two records (d1c7abfdb12b746761457109.json, ten statistical runs; fbe9f9c7cdad96d8f24298a0.json, one deterministic run under flake-shim-hold-requests.ts) are schema v2, the current door ignores them, and neither has an attempts/ file here. The transport test at HEAD is byte-identical to 7305adbf (b067b0e2…), and the matrix fix's engine/src/shared/outbound-http.ts moved on afterward, but a fix is not a current-door reproduction. Missing artifact: two schema-v3 records plus their attempts/ files, re-recorded under the door (the hold-requests shim is registered; the stall shim is statistical). The private row's own instruction is "Re-record … and the entries leave". Guarded by engine/test/prevention/flaky-test-memory.test.ts.
FLAKY-PUBLIC-S1-B12-CONTROL — public re-owning of FLAKY-S1-B12-CONTROL; needs private history, still owned. The identity is engine/test/s1-scenarios/b12.test.ts S1-B12-CONTROL; the file is green at HEAD, but the private floor records a vacuous-pass race in the control (it calls verifyS1Structure(REPOSITORY_ROOT) on the live checkout and asserts only that no universal-policy-* violation is listed, while a manifest walk that meets an unreadable entry, a symlink or a hardlink can return early before that check), and no fix has been made. The public attempt engine/traceability/flake-reproductions/attempts/e5f2e977b5b00eb82939d0b57a4bc05e88f35f79ca19ccb24c1c165b757dfbd9.json (recorded 2026-10-10T14:03:33Z) refused this identity: "on the parent it failed 4 and passed 1 of 5 run(s) (9833610b600dec8b ×4): a deterministic reproduction fails every run — reproduce the condition with --statistical". No record names it. Missing artifact: the private statistical reproduction of the vacuous-pass condition (the 4-of-5 attempt) plus the control's walk-safety fix; the focused green is not a fix. The same file's S1-B12-FAILURE arm is a different identity, disposed with FLAKY-PUBLIC-ENGINE-ONE-RUN-2026-10-09. Guarded by engine/test/prevention/flaky-test-memory.test.ts.
FLAKY-PUBLIC-WEB-GUARD-REDS-ON-ROUND-TREES — deterministic documentation defects fixed at fd7e058f; not clearable under the current ledger, so the row stays the public owner. Covers tests/prevention/agent-docs-liveness.test.ts (the briefing arm) and tests/prevention/source-root-organization.test.ts (the engine/test/ README arm). Reproduced at the recorded red tree b4dc6b33 in a scratch worktree (node_modules linked, config 0600): the two files red 2 failed | 36 passed (38), the first naming docs/floor/roadmap.md and docs/testing.md for engine/large-codebases and tests/performance/.report.json, the second naming engine/test/verification/corpus-manifest.test.ts as undocumented. At fd7e058f the same files are green 38/38; at HEAD 25a446c3 the three suspect files are green 64/64, and the 2026-10-20T11:50:26Z recorded full web run passed both. The retained ledger still reds both (2026-10-20T11:44:16Z, clean tree, not provisional). Clearing is not possible without faking: no Flake-cause: trailer reachable from HEAD names either identity; the four schema-v2 records (2ed1b081…, 8bdecb60…, efbda9fc…, 2a56ab4b…) are refused by name ("written before the door kept its attempt log"), and their causes are Markdown, which FLAKE-REPRO never judges semantic; no accepted reproduction or move exists. A probe over the live rows (judgeBurnDown) shows that removing the two entries and closing this row leaves 2 new suspects — the web guard reds — and the same holds after appending a simulated green full run, because the ledger is append-only and a trimmed failing row moves to the never-trimmed suspect archive. What would clear it: a machine-accepted explanation (a semantic declared cause plus its attempt, or a recorded move) — none is honestly available for a Markdown-only document fix — or an E-01/GC-0 retirement decision with a ledger rule that accepts a retired entry; closing the row alone reds the guard. A focused or partial run cannot supply either artifact. Guarded by tests/prevention/flaky-test-memory.test.ts.
FLAKY-PUBLIC-WEB-WATCHDOG-C3 — canonical owner after merging the duplicate FLAKY-WATCHDOG-C3 row; still owned. Covers tests/prevention/test-run-watchdog.test.ts C3. The recorded red (2026-10-20T11:44:16Z) is expected 70 to be +0; 70 is PROCESS_FAULT_EXIT_CODE (EX_SOFTWARE), so the nested focused wrapper faulted closed on an uncaught exception, an unhandled rejection or a guarded-callback fault. Reproduced with execution: a nonexistent TMPDIR drove the real wrapper to exit 70 with error (process): uncaught exception … statfs on stderr; the C3 arm then passed 10/10 focused runs at HEAD 25a446c3 and passed in the 11:50:26Z recorded full run. A scratch worktree at the recorded tree b4dc6b33 ran the arm 30 times under a private TMPDIR: 28 green and two reds, the diagnosed one ending: "stalled" at 2.1s — the 1.5s watchdog killing the wrapper during startup, a different mode from the recorded exit-70. The prior 430 drives (400 wrapper, 30 real arms under load 11.5–15.4) and these 30 did not reproduce exit 70. Why the cause was never recorded: the old assertion printed the bare exit code; HEAD's assertion now prints output.join(""), so the next fault names its stack. Evidence that would close it: one recurrence under the recorded conditions (full web suite, 1-minute load ≥ 10, parallel files) whose failure message carries the fault line; its stack's throw site is the cause, then fix that owner and reproduce it under the door with the same conditions. A focused or partial run is not enough — the recorded red happened in a full run under load, and no accepted engine/traceability/flake-reproductions/ record names this identity. Entry kept; nothing ages out. Guarded by tests/prevention/flaky-test-memory.test.ts.
FLAKY-CONFIG-PARENT-CHURN — Suspect with a named cause, not yet fixed. Covers tests/prevention/roadmap-status-owner.test.ts › "a close is a claim until linked evidence proves it…", red in Shard 5 of #711's run 40818517399 with SecurityError: Configuration parent identity changed (config_parent_changed) from configuredRepositoryIdentity() → loadPinnedConfigSnapshot(). Cause: engine/src/kernel/config.ts pins the engine folder's whole stat (sameIdentity, engine/src/shared/identity.ts: mtime, ctime, nlink and size with dev and ino) at the start of a read and compares it at each step, so any concurrent creation or removal of an entry directly in engine/ by another test of the shard (a first engine/dist or engine/.bridlewise, a lock file) refuses the read. Reproduced on demand with the same code as the parent (config.ts, identity.ts, repository-identity.ts and configured-forge.ts are unchanged from #711's base 6ac6d541): mkdir/rmdir of engine/.churn-probe in a loop beside npx vitest run tests/prevention/roadmap-status-owner.test.ts refuses with the same error. Owned by the flaky guard tests/prevention/flaky-test-memory.test.ts through engine/traceability/flaky-burn-down/web.json; the fix (judging the parent by what can swap it, or each test file not re-reading the pinned configuration under a churning shard) is the configuration owner's, recorded through harness flake reproduce --statistical --during when it lands.

Private web lanes (retained as ordinary work)

FLAKY-PERF-GATE-STALE-REPORT — narrowed 2026-10-20, still owned. Covers tests/performance/regression.test.ts and tests/prevention/flaky-test-memory.test.ts. The record (the private floor's docs/trackers/TASKS.md row, read-only here) claims the gate's arms "red on 2026-10-07/08 while the profile report was absent or not judgeable for the tree; the report was regenerated (judgeable, 2026-10-10 22:54Z). Rows recorded before a regeneration are explained by the gate's own regeneration arm; any left red are the coordinator's decision." No engine/traceability/flake-reproductions/ record names this file, its suite or any of its arms — 0 of the 158 records and 8 attempts in this tree — so FLAKE-REPRO never accepted a flake here. Measured at HEAD 54f978f3: three consecutive focused runs are red 26/36 with 10 passed each and an identical failure set; every failure is the gate's own stale-surface refusal (the report on disk was minted at 2caada8f 11:25:03Z with measured-surface hash 37a412fe…, while HEAD's surface is a1309f29…, and 23 measured files moved between the mint and HEAD, e.g. server/db/backup-restore.ts). The recorded absent-report half reproduces deterministically too: in a scratch worktree at HEAD with no report, two focused runs are red 28/36 with 8 passed, every failure naming "no profile report … npm run perf:profile makes it". Both modes are the gate doing its job; no run varies. What the gate requires: a report minted on the current measured surface by npm run perf:profile inside the host's one instrument lock under the idle-host contract. The CPU-cap row shares the measurement machinery and now needs 12 clean judged full runs in the calibrated-work metric, not the retired raw-CPU window; that window is missing (0 of 12), npm run budget:measure -- --check answers migrating (the declaration is in accumulation, the retired 1926 ms/file at 521 files is recorded as incomparable), and a single run cannot legally derive it (D-17). The host is not idle now (a concurrent pytest suite ran at 69.7% CPU; 5-minute load ~9.6 on 12 CPUs), so a fresh mint here would be a measurement the contract forbids; and no amount of test repetition can refresh a report or fill the window. Decision that unblocks it: the floor owner schedules one idle-host measurement campaign at the judged head — one npm run perf:profile mint, plus the 12 clean judged full runs for the CPU-cap window — or makes an explicit policy decision that the 12-run window cannot be filled on this host. Do not hand-edit the report, the declaration or a budget. Evidence that would close the lane: a report whose measuredSurfaceHash equals the judged head's surface with the gate 36/36; the recorded 2026-10-07/08 reds then stand retired as the gate's own pre-regeneration refusals, with nothing left to reproduce. A judged full run also reads the report (judgePerformanceBudgets) and fails performance-report when it cannot be judged, so the same mint is a prerequisite of a green full-run campaign; the CPU-cap window closes separately on 12 clean judged runs in calibrated-work/v1 with budget:measure -- --check reporting a measured floor. Guarded by tests/prevention/flaky-test-memory.test.ts; the lane owns no entry in the public engine/traceability/flaky-burn-down/web.json (that file holds only the three public suspects), and the private floor remains its owner.

Done

Document and implement the backup and restore flow — at 400a130a the claim reproduced: git show 400a130a:package.json | grep '"db-' named only db-key and db-archive; git ls-tree 400a130a server/db held no backup/restore module; docs/shipping.md:88 only advised backing up the key home and the SQLite databases. Exercising npm run db-archive -- --db <db> --chats-file <file> proved the partial path: it wrote a verified <db>.pre-archive copy and the key-home key/salt, but nothing restored either (a copy the operator cannot restore is not a backup). Now npm run db-backup -- backup --db <db> --to <new folder> holds the database alone, writes a verified copy through writeVerifiedCopy, copies the key material (or passphrase salt) and the bound-fields marker byte for byte, records every digest/size and the table counts in a manifest, and proves the copy opens under that material (databaseKeyProof) before the folder takes its name; npm run db-backup -- restore --from <folder> --db <db> treats the manifest as untrusted input, checks every digest/size/quick_check/table count, refuses a key that does not open the backup, holds the target alone, keeps a verified <db>.pre-restore copy, installs the bundle's key only when the key home has none, copies the database into place atomically, and proves the restored database opens (putting the pre-restore copy back on failure). The CLI ran end to end on a scratch database: backup reported keyProof:"opens" and digest a2b2aed0…, a user added after the backup disappeared on restore (keySource:"existing", keyProof:"opens", preRestoreCopy:"…web.db.pre-restore"), and the pre-restore copy still held the later user. A restore into a NEW folder reported keySource:"backup" and the installed key opened the restored database. Evidence: tests/unit/database-backup.test.ts 6/6 (round trip + pre-restore copy, damaged backup refused before changes, lost database + key home recovered, passphrase salt, held database refused, different key conflict refused); the focused 13-file batch 162/162 (database-backup, conversation-archive, database-exposure, db-key-rotation, source-root-organization, file-effect-recording, no-empty-catch, no-scattered-helpers, encryption-and-dedup-prevention, data-loss-5-keypersist, data-loss-3-migration, effect-kind-recording, path-spelling-comparison); engine key-home 6/6; npm --prefix engine run typecheck clean; npm run typecheck clean; npm run test:public 29/29; npm run docs:links clean (512 Markdown files); npm run check:secrets clean; harness check --skip-typecheck from engine/ allPassed: true (869 modules, architecture/readme-consumers/ratchet all pass); scripts/test-shard-manifest.mjs verify --manifest tests/test-shards.json --live … reports 522 supported, 4 excluded, 526 live. Still open and stated in the docs: the timeline ledger and the pre-migration/pre-rekey copies are not in the bundle; a key mode mismatch or a different key in the key home is refused rather than overwritten; the new test's shard weight was measured on its own, so the open "Re-measure the shard weights" row still owns the full per-file re-measurement.
Publish the corpus manifest — engine/test/fixtures/corpus-manifest.json pins lodash, express and babel/traverse by commit and file hash (99 files); npm run corpus:fetch materialises them from upstream and links the cache, npm run corpus:verify judges it, and the focused probe passes 80 engine and 12 Vitest tests.
Reconcile the flaky burn-down list with the published memory — measured 22 engine entries across 9 private lanes and 0 web entries before; re-ran all 18 distinct engine entry files and the 3 public web suspects. Re-owned the 15 engine entries that still have live tests under 7 public rows; retired 7 engine entries with evidence: 2 live MCP arms moved to engine/live/mcp-servers.test.ts, and 5 deterministic public-snapshot failures recorded in the PUBLIC-SNAPSHOT-* rows above. The 3 web suspects are owned by 2 public rows (the two doc guards were deterministic stale-doc defects fixed at fd7e058f, the watchdog C3 is the one transient). After: 15 engine entries / 7 owners and 3 web entries / 2 owners; the engine guard and the web guard both pass. Evidence: the focused entry-file runs, docs/floor/evidence.md, and the commit message's command list.
FLAKY-CUSTODY-KEEPOUT-ESTALE — retired 2026-10-20 on agent/flaky-keepout from f6c8cef2 as a stale private-web lane: the recorded failure mechanism is gone, and the public ledger does not carry its entry. The record claimed the guardian refused a whole confined spawn when a keep-out entry changed while it was located — keep_out[#] is not a resolved path: '<tmp>/<dir>/web.db': Stale file handle at 2026-10-07T16:54Z — because the run's one key home registers every test file's temporary database, so one file's cleanup churned another's keep-out entry; the private floor fixed it at d250d3da, whose code this tree carries in its sanitized import. engine/guardian/landlock-guardian.c re-locates an ESTALE entry, keeps it out by its folder and its name, and runs the unrelated spawn (keep_out_retries in engine/src/filesystem/self-protection/self-protection-contracts.ts), and the deterministic arm engine/test/filesystem/self-protection/keep-out-links.test.ts "S2, DETERMINISTIC: … (ESTALE) …" proves the old whole-spawn refusal is gone while the entry is still kept out. Observed at f6c8cef2: the two named tests are 31/31 in ten consecutive npx vitest run runs and 18/18 in three runs under the recorded condition (a private HARNESS_KEY_HOME holding a registered $TMPDIR/bw-custody-race-*/web.db that a loop unlinked and re-created); engine/test/filesystem/self-protection/keep-out-links.test.ts is 8/8; engine/test/prevention/flaky-test-memory.test.ts is 19/19; tests/prevention/flaky-test-memory.test.ts is 8/8. No entry was removed because none is in the public list: the import 2545d94f carried the private web history, 94b1a97f emptied it, and 400a130a added only the three public suspects that engine/traceability/flaky-burn-down/web.json now holds under the README's rule; engine/traceability/flaky-burn-down/engine.json is the engine suite's list and has never held a custody identity. The ledger guards pass over the closed row. This closes the public tracking row only; the private floor remains the owner of its own records. What remains is the run-wide key home's cross-file coupling (ordinary work on the private floor, not a public entry); it no longer manifests as this refusal.
FLAKY-HELPERS-README-HARNESS-VIEW — retired 2026-10-20 on agent/flaky-harness-view from 1a9a6e38 as a stale private-web lane: the recorded mechanism no longer exists, and the public ledger never carried its entry. The record claimed tests/prevention/source-root-organization.test.ts "tests/ each README names exactly the folder's real files" failed in the 2026-10-10T18:44Z full web run at e8b25c8c because tests/helpers/README.md did not name tests/helpers/harness-view.ts, and judged it not a flake: 9d7c7e78 folded that helper into tests/helpers/isolated-config.ts and deleted the file, so FLAKE-REPRO cannot explain it (the cause is absent at the fix, and a README is Markdown, never a semantic change). Observed at 1a9a6e38: the arm is deterministic, not intermittent. At e8b25c8c the helper exists (blob bb145be1) and the README omits it; restoring exactly that file as an untracked fixture twice, the arm failed twice 1/1 (exit 1, "In the folder but not named in its README (undocumented): tests/helpers/harness-view.ts"); removing it, the arm passed twice 1/1. At HEAD the file is absent and tests/helpers/README.md names isolated-config.ts. The two named files are 44/44 (36 + 8) in ten consecutive npx vitest run runs (440 test results). The ledger's own rule (engine/src/workflow/flaky-burn-down.ts) retires an entry only with its owning row, and the removal commit names the decision (FLAKE-REPRO); there is nothing to remove here because 2545d94f carried the private web history, 94b1a97f emptied it, and 400a130a re-added only the three public suspects engine/traceability/flaky-burn-down/web.json holds. That file's source-root entry is the engine/test/ README arm owned by FLAKY-PUBLIC-WEB-GUARD-REDS-ON-ROUND-TREES, a different identity from this lane's tests/ arm; the private floor's web.json remains this identity's owner and is not edited from the public floor. The web ledger guard is 8/8 and engine/test/prevention/flaky-test-memory.test.ts is 19/19 over the closed row. This closes the public tracking row only; the private floor remains the owner of its own record.
FLAKY-ISOLATION-PIDFD — fixed 2026-10-20 on agent/flaky-pidfd from 194227ee: the recorded failure is the arm's exact-step assertion, not the supervisor's cleanup. The record (the private floor's docs/trackers/TASKS.md row and the engine/traceability/flaky-burn-down/web.json entry it owns; no engine/traceability/flake-reproductions/ record names this identity in either floor, and the public web.json holds only its three public suspects) claimed "native descriptor exhaustion after launch fails only after its owned descendants are reaped" failed once in the 2026-10-10T12:36:32Z floor run because the supervisor exhausted descriptors at pidfd_open before the test's planted owned children point, so the message named the other step; the exhaustion point depends on what the process already holds. Observed at 194227ee: the arm is 30/30 in consecutive focused npx vitest run tests/prevention/test-isolation-contract.test.ts -t "native descriptor exhaustion" runs, so plain repetition does not reproduce it. Forced deterministically by wrapping the inner supervisor in strace -f -qq -o /dev/null -e inject=pidfd_open:delay_enter=1500000: the command's prlimit --pid "$PPID" --nofile=4:4 lands before the delayed pidfd_open, which returns EMFILE; 5/5 runs named test supervisor pidfd_open: Too many open files (the old assertion was red 5/5, and green 5/5 in the normal order), while every cleanup assertion held in both orders — outer receipt reaped: [], killed: [], noOwnedChildren: true, the supervisor's command dead, and the 60 s sleep descendant dead. fail() runs the same cleanup from both post-launch allocations, so engine/guardian/test-process-supervisor.c is unchanged; the arm now accepts either post-launch step (/^test supervisor (?:owned children|pidfd_open): Too many open files$/m) and keeps every cleanup assertion; the same call path is green 5/5 in the forced order and 30/30 in normal focused runs. No ledger entry was removed because none is in the public list (2545d94f imported the private web history, 94b1a97f emptied it, 400a130a re-added only the three public suspects); the private floor remains the owner of its entry, not edited here. npx vitest run tests/prevention/test-isolation-contract.test.ts is 31/31; the web flaky guard 8/8 and the engine flaky guard 19/19; npm run test:public 34/34; npm run docs:links and npm run docs:roadmap -- --check are current. This closes the public tracking row only.
Retire the two hermetic live MCP arms from the flaky list — both identities named engine/test/mcp/real-servers.test.ts live, opt-in arms that no longer exist there; the equivalent live arms are engine/live/mcp-servers.test.ts:321 (context7) and :325 (deepwiki), in the opt-in live suite. No harness flake move record exists because the public import has no parent tree that holds the hermetic identities; the entries were removed by the same commit that added this reasoned row, and the private lane remains the source of truth.
FLAKY-POPULATION-FLOOR-REDERIVED — retired 2026-10-20 on agent/flaky-population-floor from cd99bfe9 as a deterministic stale-floor red, fixed at bfb123b9, not a flake: the recorded arm reds 5/5 at the fix's parent tree and is green 5/5 at the fix and 5/5 at HEAD, and the public ledger never carried the identity. The record (the private floor's docs/trackers/TASKS.md row, read-only here) claimed "the budget's population is still the one the budget was derived against" failed in every recorded full web run from 2026-10-07 to 2026-10-10 13:33Z, then passed at 18:44Z. It is not a flake: the floor was stale, bfb123b9 re-derived it (1926 at 521 files) through the measuring tool (D-17), and the flaky memory reads the first pass as a suspect. The private engine/traceability/flaky-burn-down/web.json owns the entry under this owner; the public engine/traceability/flaky-burn-down/web.json holds only its three public suspects, so no ledger entry was removed. No engine/traceability/flake-reproductions/ record names the arm — all 59 records whose paths or conditions mention web-ui-runtime-budget belong to the web-ui-runtime-budget-verdict.test.ts sibling, and a literal search of identity for tests/prevention/web-ui-runtime-budget.test.ts:: finds none — which is the record's own "FLAKE-REPRO cannot explain it". The fix and the tree it was built on are adjacent (git rev-list --count 29090f68..bfb123b9 = 1; parent 08:32:36Z, fix 13:35:46Z, after the last recorded red at 13:33Z), and the fix moves the declaration's two values (1614 ms/file at 485 files → 1926 at 521), adds the derivation record beside them, and moves the test's two pins together; the parent's tree held 521 live test files against the declared 485 — a 7.4% drift, over the declared 3.0% band. Observed in scratch worktrees at the recorded commits with both node_modules trees linked and engine/bridlewise.config.json at 0600: at the parent 29090f68 five consecutive ./node_modules/.bin/vitest run tests/prevention/web-ui-runtime-budget.test.ts runs are red 5/5 with 1 failed | 13 passed (14), and every run names "the budget's population is still the one the budget was derived against" with "the suite has grown from the 485 test files this budget was derived against to 521 — a drift of 7.4%, over the 3.0% a derivation is allowed to survive"; at the fix bfb123b9 and at HEAD cd99bfe9 the same command is green 5/5 (14 passed (14) each). At that row's measurement head cd99bfe9 the live population was 527 (523 supported + 4 named exclusions in tests/test-shards.json, verified against a fresh vitest list --filesOnly), a 1.152% drift from the declared 521 — inside the 3.0% band, so the arm is green by its own rule and the declared floor is not stale; no re-derivation is due, and the owner's tool says it is not yet possible: npm run budget:measure -- --check answers unmeasurable with "2 of the 12 clean judged full runs of the current 527-file population are recorded" against the declared 1926/521. The fix changes the declaration's two values, adds the derivation record and moves the test's two pins; the arm and judgePopulationDrift are untouched. The shard manifest verify is 523 supported / 4 excluded / 527 live at b0e9f6305c0a and the ten-shard plan assigns all 523 supported files with a 1.000x weight sum; the 1.766x wall spread the shard-weights row measured at 9c4526e7 is that row's separate packing fact (summed file cost is not wall time), not a population staleness. The web flaky guard is 8/8 and engine/test/prevention/flaky-test-memory.test.ts is 19/19 over the closed row; tests/prevention/tasks-no-stale-duplicates.test.ts is 2/2; tests/prevention/roadmap-status-owner.test.ts is 6/6; npm run test:public 34/34; npm run docs:links clean (512 Markdown files); npm run docs:roadmap -- --check current. The roadmap's generated blocks were rebuilt by their writer. This closes the public tracking row only.
FLAKY-PUBLIC-ENGINE-GATE-LOG-PASSWORD-TAIL — covered and retired 2026-10-20 on agent/public-reowning from 114ab553 as fixed by 5f8aa96d, not left owned: the identity is engine/test/workflow/working-copy.test.ts the gate log redacts across chunk boundaries: …; the private row records it failed once (2026-10-14 19:55Z, validate 19) because its random synthetic password ended in _ or -, the persistence redaction keeps such a final character outside its marker ("password": "[REDACTED:credential]-", measured 8 of 300 random JSON values), and the exact-shape assertion failed although the password never reached the log; the test's password now ends in a letter (0 of 2000 off-shape over the four forms), and the dropped character is the separate REDACT-AMPERSAND-TAIL case, not this identity. The test file at HEAD is byte-identical to 5f8aa96d (88f3532c…), so the fix is in this tree. There is no engine/traceability/flake-reproductions/ record for the identity, but this is a deterministic test-fixture red fixed at its cause, not a flake. The one public engine.json entry leaves with this row (the ledger's shrink-only rule; the private floor remains the owner of its records). Ran: working-copy.test.ts 35/35; the engine flaky guard 19/19; npm run test:public 34/34; npm run docs:links clean (512 files); npm run docs:roadmap -- --check current. This closes the public tracking row only.
FLAKY-PUBLIC-ENGINE-INVENTORY-RACE — covered and retired 2026-10-20 on agent/public-reowning from 114ab553 as fixed by 694cfd1b, not left owned: the identity is engine/test/verification/test-surface-conservation.test.ts conservation: the identity is asserted by the production inventory door; the private row records it failed once (2026-10-14 13:55:03Z, validate 15) because the inventory CLI it runs refused "test inventory source tree changed during discovery" while engine/verification/benchmarks/opencode-history/review/independent-scope-review.test.ts made and removed sandboxes inside the live tree in the same suite, reproduced by hand six of six test-inventory --check refusals, and the cause is fixed at 694cfd1b (the sandboxes are in the run's temp root). Both files the fix touched are byte-identical at HEAD to 694cfd1b: test-surface-conservation.test.ts d0ee23a9… and independent-scope-review.test.ts dabd6bc7…. Focused runs at HEAD: test-surface-conservation.test.ts 11/11 and independent-scope-review.test.ts 8/8. There is no engine/traceability/flake-reproductions/ record for the identity, but this is a deterministic fixture red fixed at its cause, not a flake, and the fix is in this tree. The one public engine.json entry leaves with this row (the ledger's shrink-only rule; the private floor remains the owner of its records). Ran: the two files 19/19; the engine flaky guard 19/19; npm run test:public 34/34; npm run docs:links clean (512 files); npm run docs:roadmap -- --check current. This closes the public tracking row only.
FLAKY-PUBLIC-ENGINE-ONE-RUN-2026-10-09 — covered and retired 2026-10-20 on agent/public-reowning from 114ab553 as fixed in this tree, not left as a private-history claim: 114df640 fixes five of the six identities and 300a2a7a fixes S1-B13-HOSTILE-REAL. The private row's "failed in ONE run only (2026-10-09 20:42:23Z, tree eb6b8f4c87) … Not reproduced" is superseded by the door's own attempts: engine/traceability/flake-reproductions/attempts/e5f2e977b5b00eb82939d0b57a4bc05e88f35f79ca19ccb24c1c165b757dfbd9.json (recorded 2026-10-10T14:03:33Z; parent 69fc8701, fix 114df640, five runs per side) records S1-B02-FAILURE, S1-B12-FAILURE, resolved defaults: a default its own module resolves is never exported, [FC-B001] pure modular boundary and single protocol ownership and atomic-write-consistency: every src/workflow/*.ts writeFileSync call writes to an fd, never a path, and their five v2 records show 5/5 parent failures and 5/5 fix passes; 63ef82b280fe71021c1eaac3f8deee12eeb4a48a0fd54a13059aea230941fbfa.json (parent 114df640, fix 300a2a7a, five per side) records S1-B13-HOSTILE-REAL with the same 5/5 counts. The identity set is exact: those six are the six entries this row owned. Five of the fix's six test files plus engine/src/kernel/web-performance-budgets.ts are byte-identical at HEAD (b02, b12, resolved-default, FC-B001, atomic-write, web-performance-budgets; only checkout-setup.ts moved on after the fix), and b13.test.ts and test/support/repository-local-temporary.ts are byte-identical to 300a2a7a. The lane's other two entries (candidate-format, S1-B08-CONTROL) were already retired by the two PUBLIC-SNAPSHOT-* rows, so the lane is fully disposed. The six public engine.json entries leave with this row (the ledger's shrink-only rule; the private floor remains the owner of its records). Ran: the six entry files plus harness-commands 91/91; the engine flaky guard 19/19; npm run test:public 34/34; npm run docs:links clean (512 files); npm run docs:roadmap -- --check current. This closes the public tracking row only.
FLAKY-RESOURCE-SAMPLER-TICK — retired 2026-10-20 on agent/flaky-sampler from c23a89eb as fixed by b7aff7c7, not stale: the recorded REDACT-NUM mechanism reproduces deterministically at its parent and is gone at its fix and at HEAD, and the public ledger never carried this lane's entry. The record (the private floor's docs/trackers/TASKS.md row and its engine/traceability/flaky-burn-down/web.json entry, read-only here; the public web.json holds only the three public suspects) claimed the lane's single identity failed in the 2026-10-08T09:53Z full web run and three single-file runs, then passed every run, and was not reproduced by 115 fresh ticks outside the runner (50 under an all-core hog, 15 under an engine-root churn) or 0 of 10 under the state-folder churn. Its accepted engine/traceability/flake-reproductions/48f737503fd3367f3b49b0c2.json (schema v3, recorded 2026-10-11T05:51:28Z, mode: "deterministic", preload engine/test/support/flake-shim-routing-rss.ts, sha256 5514f082…) names cause engine/src/privacy/operational-redaction.ts at parent 3003d806 and fix b7aff7c7: about 3% of 9-digit byte counts pass the bank-routing check digit, so the tick's process.rss number was projected to [REDACTED:pii], the metric document no longer parsed, and the query found no process.rss row. Observed at 3003d806 under the recorded preload: 5/5 focused runs red, 2 failed of 4 (the tick arm and the actor arm that re-reads process.rss), and 2/2 green without the preload — the shim is the trigger, not stale test code. A direct probe of the projection returns {"metric":"process.rss","value":[REDACTED:pii],"unit":"bytes"} (invalid JSON) at the parent and the exact number at b7aff7c7. At b7aff7c7 under the same preload: 5/5 runs green (4/4); at HEAD c23a89eb: 10/10 green (4/4). No ledger entry was removed because none exists in the public list: 2545d94f imported the private web history, 94b1a97f emptied it, and 400a130a re-added only the three public suspects engine/traceability/flaky-burn-down/web.json holds; the ledger README says private web lanes own no entry here, and the private floor remains this identity's owner. The web flaky guard is 8/8 and engine/test/prevention/flaky-test-memory.test.ts is 19/19 over the closed row; npm run test:public 34/34; npm run docs:links clean; npm run docs:roadmap -- --check current. This closes the public tracking row only; the private record's own caveat (its 2026-10-08/10 rows measured other bytes) is not re-judged here.
FLAKY-VERDICT-CONFIG-RACE — retired 2026-10-20 on agent/flaky-verdict-config from 04548877 as fixed by f6c8cef2, not stale: the recorded mechanism reproduces red before that commit and is gone after it, and the public ledger never carried this lane's entry. The record (the private floor's engine/traceability/flaky-burn-down/web.json, read-only here) owns 39 identities in this lane, and the 39 accepted engine/traceability/flake-reproductions/*.json records — all recorded 2026-10-08T10:53:17Z, mode: "statistical", 10 runs each — name cause engine/src/kernel/config.ts, parent 8e6e314c failing every run (0 passed of 10), and fix 6c056824 passing 10/10. Their condition is a loop that creates and removes engine/.bridlewise/flake-churn while the web budget reporter's fixture drives record: the pinned-config bootstrap refuses (config_parent_changed) and the drive loses its judged history row. (The lane's earlier attempts — 20 statistical runs against concurrent tests/unit/mcp-stdio-landlock.test.ts load, fix 33d08308, and three deterministic budget-reporter records, fix 8b9b900a — are separate episodes; the accepted config batch is the one this row reproduces.) The public tree's sanitized import already carries 6c056824's exclusion of the state directory's volatile fields, so that exact location is quiet here: at the pre-fix commit 5171055c the file is 136/136 under the recorded .bridlewise churn with 0 refusals. What still failed at 5171055c was the same refusal reached through the foreign-root question: readTestExecutionConfig bootstrapped this checkout's pinned document before comparing the root, so a scratch entry churning directly under engine/ made each budget-reporter fixture drive fail. f6c8cef2 compares the root first and answers a foreign root from the defaults without the read, while this checkout's own root still loads and propagates every refusal (engine/test/workflow/test-execution-config.test.ts pins both halves; its own-root probe answers refused:alternate_config_denied). Reproduced red-first in a scratch worktree at 5171055c with node_modules linked: under continuous create/remove of engine/.flake-churn, npx vitest run tests/prevention/web-ui-runtime-budget-verdict.test.ts --reporter=default failed 40 of 136 in both runs (96 passed; 31 reporter refusals each — 23 and 21 config_parent_changed "Directory identity changed", 8 and 10 ENOENT racing the removed entry), and a direct 100-question foreign-root probe answered 0 from the defaults (45 "Directory identity changed", 50 ENOENT, 5 the recorded "Configuration parent identity changed"). At HEAD (04548877) under the same churn the file is 136/136 in three consecutive runs with 0 refusals, and the same probe answers 100/100 from the defaults. The focused runs pass --reporter=default to keep the live reporter's own-root read out of the measurement: that read still refuses under churn by design, and is the protection f6c8cef2 preserves, not this lane's flake. No ledger entry was removed because none is in the public list: 2545d94f imported the private web history, 94b1a97f emptied it, and 400a130a re-added only the three public suspects engine/traceability/flaky-burn-down/web.json holds; the private floor remains the owner of its 39 entries, which are not edited from here. Not measured: the private parent 8e6e314c itself (a private-floor object not on this branch, and its tree is not the public floor) and a full suite or shard run under churn. The engine flaky guard is 19/19 and the web flaky guard 8/8 over the closed row. This closes the public tracking row only.
FLAKY-WATCHDOG-C3 — merged 2026-10-20 on agent/public-reowning from 114ab553 into the canonical public owner FLAKY-PUBLIC-WEB-WATCHDOG-C3; the two rows named the same lane, the same C3 arm and the same guard, and the public row already carried the narrowed evidence and owns the engine/traceability/flaky-burn-down/web.json entry. One owner remains; the entry is unchanged and still owned. This closes only the duplicate ordinary-work row, not the C3 suspect.
FLAKY-WEB-ARTIFACT-CENSUS — retired 2026-10-20 on agent/flaky-artifact-census from 988eb32f as deterministic and fixed by 114df640, not a flake: the recorded arm reproduces red 5/5 at its parent and is green 5/5 at its fix and 5/5 at HEAD, and the public ledger never carried the lane's entry. The record (the private floor's docs/trackers/TASKS.md row, read-only here) claimed tests/prevention/generated-artifact-freshness.test.ts "the census discovers every gitignored-artifact reader, and the detector is awake" failed at 2026-10-08 20:09:00Z, 20:13:13Z, 20:27:51Z, 23:22:03Z, 23:27:34Z and 23:34:08Z and at 2026-10-09 20:47:53Z, passed every recorded run since 2026-10-09, and had no reproduced cause. Its accepted engine/traceability/flake-reproductions/dcfe2ad186dcb79e700697a5.json (schema v3, recorded 2026-10-10T14:26:11.916Z, mode: "deterministic", suite web, no preload, seed, setup or environment) names that explanation: cause tests/prevention/generated-artifact-freshness.test.ts, parent 69fc8701e250ca1236f74ee5d79a007d450960f3 (0 passed of 5; loads 6.34/5.45/4.63/3.82/3.26) and fix 114df640f9871b67a8fb5c0c638e3cf2165876a1 (5 passed of 5; loads 7.62/6.96/5.93/4.61/4.33); the attempt engine/traceability/flake-reproductions/attempts/437788202b87d02bef238af90f267a7c424cc86d35bcf55aab13ada06eadf2d7.json is the same five-pass run and also records two tests/prevention/no-proximity-window-assertions.test.ts identities owned by the separate FLAKY-WEB-PROXIMITY-ROUND-13-REGEX lane. The defect is the census's read detector, not a race: tests/performance/regression.test.ts reads the gitignored tests/performance/.report.json through scripts/testing/performance-measurements.ts readProfileReport(REPORT_PATH) and judgeableProfileReport(repositoryRoot, REPORT_PATH), while the parent's READ_RE and its constant extraction knew only readFileSync, JSON.parse, readRunFailureRows and readRunHistory; the reader was invisible, so the first arm's KNOWN_READERS liveness floor failed with "the census did not find tests/performance/regression.test.ts — the artifact-read detector went blind, and a green here would certify nothing". The second arm stayed green because it judges only what the blind census discovered. 114df640 adds readProfileReport(X) and judgeableProfileReport(root, X) to READ_RE and to the read-constant extraction (its message names generated-artifact-freshness), so the reader is discovered and judged again; the test file's bytes at HEAD are the fix's bytes (64bd17dc1446cf169567a9a5bb41d3bfb26eeeb9a76e0a1f8cfc06765576f515). Observed in scratch worktrees at the recorded commits with node_modules linked and engine/bridlewise.config.json at 0600 (a fresh worktree's 0664 is refused with config_mode_insecure): the parent 69fc8701 ran ./node_modules/.bin/vitest run tests/prevention/generated-artifact-freshness.test.ts five times, exit 1 in all five with 1 failed | 3 passed (4) and the named assertion each time; the fix 114df640 and HEAD 988eb32f ran the same command five times each, exit 0 with 4 passed (4) every time. The private row's "cause not reproduced" and pass-every-run-since note are a tree-state fact, not nondeterminism: the arm reds exactly while the detector is blind to a reader it names, and greens once the detector learns the owner's shape. No ledger entry was removed because none is in the public list: 2545d94f imported the private web history, 94b1a97f emptied it, and 400a130a re-added only the three public suspects engine/traceability/flaky-burn-down/web.json holds; the private floor remains the owner of this lane's record, which is not edited here. The web flaky guard is 8/8 and engine/test/prevention/flaky-test-memory.test.ts is 19/19 over the closed row; tests/prevention/roadmap-status-owner.test.ts is 6/6; tests/prevention/tasks-no-stale-duplicates.test.ts is 2/2; npm run test:public 34/34; npm run docs:links clean (512 Markdown files); npm run docs:roadmap -- --check current. The roadmap's generated blocks were rebuilt by their writer. This closes the public tracking row only.
FLAKY-WEB-F5-LINK-RUN — retired 2026-10-20 on agent/flaky-f5-link from 3d3344aa as fixed by d250d3da, not stale: the recorded GUARD-F5 mechanism reproduces deterministically at its parent under the recorded condition and is gone at its fix and at HEAD, and the public ledger never carried this lane's entries. The record (the private floor's docs/trackers/TASKS.md row and the 48 engine/traceability/flake-reproductions/*.json records its lane owns, read-only here; the public web.json holds only the three public suspects) claimed one link at ~/.local/state/bridlewise-* made engine/guardian/landlock-guardian.c refuse EVERY confined spawn with ELOOP (keep_out[…] is not a resolved path), failing 43 web tests in 9 files under a substitute HOME with a planted link; its 48 accepted records are schema v2, all mode: "deterministic", one run each (47 recorded 2026-10-08T06:19Z, one 06:21Z), cause engine/guardian/landlock-guardian.c, parent 00e9d58b, fix d250d3da, setup mkdir -p "$HOME/.local/state" "$HOME/f5-target" && ln -s "$HOME/f5-target" "$HOME/.local/state/bridlewise-coordinator", parentRuns passed 0 (loads 6.76; 9.11 for the one) and fixRuns passed 1 (loads 8.76; 9.38 for the one). Observed at the parent 00e9d58b in a scratch worktree with node_modules linked, the parent guardian pin built from its own C source (287e113e3e59c9411ace430a3bc47833207c9a8adb7b22a7229ecdcfdb5b1852, the parent's root-policy.ts pin) and that setup: npx vitest run over the lane's ten record files failed 49 of 205 tests — all 48 recorded identities plus one unrecorded sibling arm (tests/unit/custody-see-what-changed.test.ts "a move INSIDE a directory carries its counts (the folded spelling, live)") — with keep_out[2|8|11] is not a resolved path: '<home>/.local/state/bridlewise-coordinator': Too many levels of symbolic links; the row's seven record-bearing files were 23 failed / 150 passed of 173 in two full runs, exactly the recorded 1+6+4+2+7+2+1 identities, and the focused liveness arm was red 5/5. The link is the trigger: the same parent worktree is green 173/173 under the real HOME and 173/173 under a fresh substitute HOME without the link, and building the parent's gitignored engine/dist/bundle.js removed the only non-link red (an allow-rule arm). At the fix d250d3da under the same HOME and link, the seven record-bearing files are green 173/173 in two full runs (the fix guardian builds to 8084afdb93127a491125800bb81947467fb728873763b1820d7fc1c60296d1c5, the record's fix pin) and the other three record files are 31/32, the remaining red being tests/unit/mcp-stdio-landlock.test.ts's substitute-HOME-without-.ssh cause owned by FLAKY-WEB-SUBSTITUTE-HOME (fixed aa3ed91c), not the link. At HEAD 3d3344aa under the same condition: the ten record files are 205/205 green (the seven files 173/173 in three consecutive runs), the row's nine covered files are 188/188 green, and the focused liveness arm is green 5/5. The fix resolves a link entry once in the guardian, keeps out its place and its target, keeps a dangling or looping link out by name, leaves a grant standing when a link leads into it, still refuses a grant reaching an entry through a linked folder (fail-closed), and re-locates an ESTALE entry. Two of the row's covered files carry no F5 record and are not evidence of the link: tests/prevention/flaky-test-memory.test.ts passed at the parent under the link (10/10) and at HEAD (8/8), and tests/prevention/gitignore-anchoring.test.ts's MOVED-ASIDE arm fails identically at the parent with and without the link because the scratch worktree lacks the gitignored engine/large-codebases corpus link its disk predicate needs (its declared cause is .gitignore at 3896bdd1, a different owner), while it passes at HEAD under the link. No ledger entry was removed because none is in the public list: 2545d94f imported the private web history, 94b1a97f emptied it, and 400a130a re-added only the three public suspects engine/traceability/flaky-burn-down/web.json holds; the private floor remains the owner of its 48 entries, which are not edited here. The web flaky guard is 8/8 and engine/test/prevention/flaky-test-memory.test.ts is 19/19 over the closed row; npm run test:public 34/34; npm run docs:links clean; npm run docs:roadmap -- --check current. The roadmap's generated blocks were rebuilt by their writer. This closes the public tracking row only.
FLAKY-WEB-GUARD-REDS-ON-ROUND-TREES — retired 2026-10-20 on agent/flaky-guard-rounds from 37f50246 as deterministic round-tree reds, not flakes: each of the private lane's 18 identities reds at every recorded parent tree and is green at the matching next-commit fix, the round-13 instance at 81464727 is the same class and is fixed by 48898e57, and all 18 are green at HEAD. The record (the private floor's docs/trackers/TASKS.md row, read-only here) claimed tests/prevention/agent-docs-liveness.test.ts, centralized-config.test.ts, config-write-gate-owner.test.ts, declared-pattern-liveness.test.ts, error-debug-owner.test.ts, error-handling-consistency.test.ts, exposure-reachable.test.ts, guarded-callbacks.test.ts, integration-rule-refs-ratchet.test.ts, no-proximity-window-assertions.test.ts, no-rule-refs.test.ts, no-unused-imports.test.ts, path-spelling-comparison.test.ts, raw-handle-owner.test.ts, raw-source-reader-owner.test.ts, secret-intelligence-owner.test.ts, source-root-organization.test.ts and test-helpers-dedup.test.ts were "whole-tree guards red on committed round trees of 2026-10-07/08 (a real violation in a round commit, fixed by a later commit of the same round), then green: not flakes"; FLAKE-REPRO cannot explain a deterministic guard red whose fix changed the guarded tree rather than a cause of the test. The private engine/traceability/flaky-burn-down/web.json owns the 18 entries (one per file; source-root-organization, guarded-callbacks, no-proximity-window-assertions and raw-source-reader-owner each carry more than one record); the public engine/traceability/flaky-burn-down/web.json holds only its three public suspects, and the two identities it shares with this lane (agent-docs-liveness, source-root-organization) are owned there by FLAKY-PUBLIC-WEB-GUARD-REDS-ON-ROUND-TREES, not by this row. The lane's 24 accepted engine/traceability/flake-reproductions/*.json records are schema v2, mode: "deterministic", one run per side, with empty conditions (no preload, seed, setup or environment); they name seven parent→fix pairs, each one commit apart (git rev-list --count parent..fix = 1): 31fc3a7b→8e6e314c, 8a312394→10bbd3c4, 786bbe2a→00e9d58b, 48f23d75→3270c458, d250d3da→8a312394, 6c056824→e42ba568 and c93d9e50→59ecf14b. Observed in scratch worktrees at those commits with node_modules linked and engine/bridlewise.config.json at 0600: at 31fc3a7b the 12 recorded files ran red 12 failed | 251 passed (263) with exactly one failure per file, every failure name equal to its ledger identity, and at 8e6e314c the same files are 263 passed (263); at 8a312394 the five files are red 5 failed | 61 passed (66) and at 10bbd3c4 green 66 passed (66); at 786bbe2a the two files are red 2 failed | 36 passed (38) and at 00e9d58b green 38 passed (38); at 48f23d75 the two files are red 2 failed | 47 passed (49) and at 3270c458 green 49 passed (49); at d250d3da the proximity file is red 1 failed | 32 passed (33) and at 8a312394 green 33 passed (33); at 6c056824 the config-write file is red 1 failed | 21 passed (22) and at e42ba568 green 22 passed (22); at c93d9e50 the centralized-config file is red 1 failed | 9 passed (10) and at 59ecf14b green 10 passed (10). All 18 distinct identities were observed red across the seven parent runs, and the only non-lane failure name in the logs was the sibling "exempted production trees" arm at 81464727, owned by FLAKY-WEB-PROXIMITY-ROUND-13-REGEX. The one reproducible instance outside those dates is the same class: at the round-13 tree 81464727 ./node_modules/.bin/vitest run tests/prevention/no-proximity-window-assertions.test.ts ran five times, exit 1 in all five with 2 failed | 31 passed (33), and every run named this lane's "greedy/lazy split" arm with expected 58 to be less than or equal to 56 (the sibling arm, expected 24 to be less than or equal to 23, is FLAKY-WEB-PROXIMITY-ROUND-13-REGEX's, retired at 37f50246); at 48898e57 and at HEAD 37f50246 the same command ran five times each, exit 0 with 33 passed (33) every time. The test file's bytes are identical at all three commits (blob b1dda12be2a2d1b1e8ead2bb06adfb8498f944ff), so the fix changed the guarded tree, never the test. The lead's posix.basename attribution is incomplete: the scanned estate's greedy count is 58 at 81464727 and 56 at 48898e57 (a probe of the same split), and the only two rows that leave the list are two greedy test assertions rewritten in 48898e57 — engine/test/process/instrument-lock.test.ts:307 (/wholeInstrumentTestFileCount$.*, "slot"$/ → assert.ok(cli.includes(...))) and engine/test/workflow/harness-commands.test.ts:1097 (the greedy .*harness frozen accept --reason → the explicit sentence) — both in the scanned tests/engine/test estate; the posix.basename hunk (first.replace(/^.*\//u, "") → posix.basename(first)) is in engine/src/shared/flake-reproduction.ts, an exempt production tree, and accounts for the sibling lane's 24→23, not this 58→56. The same round-14 commit therefore closes both arms, by different hunks. At HEAD all 18 covered files plus tests/prevention/flaky-test-memory.test.ts ran three consecutive times, 19 passed (19) / 328 passed (328) every round (the proximity file alone five times green), so no other arm this lane covers is live. No ledger entry was removed: the public web.json holds only the three public suspects and the private floor remains this lane's owner, which is not edited here. The web flaky guard is 8/8 and engine/test/prevention/flaky-test-memory.test.ts is 19/19 over the closed row; tests/prevention/roadmap-status-owner.test.ts is 6/6; tests/prevention/tasks-no-stale-duplicates.test.ts is 2/2; npm run test:public 34/34; npm run docs:links clean (512 Markdown files); npm run docs:roadmap -- --check current. The roadmap's generated blocks were rebuilt by their writer. This closes the public tracking row only.
FLAKY-WEB-PROXIMITY-ROUND-13-REGEX — retired 2026-10-20 on agent/flaky-proximity-regex from 7908177e as deterministic and fixed by 48898e57, not a flake: the recorded arm reds 5/5 at the tree the record names and is green 5/5 at its fix and 5/5 at HEAD, and the public ledger never carried the lane's entry. The record (the private floor's docs/trackers/TASKS.md row, read-only here) claimed tests/prevention/no-proximity-window-assertions.test.ts "the exempted production trees are measured, not merely excused" failed in ONE run (2026-10-11 12:31:10Z, validate 10's web suite, tree of 81464727): round 13 had added a greedy /^.*\// to engine/src/shared/flake-reproduction.ts, an exempt production tree, taking the count from 23 to 24 against the ceiling of 23; round 14 removed it (48898e57, posix.basename), and the arm has passed every run since. That is the tree's own state, not nondeterminism. The five engine/traceability/flake-reproductions/ records that mention the file name sibling identities, never this arm: 155fbe7121999cc4714e8a82.json, 2982927deced77960e749df3.json and 3e9479bd2bfe9fec03d34314.json (schema v2) name the "greedy/lazy split" arm with three unrelated causes and fixes (8e6e314c, 3270c458, 8a312394), and 74f8f5507ff206ec54190025.json / d3d111d410bf42cc8861acf0.json (schema v3, recorded in the artifact-census attempt 437788202b87d02bef238af90f267a7c424cc86d35bcf55aab13ada06eadf2d7) name "no test file uses a proximity window" and "a window built out of ARITHMETIC" at parent 69fc8701 / fix 114df640; the census row attributes those two identities to this lane, and no record names the exempted-production arm because FLAKE-REPRO cannot explain a tree-state red whose fix changes the guarded tree. Observed in scratch worktrees at the recorded commits with node_modules linked and engine/bridlewise.config.json at 0600: ./node_modules/.bin/vitest run tests/prevention/no-proximity-window-assertions.test.ts at the parent 81464727 ran five times, exit 1 in all five with 2 failed | 31 passed (33), and every run named the arm with expected 24 to be less than or equal to 23 and listed engine/src/shared/flake-reproduction.ts [.*] /^.*\//; a direct windowedPatternsIn probe over the four exempt trees counted {"files":965,"bounded":8,"greedy":24} there, against {"files":965,"bounded":8,"greedy":23} at 48898e57 and {"files":966,"bounded":8,"greedy":23} at HEAD 7908177e, with the file carrying first.replace(/^.*\//u, "") only at the parent and posix.basename(first) at the fix and HEAD. At 48898e57 and at HEAD the same command ran five times each, exit 0 with 33 passed (33) every time. The test file's bytes are identical at all three commits (blob b1dda12be2a2d1b1e8ead2bb06adfb8498f944ff), and git diff 48898e57 7908177e is empty for both the test and engine/src/shared/flake-reproduction.ts — the fix changed the guarded tree, never the test. One finding beyond the record: the same five parent runs also red the sibling "greedy/lazy split" arm (expected 58 to be less than or equal to 56), which the private web.json at 81464727 already owns under FLAKY-WEB-GUARD-REDS-ON-ROUND-TREES; the same round-14 commit takes the scanned estate's greedy count from 58 to 56, so that end is that lane's, not this one's. No ledger entry was removed: 2545d94f imported the private web history, 94b1a97f emptied it, and 400a130a re-added only the three public suspects engine/traceability/flaky-burn-down/web.json holds; the private floor remains the owner of this lane's record, which is not edited here. The web flaky guard is 8/8 and engine/test/prevention/flaky-test-memory.test.ts is 19/19 over the closed row; tests/prevention/roadmap-status-owner.test.ts is 6/6; tests/prevention/tasks-no-stale-duplicates.test.ts is 2/2; npm run test:public 34/34; npm run docs:links clean (512 Markdown files); npm run docs:roadmap -- --check current. The roadmap's generated blocks were rebuilt by their writer. This closes the public tracking row only.
FLAKY-WEB-STRAY-TREE-RUN — retired 2026-10-20 on agent/flaky-stray-tree from ffa15bd5 as a deterministic archived-stray-tree run, not a flake, with the recorded config-mode mechanism fixed by 56d9dc92 and 48898e57: the record (the private floor's docs/trackers/TASKS.md row, read-only here; the public engine/traceability/flaky-burn-down/web.json holds only the three public suspects, so this lane owns no entry here) claimed fourteen web tests — tests/prevention/run-executes-once.test.ts ×10, tests/prevention/decisions-format.test.ts, tests/prevention/git-refusal-not-emptiness.test.ts, tests/prevention/subprocess-confinement-owner.test.ts's missing-project arm, and tests/performance/regression.test.ts's long-chat arm — failed in ONE run only (2026-10-11 08:06:37Z) of the archived stray commit ad965a41's tree in the workspace's worktree, with engine/bridlewise.config.json at 0664 after the checkout (the worktree-move defect settleCheckout fixes), "so every harness configuration read in that run was refused"; they passed in every other recorded run, and the lane is "not a flake of any tree that exists". Observed at ad965a41 (tag archive/stray-test-commit-ad965a41, in a scratch worktree with node_modules linked): chmod 600 engine/bridlewise.config.json, then git checkout -q -f --detach 6aacb7dd and back to ad965a41, left the document at 664 both times (git writes its own umask mode over the chmodded file); node --experimental-strip-types engine/src/cli.ts harness check --skip-typecheck refused it at 664 with config_mode_insecure ("Configuration mode must be exactly 0600, found 0664 …"), and at 600 the same command passed the config read and failed later in scripts/pin-authority-regeneration.ts — the mechanism is real, not stale. The fourteen are not that mechanism: the five covered files (run-executes-once, git-refusal-not-emptiness, subprocess-confinement-owner, decisions-format, regression) ran twice at that tree, once at 664 and once at 600, and both were 18 failed | 86 passed | 25 skipped (129) with identical sorted failure lists (diff empty); thirteen of the fourteen lane identities were red in both — the ten run-executes-once arms, decisions-format's well-formed-index arm, git-refusal-not-emptiness's spawn-THROWS arm, and the subprocess missing-project arm — while the fourteenth (regression's long-chat arm) was not reached because the gitignored profile report is absent from the worktree and the file reds on "the profile report is present and parseable" instead (owned by FLAKY-PERF-GATE-STALE-REPORT). The other five reds of the 18 are not this lane's: run-executes-once's newer crash-path arm, the two F5-link git-refusal-not-emptiness arms, the subprocess E arm that names the missing engine/guardian/build/harness-landlock-guardian, and regression's profile-presence arm. The causes are the tree's own and deterministic: the run-executes-once arms fail before any provider request, and the frame captured from the assistant-persistence arm is llm_stream_error ("The remote address … is on this machine or a private network, which this request may not reach"); decisions-format reds because ad965a41 (an accidental git commit -a from an agent's shell) edited three decisions and engine/scripts/verification/tracker-entries.ts without regenerating docs/decisions/README.md; the git arm gets git_not_run where it pins git_read_unavailable; the subprocess arm gets refused for an existing temp folder with the guardian binary absent (the sibling E arm names engine/guardian/build/harness-landlock-guardian missing). The owner is the worktree move: 56d9dc92 re-applies the checkout files after every move, 48898e57 folds that into the one settleCheckout point at every tree move (the land, the read-tree switches, the worktree moves, the promotion), and its shipped guard is engine/test/workspaces/workspace-integration.test.ts "every move of a worktree keeps the config's 0600…". At 48898e57 that guard is 1/1 green; planted by deleting its settleCheckout call from moveWorktree it reds 1/1 with actual ['664'] vs expected ['600']; restored it is green. At HEAD ffa15bd5 it is 1/1 green (243 ms). At HEAD the four non-regression covered files are 107/107 (all thirteen lane identities), while tests/performance/regression.test.ts is 26 red of 133 on the stale/unjudgeable profile report, which FLAKY-PERF-GATE-STALE-REPORT's open row owns. No ledger entry was removed: the public web.json holds only the three public suspects and never carried this lane, and the private floor remains the owner of its record. The web flaky guard is 8/8 and engine/test/prevention/flaky-test-memory.test.ts is 19/19 over the closed row; npm run test:public 34/34; npm run docs:links clean (512 Markdown files); npm run docs:roadmap -- --check current. This closes the public tracking row only.
FLAKY-WEB-SUBSTITUTE-HOME — retired 2026-10-20 on agent/flaky-substitute-home from aae25109 as fixed by aa3ed91c, not stale: the recorded mechanism reproduces deterministically at its parent under the recorded substitute HOME and is gone at its fix and at HEAD, and the public ledger never carried this lane's entries. The record (the private floor's docs/trackers/TASKS.md row and the two engine/traceability/flaky-burn-down/web.json entries it owns, read-only here) claimed the 2026-10-07 16:36–17:20Z rows: a read path the confinement floor would refuse at spawn was accepted at save under a substitute HOME without ~/.ssh, because server/safety/landlock-runner.ts emittableDerivedRules dropped a missing derived rule before the one compiler's keep-out judgement; its two accepted engine/traceability/flake-reproductions/*.json records are schema v2 and mode: "deterministic" — b7ebdc038b662928fbf41434.json names tests/unit/mcp-servers-route.test.ts::add and edit (the one upsert write) > a read path the confinement floor would refuse at spawn is refused at SAVE, with the floor's code, f59bbc198abe83202330c35a.json names tests/unit/mcp-stdio-landlock.test.ts::a stdio MCP server under the real guardian > writes only its own home (and TMPDIR inside it): every other root the spec could grant is EACCES, and read paths are held to W^X and the refused roots; both name cause server/safety/landlock-runner.ts, parent b4a3c298, fix aa3ed91c, environment HOME=/home/example/.cache/bridlewise-home-land-opencode (the public sanitizer's spelling of the private substitute home) and setup mkdir -p "$HOME". Observed at the parent b4a3c298 in a scratch worktree with node_modules linked, the recorded guardian pin built from its own C source (8084afdb93127a491125800bb81947467fb728873763b1820d7fc1c60296d1c5), and a fresh substitute HOME with no .ssh/.claude: npx vitest run tests/unit/mcp-servers-route.test.ts was red 5/5 with expected 200 to be 400 and the accepted server carrying readPaths: ["<home>/.ssh"] (1 failed, 25 passed), and npx vitest run tests/unit/mcp-stdio-landlock.test.ts was red 5/5 with the secret reader {status:"connected",code:null,confinement:"confined",reason:null} where the arm requires {status:"error",code:"mcp_spawn_refused",confinement:"refused",reason:"read_path_refused"}. The condition is the trigger: with the same worktree and the gitignored engine/dist/bundle.js present (its absence otherwise made the parent compiler emit a missing allow-rule and refuse the whole spec), the parent is green 3/3 under the real HOME, 2/2 under a substitute HOME that holds .ssh (stdio), and 2/2 (26/26) under a substitute HOME that holds .ssh and .claude (route). At the fix aa3ed91c under the same no-store substitute HOME: route green 5/5 (27/27, including the new UNDER ANY HOME: a read path the floor refuses BY NAME is refused at save whether or not it exists yet — absent, then present — and a near-miss that names no store is accepted) and stdio green 5/5 (1/1). At HEAD aae25109, same condition: route green 5/5 (27/27) and stdio green 5/5 (1/1). The fix judges every allow-rule by name in the one compiler (engine/src/filesystem/self-protection/guardian-binary.ts compileSelfProtectionConfigToSpec) and only then cuts the emitted list to the paths that exist, while emittableDerivedRules no longer drops a missing path before that judgement; the parent code is the opposite. No ledger entry was removed because none is in the public list: 2545d94f imported the private web history, 94b1a97f emptied it, and 400a130a re-added only the three public suspects engine/traceability/flaky-burn-down/web.json holds; the private floor remains the owner of its two entries, which are not edited here. The web flaky guard is 8/8 and engine/test/prevention/flaky-test-memory.test.ts is 19/19 over the closed row; tests/prevention/roadmap-status-owner.test.ts is 6/6; npm run test:public 34/34; npm run docs:links clean; npm run docs:roadmap -- --check current. The roadmap's generated blocks were rebuilt by their writer. This closes the public tracking row only.
FLAKY-WEB-UNDIAGNOSED — retired 2026-10-20 on agent/flaky-web-undiagnosed from 54a27378 as deterministic test-fixture reds, not flakes: both recorded identities red 5/5 at the parent tree the record names and are green 5/5 at its adjacent fix and 5/5 at HEAD, with the cause proven in each failure. The record (the private floor's docs/trackers/TASKS.md row, read-only here) claimed tests/unit/config-write-concurrency.test.ts and tests/unit/landlock-project-refusal.test.ts each had "one red each (2026-10-07 20:06Z and 2026-10-08 09:53Z), cause not found. Find it and declare a reproduced fix, or row the proven cause." The two matching engine/traceability/flake-reproductions/*.json records are schema v2, mode: "deterministic", one run per side, with empty conditions (no preload, seed, setup or environment) and causes naming the test file itself: aecb6b4aa5ac7b3a6d9b5ba7.json (config-write, parent 31fc3a7b, fix 8e6e314c, recorded 2026-10-08T10:38:58.842Z) and b6da1c789d69c52cbe059f09.json (landlock, parent 48f23d75, fix 3270c458, recorded 2026-10-08T06:34:10.453Z); each pair is adjacent (git rev-list --count parent..fix = 1). Observed in scratch worktrees at the recorded commits with node_modules linked and engine/bridlewise.config.json at 0600: at the config parent five focused runs red 5/5 with 1 failed | 6 passed (7), every run naming "the config write lock across processes > a stale lock from a dead holder is broken, not waited on" and ConfigWriteLockTimeout: could not acquire the lock at … within 10000ms; at its fix and at HEAD the same command is green 5/5 (7 passed (7)). At the landlock parent five runs red 5/5 with 1 failed | 12 passed (13), every run naming "the ONE keep-out list at the project door and the file choke point (CRED-F11) > a home is refused because it holds credential stores …" and expected "Path '<tmp>/fake-home-…' contains <tmp>/fake-home-…/.local/share/bridlewise/evidence, which is the harness's own state or code …" to match /credentials or keys/i; at its fix and at HEAD the same command is green 5/5 (13 passed (13) at the fix; 11 passed (11) at HEAD, where the two WSL arms were removed later). The causes are the tests' own fixtures, not races: the config test planted a lock record with pid and no startTime, while the parent's file-lock.ts parseContent already requires pid AND start time for an identity, so the fresh record read as an unreadable foreign lock and was honoured for filesystemInfrastructure.fileLock.staleMs (120000 ms), longer than the 10 s acquire timeout; 8e6e314c adds startTime: 1 beside the dead pid, so the dead holder is broken at once. The landlock test set HOME to a fake home without pinning HARNESS_EVIDENCE_HOME, so the evidence store's default (~/.local/share/bridlewise/evidence, privateHomeSetting) landed inside that home and the one keep-out door refused the home as containing harness state before reaching the credential-store arm; 3270c458 pins the store outside the fake home and restores it. The recorded reds fall between their parent and fix commits (config: parent 09:45:39Z, red 09:53Z, fix 10:07:28Z; landlock: parent 19:48:17Z, red 20:06Z, fix 20:10:44Z, UTC), so the deterministic parent reds are the recorded "one red each"; no intermittent failure was observed. No ledger entry was removed: the public engine/traceability/flaky-burn-down/web.json never carried these identities (it holds only the three public suspects), and the private floor remains the owner of its v2 records and its lane, which are not edited here. The web flaky guard is 8/8 and engine/test/prevention/flaky-test-memory.test.ts is 19/19 over the closed row; npm run test:public 34/34; npm run docs:links clean; npm run docs:roadmap -- --check current. The roadmap's generated blocks were rebuilt by their writer. This closes the public tracking row only.
Repair the public full-suite baseline — the 521-file supported set is green and the four remaining failures are named exclusions with a reason and evidence.
Verify the public floor on a fresh machine — a clean clone at b866b826 ran the public gate (28/28), the corpus fetch and verify, the focused probe (81 engine + 12 Vitest tests), and the supported 521-file suite (8720 passed, 0 failed); it found a corpus-fetch bug (fixed 0e45bf58) and two undocumented builds (documented 5522cc3d).
Give the testing repository its own front door — publish a contributor hub, move product documentation to a linked entry point, and keep the complete mirror.
Make the testing hub discoverable from every surface — the README, Pages hub, roadmap, help, and product README are in step.
Link the task board from the hub — the contributor hub at docs/index.md links docs/trackers/TASKS.md beside "How to help" and "Contributing", so the open work is reachable from the site root.
Anchoring the public ignore rules — keep every pattern scoped to the place it names, and pass the floor guard.
Allow the public node:test suite in the source walks — keep .mjs smoke files visible to the guards that judge the tree.
Publish the milestone roadmap — state M0 to M4, exit criteria, and the full-suite audit.
Add the shard merge contract — refuse missing, duplicate, failed, unexpected, and out-of-root shard files, and write one receipt.
Publish the full supported-set shard receipt — CI run 39439338300 at 3b4db454 ran the matrix on a push: the plan, ten ubuntu-24.04 shards (521 files, 8722 tests, 8722 passed, 0 failed, 0 skipped), and the merge all succeeded, and the merge job uploaded the test-shard-receipt artifact described in the evidence page. This supersedes the prose-only d47909de receipt. The artifact records testPhaseMs 88000 but no same-commit single-host baseline, so it does not re-derive the 2.81x factor; the roadmap's 10x exit line remains open.
Re-measure the shard weights at the manifest's own head — closed 2026-10-20 at f54df4a5. CI run 39470087124's test-shard-receipt artifact measured the ten ubuntu-24.04 shards over 523 files and 8734 tests (8734 passed, 0 failed, 0 skipped): testPhaseMs 83438, testPhaseCpuMs 658687, shard walls 49566–81359 ms (max/min 1.64x). The heavy shard was 8 (81359 ms, 53 files; promotion-boundary 29003 ms, subprocess-confinement-owner 22641 ms, content-search-deadline 11618 ms, redaction-reaches-provider 9362 ms); the light shard was 4 (49566 ms, 52 files, 579 tests). The checked-in weights from 0ba57912 predicted 1.00x, so the imbalance was stale measurement, not the assignment: the run's per-file endTime - startTime differed from the checked-in weight by 0.052x–10.47x and the weight sum fell from 1487347 ms to 798882 ms (1.86x). Re-derived through the manifest owner (node scripts/test-shard-manifest.mjs measure --manifest tests/test-shards.json --head f54df4a5… --runner ubuntu-24.04 --out tests/test-shards.json over the ten test-shard-report-* artifacts), which rewrote all 523 weights and measuredHeadSha; the new plan predicts 79888–79889 ms per shard (1.00x). The after wall spread is not measured: the run had at most three concurrent files, and packing the same file durations into three slots per shard gives a 26630–39967 ms critical path (1.50x) because test-isolation-contract alone costs 39967 ms; the next receipt confirms the wall, and splitting that file is the remaining lever. MEASURED 2026-10-20 (CI run 39471843640 on 9c4526e7, artifact test-shard-receipt): the walls did NOT improve — 45184–79817 ms, max/min 1.766x against the previous 1.641x, same 523 files and 8734 tests, all green. The weights are now truthful (the own-measure path rewrote all 523), but summed file cost is not wall time: setup, collection and per-file overhead are not in the weights, so balancing the sums cannot balance the walls. The open work is therefore wall-aware packing or per-shard overhead accounting (or splitting test-isolation-contract), not another weight edit — the weights themselves are measured and owned.
Activate the sharded full-suite gate — .github/workflows/test-shards.yml is now a reusable workflow called by the shards job in .github/workflows/ci.yml on every push and pull request to main; the merge refuses a failed shard or a union that is not the manifest exactly once, and uploads test-shard-receipt. The dispatch path and runner choice remain. The local two-shard sample and the refusal arms are recorded in the evidence page.
The clean-machine setup names every build before the suite — The setup sequence names the guardian build and engine bundle before the supported suite, and docs/testing.md names each refusal rather than calling it a skip. Carried from: docs/testing.md: Development-floor setup; TASKS.md: Verify the public floor on a fresh machine.
Docs and briefings resolve only to tracked paths — The docs link check resolves every tracked repository-relative Markdown link, and the briefing liveness guard refuses a linked path or backticked repo path that git does not hold. Carried from: tests/prevention/agent-docs-liveness.test.ts; scripts/check-docs-links.mjs.
Tracked modes and the self-protection config keep their contract — A tracked file recorded as 100644 stays 0644 in the working tree; a new atomic write takes 0600 only when it creates the file; and engine/bridlewise.config.json is 0600 in the checkout and CI. Carried from: TASKS.md: PUBLIC-SNAPSHOT-FILE-MODES; .github/workflows/ci.yml.
Every gate carries a replayable evidence record — The evidence page's gates name a command and an expected shape, and the record-your-own-check form gives a reviewer the claim, commit, command, observation, and interpretation fields. Carried from: docs/floor/evidence.md: Record your own check.
Public floor, public gate and preview release — Both repositories, the Pages sites, the public gate, failure reporting, the promotion gate and v0.0.3-preview are live. Carried from: M0, existing roadmap.
Build the floor from a clean machine — A clean clone reaches the public gate, the pinned corpus probe, and the supported suite through the documented commands; the sharded gate and receipt (M1), corpus boundary (M1), contributor hub (M4), and remaining known gaps (M2-X4) are composed here rather than restated. Carried from: TASKS.md closed rows: Verify the public floor on a fresh machine, Publish the corpus manifest; docs/testing.md setup; composes M1-SHARD, M1-RECEIPT, M1-CORPUS, M4-HUB and M2-X4.
Reproducible fixtures — The pinned corpus subset is fetched and verified outside the checkout; the raw cache stays unpublished. Carried from: M1 workstream 3, existing roadmap.
One qualification receipt — The merge refuses a missing, duplicate, failed, skipped, dirty or wrong-commit shard and uploads one receipt with the counts, timings and exclusion anchors. Carried from: M1 workstream 2, existing roadmap.
Repair the baseline reds — The supported file set runs without a failing or skipped test, and every exclusion is named with evidence. Carried from: M1 workstream 5, existing roadmap.
Shard the full suite — The manifest verifies against the live suite, the plan is deterministic, and a matrix of runners executes disjoint shards. Carried from: M1 workstream 1, existing roadmap.
CI calls the shard workflow — A push and pull-request CI job calls the shard workflow; dispatch remains available. Carried from: M1 exit criterion 1, existing roadmap.
The merge refuses a bad shard set — The merge refuses a missing shard, a duplicate file, a skipped file, a failed result, a dirty tree, or a shard from another commit. Carried from: M1 exit criterion 2, existing roadmap.
The merge uploads one receipt — The merge uploads one receipt naming the manifest digest, shard indexes and timings, pass/fail counts, and the excluded files with their evidence anchors. Carried from: M1 exit criterion 3, existing roadmap.
The receipt names commit, class, time and prerequisites — One receipt records the exact commit, shard count, runner class, total test-phase time, and any unsupported suite with its named prerequisite. Carried from: M1 exit criterion 4, existing roadmap.
A fresh clone runs the supported suite — A fresh clone with the documented setup runs the supported suite without guessing which tests are silently missing. Carried from: M1 exit criterion 6, existing roadmap; met at b866b826.
preflight names each capability — preflight names each capability and its state, with evidence and a remedy for anything denied. Carried from: M2 exit criterion 1, existing roadmap; receipt shape recorded in TASKS.md.
A release is verifiable from published assets — A release can be verified from published assets and instructions. Carried from: M2 exit criterion 3, existing roadmap.
The review boundary is stated without an audit claim — The project states exactly what has and has not been reviewed, without implying that CI is an audit. Carried from: M2 exit criterion 4, existing roadmap.
Backup and restore for the database and key home, with verification — One documented flow backs up and restores the database with its key material and proves each copy opens. Carried from: M3 workstream 1, existing roadmap; task board done row.
Backup and restore are one verified flow — Backup and restore are one documented flow with a verification step. Carried from: M3 exit criterion 2, existing roadmap.
A first-patch path for docs, tests, guards, benchmarks and portability — Each contribution lane starts from a public command and a reviewable first step. Carried from: M4 workstream 3, existing roadmap.
A contributor hub distinct from the product home — The floor has its own front door, separate from the product documentation mirror. Carried from: M4 workstream 1, existing roadmap.
Review expectations that reward reproduction and prevention — The review guide asks for the reproduction, the prevention guard and the evidence, not only a green run. Carried from: M4 workstream 4, existing roadmap.
A roadmap that records state and exit criteria instead of a wish list — Every planned-but-not-done item is rendered from its owner, and a guard refuses a stale status block. Carried from: M4 workstream 5, existing roadmap; this change.
Skipping or hiding a failing test to make a badge green — A failing test is owned by a named task row, and a guard refuses a stale duplicate.
A hosted multi-tenant service in the preview — The preview is a single-user developer preview and carries no hosting claim.
Publishing the raw 4.1 GB corpus as a repository — Mixed licenses, nested histories, duplicate checkouts and credential-shaped fixtures.
A production-readiness claim before the admission evidence exists — The admission gates are open and no capability beyond preflight is admitted.
A release date — This roadmap is a statement of intent, not a schedule.
A universal provider compatibility claim — Provider conformance is proved per shape, not universally.
A benchmark number without its method — Performance claims must link to a method and a report.
Make the performance report reproducible — the idle-host contract is documented in the test map, and a fresh 2caada8f profile was judged by the regression gate (36/36); the red LCP, long-task, API, and long-chat budgets belong to M3.
Add per-capability admission receipts — every preflight capability entry now names the fact that decided it and what would change a denial: evidence.path is engine/src/kernel/root-policy.ts, evidence.field is capabilities.<name> (covered by the receipt's rootPolicyHash), and remedy is null only for the admitted preflight capability while each denied capability names its governance gate as the remedy. The regression test (engine/test/preflight.test.ts, "each capability receipt names its covering policy fact and a remedy when denied") failed before the fix with TypeError: Cannot read properties of undefined (reading 'path') and passes 29/29 after; the focused preflight/S1/S2.4 consumer set is 57/57, tests/prevention/exposure-reachable.test.ts is 14/14, npm --prefix engine run typecheck is clean, npm run test:public is 29/29, and node --experimental-strip-types src/cli.ts harness check --skip-typecheck passed with the architecture manifest in sync (869 modules, no registry change). This closes the receipt shape only: the M2 admission gates for model invocation, repository mutation, process execution, and network egress remain open, and no capability beyond preflight is admitted.
Add a second provider conformance fixture — the Chat Completions request and stream shapes are proved offline without a universal-compatibility claim.
PUBLIC-SNAPSHOT-BUNDLE-STALE — closed 2026-10-20 at c0f637e7. Reproduced 1 red of 5: npm --prefix engine run build:bundle measured 68adb4f4d2633972c64b0ed1e7ae4cff7fb9eac026d0950b175a31b0e86789ab (5,996,223 bytes; the row's ab8f23b4... was the f518c9f6 source) while ROOT_POLICY still pinned c2d96102.... The rebuild alone cannot move the pin: scripts/build-bundle.ts publishes the sealed bytes, and the pin owner is the root-policy-self-protection-bundle-sha256 hash binding written by harness regenerate. Ran the documented owner one-shot from engine/: node src/cli.ts harness sync --with-bundle — status pass, steps register, regenerate, bundle-build, regenerate, check all pass; convergence took 2 passes and rewrote only engine/src/kernel/root-policy.ts (bundleSha256 c2d96102... → 68adb4f4...). The focused guard is 5/5 after. No hand edit: the dist/bundle.js artifact stays gitignored and generated. The stale writer is the src/ changes after the c2d96102... build (the last is c0f637e7, the backup/restore flow) landing without a bundle rebuild; the guard and the one-shot remedy already refuse that. The later item-4 source change re-ran the same one-shot and moved the pin to f7138261...; test/prevention/bundle-staleness.test.ts is 5/5 at the final head too. Not a flaky suspect.
PUBLIC-SNAPSHOT-CANDIDATE-FORMAT — closed 2026-10-20 at c0f637e7. Reproduced 3 red of 25 (artifact admission rejected content format: ...historical-evidence.tar.gz, 4532 !== 4533, and artifact-search-projection-drift:...verify-artifacts.mjs). The owner is the projection declaration, not the evidence fixture: the public import sanitized the local home path to /home/example in exactly three text projections while content-manifest.json still declared the private-floor bytes (1627/360872/4533 against 1626/360852/4532); the archived originals do not match the manifest either (they retain the older code-harness path), and the public tree cannot carry the private home path because npm run check:secrets refuses it outside fixture paths. Re-measured the manifest from the bytes this tree carries under its own identity/append-one-lf rules (all three are identity) and updated both sidecars' contentManifestSha256 (52149559... → bef1b490...); no evidence byte or archive was rewritten. node --experimental-strip-types --test test/candidate-format.test.ts is 25/25 after. The public import sanitizer must re-measure this manifest whenever it rewrites a projection; the focused guard is the refusal if it does not.
PUBLIC-SNAPSHOT-EXTERNAL-BENCHMARK-SOURCES — closed 2026-10-20 at c0f637e7. Reproduced 35 diagnostics (3 hash-drift, 16 missing, 16 unreadable; the row's 34 was the f518c9f6 measurement). Decision: this is the public boundary, not a missing fixture. The 16 verification/benchmarks/historical-opencode/ sources are the private floor's historical research and the public snapshot pruned them deliberately (ROOT_POLICY records the 16→8 test-surface prune; the public tree carries no historical-opencode/ directory), so no source was fabricated or restored. The architecture owner now declares publication: "not-published" on those 16 commands: verifyExternalCommands emits architecture-external-command-source-not-published:<path> on every run and architecture-external-command-source-unexpectedly-published:<path> if one appears; the S1 reader skips only the expected-absent read, and isUnavailableCapabilityDiagnostic classifies the named boundary so S1-B08-CONTROL and S1-B13-CONTROL accept it as a baseline refusal — verifyS1Structure().ok stays false and all 16 named diagnostics remain visible, not silenced. The three published sources that had drifted (code-intelligence/inspect_existing_baseline.py, code-intelligence/tests/test_qualification.py, runtime/verify-node-v24.18.0-linux-x64.sh) are deliberately sanitized public copies, so their sourceSha256 pins were re-measured to the public bytes (478d8122…, 191b4eb3…, 8d20dcf7…) and they remain published and hash-bound. The recursive inventory's second hand-written pin moved 16→8 / 8dcad553… to match root-policy.ts. Ran: node --experimental-strip-types --test test/verification/architecture-external-commands.test.ts 8/8 (new absent and unexpectedly-present boundary arms), test/s1-scenarios/b08.test.ts 3/3, test/s1-scenarios/b13.test.ts 3/3, test/verification/recursive-test-inventory.test.ts 29/29, test/prevention/flaky-test-memory.test.ts 19/19, test/verification/test-surface-conservation.test.ts 11/11, and node src/cli.ts harness sync --with-bundle (pass; re-pinned f7138261…).
PUBLIC-SNAPSHOT-FILE-MODES — closed 2026-10-20. Reproduced 1 red of 5 (the guard named scripts/verification/corpus.ts 600 and test/verification/corpus-manifest.test.ts 600); git ls-files -s records both as 100644, so the expected working-tree mode is 0644 (Git records only the executable bit; the tree's dominant disk mode is 0664). Repaired with chmod 0644; the focused guard is 5/5 (node --experimental-strip-types --test test/prevention/git-freshness.test.ts). The copy that produced them is the public-snapshot import outside this checkout: no in-repo writer or generator creates either tracked file, and src/filesystem/atomic-write.ts already carries an existing target's mode across its rename (a NEW file deliberately takes 0600). A fresh clone materializes 0644 and this guard refuses a recurrence. The chmod itself is not representable in a Git commit because Git stores only 100644 versus 100755. Not a flaky suspect.
Record the v0.0.3 release evidence — receipt, checksums, attestations, and verification commands.
Update the rewind provider stub — read the Responses request shape and exercise the real context path.
Split the slow rewind test — four behavior files, each with a fresh harness, 44 tests in total, and the largest at 4.52% against the 5% per-file share cap.
Give each shard exclusion evidence that resolves — the four tests/test-shards.json evidence fields point at docs/floor/roadmap.md#snapshot, the dated public-baseline audit that names all four exclusions, instead of the milestone anchor the roadmap never defined.
Refuse a failed tree-sitter parse instead of an empty extraction — extractSymbolsTreeSitter now throws the typed tree_sitter_parse_failed refusal (backend error carried as cause; the file is named in the message), parseSync refuses a missing tree, and generateRepositoryMap refuses instead of skipping the file. The regression at engine/test/intelligence/tree-sitter-js-extract.test.ts was red first (returned 0 symbols (lineCount 3)) and is green (8/8); the focused intelligence/editor suites (220 tests), the ten tree-sitter guards, and npm run test:public (28/28) pass. The isolated farm keeps its documented per-file containment for a killed child, and a typed parse refusal now reaches it as FarmFileResult.errorCode rather than as a successful zero-symbol extract.