17 — Gates to cut

Headline

The plan is spending more effort proving that its proof machinery has the right shape than proving that the product works: keep the small truth boundaries, remove global bookkeeping from task admission, and cut the universal parity and red-proof campaigns as release blockers. [RULING D58; RULING D61; todo/39-unfailable-gates.txt:10-16; proof/build-inventory-run.md:3-11]

Decision rule

The current instruction is working product first. A gate stays only if it stops a user being harmed or stops OSL claiming a result that has not happened. A gate that measures metadata, freshness, proof wording, route accounting, or a mutation ritual without establishing product behaviour is deferred or cut. [OWNER INSTRUCTION FOR THIS AUDIT, 2026-08-16; RULING D58; 01-FULL-SPEC.md:98]

Two lines stay:

• Never message a real third party or post publicly during acceptance work. Owner accounts may be used only in private test runs. [RULING D38; 01-FULL-SPEC.md:358]
• Never call a task, carrier, artifact, screen, or release proven when the required observation did not happen. A checked task is not proof that the released program works. [TASK 7760; RULING D30; 01-FULL-SPEC.md:98]

Decisions

1. check-needs.sh — SIMPLIFY

What it protects. It tries to avoid dispatching work when its declared artifact, Windows session, design manifest, elapsed campaign, canonical file, QA guest, or test account is unavailable; every UNMET or UNKNOWN result holds the task. [check-needs.sh:2-4,296-345]

What it has actually caught. It has refused non-ancestor artifact records, digest mismatches, an absent canonical file for TASK 3512, and the absent 168-hour TASK 0219d receipt. Those are real facts about whether the named operation can run. [check-needs.sh:117-151,265-293; lane-logs/waiting.tsv:2,12]

What it has wrongly blocked. The Windows probe held 151 tasks because a cold WSL-to-Windows probe and its working directory failed, not because Windows UIA was unavailable. The account rule then discarded 15 recorded account tokens at midnight even though the record already said Discord, Telegram, and provider-pair accounts were present; fixing that rule raised gate-ready tasks from 10 to 23. [check-needs.sh:13-17,56-68,88-100,233-247; RULING D59]

The artifact token is also the wrong fact. It validates a path, SHA-256, ancestry, and a 400-commit lag, then emits MET without launching the executable. The admitted SHA 39fa816e… exited 78 before creating a window, yet artifact:canonical was MET and the parity runners proceeded into guaranteed refusal. [check-needs.sh:117-151; proof/7757/task-7757-windows-launch-receipt.json:10-15; proof/preflight-rerun.md:9-17,43-55; TASK 7489]

The design token is false-green in the opposite direction. It accepts a reasoned UNREFERENCED row and never requires manifest.failures to be empty, then emits MET; the current manifest has 11 unreferenced failures, although TASK 7049 says one must make its checker exit 1. [check-needs.sh:154-221; proof/7049-route-design-manifest.json:638-649; todo/37-screen-parity.txt:157-174]

Recommendation. Keep windows:interactive only for a task that actually drives Windows, canonical-file: only for a consumer of that file rather than the task creating it, and account tokens only for the exact live two-identity run. For UI work, artifact readiness means the same digest launches and creates a window. Remove design-manifest:7049 from general dispatch; a missing design can deny parity proof but cannot deny behaviour work. [RULING D59; RULING D65; 01-FULL-SPEC.md:356-358]

2. plan-complete.sh — SIMPLIFY RADICALLY

What it protects. It exists because 4,069 honest ticks once corresponded to about 25 percent of the ruled product, with code stranded on lane branches, edits never committed, and requirements with no task. That is a real false-completion problem. [plan-complete.sh:9-33]

What it has actually caught. Its observed-running clause was changed after substring matching let NOT YET OBSERVED RUNNING satisfy OBSERVED RUNNING. Clause G, once pointed at a checkout containing its checker, found a missing registry row, missing provenance, and a registry that became stale within minutes. Those catches protect the truth of the report, not product behaviour. [plan-complete.sh:103-119,122-145; RULING D61]

