Record terminal TFTMAC incremental sweep

.clara/plans/25f21f7e-ba86-4e3d-832d-9984522811c0/AMENDMENT_001_CONTINUOUS_4H.md

@@ -0,0 +1,40 @@
+# Amendment 001 — Continuous Four-Hour Tail
+
+## Why this amendment exists
+The approved candidate queue can finish before the exact four-hour campaign deadline. The current runner exits immediately when the queue is exhausted. That does not satisfy the requested continuous four-hour evidence window.
+
+## Scope change
+After the candidate queue is exhausted, do **not** invent or admit another tuning candidate. Repeatedly execute a `stability-control` run using the exact current campaign working profile and the existing matched native workload until the deadline prevents admission of the next run.
+
+A stability-control run:
+- changes no CVar and cannot promote a candidate;
+- uses the current working-profile bytes unchanged;
+- uses the same DEV app, StockShadow runtime, Tocker navigation, native SurfaceFlinger/SQLite evidence, and rollback path already approved;
+- records run/capture/profile identity, metrics, result classification, and rollback evidence in campaign state/report;
+- stops the campaign immediately if runtime identity, telemetry, correctness, or rollback is not green.
+
+Deadline rule: check the monotonic deadline before each new stability-control admission. A run already admitted before the deadline may finish and must complete rollback/evidence sealing; no subsequent run may start after the deadline.
+
+## Complexity Economics Gate
+PASS. The smallest correct mechanism is one bounded tail loop in `OvernightLab/incremental_lab.py` reusing `run_profile()` with a synthetic no-mutation stability specification. No new runtime, scheduler, service, VM, AVD, profiler, store, or mutation state machine is introduced.
+
+## ZenGate
+PASS. ZenMC V2 completed with 100,000 trajectories, zero invariant violations, result `PASS`, receipt `857b5abdff538ca5903473a9ca7c7e58fdccd0dab39eacae96ba24de93b7300e`. This amendment changes only queue-exhaustion behavior. All original protected boundaries, one-factor candidate rules, rollback gates, evidence rules, and final delivery requirements remain unchanged.
+
+## ZenMC V2 qualification
+ZENMC_REQUIRED because the amendment changes deadline, recovery, rollback, and repeated asynchronous run transitions. Model identity: `TFTMAC_INCREMENTAL_4H_LIFECYCLE_V2`.
+
+Required invariants:
+1. Frozen LKG is never mutated.
+2. No tuning candidate is admitted after candidate-queue exhaustion.
+3. Every post-queue run is `stability-control` on the current working-profile identity.
+4. Any rollback failure terminates future run admission.
+5. Deadline prevents admission of the next candidate or stability run.
+6. Candidate promotion still requires positive confirmation.
+7. A run admitted before deadline may finish, but must seal evidence and rollback before terminal campaign state.
+
+## Source delta authorized after V2 PASS + checkpoint
+- Add the stability-control tail loop and state/report ledger fields only.
+- Extend offline self-test to prove the tail-loop policy is enabled without executing the emulator.
+- Re-run governed validation and live-install hash-parity/self-test.
+- Then start the durable four-hour campaign exactly as the approved plan requires.

.clara/plans/25f21f7e-ba86-4e3d-832d-9984522811c0/AMENDMENT_002_CLASSIFIER_BLOCKER.md

