oh-my-opencode 4.18.0 → 4.18.2

package/.agents/skills/work-with-pr/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: work-with-pr
-description: "Full PR lifecycle in a fresh task-owned git worktree: implement via the ulw-loop skill with mandatory evidence-bound manual QA → reviewer-readable English PR → verification loop (CI + review-work reviewers + Cubic, where Cubic is skipped only when its quota is exhausted) → merge by default → worktree cleanup. Decomposes one task into the smallest atomic, independently-mergeable PRs and builds the independent ones concurrently via one worktree per PR driven by parallel subagents or a team. Unbounded loop: any failing gate sends you back to fix-and-re-QA inside that PR's worktree. Use whenever implementation work needs to land as a PR. Triggers: 'create a PR', 'implement and PR', 'work on this and make a PR', 'implement issue', 'land this as a PR', 'split into atomic PRs', 'parallel PRs', 'work-with-pr', 'PR workflow', 'implement end to end', even when user just says 'implement X' if the context implies PR delivery."
+description: "Full PR lifecycle in a fresh task-owned git worktree: implement via the ulw-loop skill with mandatory evidence-bound manual QA → reviewer-readable English PR → verification loop (CI + Cubic, where Cubic is skipped only when its quota is exhausted) → merge by default → worktree cleanup. Decomposes one task into the smallest atomic, independently-mergeable PRs and builds the independent ones concurrently via one worktree per PR driven by parallel subagents or a team. Unbounded loop: any failing gate sends you back to fix-and-re-QA inside that PR's worktree. Use whenever implementation work needs to land as a PR. Triggers: 'create a PR', 'implement and PR', 'work on this and make a PR', 'implement issue', 'land this as a PR', 'split into atomic PRs', 'parallel PRs', 'work-with-pr', 'PR workflow', 'implement end to end', even when user just says 'implement X' if the context implies PR delivery."
 ---
 
 # Work With PR — Full PR Lifecycle
 
-You are executing a complete PR lifecycle: from fresh task-owned worktree setup, through `ulw-loop`-driven implementation with evidence-bound manual QA, PR creation, and an unbounded verification loop until the PR is merged. The loop has three gates — CI, review-work, and Cubic — and a failing gate sends you back into that PR's worktree to fix and re-QA. You keep cycling until every active gate passes at once.
+You are executing a complete PR lifecycle: from fresh task-owned worktree setup, through `ulw-loop`-driven implementation with evidence-bound manual QA, PR creation, and an unbounded verification loop until the PR is merged. The loop has two gates — CI and Cubic — and a failing gate sends you back into that PR's worktree to fix and re-QA. You keep cycling until every active gate passes at once.
 
 **The unit of delivery is the smallest PR that compiles, passes, and stands on its own — not "one task, one PR."** A single task routinely splits into several atomic PRs; the lifecycle below describes ONE of them, so apply it to each, and build the independent ones concurrently (Phase 0).
 
@@ -18,8 +18,7 @@ Phase 1: Implement     → Drive the work through the ulw-loop skill:
 Phase 2: PR Creation   → Push, create a reviewer-readable English PR targeting dev
 Phase 3: Verify Loop   → Unbounded iteration; a failing gate routes back to Phase 1:
   ├─ Gate A: CI         → gh pr checks (bun test, typecheck, build)