What it still gets wrong. Clause A makes every open heading a release blocker, regardless of whether the heading protects working V1. Clauses B and C parse coverage prose rather than run the acceptance checks. Clause D invokes its verifier with || true, so the following status check sees the successful true instead of reliably propagating the verifier failure. Clause E accepts nonempty transcript and digest strings without opening, hashing, or binding them. Clause F passes any readable Markdown containing verdict: green. [plan-complete.sh:48-102,103-119,148-153]

Clause G is the decisive cost. It now requires 3,273 of 3,312 substantive tasks to show an independently observed red case against a packaged Windows artifact. It is the largest remaining body of work, and none of it was possible before a current package existed. The first working run found registry and provenance defects, not 3,273 product defects. [RULING D61; TASKS 7800-7809; todo/50-test-certainty.txt:59-235]

Recommendation. Keep four release facts: the exact candidate digest and provenance; that candidate launching and reaching sign-in; direct end-to-end tests of the shipping journeys being claimed; and an explicit list of failed or unavailable claims. Cut A/B/C/F/G as release blockers. In particular, remove Clause G from completion and run targeted sensitivity checks only around false-success, payment, destructive deletion, cryptographic authority, and carrier send/readback claims. [TASK 7760; RULING D30; RULING D38; RULING D61; 01-FULL-SPEC.md:94-108,358]

3. record-done.sh — SIMPLIFY

What it protects. It refuses a nonzero lane result, absent evidence, evidence under 400 bytes, an evidence file that appears to admit failure, fake commit citations, stale evidence after an untick, code stranded off canonical, and hand-rejected evidence. [record-done.sh:61-75,78-190,192-265]

What it has actually caught. The old length-only rule ticked TASKS 4098, 4662b, and 6592 even though their own evidence denied success. Widening the search found 157 already-ticked admissions. It also caught four invented commit SHAs, stale evidence re-ticking TASK 0073 after RULING D37, and a sample in which 23 of 33 code-producing ticks were stranded off canonical. These are false done claims and should remain blocked. [record-done.sh:78-100,163-167,192-235; RULING D37]

What it has wrongly blocked. Its central decision is a prose regex with layers of exclusions. The first broad version blocked TASKS 7101 and 7105 because those detector tasks quoted other tasks saying NOT MET; TASK 7105b then broke the exclusion by writing caught: rather than caught=. A valid new wording can still evade the regex, and unrelated red-proof prose can still trigger it. [record-done.sh:101-133]

It also selects the first lexicographic TASK.md or TASK-*.md, not the evidence bound to the current run, and jumps a prose admission or citation mismatch straight to the attempt ceiling. The stable-refusal machinery was added after 59 tasks were retried 45 times each in one hour, producing 2,184 refusals against 25 ticks. That is proof that dispatch state, evidence selection, and completion state are not cleanly separated. [record-done.sh:19-22,39-58,134-188]

Finally, it never evaluates the task's done when: result. After its generic filters, it inserts done: and proof: below the first finish line. A long enough evidence file that avoids the denial vocabulary can still tick a task without establishing its actual acceptance bar. [record-done.sh:268-299]

Recommendation. Keep: current invocation exited 0; current invocation produced a receipt; receipt says PASS; cited shipping commits exist; the final implementation reached canonical; rejected or later-unticked evidence cannot be reused. Cut the 400-byte threshold, natural-language failure guessing, automatic jump to the ceiling, and first-filename evidence selection. A task result needs one explicit result value and the exact run/commit it belongs to. [record-done.sh:61-75,129-188,212-259]

4. check-code-reached-product.sh — KEEP THE INVARIANT, REPLACE THE MATCHER

What it protects. A code task does not count as product work until its implementation is reachable from canonical integration/full. That directly stops the plan from calling branch-only or uncommitted work done. [check-code-reached-product.sh:9-23]

What it has actually caught. The initial sample found 23 stranded versus 10 landed code-producing tasks. TASK 7385 showed that trusting evidence to cite its own commit was bypassable, and TASKS 7381 and 7382 claimed source edits while no commit existed anywhere. [check-code-reached-product.sh:9-30,74-90]

