Infinite drift-detection loop on out-of-intent-dir output file (operations/fnox.toml)

[jwaldrip]

Summary

In autopilot mode, the operations stage gets stuck in an infinite drift_detected loop on terraform/environments/ops/fnox.toml (an output declared by unit-05-ops-secrets-provisioning). The witnessed approval sha matches the live file exactly, the working tree is clean, and the file's mtime is older than the witness time — but every haiku_run_next tick re-emits the drift event with a freshly-incremented since timestamp. There is no agent-side recovery path.

• Engine version: haiku-method 8.0.0
• Studio: software, Stage: operations, Unit: unit-05-ops-secrets-provisioning
• Mode: autopilot, Schema: v8
• Intent slug: twelve-week-plan-accountability-app

Reproduction state

unit-05 FM:
  approvals.spec.witnesses['terraform/environments/ops/fnox.toml']
    = e89e8fde2904e90794a030e5e84d1bdecc7efca2d1ad4c7b5be7c9ecc09d6af4

$ shasum -a 256 terraform/environments/ops/fnox.toml
e89e8fde2904e90794a030e5e84d1bdecc7efca2d1ad4c7b5be7c9ecc09d6af4

$ git status terraform/environments/ops/fnox.toml
nothing to commit, working tree clean

$ stat -f '%Sm' -t '%FT%TZ' terraform/environments/ops/fnox.toml
2026-05-13T02:25:12Z

drift_detected.since = 2026-05-16T06:17:43.393Z   ← also = approvals.spec.at

The drift event fires after every tick:

{
  "kind": "drift_detected",
  "events": [{
    "unit": "unit-05-ops-secrets-provisioning",
    "role": "spec",
    "kind": "output",
    "file": "terraform/environments/ops/fnox.toml",
    "since": "2026-05-16T06:17:43.393Z"
  }]
}

Attempted recoveries (all failed)

1. File drift FB and close as cosmetic with empty `target_invalidates`. Full fix_hats chain (classifier → ops-engineer → feedback-assessor) ran cleanly; FB closed. Next tick fired the same drift event with a new `since`. Repeated twice (FB-002, FB-003) — same loop.
2. `haiku_baseline_init { mode: "establish-paths", paths: ["terraform/environments/ops/fnox.toml"] }` → `baselines_created: 0` (the file is outside the intent directory, so it isn't picked up).
3. `haiku_baseline_init { mode: "establish-all" }` → 157 baselines created, all under `.haiku/intents//`. `fnox.toml` not included. Drift still fires.
4. `haiku_debug { op: "reset_drift" }` and `{ op: "reset_drift", stage: "operations" }` → both returned `"cancelled — no state mutated."` The SPA-picker confirmation isn't reachable from a Claude Code CLI session.
5. Manually staging the witnessed sha's content into `.haiku/intents//baseline-content/` (using the live file's own bytes, since the sha matches) → no effect.

Why this hits autopilot hard

In autopilot the loop drives itself. This single drift event blocks all downstream work indefinitely with no agent-side break-out. After ~30 FB cycles successfully closed the design stage, development unit-22 (Cucumber tests, 464 scenarios pass), and operations units 06/07, the entire pipeline parks here.

Suggested fixes

1. Drift sweep should short-circuit when the output witness sha matches the live file sha regardless of `since` timestamps. The file demonstrably hasn't changed.
2. `haiku_debug reset_drift` needs a non-elicitation path (e.g. `confirm: true` arg, or honoring `HAIKU_DEBUG_AUTO_CONFIRM=1`) for sessions where the SPA picker isn't available.
3. `haiku_baseline_init { mode: "establish-paths" }` should accept workspace-relative paths for outputs that legitimately live outside the intent directory (terraform envs, ops configs, etc.) and stamp witnesses against the workspace location.

Run context

• Long-running autopilot session. Pre-cursor sync conflicts had been resolved manually on both `haiku//main` and `haiku//design` earlier in the run — possibly relevant if the drift baseline got snapshotted across a merge that didn't actually change `fnox.toml` content.
• Mode was switched mid-flight from `continuous` → `autopilot` via `/haiku:change-mode`.

Session bundle (main + 76 subagent transcripts + tool-results, ~9.4 MB) is available locally — happy to attach a redacted excerpt if useful.

Filed via `haiku_report` already; opening as a GitHub issue for tracking.