@@ -0,0 +1,42 @@
+# Amendment 002 — Blocking Classifier False Positive + Truthful Control Terminal State
+
+## Discovery classification
+`BLOCKING DEPENDENCY` discovered by the first live control of campaign `incremental-20260911T082151Z-1f32770a`.
+
+The control reached real Tocker battle stages 1-1 and 1-2, then the screen classifier labeled the normal stage-1-3 shop frame as `error_reject_marker`. Independent Vision OCR of the saved frame contained no `ERROR`, `FAILED`, `UNAVAILABLE`, `DECLINED READY CHECK`, or `RETURNED TO THE LOBBY` text.
+
+Debugging the existing classifier proved the exact root cause. `EvidenceMatcher.has()` concatenates every OCR line into `compactCorpus` to permit phrases split across OCR lines. On the saved normal frame, three independent OCR lines `Brawler`, `r`, and `Ornn` concatenate to `BRAWLERRORNN`, which contains the synthetic substring `ERROR`. The current generic `matcher.has("ERROR")` therefore creates a false fail-closed state from cross-line text that never existed on screen.
+
+A second in-scope bookkeeping defect was exposed at the same time: the run's rollback receipt proves DEV stopped, emulator stopped, profile restored, installed DEV integrity true, frozen LKG integrity true, and `verified=true`, but `incremental_lab.py` sets campaign-level `rollback_verified=false` merely because the control classification is `INCONCLUSIVE`. It then labels the early pre-deadline stop `DEADLINE_COMPLETE`. Both statements are factually false.
+
+## Smallest authorized repair
+1. Keep cross-line `EvidenceMatcher.has()` unchanged for existing phrase matching.
+2. Add a line-local matcher and use it only for the strong error markers plus `ERROR`. Error rejection may match inside one OCR line, but never by concatenating unrelated OCR lines.
+3. Add a regression self-test reproducing the exact `Brawler` + `r` + `Ornn` boundary so it cannot synthesize `ERROR` again.
+4. In `incremental_lab.py`, derive campaign rollback truth from the actual run rollback receipt, never from `INCONCLUSIVE` classification alone.
+5. If a control is not green before the deadline but rollback is proven, stop that attempt as `BLOCKED_INCONCLUSIVE` with the exact blocker instead of falsely claiming deadline completion. Keep queue index unchanged.
+6. On a governed resume after the blocking dependency is repaired, clear only the transient blocker marker, reconcile actual runtime/rollback through the existing resume path, and reattempt the same current control before the original deadline. Do not erase the prior run or its evidence.
+7. Preserve the original campaign deadline. Recovery downtime is an interruption/recovery interval; do not create a second overlapping campaign.
+
+## Complexity Economics Gate
+PASS. This is one matcher method, one targeted call-site change, one regression test, and truthful state bookkeeping in the existing runner. No new classifier, OCR framework, retry service, scheduler, runtime, or recovery subsystem is added.
+
+## ZenGate
+PASS. ZenMC V3 completed with 100,000 trajectories, zero invariant violations, result `PASS`, receipt `052d36aeda6fc63d8a67b07e312166c1e4106e246be5485fa856c76d9573ea30`. The repair is limited to the proven blocker and the false completion/rollback statements it exposed. No tuning candidate, game setting, runtime identity, protected Control/LKG boundary, or comparison doctrine changes.
+
+## ZenMC V3 qualification
+ZENMC_REQUIRED because the repair changes blocked/resume/completion semantics in the four-hour lifecycle.
+
+Required invariants:
+- unrelated OCR lines can never synthesize a strong error marker;
+- a non-green control never advances the candidate queue;
+- `INCONCLUSIVE` does not imply rollback failure;
+- actual rollback failure still blocks all future run admission;
+- a verified-rollback blocked control may resume the same queue index before the original deadline after the blocker is repaired;
+- deadline still prevents admission of the next run;
+- frozen LKG remains immutable;
+- candidate promotion still requires positive confirmation;
+- post-queue stability controls remain no-mutation working-profile runs only.
+
+## Resume target after repair
+Resume `incremental-20260911T082151Z-1f32770a` from queue index 0 under its original deadline after source validation, live classifier/runner install, classifier regression proof against `state-0051-error.png`, and protected-state verification.

.clara/plans/25f21f7e-ba86-4e3d-832d-9984522811c0/AMENDMENT_003_DURABLE_DEADLINE.md

@@ -0,0 +1,49 @@
+# Amendment 003 — Durable Four-Hour Deadline Across Host-Operation Resume
+
+## Discovery classification
+`BLOCKING DEPENDENCY` discovered during the first governed resume of campaign `incremental-20260911T082151Z-1f32770a`.
+
+The runner persisted `deadline_monotonic_ns`. The original campaign process stored `14400097332625`, while the next Clara host-operation process observed a current monotonic value near `49626079892666`. The resulting resume calculation falsely reported zero seconds remaining even though the durable wall-clock campaign start was `2026-09-11T08:21:51Z` and the approved four-hour deadline is therefore `2026-09-11T12:21:51Z`.
+
+A process-local monotonic origin is valid only within one process/clock namespace. It is not a durable checkpoint value across Clara host-operation recovery. Persisting it violated the plan's restart/recovery requirement and could truncate the four-hour campaign without running the queue.
+
+## Smallest authorized repair
+1. Persist the campaign deadline as an absolute UTC timestamp (`deadline_utc`) derived once when the campaign is created.
+2. Persist `duration_seconds` for provenance.
+3. Use UTC comparison for all candidate admission, confirmation admission, stability-control admission, and final deadline classification.
+4. Never reconstruct an absent durable deadline from a fresh process-local monotonic value.
+5. For a legacy/in-progress campaign missing `deadline_utc`, fail closed with `CAMPAIGN_DEADLINE_MIGRATION_REQUIRED` until an exact evidence-backed one-time state migration provides it.
+6. Migrate the current campaign only from its already-persisted `started_utc=2026-09-11T08:21:51Z` plus the user-approved `4h` duration, yielding `deadline_utc=2026-09-11T12:21:51Z`. Preserve the old monotonic value under a forensic legacy field rather than treating it as authority.
+7. Resume the same campaign ID and queue index. Do not create a replacement campaign, do not discard the prior false-classifier run, and do not extend the deadline to compensate for repair time.
+
+## Complexity Economics Gate
+PASS. The canonical durable value is one absolute UTC deadline already supported by Python's standard library. No scheduler, timer service, clock daemon, lease, or new persistence subsystem is required.
+
+## ZenGate
+PASS. ZenMC V4 completed with 100,000 trajectories, zero invariant violations, result `PASS`, receipt `77576f5db814d315d11a8af9992340a778f416239780182dc46fea4646440766`. This amendment changes only the persisted deadline representation and admission checks required for restart-safe execution. Candidate semantics, measurement workload, promotion logic, protected Control/LKG boundaries, and the four-hour wall-clock duration are unchanged.
+
+## ZenMC V4 qualification
+ZENMC_REQUIRED because the defect is specifically in restart/recovery and deadline transitions.
+
+Required invariants:
+- one campaign has one immutable absolute UTC deadline;
+- restart/host-operation changes never reset or extend that deadline;
+- legacy state without a durable deadline fails closed until explicit evidence-backed migration;
+- current campaign migration equals `started_utc + 14400 seconds` exactly;
+- no candidate/confirmation/stability run is admitted at or after `deadline_utc`;
+- a run admitted before the deadline may finish and must seal rollback/evidence before terminal state;
+- queue index and accepted stack survive restart unchanged;
+- rollback failure still stops all future admissions;
+- frozen LKG remains immutable;
+- post-queue runs remain stability-control only.
+
+## Current campaign migration authority
+Campaign: `incremental-20260911T082151Z-1f32770a`
+
+Persisted start: `2026-09-11T08:21:51Z`
+
+Approved duration: `14400` seconds (4 hours)
+
+Exact durable deadline: `2026-09-11T12:21:51Z`
+
+The migration may occur only after the currently-running old resume process is terminal and the repaired source is validated/installed, so no two processes can race on campaign state.

