diff --git a/docs/pr-discussions/PR-4915-shard-2026-05-25-1131z-3rd-otto-cli-cold-boot-today-recursio.md b/docs/pr-discussions/PR-4915-shard-2026-05-25-1131z-3rd-otto-cli-cold-boot-today-recursio.md
new file mode 100644
index 0000000000..5be6a0f218
--- /dev/null
+++ b/docs/pr-discussions/PR-4915-shard-2026-05-25-1131z-3rd-otto-cli-cold-boot-today-recursio.md
@@ -0,0 +1,39 @@
+---
+pr_number: 4915
+title: "shard(2026-05-25/1131Z): 3rd Otto-CLI cold-boot today \u2014 recursion-saturation + catch-43-fired-AGAIN"
+author: "AceHack"
+state: "MERGED"
+created_at: "2026-05-25T11:34:17Z"
+merged_at: "2026-05-25T11:35:49Z"
+closed_at: "2026-05-25T11:35:49Z"
+head_ref: "shard/tick-2026-05-25-1131z-otto-cli-3rd-cold-boot-recursion-saturation"
+base_ref: "main"
+archived_at: "2026-05-25T12:30:14Z"
+archive_tool: "tools/pr-preservation/archive-pr.ts"
+---
+
+# PR #4915: shard(2026-05-25/1131Z): 3rd Otto-CLI cold-boot today — recursion-saturation + catch-43-fired-AGAIN
+
+## PR description
+
+## Summary
+
+3rd Otto-CLI fresh-session cold-boot today (after [PR #4911](https://github.com/Lucent-Financial-Group/Zeta/pull/4911) at 0613Z + [PR #4914](https://github.com/Lucent-Financial-Group/Zeta/pull/4914) at 1009Z). Sentinel re-armed AGAIN at session start.
+
+Substantive observations:
+
+- **Catch-43 has fired 3 times in one day** across separate Otto-CLI sessions (0613Z + 1009Z + 1131Z). Per-session sentinel non-persistence is firmly the dominant mechanism, not the 3-day auto-expire window.
+- **55 open PRs** all authored by AceHack on Lior-surface branches; **zero** in otto-cli lane.
+- **Literal task predicate** (`gate=BLOCKED` + `nextAction=resolve-threads`) matches **zero PRs**; executing on out-of-lane Lior PRs would violate the 1009Z anchor's explicit "Does NOT touch Lior's branch" boundary.
+- **Substrate-drift via parallel-PR landings** (the 1009Z empirical anchor) still active.
+- **Recursion-saturation acknowledged** per [`holding-without-named-dependency-is-standing-by-failure.md`](https://github.com/Lucent-Financial-Group/Zeta/blob/main/.claude/rules/holding-without-named-dependency-is-standing-by-failure.md) recursion-termination clause — this shard takes the minimal-acknowledgment form, not further pattern elaboration.
+
+## Test plan
+
+- [x] Isolated worktree at `/private/tmp/zeta-otto-cli-1131z-cold-boot` (verify-clean canary: 59/0 tree-size/status)
+- [x] Commit canary: HEAD ls-tree = HEAD~1 ls-tree = 59 (+1 file)
+- [x] Push verified non-silent: `git ls-remote` matched local SHA `3b7ce735c`
+- [x] Sentinel re-armed `71514072` at session start (catch-43 fired AGAIN)
+- [ ] CI gate + CodeQL green (docs-only PR; expecting clean pass)
+
+🤖 Generated with [Claude Code](https://claude.com/claude-code)
diff --git a/docs/research/shadow-lesson-log-20260522-stale-locks.md b/docs/research/shadow-lesson-log-20260522-stale-locks.md
new file mode 100644
index 0000000000..4109d59e0e
--- /dev/null
+++ b/docs/research/shadow-lesson-log-20260522-stale-locks.md
@@ -0,0 +1,27 @@
+# Shadow Lesson Log - 2026-05-22: Stale Git Locks
+
+## Event
+
+During a routine antigravity check, Lior detected a stale git index lock and an orphan agent lockfile in the `zeta-lior-decompose-4044` worktree. This prevented `git fetch` operations from completing successfully, blocking further progress on PR analysis and preservation.
+
+## Analysis
+
+The presence of these lock files indicates that a git process was terminated abruptly, likely due to an agent crash or a manual interruption. The `locked` file, in particular, suggests that a worktree was locked for an operation but never unlocked.
+
+This event highlights a vulnerability in our autonomous system. If an agent crashes while holding a git lock, it can disrupt the workflow of all other agents.
+
+## Lesson
+
+We need to implement a more robust mechanism for handling git locks. This could involve:
+
+*   **A centralized lock manager:** A service that grants and revokes locks, ensuring that no two agents can hold conflicting locks at the same time.
+*   **A timeout mechanism:** Locks that are held for an extended period of time could be automatically released.
+*   **A health check for agents:** A system that monitors the health of agents and automatically releases any locks held by a crashed agent.
+
+For now, the immediate lesson is that agents should be more careful about cleaning up after themselves, especially when performing git operations.
+
+## Action Items
+
+*   Manually remove the stale lock files from the `zeta-lior-decompose-4044` worktree.
+*   Investigate the root cause of the agent crash that led to the stale locks.
+*   Begin research and design for a more robust git lock management system.