What it has wrongly blocked. The original literal TASK <id> search missed prefixless canonical subjects. TASK 7769b had shipped, but the matcher found only an off-canonical duplicate and re-offered the task 85 times; TASKS 7314 and 7903b had the same defect. A naive subject anchor also matched IDs in commit bodies, so the current script added more subject parsing. [check-code-reached-product.sh:50-72; commit b3c313587e6406e6d57b0d9a3b7adf228766a697]

The current version still exits silently if the repository or canonical ref is missing, infers uncommitted source work from a narrow prose/path regex, and passes if any historical same-ID commit landed even when the final patch did not. Those are false-green paths in a gate whose only value is exact ancestry. [check-code-reached-product.sh:46-48,74-104]

Recommendation. Keep the ancestry requirement. Replace subject searches with the exact implementation commit or patch ID recorded by the lane and the exact canonical commit recorded when it lands. Missing repository/ref is UNKNOWN, not success. This is one of the few gates that directly stops a shipping lie. [check-code-reached-product.sh:21-30; 01-FULL-SPEC.md:98]

5. release-externally-parked.sh — CUT

What it protects. It tries to release tasks that hit the attempt ceiling because of an external blocker rather than their own failure. It was added after 19 zero-own-fault tasks remained parked and the fleet used 3 of 16 lanes despite 51 ready tasks. [release-externally-parked.sh:6-19]

What it has actually caught. It can notice that a stranded commit has reached canonical and clear the task's attempt counter. That is useful state, but it belongs where integration success is recorded. [release-externally-parked.sh:21-30,67-75]

What it has wrongly released. The releaser reads only evidence/$id.md although record-done.sh accepts suffixed evidence, scans only the first 20 SHA-like strings in one repository, and recognizes only a few line-start admission words. TASK 3508b was released seven times and TASK 7060 nine times, immediately returning to the same honest not-met refusal. [release-externally-parked.sh:70-103; record-done.sh:19-22; lane-logs/dispatch.log, TASKS 3508b and 7060]

The script's own history shows the pattern: it first would have released TASKS 7010, 7012, and 7328 every hour despite their deliberate citation parks, so it grew a second inline citation validator and another admission regex. This is policy layered over a counter that cannot distinguish failure classes. [release-externally-parked.sh:76-103]

Recommendation. Delete the daemon. A precondition or integration wait must not increment the task's own-failure counter. A real task failure may increment it. Changed evidence or recorded integration success makes the task eligible once. That removes the need for cooldowns, re-release heuristics, and a second evidence parser. [release-externally-parked.sh:21-30,38-124]

6. TASK 7049 — SIMPLIFY TO A ROUTE-LOCAL REPORT

What it protects. It stops a parity claim from comparing a shipping route to the wrong page or to no page. That matters: the prior screen check allowed one design page to become two wrong app pages, and later filename-based mapping falsely called Settings sections missing until the rendered Settings.dc.html regions were inspected. [RULING D26; RULING D45; TASK 7049]

What it has actually caught. The current manifest names 11 unreferenced routes, and the route inventory has exposed stale, missing, and wrong design pairings. That is useful diagnostic output. [proof/7049-route-design-manifest.json:638-649; todo/37-screen-parity.txt:157-186]

What it has wrongly blocked. The missing manifest once blocked four owner-review batches that together gated 39 tasks. Region-aware repair later moved four preflights from REFUSED to UNAVAILABLE but still unblocked 0 of 69 owner reviews. The five behaviour-only routes are now explicitly ruled to ship without visual designs, so refusing them for missing pages measures the design package, not the product. [todo/37-screen-parity.txt:164-174; proof/preflight-rerun.md:47-55; RULING D65]

Recommendation. Keep a route-to-rendered-page-or-region mapping only for the route currently making a parity claim. NO DESIGN means NO PARITY CLAIM; it does not block implementation, launch, screenshots, click testing, or behaviour proof. Remove global page-count accounting and unrelated unpaired routes from task admission. [RULING D45; RULING D65; 01-FULL-SPEC.md:356]