.clara/plans/25f21f7e-ba86-4e3d-832d-9984522811c0/AMENDMENT_004_STAGE15_PHASE.md

@@ -0,0 +1,53 @@
+# Amendment 004 — Tocker 1-5 phase classification blocker
+
+## Classification
+
+BLOCKING DEPENDENCY discovered by the live governed campaign. This amendment does not admit a new optimization candidate or widen the performance experiment. It repairs the existing screen-classifier semantics required to reach the already-approved 1-5 measurement gate.
+
+## Current evidence
+
+Campaign `incremental-20260911T082151Z-1f32770a` remains at queue index 0 with no accepted performance candidate and verified rollback.
+
+Latest control `run-747b11debe5a47a09dc96a24abdc8213` reached Tocker stage 1-5 and remained there until the navigation watchdog expired. The final screenshot is a normal battle HUD with OCR including stage `1-5`, `Score`, score value `36,550`, traits, gold, and board occupancy. It contains no reject/error/login marker. The classifier returns `state=battle`, `stage=1-5`, but `phase=null` because the stage-1-5 combat presentation does not expose the cyan combat timer or a literal `COMBAT` marker.
+
+A read-only audit of all 371 current-campaign battle classifications found:
+- 315 phase-null rows: `SCORE`, no shop, no FIGHT.
+- 46 known combat rows: `SCORE`, no shop; 12 also expose FIGHT late in combat.
+- 2 known planning rows with SCORE both expose FIGHT.
+- 6 known planning rows without SCORE expose shop/planning controls.
+- 1 observed post-combat SCORE row exposes shop/reward state and is already recognized through the `TIME BONUS` path.
+
+Therefore `SCORE` alone is not a legal new phase signal. The admissible missing semantic is: a battle frame with SCORE after existing explicit combat/planning/post-combat checks, where no shop is open and no FIGHT control is visible.
+
+## Purified repair
+
+1. Compute `shopOpen` and `fightButtonVisible` before `battlePhase` is called.
+2. Pass those two already-existing observed UI facts into `battlePhase`.
+3. Preserve precedence exactly:
+   - explicit `COMBAT` / cyan timer -> combat;
+   - explicit PLANNING/PREPARE/FIGHT/REROLL -> planning;
+   - TIME BONUS -> post_combat;
+   - only then, if battle HUD contains line-local SCORE and both `shopOpen == false` and `fightButtonVisible == false`, classify combat.
+4. Keep all reject/login/disconnect/trial-choice classification behavior unchanged.
+5. Add self-test fixtures proving:
+   - SCORE + no shop + no FIGHT -> combat;
+   - SCORE + FIGHT -> planning;
+   - TIME BONUS remains post_combat.
+6. Replay the exact failed 1-5 screenshot and require `state=battle`, `stage=1-5`, `phase=combat`.
+7. Production validate, checkpoint/publish, install the classifier through the existing OvernightLab install seam, prove source/live parity, then resume the same campaign at queue index 0 and immutable deadline `2026-09-11T12:21:51Z`.
+
+## Non-goals
+
+- No candidate/CVar change.
+- No new workload.
+- No timeout increase.
+- No blind click.
+- No Control/LKG mutation.
+- No app/emulator/AVD rebuild.
+- No change to promotion thresholds.
+
+## ZenGate
+
+PASS. ZenMC V5 (`TFTMAC_INCREMENTAL_4H_LIFECYCLE_V5_STAGE15_PHASE`) completed 100,000 trajectories with zero invariant violations. Receipt SHA-256: `d5731f249d5921d102216af7324e8ee72b02b4491e3e0db0ba21a647a1588d5a`.
+
+The simplest safe mechanism is extending the existing classifier with two already-computed UI facts; no new state machine, service, store, or instrumentation is required.