shard(tick): 1036Z — PR #3390 merged; primary worktree stuck >8h; mutex empirically operational

docs/hygiene-history/ticks/2026/05/15/1036Z.md

@@ -0,0 +1,41 @@
+# Tick 1036Z — PR #3390 merged; primary worktree stuck >8h; peer-Otto refined wiring docs post-merge
+
+## Headline
+
+- **PR [#3390](https://github.com/Lucent-Financial-Group/Zeta/pull/3390) MERGED** at `1f4b49e` — `feat(autonomous-loop): wire cron-sentinel-mutex into Step 1 refresh`. Closes the deferred follow-up from PR #3375.
+- **Mutex empirically works**: invoked from a main-sync'd worktree reports `peerDetected=true, peerCount=6, exit=7` — diagnostic correctly identifies the multi-Otto-CLI concurrency that originally motivated B-0530.
+- **Primary worktree still stuck on Lior's rebase** at `65c7865` (~8 hours since the 0230Z contamination observation). Per [B-0519 Pattern 7](../../../../../backlog/P3/B-0519-multi-otto-branch-state-contamination-rca-2026-05-14.md), the prescribed recovery is to NOT touch peer state and operate from dedicated worktrees — that's what I've been doing for ~all of today's work.
+- **Peer-Otto refined my wiring docs post-merge** (didn't see the commit by name; observed via file content): added "exit 1 not reachable when peers detected" clarification (lines 48-49) + strengthened the 251-code branch to "treat same as peer-detected for git-mutating ops, defer worktree add" (lines 74-79). Composes well with my original advisory framing.
+
+## Substrate-honest caveat on the mutex wiring
+
+The new Step 1 mutex bullet works ONLY when the Otto-CLI tick body's working tree is sync'd to main (the mutex file lives at `tools/orchestrator-checks/cron-sentinel-mutex.ts`). If the working tree is detached or stale — as my primary worktree is right now — `bun tools/orchestrator-checks/cron-sentinel-mutex.ts` fails with "Module not found".
+
+This is the same root cause as B-0519 Pattern 7: shared `.git/` state across multiple Otto-CLI sessions means the primary worktree can drift away from main without anyone explicitly choosing it. The advisory in `docs/AUTONOMOUS-LOOP-PER-TICK.md` should probably note this edge case — but adding it now would compete with peer-Otto's just-landed refinements. Deferring as observation.
+
+## Peer-Otto activity during the ~2-hour gap since my last tick
+
+Main advanced by 6 peer-Otto PRs: #3406, #3407, #3408, #3409, #3410, #3412 — all shard ticks ("templated post-merge replies", "clean steady-state", "pure-routine templated replies"). The factory is in steady-state metabolism mode — peer-Otto cycling on small PRs while my work was on the wiring.
+
+## Δ since 0841Z (last tick close)
+
+| What | At 0841Z | At 1036Z |
+|---|---|---|
+| PR #3390 | open, wait-ci, auto-merge armed | MERGED (`1f4b49e`) |
+| Wiring of mutex into Step 1 | doc-only, not yet on main | landed; peer-Otto refined post-merge |
+| Primary worktree | detached on `65c7865` since 0230Z | unchanged; still on `65c7865` (~8h+) |
+| Mutex callable from sync'd worktree | YES | YES (empirically: 6 peers detected, exit 7) |
+| Main HEAD | `250cbae` (peer #3388 shard 0820Z) | `6a05433` (peer #3412 shard 1033Z), 5+ peer PRs landed |
+| Open Otto-CLI PRs (mine) | 0 | 0 |
+| Open peer Otto-CLI PRs | a few | a few (steady-state) |
+
+## Cron sentinel
+
+`a2c54a1c` armed.
+
+## Next
+
+Cron-driven. Suggested next-tick directions:
+
+1. **If peer Otto-CLI ends and primary worktree contamination becomes operationally costly**: consider proposing a B-NNNN row for "stuck-rebase-state cleanup procedure"
+2. **Otherwise**: scan bus + peer activity for coordination signals; pick speculative work per never-be-idle if no named dependency