- Add step-by-step guide for LLM agents to setup oh-my-opencode
- Include OpenCode installation check with link to official docs
- Include oh-my-opencode plugin configuration script
- Update Table of Contents for both EN/KO README files

- Remove sisyphusJuniorModel fallback bypass (BUG #1)
  - userModel fallback was incorrectly bypassing category fallbackChain
  - Now correctly uses category requirements before system default

- Fix variant preservation in actualModel fallback path (BUG #2)
  - Variant was lost when categoryModel undefined but actualModel existed
  - Now preserves variant when falling back to actualModel parsing

- Add variant to session continuation (BUG code-yeongyu#3)
  - Session resume didn't pass variant from message history
  - Now extracts resumeVariant and passes as body.variant

- Remove unused inheritedModel parameter (BUG code-yeongyu#4)
  - resolveCategoryConfig had misleading unused parameter
  - Cleaned up function signature and all call sites

- Add variant-model compatibility validation (BUG code-yeongyu#5)
  - No warning when variant might not be supported by provider
  - Added isVariantLikelySupported() validation with console.warn

Test coverage:
- Updated 10+ existing tests to remove inheritedModel references
- Added 9 new tests for variant validation functions
- All 110 tests pass (77 delegate-task + 33 model-requirements)

…ts, abort before retry

- Swap resolveAgentForSession priority: session agent before event agent (Bug code-yeongyu#2)
- Add pinnedSessionAgentMap so /start-work agent can't be overwritten by SDK events (Bug code-yeongyu#3)
- Abort in-flight request before fallback promptAsync to prevent silent drops (Bug code-yeongyu#1)
- Add session.get fallback for agent resolution when chat.message never fires (Bug code-yeongyu#4)
- Fix agentPattern regex: replace \b with custom boundary for underscore-delimited session IDs
- Revert resolveAgentFromModel reverse-lookup (unreliable with overlapping models)
- Add tests for pinned agents (8), agent-resolver (17), abort ordering, session.get resolution

…-yeongyu#309)

Critical fixes:
- Bug #1: SubagentStop hook defaulted all agents to 'failed' because SDK
  doesn't provide `success` field. Now defaults to 'completed' when undefined.
- Bug code-yeongyu#4: Token stats lost across TokenTracker instances. Constructor now
  restores session stats from global state for the same session ID.
- Bug code-yeongyu#5: Ultrawork session isolation bypassed when both session IDs were
  undefined (undefined === undefined). Now rejects all falsy session IDs.

High priority fixes:
- Bug code-yeongyu#6: Cancel skill force-clear missed 12+ state files (boulder,
  hud-state, subagent-tracking, checkpoints, etc). Added comprehensive list.
- Bug code-yeongyu#7: HUD semverCompare() returned NaN on pre-release versions like
  "3.9.5-beta". Fixed to use parseInt and handle pre-release ordering.
- Bug code-yeongyu#8: Silent JSON parse failures in critical state readers. Added
  error logging to ralph and ultrawork state readers.
- Bug code-yeongyu#9: Stale task detection had no default behavior when onStaleSession
  callback was not configured. Now auto-cleans after 2x threshold.
- Bug code-yeongyu#10: Hardcoded 3-architect assumption in validation. Extracted to
  REQUIRED_ARCHITECTS constant.

Medium priority fixes:
- Bug code-yeongyu#11: Auto-invoke history used non-atomic writes. Now uses
  atomicWriteJson to prevent corruption from concurrent sessions.
- Bug code-yeongyu#12: Ecomode docs said "all tasks" use Haiku, contradicting the
  escalation paths. Clarified to "most tasks" with upgrade criteria.
- Bug code-yeongyu#13: Added safeUnlinkSync/safeRmSync utilities to prevent ENOENT
  crashes during cleanup operations.
- Bug code-yeongyu#14: State files containing user prompts written with 0644
  permissions. Now writes with 0600 (owner-only read/write).
- Bug code-yeongyu#15: Model names recorded inconsistently (e.g., 'claude-3-5-haiku'
  vs 'claude-haiku-4'). Now normalizes at recording time via exported
  normalizeModelName().

Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>

Eliminate dual manager instances:
- Removed Manager #1 from create-managers.ts
- Hook now uses coordinator.resolve() to find binding
- Hook uses binding.manager and binding.rlmSessionId

Fixed applyFeedback session ID path:
- turn-feedback.ts now uses binding.rlmSessionId for createBlobVariable

Updated tests to reflect correct RLM behavior:
- RLM sessions use applyFeedback, not generic distillation
- Tests verify coordinator-based session lookup

All 3,608 tests pass.

Eliminate dual manager instances:
- Removed Manager #1 from create-managers.ts
- Hook now uses coordinator.resolve() to find binding
- Hook uses binding.manager and binding.rlmSessionId

Fixed applyFeedback session ID path:
- turn-feedback.ts now uses binding.rlmSessionId for createBlobVariable

Updated tests to reflect correct RLM behavior:
- RLM sessions use applyFeedback, not generic distillation
- Tests verify coordinator-based session lookup

All 3,608 tests pass.

Eliminate dual manager instances:
- Removed Manager #1 from create-managers.ts
- Hook now uses coordinator.resolve() to find binding
- Hook uses binding.manager and binding.rlmSessionId

Fixed applyFeedback session ID path:
- turn-feedback.ts now uses binding.rlmSessionId for createBlobVariable

Updated tests to reflect correct RLM behavior:
- RLM sessions use applyFeedback, not generic distillation
- Tests verify coordinator-based session lookup

All 3,608 tests pass.

…tracking

- Remove overly broad /not found/i regex that matched grep 'No matches found' output
- Replace /expect.*to/i test pattern with /AssertionError/i for precise test failure detection
- Narrow trackBuildResult regex from /error/i to /(?:compilation|type)\s+error/i
- Add bash quiet-success handler to reset lastBuildResult from 'fail' to 'unknown'

Fixes P-007 (false-positive error tracking chain) bugs code-yeongyu#1, code-yeongyu#2, code-yeongyu#4

Ultraworked with [Sisyphus](https://github.com/code-yeongyu/oh-my-openagent)

Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>

…fy narrative, reconcile S5 count)

- Fix #1: Filled `## Top-3 Selected Ports` with the 3 executed ports (Sisyphus 3bae6dd2, Hephaestus 0dca1c4e, Prometheus 9393ac6c), their sources, targets, and tier-2 classification.
- Fix #2: Unified stale narrative cycle-2-dep labels post-Oracle reassignment — ralph-loop: N→Y in Top-ROI bullets and Top-5 candidates (uses subagentStop.followup_message); session-recovery: field corrected from sessionStart.user_message to sessionStart.env + additional_context in Top-5 candidates. unstable-agent-babysitter: no narrative drift found (data table already Y, reconciliation note already correct).
- Fix code-yeongyu#3: S5 count reconciliation — option (b): S5 table has exactly 52 data rows (verified by manual count lines 146–197); section header and per-surface table both say 52. FV4 likely miscounted the reconciliation blockquote or header separator as a data row. No file changes needed.

Post-FV cleanup commit. No tier reassignments, no port-content changes. Only doc housekeeping.

Two order-breaking bugs remained in flushPending:

1. drained items after the failing write were dropped. pendingDeltaBuffer.drain
   removes the entire queue, writePendingEvent re-enqueued only the failed
   item, and the remaining items after it (already pulled out of the buffer)
   were never written or requeued.

2. The handler wrote the current event after a failed flush, so a buffered
   predecessor that just failed to write would land in the pane AFTER the
   new event on retry, breaking stream order.

Replace flushPending with drainAndWrite which re-enqueues every item
remaining after the failing write in their original order. Handlers now
enqueue the current event before draining so any write failure defers the
current event too, preserving order when the retry scheduler eventually
drains everything.

Extracted pending-retry-scheduler.ts to keep hook.ts under the 200 LOC
architecture limit, and unified the delta/updated branches through a new
handlePendingEvent helper.

Two new regression tests:
- 'does not lose buffered events after the second drained write fails and
  retries them in order' (4 pending + 1 new, write #2 fails, retry replays
  [b, c, d] so panes see A B B C D)
- 'defers the current event when a buffered drain fails so stream order is
  preserved on retry' (1 pending + 1 new, write #1 fails, retry replays
  [a, b] so panes see A A B - the new event never precedes the failed one)

Two order-breaking bugs remained in flushPending:

1. drained items after the failing write were dropped. pendingDeltaBuffer.drain
   removes the entire queue, writePendingEvent re-enqueued only the failed
   item, and the remaining items after it (already pulled out of the buffer)
   were never written or requeued.

2. The handler wrote the current event after a failed flush, so a buffered
   predecessor that just failed to write would land in the pane AFTER the
   new event on retry, breaking stream order.

Replace flushPending with drainAndWrite which re-enqueues every item
remaining after the failing write in their original order. Handlers now
enqueue the current event before draining so any write failure defers the
current event too, preserving order when the retry scheduler eventually
drains everything.

Extracted pending-retry-scheduler.ts to keep hook.ts under the 200 LOC
architecture limit, and unified the delta/updated branches through a new
handlePendingEvent helper.

Two new regression tests:
- 'does not lose buffered events after the second drained write fails and
  retries them in order' (4 pending + 1 new, write #2 fails, retry replays
  [b, c, d] so panes see A B B C D)
- 'defers the current event when a buffered drain fails so stream order is
  preserved on retry' (1 pending + 1 new, write #1 fails, retry replays
  [a, b] so panes see A A B - the new event never precedes the failed one)

Two order-breaking bugs remained in flushPending:

1. drained items after the failing write were dropped. pendingDeltaBuffer.drain
   removes the entire queue, writePendingEvent re-enqueued only the failed
   item, and the remaining items after it (already pulled out of the buffer)
   were never written or requeued.

2. The handler wrote the current event after a failed flush, so a buffered
   predecessor that just failed to write would land in the pane AFTER the
   new event on retry, breaking stream order.

Replace flushPending with drainAndWrite which re-enqueues every item
remaining after the failing write in their original order. Handlers now
enqueue the current event before draining so any write failure defers the
current event too, preserving order when the retry scheduler eventually
drains everything.

Extracted pending-retry-scheduler.ts to keep hook.ts under the 200 LOC
architecture limit, and unified the delta/updated branches through a new
handlePendingEvent helper.

Two new regression tests:
- 'does not lose buffered events after the second drained write fails and
  retries them in order' (4 pending + 1 new, write #2 fails, retry replays
  [b, c, d] so panes see A B B C D)
- 'defers the current event when a buffered drain fails so stream order is
  preserved on retry' (1 pending + 1 new, write #1 fails, retry replays
  [a, b] so panes see A A B - the new event never precedes the failed one)