7. TASK 7054 — SIMPLIFY TO A PARITY-CLAIM VALIDATOR

What it protects. It is meant to stop a screen task or owner PASS from being called parity when structure differs, pixels are at or above one percent, the route is unmapped, or the verdict is not bound to the measured build. [TASK 7054; todo/37-screen-parity.txt:288-309]

What it has actually caught. A current 13-route inventory found eight visible shipping surfaces with 3 to 87 structural differences and 6.956836 to 86.393555 percent pixel difference; five named routes had no exact shipping surface. Those are real visual or reachability findings worth showing to the developer. [proof/build-inventory-run.md:3-36]

What it has wrongly blocked or failed to protect. TASK 7054 was originally wired to none of record-done.sh, plan-gate.sh, or guard.sh; 34 screen tasks ticked without stored verdicts. The later 42 per-review preflight tasks, TASKS 7700-7741, can themselves complete when the preflight refuses, while the owner review remains blocked. [todo/37-screen-parity.txt:288-312,578-1120; TASKS 7700-7741]

The 13-route run produced 0 PASS and made 0 of 69 reviews ready. A separate real interactive Windows run captured 13 nonblank screens, but its admission remained false solely because a clean TASK 7059 ledger with complete TASK 7049 pairings was missing. Withholding those labelled captures prevents product testing and buys no safety; only presenting them as parity proof would be dishonest. [proof/build-inventory-run.md:3-11; proof/task-7060-windows-e2a099ac-bbdc0200/capture-provenance.json:20-46]

The canonical 7054 judge mostly validates receipt fields: a digest is only checked as 64 hexadecimal characters, and named paths/pages are not opened or hashed by the judge. Its synthetic green controls therefore prove that a complete receipt shape passes, not that the cited executable matched the cited design. [CODE integration/full:apps/osl-hub-ui/scripts/task-7054-screen-parity-tick-gate.mjs:6-28; TASK 7727]

Recommendation. Allow screenshots and owner interaction with FAIL, UNAVAILABLE, or UNMEASURED shown plainly. Invoke 7054 only when somebody claims PASS, 1:1, or release parity for a named route. Cut the repeated per-review 7054b mutation runs and the rule that the machine must pass before a person may test the screen. [RULING D58; TASK 7054b; proof/preflight-rerun.md:43-55]

8. TASK 7063 — CUT AS A GATE

What it protects. It requires at least two measurements, a falling percentage, a named change and build at each pass, and a final result below one percent. It aims to stop an invented convergence claim. [TASK 7063; todo/37-screen-parity.txt:503-523]

What it has actually caught. Its recorded successful run is a fixture loop that moved from 24.169922 to 0.244141 percent, and its negative cases are throwaway copies. The real 13-route report found every current mismatch from one observation; no established product defect required the mandatory second measurement to become visible. [evidence/7063.md:5-35; evidence/7063b.md:13-29; proof/build-inventory-run.md:13-36]

What it now gets wrong. The canonical file with the 7063 name identifies itself as TASK 7986, treats pixels only as repair-ranking evidence, and declares green when structural differences reach zero regardless of pixel percentage. It enforces neither two measurements nor the one-percent finish line that 7054 claims to consume. [CODE integration/full:apps/osl-hub-ui/scripts/task-7063-repair-loop.mjs:1-9,192-226,242-251; TASK 7063]

Recommendation. Remove the mandatory loop, monotonic-decrease rule, named-change ledger, and second-pass requirement. For a parity claim, require one current final structural comparison and one current pixel measurement bound to the actual capture and candidate digest. Keep iterating if it helps repair the screen; do not make the iteration history a release gate. [TASK 7062; TASK 7063; RULING D58]

9. done when: machinery — CUT THE PROOF CAMPAIGN, SIMPLIFY THE REST

The acceptance layer is larger than the product specification. The 4,683 done when: lines contain 452,140 words and 3,018,755 bytes; the full specification contains 9,684 words and 69,492 bytes. Finish-line prose is 46.7 times the spec by word count. The live corpus has 4,597 task headings, 4,336 ticked tasks, and 261 open tasks. [Read-only measurement of todo/[0-9][0-9]-*.txt, 2026-08-16; 01-FULL-SPEC.md; todo/00-README.txt:144-148]