-  ├─ Gate B: review-work → 5-agent parallel review (the reviewer subagents)
-  └─ Gate C: Cubic      → cubic-dev-ai[bot] "No issues found"
+  └─ Gate B: Cubic      → cubic-dev-ai[bot] "No issues found"
                          (SKIPPED, not failed, when Cubic's quota is exhausted)
 Phase 4: Merge         → Auto-merge by default; wait until actually merged, then worktree cleanup
 ```
@@ -30,7 +29,7 @@ Phase 4: Merge         → Auto-merge by default; wait until actually merged, th
 
 ## Phase 0: Setup
 
-Create a fresh isolated worktree for each PR before implementation or review work starts. The user's main working directory is read-only context — it may have uncommitted work, and a branch checkout would destroy it. Isolation also makes parallelism cheap: one worktree per PR, so several build at once without colliding.
+Create a fresh isolated worktree for each PR before implementation starts. The user's main working directory is read-only context — it may have uncommitted work, and a branch checkout would destroy it. Isolation also makes parallelism cheap: one worktree per PR, so several build at once without colliding.
 
 <setup>
 
@@ -181,7 +180,7 @@ PR_NUMBER=$(gh pr view --json number -q .number)
 
 ## Phase 3: Verification Loop
 
-This is the core of the skill. Every active gate must pass for the PR to be ready. The loop has no iteration cap — keep going until done. Gate ordering is intentional: CI is cheapest/fastest, review-work is most thorough, Cubic is external and asynchronous. Gate C (Cubic) is the one gate that can be SKIPPED rather than satisfied — only when its quota is exhausted; it is never skipped just because it found issues. A failing gate is not a patch-and-push: route back to Phase 1, where fixes get the same scope discipline and, if behavior changed, fresh manual-QA evidence before you re-enter the loop.
+This is the core of the skill. Every active gate must pass for the PR to be ready. The loop has no iteration cap — keep going until done. Gate ordering is intentional: CI is cheapest/fastest; Cubic is external and asynchronous. Gate B (Cubic) is the one gate that can be SKIPPED rather than satisfied — only when its quota is exhausted; it is never skipped just because it found issues. A failing gate is not a patch-and-push: route back to Phase 1, where fixes get the same scope discipline and, if behavior changed, fresh manual-QA evidence before you re-enter the loop.
 
 <verify_loop>
 
@@ -189,12 +188,10 @@ This is the core of the skill. Every active gate must pass for the PR to be read
 while true:
   1. Wait for CI          → Gate A
   2. If CI fails          → back to Phase 1: read logs, fix + re-QA, commit, push, continue
-  3. Run review-work      → Gate B (the reviewer subagents)
-  4. If review fails      → back to Phase 1: fix blocking issues + re-QA, commit, push, continue
-  5. Check Cubic          → Gate C
-  6. If Cubic has issues   → back to Phase 1: fix + re-QA, commit, push, continue
-  7. If Cubic quota out    → record Gate C SKIPPED, stop waiting on it
-  8. All active gates pass → break
+  3. Check Cubic          → Gate B
+  4. If Cubic has issues   → back to Phase 1: fix + re-QA, commit, push, continue
+  5. If Cubic quota out    → record Gate B SKIPPED, stop waiting on it
+  6. All active gates pass → break
 ```
 
 ### Gate A: CI Checks
@@ -219,25 +216,7 @@ gh run view "$RUN_ID" --log-failed
 
 Read the logs, then fix per the iteration discipline below.
 
-### Gate B: review-work
-
-The review-work skill launches 5 parallel sub-agents (goal verification, QA, code quality, security, context mining). All 5 must pass.
-
-Invoke review-work after CI passes — there's no point reviewing code that doesn't build:
-
-```
-task(
-  category="unspecified-high",
-  load_skills=["review-work"],
-  run_in_background=false,
-  description="Post-implementation review of PR changes",
-  prompt="Review the implementation work on branch {BRANCH_NAME}. The worktree is at {WORKTREE_PATH}. Goal: {ORIGINAL_GOAL}. Constraints: {CONSTRAINTS}. Run command: bun run dev (or as appropriate)."
-)
-```
-
-**On failure**: review-work reports blocking issues with specific files and line numbers. Fix each blocking issue per the iteration discipline below.
-
-### Gate C: Cubic Approval
+### Gate B: Cubic Approval
 
 Cubic (`cubic-dev-ai[bot]`) is an automated review bot that comments on PRs. It does NOT use GitHub's APPROVED review state — instead it posts comments with issue counts and confidence scores.
 
@@ -245,7 +224,7 @@ Cubic (`cubic-dev-ai[bot]`) is an automated review bot that comments on PRs. It
 
 **Issue signal**: The comment lists issues with file-level detail.
 
-**Quota-exhausted signal**: Cubic posts a usage/quota/limit message instead of a review, or no Cubic review appears within the bounded wait below. This is the ONLY case where you skip Gate C and proceed — record it as SKIPPED in the final report, never silently. Issues are never a reason to skip.
+**Quota-exhausted signal**: Cubic posts a usage/quota/limit message instead of a review, or no Cubic review appears within the bounded wait below. This is the ONLY case where you skip Gate B and proceed — record it as SKIPPED in the final report, never silently. Issues are never a reason to skip.
 
 ```bash
 # Get the latest Cubic review
@@ -255,7 +234,7 @@ CUBIC_REVIEW=$(gh api "repos/${REPO}/pulls/${PR_NUMBER}/reviews" \
 if echo "$CUBIC_REVIEW" | grep -q "No issues found"; then
   echo "Cubic: APPROVED"
 elif echo "$CUBIC_REVIEW" | grep -qiE "quota|usage limit|rate limit|out of (credits|reviews)|upgrade your plan"; then
-  echo "Cubic: SKIPPED (quota exhausted)"   # Gate C satisfied-by-skip; do not loop on it
+  echo "Cubic: SKIPPED (quota exhausted)"   # Gate B satisfied-by-skip; do not loop on it
 else
   echo "Cubic: ISSUES FOUND"
   echo "$CUBIC_REVIEW"
@@ -268,7 +247,7 @@ Cubic reviews are triggered automatically on PR updates. After pushing a fix, wa
 
 ```bash
 # Wait for a NEW Cubic review after push. If none arrives within the bound,
-# Cubic is out of quota (or not running) → skip Gate C rather than spin forever.
+# Cubic is out of quota (or not running) → skip Gate B rather than spin forever.
 PUSH_TIME=$(date -u +%Y-%m-%dT%H:%M:%SZ)
 for _ in $(seq 1 30); do
   LATEST_REVIEW_TIME=$(gh api "repos/${REPO}/pulls/${PR_NUMBER}/reviews" \
@@ -276,7 +255,7 @@ for _ in $(seq 1 30); do
   [[ "$LATEST_REVIEW_TIME" > "$PUSH_TIME" ]] && break
   timeout 20 gh pr checks "$PR_NUMBER" --watch >/dev/null 2>&1 || true  # spend the interval usefully
 done
-# Loop exhausted without a newer review → treat Gate C as SKIPPED (quota exhausted)
+# Loop exhausted without a newer review → treat Gate B as SKIPPED (quota exhausted)
 [[ "$LATEST_REVIEW_TIME" > "$PUSH_TIME" ]] || echo "Cubic: SKIPPED (no review within bound — quota exhausted)"
 ```
 
@@ -357,7 +336,7 @@ Summarize what happened:
 - **PR**: #{PR_NUMBER} — {PR_TITLE}
 - **Branch**: {BRANCH_NAME} → {BASE_BRANCH}
 - **Iterations**: {N} verification loops
-- **Gates**: CI pass | review-work pass | Cubic {pass | SKIPPED (quota exhausted)}
+- **Gates**: CI pass | Cubic {pass | SKIPPED (quota exhausted)}
 - **Merged**: {yes | no — left for you to merge, as requested}
 - **Worktree**: cleaned up
 ```
@@ -396,7 +375,7 @@ git rebase "origin/$BASE_BRANCH"
 | Working in main worktree instead of isolated worktree | Pollutes user's working directory, may destroy uncommitted work | CRITICAL |
 | Committing or pushing without manual-QA evidence on disk | "Tests pass" never proves the feature works; the repo forbids it for OpenCode/Codex-touching changes | CRITICAL |
 | Pushing directly to dev/master | Bypasses review entirely | CRITICAL |
-| Skipping CI gate after code changes | review-work and Cubic may pass on stale code | CRITICAL |
+| Skipping CI gate after code changes | Cubic may pass on stale code | CRITICAL |
 | Skipping Cubic because it found issues | Only an exhausted quota justifies a skip; real issues must be fixed and re-pushed | HIGH |
 | Fixing unrelated code during verification loop | Scope creep causes new failures | HIGH |
 | Deleting worktree on failure | User loses ability to inspect/resume | HIGH |

package/.agents/skills/work-with-pr-workspace/evals/evals.json

@@ -12,8 +12,8 @@
         {"id": "atomic-commits", "text": "Plan specifies multiple atomic commits for multi-file changes"},
         {"id": "local-validation", "text": "Runs bun run typecheck, bun test, and bun run build before pushing"},
         {"id": "pr-targets-dev", "text": "PR is created targeting dev branch (not master)"},
-        {"id": "three-gates", "text": "Verification loop includes all 3 gates: CI, review-work, and Cubic"},
-        {"id": "gate-ordering", "text": "Gates are checked in order: CI first, then review-work, then Cubic"},
+        {"id": "two-gates", "text": "Verification loop includes both gates: CI and Cubic"},
+        {"id": "gate-ordering", "text": "Gates are checked in order: CI first, then Cubic"},
         {"id": "cubic-check-method", "text": "Cubic check uses gh api to check cubic-dev-ai[bot] reviews for 'No issues found'"},
         {"id": "worktree-cleanup", "text": "Plan includes worktree cleanup after merge"},
         {"id": "real-file-references", "text": "Code changes reference actual files in the codebase (config schema, background manager)"}
@@ -28,7 +28,7 @@
         {"id": "worktree-isolation", "text": "Plan uses git worktree in a sibling directory"},
         {"id": "minimal-fix", "text": "Fix is minimal — adds null check, doesn't refactor unrelated code"},
         {"id": "test-added", "text": "Test case added for the missing worktree_path scenario"},
-        {"id": "three-gates", "text": "Verification loop includes all 3 gates: CI, review-work, Cubic"},
+        {"id": "two-gates", "text": "Verification loop includes both gates: CI, Cubic"},
         {"id": "real-atlas-files", "text": "References actual atlas hook files in src/hooks/atlas/"},
         {"id": "fix-branch-naming", "text": "Branch name follows fix/ prefix convention"}
       ]

package/.opencode/skills/work-with-pr/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: work-with-pr
-description: "Full PR lifecycle in a fresh task-owned git worktree: implement via the ulw-loop skill with mandatory evidence-bound manual QA → reviewer-readable English PR → verification loop (CI + review-work reviewers + Cubic, where Cubic is skipped only when its quota is exhausted) → merge by default → worktree cleanup. Decomposes one task into the smallest atomic, independently-mergeable PRs and builds the independent ones concurrently via one worktree per PR driven by parallel subagents or a team. Unbounded loop: any failing gate sends you back to fix-and-re-QA inside that PR's worktree. Use whenever implementation work needs to land as a PR. Triggers: 'create a PR', 'implement and PR', 'work on this and make a PR', 'implement issue', 'land this as a PR', 'split into atomic PRs', 'parallel PRs', 'work-with-pr', 'PR workflow', 'implement end to end', even when user just says 'implement X' if the context implies PR delivery."
+description: "Full PR lifecycle in a fresh task-owned git worktree: implement via the ulw-loop skill with mandatory evidence-bound manual QA → reviewer-readable English PR → verification loop (CI + Cubic, where Cubic is skipped only when its quota is exhausted) → merge by default → worktree cleanup. Decomposes one task into the smallest atomic, independently-mergeable PRs and builds the independent ones concurrently via one worktree per PR driven by parallel subagents or a team. Unbounded loop: any failing gate sends you back to fix-and-re-QA inside that PR's worktree. Use whenever implementation work needs to land as a PR. Triggers: 'create a PR', 'implement and PR', 'work on this and make a PR', 'implement issue', 'land this as a PR', 'split into atomic PRs', 'parallel PRs', 'work-with-pr', 'PR workflow', 'implement end to end', even when user just says 'implement X' if the context implies PR delivery."
 ---
 
 # Work With PR — Full PR Lifecycle
 
-You are executing a complete PR lifecycle: from fresh task-owned worktree setup, through `ulw-loop`-driven implementation with evidence-bound manual QA, PR creation, and an unbounded verification loop until the PR is merged. The loop has three gates — CI, review-work, and Cubic — and a failing gate sends you back into that PR's worktree to fix and re-QA. You keep cycling until every active gate passes at once.
+You are executing a complete PR lifecycle: from fresh task-owned worktree setup, through `ulw-loop`-driven implementation with evidence-bound manual QA, PR creation, and an unbounded verification loop until the PR is merged. The loop has two gates — CI and Cubic — and a failing gate sends you back into that PR's worktree to fix and re-QA. You keep cycling until every active gate passes at once.
 
 **The unit of delivery is the smallest PR that compiles, passes, and stands on its own — not "one task, one PR."** A single task routinely splits into several atomic PRs; the lifecycle below describes ONE of them, so apply it to each, and build the independent ones concurrently (Phase 0).
 
@@ -18,8 +18,7 @@ Phase 1: Implement     → Drive the work through the ulw-loop skill:
 Phase 2: PR Creation   → Push, create a reviewer-readable English PR targeting dev
 Phase 3: Verify Loop   → Unbounded iteration; a failing gate routes back to Phase 1:
   ├─ Gate A: CI         → gh pr checks (bun test, typecheck, build)
-  ├─ Gate B: review-work → 5-agent parallel review (the reviewer subagents)
-  └─ Gate C: Cubic      → cubic-dev-ai[bot] "No issues found"
+  └─ Gate B: Cubic      → cubic-dev-ai[bot] "No issues found"
                          (SKIPPED, not failed, when Cubic's quota is exhausted)
 Phase 4: Merge         → Auto-merge by default; wait until actually merged, then worktree cleanup
 ```
@@ -30,7 +29,7 @@ Phase 4: Merge         → Auto-merge by default; wait until actually merged, th
 
 ## Phase 0: Setup
 
-Create a fresh isolated worktree for each PR before implementation or review work starts. The user's main working directory is read-only context — it may have uncommitted work, and a branch checkout would destroy it. Isolation also makes parallelism cheap: one worktree per PR, so several build at once without colliding.
+Create a fresh isolated worktree for each PR before implementation starts. The user's main working directory is read-only context — it may have uncommitted work, and a branch checkout would destroy it. Isolation also makes parallelism cheap: one worktree per PR, so several build at once without colliding.
 
 <setup>
 
@@ -181,7 +180,7 @@ PR_NUMBER=$(gh pr view --json number -q .number)
 
 ## Phase 3: Verification Loop
 
-This is the core of the skill. Every active gate must pass for the PR to be ready. The loop has no iteration cap — keep going until done. Gate ordering is intentional: CI is cheapest/fastest, review-work is most thorough, Cubic is external and asynchronous. Gate C (Cubic) is the one gate that can be SKIPPED rather than satisfied — only when its quota is exhausted; it is never skipped just because it found issues. A failing gate is not a patch-and-push: route back to Phase 1, where fixes get the same scope discipline and, if behavior changed, fresh manual-QA evidence before you re-enter the loop.
+This is the core of the skill. Every active gate must pass for the PR to be ready. The loop has no iteration cap — keep going until done. Gate ordering is intentional: CI is cheapest/fastest; Cubic is external and asynchronous. Gate B (Cubic) is the one gate that can be SKIPPED rather than satisfied — only when its quota is exhausted; it is never skipped just because it found issues. A failing gate is not a patch-and-push: route back to Phase 1, where fixes get the same scope discipline and, if behavior changed, fresh manual-QA evidence before you re-enter the loop.
 
 <verify_loop>
 
@@ -189,12 +188,10 @@ This is the core of the skill. Every active gate must pass for the PR to be read
 while true:
   1. Wait for CI          → Gate A
   2. If CI fails          → back to Phase 1: read logs, fix + re-QA, commit, push, continue
-  3. Run review-work      → Gate B (the reviewer subagents)
-  4. If review fails      → back to Phase 1: fix blocking issues + re-QA, commit, push, continue
-  5. Check Cubic          → Gate C
-  6. If Cubic has issues   → back to Phase 1: fix + re-QA, commit, push, continue
-  7. If Cubic quota out    → record Gate C SKIPPED, stop waiting on it
-  8. All active gates pass → break
+  3. Check Cubic          → Gate B
+  4. If Cubic has issues   → back to Phase 1: fix + re-QA, commit, push, continue
+  5. If Cubic quota out    → record Gate B SKIPPED, stop waiting on it
+  6. All active gates pass → break
 ```
 
 ### Gate A: CI Checks
@@ -219,25 +216,7 @@ gh run view "$RUN_ID" --log-failed
 
 Read the logs, then fix per the iteration discipline below.
 
-### Gate B: review-work
-
-The review-work skill launches 5 parallel sub-agents (goal verification, QA, code quality, security, context mining). All 5 must pass.
-
-Invoke review-work after CI passes — there's no point reviewing code that doesn't build:
-
-```
-task(
-  category="unspecified-high",
-  load_skills=["review-work"],
-  run_in_background=false,
-  description="Post-implementation review of PR changes",
-  prompt="Review the implementation work on branch {BRANCH_NAME}. The worktree is at {WORKTREE_PATH}. Goal: {ORIGINAL_GOAL}. Constraints: {CONSTRAINTS}. Run command: bun run dev (or as appropriate)."
-)
-```
-
-**On failure**: review-work reports blocking issues with specific files and line numbers. Fix each blocking issue per the iteration discipline below.
-
-### Gate C: Cubic Approval
+### Gate B: Cubic Approval
 
 Cubic (`cubic-dev-ai[bot]`) is an automated review bot that comments on PRs. It does NOT use GitHub's APPROVED review state — instead it posts comments with issue counts and confidence scores.
 
@@ -245,7 +224,7 @@ Cubic (`cubic-dev-ai[bot]`) is an automated review bot that comments on PRs. It
 
 **Issue signal**: The comment lists issues with file-level detail.
 
-**Quota-exhausted signal**: Cubic posts a usage/quota/limit message instead of a review, or no Cubic review appears within the bounded wait below. This is the ONLY case where you skip Gate C and proceed — record it as SKIPPED in the final report, never silently. Issues are never a reason to skip.
+**Quota-exhausted signal**: Cubic posts a usage/quota/limit message instead of a review, or no Cubic review appears within the bounded wait below. This is the ONLY case where you skip Gate B and proceed — record it as SKIPPED in the final report, never silently. Issues are never a reason to skip.
 
 ```bash
 # Get the latest Cubic review
@@ -255,7 +234,7 @@ CUBIC_REVIEW=$(gh api "repos/${REPO}/pulls/${PR_NUMBER}/reviews" \
 if echo "$CUBIC_REVIEW" | grep -q "No issues found"; then
   echo "Cubic: APPROVED"
 elif echo "$CUBIC_REVIEW" | grep -qiE "quota|usage limit|rate limit|out of (credits|reviews)|upgrade your plan"; then
-  echo "Cubic: SKIPPED (quota exhausted)"   # Gate C satisfied-by-skip; do not loop on it
+  echo "Cubic: SKIPPED (quota exhausted)"   # Gate B satisfied-by-skip; do not loop on it
 else
   echo "Cubic: ISSUES FOUND"
   echo "$CUBIC_REVIEW"
@@ -268,7 +247,7 @@ Cubic reviews are triggered automatically on PR updates. After pushing a fix, wa
 
 ```bash
 # Wait for a NEW Cubic review after push. If none arrives within the bound,
-# Cubic is out of quota (or not running) → skip Gate C rather than spin forever.
+# Cubic is out of quota (or not running) → skip Gate B rather than spin forever.
 PUSH_TIME=$(date -u +%Y-%m-%dT%H:%M:%SZ)
 for _ in $(seq 1 30); do
   LATEST_REVIEW_TIME=$(gh api "repos/${REPO}/pulls/${PR_NUMBER}/reviews" \
@@ -276,7 +255,7 @@ for _ in $(seq 1 30); do
   [[ "$LATEST_REVIEW_TIME" > "$PUSH_TIME" ]] && break
   timeout 20 gh pr checks "$PR_NUMBER" --watch >/dev/null 2>&1 || true  # spend the interval usefully
 done
-# Loop exhausted without a newer review → treat Gate C as SKIPPED (quota exhausted)
+# Loop exhausted without a newer review → treat Gate B as SKIPPED (quota exhausted)
 [[ "$LATEST_REVIEW_TIME" > "$PUSH_TIME" ]] || echo "Cubic: SKIPPED (no review within bound — quota exhausted)"
 ```
 
@@ -357,7 +336,7 @@ Summarize what happened:
 - **PR**: #{PR_NUMBER} — {PR_TITLE}
 - **Branch**: {BRANCH_NAME} → {BASE_BRANCH}
 - **Iterations**: {N} verification loops
-- **Gates**: CI pass | review-work pass | Cubic {pass | SKIPPED (quota exhausted)}
+- **Gates**: CI pass | Cubic {pass | SKIPPED (quota exhausted)}
 - **Merged**: {yes | no — left for you to merge, as requested}
 - **Worktree**: cleaned up
 ```
@@ -396,7 +375,7 @@ git rebase "origin/$BASE_BRANCH"
 | Working in main worktree instead of isolated worktree | Pollutes user's working directory, may destroy uncommitted work | CRITICAL |
 | Committing or pushing without manual-QA evidence on disk | "Tests pass" never proves the feature works; the repo forbids it for OpenCode/Codex-touching changes | CRITICAL |
 | Pushing directly to dev/master | Bypasses review entirely | CRITICAL |
-| Skipping CI gate after code changes | review-work and Cubic may pass on stale code | CRITICAL |
+| Skipping CI gate after code changes | Cubic may pass on stale code | CRITICAL |
 | Skipping Cubic because it found issues | Only an exhausted quota justifies a skip; real issues must be fixed and re-pushed | HIGH |
 | Fixing unrelated code during verification loop | Scope creep causes new failures | HIGH |
 | Deleting worktree on failure | User loses ability to inspect/resume | HIGH |

package/.opencode/skills/work-with-pr-workspace/evals/evals.json

@@ -12,8 +12,8 @@
         {"id": "atomic-commits", "text": "Plan specifies multiple atomic commits for multi-file changes"},
         {"id": "local-validation", "text": "Runs bun run typecheck, bun test, and bun run build before pushing"},
         {"id": "pr-targets-dev", "text": "PR is created targeting dev branch (not master)"},
-        {"id": "three-gates", "text": "Verification loop includes all 3 gates: CI, review-work, and Cubic"},
-        {"id": "gate-ordering", "text": "Gates are checked in order: CI first, then review-work, then Cubic"},
+        {"id": "two-gates", "text": "Verification loop includes both gates: CI and Cubic"},
+        {"id": "gate-ordering", "text": "Gates are checked in order: CI first, then Cubic"},
         {"id": "cubic-check-method", "text": "Cubic check uses gh api to check cubic-dev-ai[bot] reviews for 'No issues found'"},
         {"id": "worktree-cleanup", "text": "Plan includes worktree cleanup after merge"},
         {"id": "real-file-references", "text": "Code changes reference actual files in the codebase (config schema, background manager)"}
@@ -28,7 +28,7 @@
         {"id": "worktree-isolation", "text": "Plan uses git worktree in a sibling directory"},
         {"id": "minimal-fix", "text": "Fix is minimal — adds null check, doesn't refactor unrelated code"},
         {"id": "test-added", "text": "Test case added for the missing worktree_path scenario"},
-        {"id": "three-gates", "text": "Verification loop includes all 3 gates: CI, review-work, Cubic"},
+        {"id": "two-gates", "text": "Verification loop includes both gates: CI, Cubic"},
         {"id": "real-atlas-files", "text": "References actual atlas hook files in src/hooks/atlas/"},
         {"id": "fix-branch-naming", "text": "Branch name follows fix/ prefix convention"}
       ]

package/bin/AGENTS.md

@@ -0,0 +1,33 @@
+# bin/ - Published Launcher Shim
+
+## OVERVIEW
+
+Node-side launch surface for every public CLI alias. The root shim resolves a platform package and spawns its generated `bin/oh-my-opencode.js` launcher payload; it is not the TypeScript CLI implementation.
+
+## WHERE TO LOOK
+
+| Task | Location | Notes |
+|------|----------|-------|
+| Main launcher | `oh-my-opencode.js` | Entry for `oh-my-opencode`, `oh-my-openagent`, `omo`, `lazycodex`, and `lazycodex-ai` |
+| Platform selection | `platform.js` | OS/arch/libc package candidates and baseline fallback |
+| Platform types | `platform.d.ts` | Public declarations for the plain-JS selector |
+| Version mismatch output | `version-mismatch.js` | User-facing installed-wrapper/platform-package mismatch diagnostics |
+| Behavior tests | `*.test.ts` | Bun tests for invocation routing, platform selection, and diagnostics |
+
+## RUNTIME FLOW
+
+`oh-my-opencode.js` derives the invocation name, optionally routes the LazyCodex Node installer, resolves an ordered list of `oh-my-opencode-*` or `oh-my-openagent-*` platform package candidates, then spawns the first installed package's generated `bin/oh-my-opencode.js` launcher. Each generated Node launcher runs root `dist/cli` with Bun and, when Bun is missing or exits with `SIGILL`, falls back to root `dist/cli-node` with Node. The root shim retains ordered package fallback compatibility, including x64 `-baseline` candidates, but current generated platform payloads are identical Node scripts, so a Bun `SIGILL` is normally handled inside the selected launcher rather than by switching to a baseline package.
+
+## CONVENTIONS
+
+- Keep this surface Node-compatible; the root shim and generated launcher payloads are plain Node scripts.
+- Preserve all five aliases. Alias-to-platform-family behavior is shared with `postinstall.mjs` and publish-time package rewrites.
+- Keep error output actionable: report the detected platform and the ordered package candidates.
+- Tests run from the root with `bun test bin` or as part of `bun test`.
+
+## ANTI-PATTERNS
+
+- Do not import adapter source from `packages/omo-opencode/src/`; this shim must remain usable from the published package layout.
+- Do not hard-code one npm package family. `oh-my-opencode` and `oh-my-openagent` wrappers share the launcher.
+- Do not edit generated launcher payloads under `packages/oh-my-opencode-*/bin/`; regenerate them through `script/build-binaries.ts`.
+- Do not remove baseline fallback without updating platform tests and publish-platform coverage.