Two order-breaking bugs remained in flushPending:

1. drained items after the failing write were dropped. pendingDeltaBuffer.drain
   removes the entire queue, writePendingEvent re-enqueued only the failed
   item, and the remaining items after it (already pulled out of the buffer)
   were never written or requeued.

2. The handler wrote the current event after a failed flush, so a buffered
   predecessor that just failed to write would land in the pane AFTER the
   new event on retry, breaking stream order.

Replace flushPending with drainAndWrite which re-enqueues every item
remaining after the failing write in their original order. Handlers now
enqueue the current event before draining so any write failure defers the
current event too, preserving order when the retry scheduler eventually
drains everything.

Extracted pending-retry-scheduler.ts to keep hook.ts under the 200 LOC
architecture limit, and unified the delta/updated branches through a new
handlePendingEvent helper.

Two new regression tests:
- 'does not lose buffered events after the second drained write fails and
  retries them in order' (4 pending + 1 new, write #2 fails, retry replays
  [b, c, d] so panes see A B B C D)
- 'defers the current event when a buffered drain fails so stream order is
  preserved on retry' (1 pending + 1 new, write #1 fails, retry replays
  [a, b] so panes see A A B - the new event never precedes the failed one)

Two order-breaking bugs remained in flushPending:

1. drained items after the failing write were dropped. pendingDeltaBuffer.drain
   removes the entire queue, writePendingEvent re-enqueued only the failed
   item, and the remaining items after it (already pulled out of the buffer)
   were never written or requeued.

