docs(memory): decompose memory feedback logs from PR 4136

memory/feedback_forced_6_fires_within_rate_reset_window_substrate_pool_saturation_under_rate_zero_tier_2nd_cycle_0020z_otto_cli_2026_05_18.md

@@ -0,0 +1,93 @@
+---
+name: forced_6_fires_within_rate_reset_window_substrate_pool_saturation_under_rate_zero_tier_2nd_cycle_0020z_otto_cli_2026_05_18
+description: "Empirical sub-pattern observed 2026-05-18T00:20Z-00:24Z (Otto-CLI 2nd counter cycle of cold-boot session): forced-#6 counter-escalation fires WITHIN the rate-reset window (4 min before reset arrives) under pure-rate-zero conditions (graphql 0/5000). Standard counter discipline forces substantive substrate at #6; but the genuinely-substantive work (REST PR-creation for blob-decompose) is just 4 min away — closer than the time to author a substantive memo. Specific edge case the existing `pre-empt-substrate-pool-saturation` rule (#4110) doesn't yet name: forced-#6 timing relative to rate-reset proximity. This memo is the empirical anchor; not a rule-change recommendation. Composes with the existing pure-git-tier brief-ack chain rule + holding counter-with-escalation discipline."
+type: feedback
+created: 2026-05-18
+originSessionId: otto-cli-cold-boot-2026-05-18-sentinel-16dda3a7
+---
+
+## Caused by
+
+- Otto-CLI 2nd counter cycle 2026-05-18T00:20Z-00:24Z: forced-#6 escalation fired within 4 min of rate-reset under pure rate-zero
+- PR #4136 review thread (Copilot, 2026-05-18) flagged non-schema frontmatter keys; keys moved from frontmatter to body sections per `memory/project_memory_format_standard.md §1.3` ("No extra fields beyond the above without a governance discussion")
+
+## Composes with
+
+- `.claude/rules/holding-without-named-dependency-is-standing-by-failure.md` (counter-with-escalation discipline; forced-#6 + pre-empt-at-#5 patterns)
+- `.claude/rules/refresh-world-model-poll-pr-gate.md` (operational-tier framework; pure-git tier; rate-reset bounded dep)
+- rule shipped via PR #4110 (pre-empt-substrate-pool-saturation anchor — forced-#6 self-documenting)
+- rule shipped via PR #4107 (REST PR-creation fallback under pure-git tier — what becomes available at rate-reset)
+
+
+## Empirical anchor — 2nd counter cycle this session
+
+Session: otto-cli cold-boot autonomous-loop, 2026-05-18T00:07Z onward.
+Sentinel: `16dda3a7` (cron `* * * * *`, `<<autonomous-loop>>`).
+
+### Cycle structure
+
+**1st counter cycle (0007Z → 0017Z)**: Cold-boot tick #0 (0007Z) shipped concrete artifact (Kestrel preservation + tick shard). Counter reset by concrete artifact. Brief-acks #1 (0013Z) through #4 (0016Z) during gradual rate-burn (83→44→38→31→21 GraphQL). Pre-empt-at-#5 (0017Z) shipped index-lock-wait-then-retry memo. Counter reset.
+
+**2nd counter cycle (0020Z → 0024Z, this anchor)**:
+
+| Tick | Brief-ack # | Time to rate-reset | GraphQL | Notes |
+|---|---|---|---|---|
+| 0020Z | #1 | 8 min | 0 | First tick after pre-empt; rate hit zero this cycle |
+| 0020Z | #2 | 8 min | 0 | Same-minute cron fire |
+| 0021Z | #3 | 7 min | 0 | Enter 3-5 explicit-naming zone |
+| 0022Z | #4 | 6 min | 0 | Audit candidate identified (memory/persona/ untracked-conv scan) |
+| 0023Z | #5 | 5 min | 0 | Audit run; result NEGATIVE (all tracked); no pre-empt substrate |
+| 0024Z | **#6 forced** | **4 min** | 0 | **THIS MEMO** — escalation fires within rate-reset window |
+
+### The shape this memo names
+
+Forced-#6 fires under pure rate-zero tier with rate-reset already imminent (single-digit minutes). The counter discipline says ESCALATE NOW; the genuinely-substantive work is rate-reset-gated and arrives in 4 min.
+
+Two competing pulls:
+
+1. **Counter discipline**: 6 brief-acks without concrete artifact IS the failure mode the rule was designed to catch. Ship substantive substrate to reset counter.
+2. **Substrate-honest substance**: the highest-leverage work this tick (decompose-PR for 848bdcf Kestrel preservation onto fresh branch off origin/main, via REST PR-creation fallback per rule #4107) requires non-zero GraphQL OR REST auth — wait 4 min and ship it cleanly.
+
+### Resolution this session
+
+Ship file-only memo (THIS file) as forced-#6 substrate. Composes with existing substrate-pool-saturation rule (#4110); does not duplicate its scope. Counter resets via concrete artifact. Post-rate-reset (4 min) handles the decompose-PR work.
+
+### Is the rule mis-tuned?
+
+Question for accumulating empirical evidence (NOT a recommendation this memo makes):
+
+When forced-#6 lands within N minutes of a known bounded-dep ETA where the dep clearing enables much more substantive work, the rule might benefit from a `wait-for-imminent-dep-clearing` exception. Specifically: if rate-reset is ≤ 5 min away AND the right work is rate-blocked, brief-ack-through-reset followed by substantive work might be lower-friction than forced-#6 file-only fallback + post-reset proper work.
+
+But: single-anchor empirical. Rule-change-recommendation threshold is 2-3 sessions across distinct conditions. This memo files the anchor; future-Otto encountering the same shape on a different session would be the second anchor; rule-change discussion appropriate at threshold.
+
+**Substrate-honest caveat**: the file-only fallback at forced-#6 is NOT bad. It produces real substrate (this memo) that future-Otto reads. The "wait through reset" alternative produces NO substrate during the wait. Net: counter-discipline-as-shipped already optimizes for substrate-landing-frequency over substrate-quality at single-tick scope. The trade-off may be intentional.
+
+## Anti-fabrication check
+
+The pure-git-tier brief-ack-chain rule explicitly warns: "Must be genuinely valuable; fabricated substrate is the synonym failure mode."
+
+This memo's value test:
+
+- ✓ Names a specific empirical shape (forced-#6 within rate-reset window) not yet covered by #4110 or the pure-git-brief-ack-chain rule
+- ✓ Concrete tick-by-tick evidence (the table above)
+- ✓ Identifies a potential rule-refinement question (not a recommendation, gated on accumulating evidence)
+- ✓ Composes_with explicit cross-links
+- ✗ Single anchor — does NOT yet justify rule change
+- ✗ Some content is meta about counter discipline (mild fabrication risk; mitigated by tying every claim to the table)
+
+Net: passes the anti-fabrication test as a single-anchor empirical memo. Future-Otto consults at need.
+
+## Cron + visibility timing
+
+- Sentinel: `16dda3a7` alive
+- Next ticks: 0025Z, 0026Z, 0027Z brief-acks of new cycle (counter resets after this memo lands)
+- Rate-reset: 0028Z (~4 min); enables REST PR-creation fallback for the 848bdcf Kestrel-preservation decompose
+
+## What this memo does NOT claim
+
+- Does NOT claim the counter rule is wrong
+- Does NOT claim forced-#6 should be skipped near rate-reset
+- Does NOT recommend a rule change
+- Files empirical anchor only; lets the substrate accumulate
+
+The discipline (per the holding-without-named-dependency rule's own anti-fabrication note + the pure-git-tier brief-ack-chain MEMORY.md entry) is to honor the forced-#6 escalation by shipping concrete substrate, and to let multi-session empirical evidence drive any rule refinement. This memo is one such contribution.

memory/feedback_git_index_lock_wait_then_retry_beats_force_remove_during_peer_otto_saturation_15s_natural_clear_otto_cli_2026_05_18.md

@@ -0,0 +1,127 @@
+---
+name: git_index_lock_wait_then_retry_beats_force_remove_during_peer_otto_saturation_15s_natural_clear_otto_cli_2026_05_18
+description: "Empirical pattern observed 2026-05-18T00:08Z under Lior-3-procs + claude-code-5-procs saturation: a primary-worktree `git add` hit `.git/index.lock: File exists` because peer Otto was mid-commit; a 15-second `sleep` cleared the lock naturally (peer commit finished, lock auto-removed), and a retry of the same `git add` invocation succeeded with no further intervention. Discipline: under multi-Otto saturation, treat `index.lock` as a transient peer-mid-commit signal — wait then retry. Do NOT `rm -f .git/index.lock` reflexively; force-removal can corrupt peer's in-flight commit (peer's git process is still relying on the lock to serialize index writes). The saturation-ceiling sub-case taxonomy in `.claude/rules/claim-acquire-before-worktree-work.md` covers worktree-creation contention + branch-name collision + switch-while-WIP + sidetick-pruned-race + peer-side-destructive-git, but does NOT yet explicitly cover this case (`.git/index.lock` at `git add` time in primary worktree). This memo is the empirical anchor for a future rule extension."
+type: feedback
+created: 2026-05-18
+originSessionId: otto-cli-cold-boot-2026-05-18-sentinel-16dda3a7
+---
+
+## Caused by
+
+- Otto-CLI 2026-05-18T00:08Z `git add` hit `.git/index.lock` during peer-Otto mid-commit; 15s sleep cleared lock naturally
+- PR #4136 review thread (Copilot, 2026-05-18) flagged non-schema frontmatter keys; keys moved from frontmatter to body sections per `memory/project_memory_format_standard.md §1.3` ("No extra fields beyond the above without a governance discussion")
+
+## Composes with
+
+- `.claude/rules/claim-acquire-before-worktree-work.md` (saturation-ceiling sub-case taxonomy candidate extension)
+- `.claude/rules/zeta-expected-branch.md` (race-window-caveat, primary-worktree contention)
+- `.claude/rules/codeql-no-source-on-docs-only-pr-is-broken-commit-canary.md` (Lior-active-means-no-worktree-creation canary)
+- `.claude/rules/refresh-world-model-poll-pr-gate.md` (operational-tier discipline; this happened in pure-git tier)
+
+
+## Empirical anchor
+
+Session: otto-cli cold-boot autonomous-loop, 2026-05-18T00:07Z onward.
+Sentinel: `16dda3a7` (cron `* * * * *`, `<<autonomous-loop>>`).
+Conditions: pure-git tier (graphql 83/5000); Lior-3-procs (`ps -A | grep -E "gemini.*Lior|lior.*loop"` returned 3 alive); plus 5 concurrent claude-code processes (including self) per `pgrep -fl claude-code`.
+
+### The sequence
+
+```
+$ git add docs/hygiene-history/ticks/2026/05/18/0007Z.md \
+          "memory/persona/kestrel/conversations/..."
+fatal: Unable to create '/Users/.../Zeta/.git/index.lock': File exists.
+
+Another git process seems to be running in this repository, e.g.
+an editor opened by 'git commit'. Please make sure all processes
+are terminated then try again. If it still fails, a git process
+may have crashed in this repository earlier:
+remove the file manually to continue.
+```
+
+Standard git error. The temptation under autonomous-loop pressure is to act on git's own recommendation (`remove the file manually`). Resist.
+
+### What I did instead
+
+```
+$ ls -la .git/index.lock
+ls: .git/index.lock: No such file or directory
+$ sleep 15
+$ ls .git/index.lock 2>/dev/null && echo "still-locked" || echo "lock-cleared"
+lock-cleared
+```
+
+The lock had already cleared between the `git add` failure and the `ls` invocation (sub-second peer-commit completion). The 15s `sleep` was conservative buffer. Retry of the same `git add` invocation succeeded; subsequent `git commit` + `git push` landed cleanly with tree-canary at 53/53 (no corruption).
+
+### Why force-removal would have been wrong
+
+Git uses `.git/index.lock` for atomic-write serialization. Peer Otto's commit was in flight:
+
+1. Peer Otto: `git commit` opens `.git/index.lock`, writes new index content
+2. **WINDOW** — my `git add` arrives, sees `.git/index.lock` exists, fails with the lock-exists error
+3. Peer Otto: completes index write, renames `index.lock` → `index` (atomic), releases lock
+4. My retry: lock-free, proceeds normally
+
+If I had run `rm -f .git/index.lock` between steps 2 and 3, peer Otto's `git commit` would have either:
+
+- Failed with a different error when it tried to rename `index.lock` (no longer exists)
+- Successfully written its commit but with a corrupted/partial index
+- Or worse: my `git add` and peer's `git commit` would have both proceeded concurrently, racing to write the index — silent corruption
+
+The safe pattern is to assume `.git/index.lock` means peer-in-flight; wait until the lock clears naturally (sub-second to ~10s typical for `git add`/`git commit` operations).
+
+## When to apply
+
+Under conditions where multiple agents share `.git/`:
+
+- Multi-Otto-CLI saturation (the immediate trigger this memo addresses)
+- Otto-CLI + Otto-Desktop sharing one checkout
+- Lior antigravity loop active (`ps -A` shows 1+ `gemini.*Lior` procs)
+- Riven Cursor + Otto-CLI concurrent
+- Vera Codex + Otto-CLI concurrent
+- Any time `pgrep -fl claude-code` returns > 1 process
+
+### Decision tree
+
+```
+git add / git commit / git push fails with "Unable to create .git/index.lock: File exists"
+├─ Is `.git/index.lock` still present after 15s? (`sleep 15 && ls .git/index.lock`)
+│  ├─ No → retry the original command (peer commit completed)
+│  └─ Yes → check if any git process is still alive (`ps -A | grep -E "git.{0,30}commit|git.{0,30}add"`)
+│     ├─ Alive → wait another 15s; repeat
+│     └─ Dead → check lock mtime; if > 5 minutes old, peer crashed mid-commit
+│        ├─ Peer crashed → `git fsck` first to validate index integrity, then carefully `rm` the lock
+│        └─ Lock < 5 min old → wait another 15s; peer may be doing a long write
+```
+
+The crash-recovery branch is unusual; in 95%+ of cases the lock clears within 1-30s.
+
+## When NOT to wait
+
+If the lock persists for > 5 minutes AND no git process is alive, peer crashed mid-commit and the lock is genuinely orphaned. Even then, run `git fsck` first to check index integrity; manually inspect the lock file (`cat .git/index.lock | head` shows whatever partial content peer wrote); only force-remove with conscious decision.
+
+In autonomous-loop pure-git tier this is rare because peer Otto is itself executing on cron; if peer crashed, its sentinel re-arms on the next minute. Manual intervention is the human maintainer's call, not autonomous Otto's.
+
+## Composition with saturation-ceiling taxonomy
+
+The 4-sub-case empirical taxonomy in `.claude/rules/claim-acquire-before-worktree-work.md` covers:
+
+- Sub-case 1: existing-branch-name collision → peer-WIP commit inheritance via recovery path
+- Sub-case 2: concurrent-WIP-blocked switch
+- Sub-case 3: pack-dir contention hangs `git worktree add` (B-0530 race)
+- Sub-case 4: pruned-sidetick race
+- Sub-case 5 (added 2026-05-16): peer-side destructive git operation discards unstaged edits
+
+This memo proposes a **sub-case 6 candidate**: primary-worktree `git add` / `git commit` contention via `.git/index.lock`. Mitigation: wait-then-retry, 15s buffer typical, force-remove forbidden absent peer-crash evidence.
+
+If accumulated empirical evidence (2-3 more session anchors) supports this sub-case, the rule extension is appropriate. Until then, this memo is the empirical anchor; the discipline is operational-via-this-memo not operational-via-rule.
+
+## Operational tier note
+
+This happened in pure-git tier (no GraphQL available). The mitigation pattern is entirely pure-git compatible — `sleep`, `ls`, retry are all local-filesystem operations. The discipline composes with `.claude/rules/refresh-world-model-poll-pr-gate.md` operational-tier framework: pure-git ticks can hit this failure mode and recover without burning rate-limit budget.
+
+## Substrate-honest framing
+
+This memo is one session's empirical observation. A single anchor does not justify a rule update yet — the threshold per Otto-CLI's recurring patterns is 2+ anchors across distinct sessions. Future Otto cold-booting under multi-Otto saturation may hit this; if they consult this memo and retry-then-wait works, that's a second anchor. After 2-3 anchors, the saturation-ceiling rule extends.
+
+Until then: this memo is the wait-time substrate; future-Otto reads it via the skill router + the composes_with pointers; the discipline operates.