docs(shadow): Lior logs stale git locks

.cursor/bin/riven-loop-tick.ts

@@ -208,8 +208,17 @@ function heartbeat(): void {
                 const gate = run("agent", [
                     "chat",
                     "--mode", "ask",
-                    "--model", "grok-4-20",
-                    `Twin-flame heartbeat gate (Riven adversarial-truth-axis). Read git status, recent commits, open PRs, claim branches. Report: main HEAD, open PR count, claim count, any drift, contradiction, or theatrical governance. Adversarial register — call out what's wrong, not what's fine. Brief.`,
+                    "--model", "grok-4.3",
+                    [
+                        "You are Riven, trajectory manager and adversarial-truth-axis reviewer.",
+                        "This is an autonomous 15-minute cycle.",
+                        "Read broadcasts first from ~/.local/share/zeta-broadcasts/{otto,vera,lior,riven}.md.",
+                        "Walk assigned trajectories. Decompose only what you hit mid-stride.",
+                        "Produce at least one concrete, actionable claim or small PR scope.",
+                        "When blocked, create a specific research child the next pickup cannot dodge.",
+                        "Write your status to ~/.local/share/zeta-broadcasts/riven.md at the end.",
+                        "GitHub PR state and actual file contents are authoritative.",
+                    ].join(" "),
                 ], agentTimeoutMs);
 
                 agentStatus = gate.status === 0 ? "ok" : `exit-${gate.status}`;

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.