2. The handler wrote the current event after a failed flush, so a buffered
   predecessor that just failed to write would land in the pane AFTER the
   new event on retry, breaking stream order.

Replace flushPending with drainAndWrite which re-enqueues every item
remaining after the failing write in their original order. Handlers now
enqueue the current event before draining so any write failure defers the
current event too, preserving order when the retry scheduler eventually
drains everything.

Extracted pending-retry-scheduler.ts to keep hook.ts under the 200 LOC
architecture limit, and unified the delta/updated branches through a new
handlePendingEvent helper.

Two new regression tests:
- 'does not lose buffered events after the second drained write fails and
  retries them in order' (4 pending + 1 new, write #2 fails, retry replays
  [b, c, d] so panes see A B B C D)
- 'defers the current event when a buffered drain fails so stream order is
  preserved on retry' (1 pending + 1 new, write #1 fails, retry replays
  [a, b] so panes see A A B - the new event never precedes the failed one)

Two order-breaking bugs remained in flushPending:

1. drained items after the failing write were dropped. pendingDeltaBuffer.drain
   removes the entire queue, writePendingEvent re-enqueued only the failed
   item, and the remaining items after it (already pulled out of the buffer)
   were never written or requeued.

2. The handler wrote the current event after a failed flush, so a buffered
   predecessor that just failed to write would land in the pane AFTER the
   new event on retry, breaking stream order.