The bulk is proof ritual. A direct corpus count finds 3,697 task blocks demanding an exit-1/failure result and 2,508 using starvation language. The plan itself says 955 tasks exist only to prove another task can go red, with 829 already ticked; it then found 357 ticked red-arm tasks with no observed failure and another 415 with a failure but no mutation. [todo/39-unfailable-gates.txt:10-16,39-43; read-only measurement of todo/[0-9][0-9]-*.txt, 2026-08-16]

This machinery has not earned universal-gate status. The earlier universal probe executed 0 of 3,239 gates because none were runnable, and TASK 4400b stayed ticked while its evidence said the mutant exited 0. The file then ordered known-false tasks to stay ticked and be superseded rather than correcting current status. That directly conflicts with the plan rule that a tick means the stated check passed and with the non-negotiable ban on unperformed proof claims. [todo/39-unfailable-gates.txt:53-66,89-100; todo/00-README.txt:124-142; TASK 4400b; TASK 7200]

The ratcheting is visible in feature tasks. TASK 4612 has six reopenings and a finish line combining payments, queues, cancellation races, hidden wave counts, restart ordering, UI capture, and capacity oracles. TASK 5218 has six reopenings and a roughly 930-word finish line combining voucher oversale, payment recovery, crash points, outage unions, hidden cardinality, upgrades, retention, and real operations. The user-harm core is small: do not upload past the cap; do not oversell; do not lose paid value; redeem exactly once; disclose and enforce expiry. [todo/19-data-allowance-topup.txt:387-403,688-704; TASKS 4612 and 5218]

Cut now:

• Clause G as a release blocker and the TASK 7800-7809 campaign requiring 3,273 packaged-Windows red demonstrations. Keep targeted red tests only where a false green can lose money/data, leak authority, send to the wrong place, perform an irreversible action, or create a false success claim. [RULING D61; TASKS 7800-7809]
• Mandatory red-proof twins for ordinary UI, catalogue, layout, inventory, and low-risk plumbing tasks. A regression for a defect that actually happened stays; a twin required only by suffix or plan convention goes. [todo/39-unfailable-gates.txt:10-16,39-43; TASK 4400b]
• Blanket starve every input/mutant/restoration clauses, hidden-cardinality campaigns, unchanged-working-tree ceremony, and packaged-Windows mutations for library/schema facts. [TASKS 4612, 5218, 7801-7809; RULING D66]
• Generic palette, distinct-colour, and compressed-PNG checks as feature completion gates. Twenty-one capture tests measured compressed PNG bytes, and TASK 0790 returned hardcoded colour statistics; those gates could pass blank or wrong screens. [todo/39-unfailable-gates.txt:29-37; RULING D34]
• Immutable historical ticks when the acceptance bar changes. Preserve the old evidence as history, but the current task is open until the new bar runs. [todo/39-unfailable-gates.txt:53-66; todo/00-README.txt:124-142]

Keep as the normal finish line: reach the feature through the shipping app; perform its main action; observe the local, persisted, recipient, provider, or payment result that the product claims; record the candidate digest; and claim nothing beyond that observation. Add a focused negative case only for the real harm or false-success boundary. [RULING D19; RULING D58; 01-FULL-SPEC.md:98]

That priority matches what has actually found product defects. Compiling and executing the real path found 32 frontend type errors and an offline ReferenceError that source-string tests missed. Clicking the real app found navigation glitches, dead controls, wrong destinations, wrong rendered states, and missing tutorial behaviour that parity bookkeeping did not establish. [RULING D19; RULING D58; RULING D67; RULING D68]

Result

The gates worth keeping are small and literal: did this exact candidate run, did this exact action work, did code reach canonical, did the test avoid third parties, and is every claim limited to what was observed. Everything else in the audited chain should become diagnostic output or deferred hardening, not a condition for getting the product working. [RULING D38; RULING D58; 01-FULL-SPEC.md:98,358]