Replace flushPending with drainAndWrite which re-enqueues every item
remaining after the failing write in their original order. Handlers now
enqueue the current event before draining so any write failure defers the
current event too, preserving order when the retry scheduler eventually
drains everything.

Extracted pending-retry-scheduler.ts to keep hook.ts under the 200 LOC
architecture limit, and unified the delta/updated branches through a new
handlePendingEvent helper.

Two new regression tests:
- 'does not lose buffered events after the second drained write fails and
  retries them in order' (4 pending + 1 new, write #2 fails, retry replays
  [b, c, d] so panes see A B B C D)
- 'defers the current event when a buffered drain fails so stream order is
  preserved on retry' (1 pending + 1 new, write #1 fails, retry replays
  [a, b] so panes see A A B - the new event never precedes the failed one)

Two order-breaking bugs remained in flushPending:

1. drained items after the failing write were dropped. pendingDeltaBuffer.drain
   removes the entire queue, writePendingEvent re-enqueued only the failed
   item, and the remaining items after it (already pulled out of the buffer)
   were never written or requeued.

2. The handler wrote the current event after a failed flush, so a buffered
   predecessor that just failed to write would land in the pane AFTER the
   new event on retry, breaking stream order.

Replace flushPending with drainAndWrite which re-enqueues every item
remaining after the failing write in their original order. Handlers now
enqueue the current event before draining so any write failure defers the
current event too, preserving order when the retry scheduler eventually
drains everything.

Extracted pending-retry-scheduler.ts to keep hook.ts under the 200 LOC
architecture limit, and unified the delta/updated branches through a new
handlePendingEvent helper.

Two new regression tests:
- 'does not lose buffered events after the second drained write fails and
  retries them in order' (4 pending + 1 new, write #2 fails, retry replays
  [b, c, d] so panes see A B B C D)
- 'defers the current event when a buffered drain fails so stream order is
  preserved on retry' (1 pending + 1 new, write #1 fails, retry replays
  [a, b] so panes see A A B - the new event never precedes the failed one)

The previous description (41 words) told the LLM to write 'complete AST
nodes' but did not explain that regex syntax is the #1 failure mode. It
also shipped a bug: the Python example 'def $FUNC($$$):' had a trailing
colon that the hint system actively flags as wrong.

Extract descriptions into tool-descriptions.ts and rewrite:
- Open with 'This is NOT regex' so the constraint is unmissable
- List the four regex patterns that do not work (|, .*, \\w, [a-z])
  with the corrective action for each
- Tell the LLM to switch to grep when the pattern is text-shaped
- Fix the Python example (no trailing colon) and add Go and Rust rows
  since the failing reports came from Go codebases
- Shorten the pattern-param description with the same anti-regex list

Also harden the LSP reference for the new test files using the
bun-types triple-slash directive already used elsewhere.

Two order-breaking bugs remained in flushPending:

1. drained items after the failing write were dropped. pendingDeltaBuffer.drain
   removes the entire queue, writePendingEvent re-enqueued only the failed
   item, and the remaining items after it (already pulled out of the buffer)
   were never written or requeued.

2. The handler wrote the current event after a failed flush, so a buffered
   predecessor that just failed to write would land in the pane AFTER the
   new event on retry, breaking stream order.

Replace flushPending with drainAndWrite which re-enqueues every item
remaining after the failing write in their original order. Handlers now
enqueue the current event before draining so any write failure defers the
current event too, preserving order when the retry scheduler eventually
drains everything.

Extracted pending-retry-scheduler.ts to keep hook.ts under the 200 LOC
architecture limit, and unified the delta/updated branches through a new
handlePendingEvent helper.

Two new regression tests:
- 'does not lose buffered events after the second drained write fails and
  retries them in order' (4 pending + 1 new, write #2 fails, retry replays
  [b, c, d] so panes see A B B C D)
- 'defers the current event when a buffered drain fails so stream order is
  preserved on retry' (1 pending + 1 new, write #1 fails, retry replays
  [a, b] so panes see A A B - the new event never precedes the failed one)

Two order-breaking bugs remained in flushPending:

1. drained items after the failing write were dropped. pendingDeltaBuffer.drain
   removes the entire queue, writePendingEvent re-enqueued only the failed
   item, and the remaining items after it (already pulled out of the buffer)
   were never written or requeued.

2. The handler wrote the current event after a failed flush, so a buffered
   predecessor that just failed to write would land in the pane AFTER the
   new event on retry, breaking stream order.

Replace flushPending with drainAndWrite which re-enqueues every item
remaining after the failing write in their original order. Handlers now
enqueue the current event before draining so any write failure defers the
current event too, preserving order when the retry scheduler eventually
drains everything.

Extracted pending-retry-scheduler.ts to keep hook.ts under the 200 LOC
architecture limit, and unified the delta/updated branches through a new
handlePendingEvent helper.

Two new regression tests:
- 'does not lose buffered events after the second drained write fails and
  retries them in order' (4 pending + 1 new, write #2 fails, retry replays
  [b, c, d] so panes see A B B C D)
- 'defers the current event when a buffered drain fails so stream order is
  preserved on retry' (1 pending + 1 new, write #1 fails, retry replays
  [a, b] so panes see A A B - the new event never precedes the failed one)

Two order-breaking bugs remained in flushPending:

1. drained items after the failing write were dropped. pendingDeltaBuffer.drain
   removes the entire queue, writePendingEvent re-enqueued only the failed
   item, and the remaining items after it (already pulled out of the buffer)
   were never written or requeued.

2. The handler wrote the current event after a failed flush, so a buffered
   predecessor that just failed to write would land in the pane AFTER the
   new event on retry, breaking stream order.

Replace flushPending with drainAndWrite which re-enqueues every item
remaining after the failing write in their original order. Handlers now
enqueue the current event before draining so any write failure defers the
current event too, preserving order when the retry scheduler eventually
drains everything.

Extracted pending-retry-scheduler.ts to keep hook.ts under the 200 LOC
architecture limit, and unified the delta/updated branches through a new
handlePendingEvent helper.

Two new regression tests:
- 'does not lose buffered events after the second drained write fails and
  retries them in order' (4 pending + 1 new, write #2 fails, retry replays
  [b, c, d] so panes see A B B C D)
- 'defers the current event when a buffered drain fails so stream order is
  preserved on retry' (1 pending + 1 new, write #1 fails, retry replays
  [a, b] so panes see A A B - the new event never precedes the failed one)

Two order-breaking bugs remained in flushPending:

1. drained items after the failing write were dropped. pendingDeltaBuffer.drain
   removes the entire queue, writePendingEvent re-enqueued only the failed
   item, and the remaining items after it (already pulled out of the buffer)
   were never written or requeued.

2. The handler wrote the current event after a failed flush, so a buffered
   predecessor that just failed to write would land in the pane AFTER the
   new event on retry, breaking stream order.

Replace flushPending with drainAndWrite which re-enqueues every item
remaining after the failing write in their original order. Handlers now
enqueue the current event before draining so any write failure defers the
current event too, preserving order when the retry scheduler eventually
drains everything.

Extracted pending-retry-scheduler.ts to keep hook.ts under the 200 LOC
architecture limit, and unified the delta/updated branches through a new
handlePendingEvent helper.

Two new regression tests:
- 'does not lose buffered events after the second drained write fails and
  retries them in order' (4 pending + 1 new, write #2 fails, retry replays
  [b, c, d] so panes see A B B C D)
- 'defers the current event when a buffered drain fails so stream order is
  preserved on retry' (1 pending + 1 new, write #1 fails, retry replays
  [a, b] so panes see A A B - the new event never precedes the failed one)

Two order-breaking bugs remained in flushPending:

1. drained items after the failing write were dropped. pendingDeltaBuffer.drain
   removes the entire queue, writePendingEvent re-enqueued only the failed
   item, and the remaining items after it (already pulled out of the buffer)
   were never written or requeued.

2. The handler wrote the current event after a failed flush, so a buffered
   predecessor that just failed to write would land in the pane AFTER the
   new event on retry, breaking stream order.

Replace flushPending with drainAndWrite which re-enqueues every item
remaining after the failing write in their original order. Handlers now
enqueue the current event before draining so any write failure defers the
current event too, preserving order when the retry scheduler eventually
drains everything.

Extracted pending-retry-scheduler.ts to keep hook.ts under the 200 LOC
architecture limit, and unified the delta/updated branches through a new
handlePendingEvent helper.

Two new regression tests:
- 'does not lose buffered events after the second drained write fails and
  retries them in order' (4 pending + 1 new, write #2 fails, retry replays
  [b, c, d] so panes see A B B C D)
- 'defers the current event when a buffered drain fails so stream order is
  preserved on retry' (1 pending + 1 new, write #1 fails, retry replays
  [a, b] so panes see A A B - the new event never precedes the failed one)

Two order-breaking bugs remained in flushPending:

1. drained items after the failing write were dropped. pendingDeltaBuffer.drain
   removes the entire queue, writePendingEvent re-enqueued only the failed
   item, and the remaining items after it (already pulled out of the buffer)
   were never written or requeued.

2. The handler wrote the current event after a failed flush, so a buffered
   predecessor that just failed to write would land in the pane AFTER the
   new event on retry, breaking stream order.

Replace flushPending with drainAndWrite which re-enqueues every item
remaining after the failing write in their original order. Handlers now
enqueue the current event before draining so any write failure defers the
current event too, preserving order when the retry scheduler eventually
drains everything.

Extracted pending-retry-scheduler.ts to keep hook.ts under the 200 LOC
architecture limit, and unified the delta/updated branches through a new
handlePendingEvent helper.

Two new regression tests:
- 'does not lose buffered events after the second drained write fails and
  retries them in order' (4 pending + 1 new, write #2 fails, retry replays
  [b, c, d] so panes see A B B C D)
- 'defers the current event when a buffered drain fails so stream order is
  preserved on retry' (1 pending + 1 new, write #1 fails, retry replays
  [a, b] so panes see A A B - the new event never precedes the failed one)

Two order-breaking bugs remained in flushPending:

1. drained items after the failing write were dropped. pendingDeltaBuffer.drain
   removes the entire queue, writePendingEvent re-enqueued only the failed
   item, and the remaining items after it (already pulled out of the buffer)
   were never written or requeued.

2. The handler wrote the current event after a failed flush, so a buffered
   predecessor that just failed to write would land in the pane AFTER the
   new event on retry, breaking stream order.

Replace flushPending with drainAndWrite which re-enqueues every item
remaining after the failing write in their original order. Handlers now
enqueue the current event before draining so any write failure defers the
current event too, preserving order when the retry scheduler eventually
drains everything.

Extracted pending-retry-scheduler.ts to keep hook.ts under the 200 LOC
architecture limit, and unified the delta/updated branches through a new
handlePendingEvent helper.

Two new regression tests:
- 'does not lose buffered events after the second drained write fails and
  retries them in order' (4 pending + 1 new, write #2 fails, retry replays
  [b, c, d] so panes see A B B C D)
- 'defers the current event when a buffered drain fails so stream order is
  preserved on retry' (1 pending + 1 new, write #1 fails, retry replays
  [a, b] so panes see A A B - the new event never precedes the failed one)

…rite-protection

fix: block Write tool on notepad files to prevent data loss

Subagent sessions are handled by specialized callbacks:
- CALL code-yeongyu#2: create-managers.ts via onSubagentSessionCreated (async)
- CALL code-yeongyu#3: tool-registry.ts via onSyncSessionCreated (sync)

Event handler (CALL code-yeongyu#1) now only forwards parent sessions to
tmuxSessionManager, preventing double/triple tmux spawns.

- Add focused ROADMAP with TOC and clear priorities
- Pin package layering refactor as #1 urgent work
- Add multi-harness agent OS notice to all language READMEs
- Add ROADMAP section to root README with contributor guidance
- All ROADMAP-related PRs should use the ROADMAP label

**Justification — Oracle analysis #1:**
Oracle ranked this the highest-ROI gem-team translation. Prometheus plans
currently lack pre-execution risk analysis, task-level contracts, and
sizing constraints. A plan can pass review while containing under-decomposed
tasks and hidden failure modes.

Oracle: 'Prometheus: add task contracts, pre-mortem, and sizing caps.
Target plan-template.ts and plan-generation.ts.'

Metis confirmed: plan YAML with contracts and verification predicates is
gem-team's central coordination artifact. Without it, multi-agent execution
is guesswork — agents assume what preceding tasks produced rather than
verifying against explicit contracts.

**What changed — plan-template.ts:**
- Pre-Mortem Risk Analysis section (MANDATORY for Medium+ effort):
  overall risk level, critical failure modes table (scenario/likelihood/
  impact/mitigation), key assumptions
- Task Contracts section (MANDATORY): interface definitions between
  dependent tasks (from_task → to_task, interface, format)
- Sizing Limits per task: estimated_files ≤ 3, estimated_lines ≤ 300
- Failure Modes per task (REQUIRED for Medium+ priority)

**What changed — plan-generation.ts:**
- Oracle phase-2 verification expanded from 6 to 9 checks (pre-mortem,
  sizing, contracts)
- Self-review checklist expanded from 9 to 12 checks

**Gem-team sources:**
- gem-planner Synthesize DAG contracts (gem-planner.agent.md:70)
- gem-planner Change Sizing ≤300 lines (gem-planner.agent.md:104)
- gem-planner Pre-Mortem (gem-planner.agent.md:138)
- gem-planner verification criteria (gem-planner.agent.md:323)

**Justification — Metis blind-spot #1 + Oracle analysis #3:**

Metis identified the implementation_handoff as the single most valuable
gem-team pattern OMO is missing: when a debugger diagnoses a bug, the
implementer MUST NOT re-research — but OMO has no mechanism to prevent
this. Agents re-do each other's work, burning tokens and losing context.

Metis: 'The implementation_handoff pattern prevents the #1 multi-agent
failure mode: agents re-doing each other's work. The do_not_reinvestigate
field tells the implementer to trust prior work and just execute.'

Oracle confirmed: 'Add debugging consultation mode with 4-phase diagnosis,
Three-Fail Rule, and structured implementation_handoff output.'

**What changed — oracle.ts:**
- Added ORACLE_DEBUGGING_MODE constant (shared across all 4 model variants)
  5-step diagnosis workflow: Reproduce → Trace root cause → Analyze data
  flow → Bisect only when needed → Distinguish cause from symptoms
- Three-Fail Rule: after 3 failed fix attempts in same session, escalate
- Structured [IMPLEMENTATION_HANDOFF] output block with:
  do_not_reinvestigate, required_test_first, target_files, minimal_change,
  acceptance_checks
- Red flags that trigger escalation instead of continued diagnosis
- Injected via factory function into all 4 prompt variants (default,
  GPT, GPT-5.2, GPT-5.5)

**Why this matters:**
This closes the loop Oracle → implementer. When Oracle diagnoses a bug,
the implementation_handoff tells Atlas/Hephaestus exactly what to change
without re-discovering what Oracle already found. Combined with the
knowledge trust hierarchy (previous commit), implementers now know that
Oracle's handoff is Trusted-tier — follow as instructions.

**Gem-team sources:**
- gem-debugger 4-phase diagnosis (gem-debugger.agent.md:41-164)
- Three-Fail Rule (gem-debugger.agent.md:170-197)
- implementation_handoff output (gem-debugger.agent.md:224-229)

- Create @oh-my-opencode/agent-analytics package with SQLite storage
- Implement metrics collection for tool calls, delegations, sessions
- Add agent-analytics hook for automatic performance tracking
- Add 'omo analytics' CLI with summary, agent, trends, and clear commands
- Include comprehensive test suite

Closes #1

- Create @oh-my-opencode/agent-analytics package with SQLite storage
- Implement metrics collection for tool calls, delegations, sessions
- Add agent-analytics hook for automatic performance tracking
- Add 'omo analytics' CLI with summary, agent, trends, and clear commands
- Include comprehensive test suite

Closes #1

- Create @oh-my-opencode/agent-analytics package with SQLite storage
- Implement metrics collection for tool calls, delegations, sessions
- Add agent-analytics hook for automatic performance tracking
- Add 'omo analytics' CLI with summary, agent, trends, and clear commands
- Include comprehensive test suite

Closes #1