feat(M2): Documentation flow, accuracy, consistency cleanup, and cross-platform shell portability

2026-05-03 20:14:44 -05:00
parent 0443381aa0
commit be993429c1
59 changed files with 1898 additions and 385 deletions
@@ -12,6 +12,7 @@ Execute an existing plan (created by `create-plan`) in an isolated git worktree,
 This OpenCode variant depends on Superpowers execution skills being installed via OpenCode's native skill system.

 Required:
+
 - Plan folder exists under `ai_plan/` at project root
 - `continuation-runbook.md` exists in plan folder
 - `milestone-plan.md` exists in plan folder
@@ -46,6 +47,7 @@ If no plan folder exists:
 ### Phase 1: Bootstrap Superpowers Context (REQUIRED)

 Use OpenCode's native skill tool:
+
 - list skills
 - verify `superpowers/executing-plans`, `superpowers/using-git-worktrees`, `superpowers/verification-before-completion`, and `superpowers/finishing-a-development-branch` are discoverable

@@ -81,7 +83,6 @@ Store `REVIEWER_CLI`, `REVIEWER_MODEL`, and `MAX_ROUNDS`. These values are fixed

 Reviewer CLI: `codex`, `claude`, `cursor`, `opencode`, `pi`, or `skip`.

-
 If `REVIEWER_CLI=pi`, verify the Pi reviewer binary before entering the review loop:

 ```bash
@@ -95,9 +96,11 @@ When `REVIEWER_CLI=pi`, the reviewer model is configured independently from the
 ### Phase 4: Set Up Worktree (REQUIRED SUB-SKILL)

 Use OpenCode's native skill tool to load:
+
 - `superpowers/using-git-worktrees`

 Then:
+
 1. Branch naming: `implement/<plan-folder-name>` (e.g., `implement/2026-03-04-auth-system`).
 2. Follow worktree skill's directory priority: `.worktrees/` > `worktrees/` > CLAUDE.md > ask user.
 3. Verify `.gitignore` covers worktree directory.
@@ -121,6 +124,7 @@ Mark first story `in-dev` in `story-tracker.md`.
 #### Step 3: Implement Stories

 Execute each story in order. After completing each story:
+
 1. Mark `in-dev` -> `completed` in `story-tracker.md`
 2. Update counts
 3. Mark next story `in-dev`
@@ -130,6 +134,7 @@ Commit hashes are not available yet — they are backfilled in Step 6 after the
 #### Step 4: Verify Milestone (REQUIRED SUB-SKILL)

 Use OpenCode's native skill tool to load:
+
 - `superpowers/verification-before-completion`

 ```bash
@@ -156,6 +161,7 @@ git commit -m "feat(<scope>): implement milestone M<N> - <description>"
 ```

 Do NOT push. After committing:
+
 1. Backfill the commit hash into the Notes column for all stories in this milestone in `story-tracker.md`.
 2. Mark milestone as `approved` in `story-tracker.md`.
 3. Move to next milestone.
@@ -171,6 +177,7 @@ REVIEW_ID=$(uuidgen | tr '[:upper:]' '[:lower:]' | head -c 8)
 ```

 Use `REVIEW_ID` for all milestone review temp file paths:
+
 - `/tmp/milestone-${REVIEW_ID}.md`
 - `/tmp/milestone-review-${REVIEW_ID}.md`
 - `/tmp/milestone-review-${REVIEW_ID}.json`
@@ -196,6 +203,9 @@ case "$REVIEWER_CLI" in
  cursor)
    HELPER_SUCCESS_FILE_ARGS+=(--success-file /tmp/milestone-review-${REVIEW_ID}.json)
    ;;
+  opencode)
+    HELPER_SUCCESS_FILE_ARGS+=(--success-file /tmp/milestone-review-${REVIEW_ID}.md)
+    ;;
 esac
 ```

@@ -247,6 +257,7 @@ VERDICT: APPROVED
 ```

 Rules:
+
 - Order findings from `P0` to `P3`.
 - `P0` = total blocker, `P1` = major risk, `P2` = must-fix before approval, `P3` = cosmetic / nice to have.
 - Use `- None.` when a severity has no findings.
@@ -269,7 +280,6 @@ Write the reviewer invocation to `/tmp/milestone-review-${REVIEW_ID}.sh` as a ba
 set -euo pipefail
 ```

-
 **If `REVIEWER_CLI` is `pi`:**

 Fresh call every round (Pi reviewer calls do not use session resume):
@@ -391,6 +401,77 @@ Rules:

 For `cursor`, the command script writes raw JSON to `/tmp/milestone-review-${REVIEW_ID}.json`. Do not run `jq` extraction until after the helper or fallback execution completes. If `jq` is not installed, inform the user: `brew install jq` (macOS) or equivalent.

+**If `REVIEWER_CLI` is `opencode`:**
+
+OpenCode uses `--agent plan` for read-oriented review. Fresh call is the recommended default.
+
+Round 1:
+
+```bash
+opencode run \
+  -m ${REVIEWER_MODEL} \
+  --agent plan \
+  --format json \
+  "Read the file /tmp/milestone-${REVIEW_ID}.md and review this milestone implementation.
+
+Evaluate:
+1. Correctness — Does the implementation match the milestone spec?
+2. Acceptance criteria — Are all criteria met?
+3. Code quality — Clean, maintainable, no obvious issues?
+4. Test coverage — Are changes adequately tested?
+5. Security — Any security concerns introduced?
+
+Return exactly these sections in order:
+## Summary
+## Findings
+### P0
+### P1
+### P2
+### P3
+## Verdict
+
+Rules:
+- Order findings from highest severity to lowest.
+- Use \`- None.\` when a severity has no findings.
+- \`P0\` = total blocker, \`P1\` = major risk, \`P2\` = must-fix before approval, \`P3\` = cosmetic / nice to have.
+- End with exactly one verdict line: \`VERDICT: APPROVED\` or \`VERDICT: REVISE\`
+- \`VERDICT: APPROVED\` is allowed only when there are no \`P0\`, \`P1\`, or \`P2\` findings. \`P3\` findings are non-blocking." \
+  > /tmp/milestone-review-${REVIEW_ID}.json
+```
+
+Round 2 and later (fresh-call, recommended default):
+
+```bash
+opencode run \
+  -m ${REVIEWER_MODEL} \
+  --agent plan \
+  --format json \
+  "You previously reviewed this milestone and requested revisions.
+
+Previous feedback summary: [key points from last review]
+
+I've revised. Updated milestone payload is in /tmp/milestone-${REVIEW_ID}.md.
+
+Changes made:
+[List specific changes]
+
+Re-review using the same ## Summary, ## Findings, and ## Verdict structure as before." \
+  > /tmp/milestone-review-${REVIEW_ID}.json
+```
+
+Extract the review body:
+
+```bash
+jq -r '.[] | select(.type == "message" and .role == "assistant") | .content' \
+  /tmp/milestone-review-${REVIEW_ID}.json \
+  > /tmp/milestone-review-${REVIEW_ID}.md \
+  || cp /tmp/milestone-review-${REVIEW_ID}.json /tmp/milestone-review-${REVIEW_ID}.md
+```
+
+If the JSON parse falls through, promote the raw JSON file as the review output. On any opencode
+CLI or JSON parsing failure, treat this loop round as `completed-empty-output` and follow the
+helper-failure escalation in Step 4.
+
 Run the command script through the shared helper when available:

 ```bash
@@ -410,6 +491,7 @@ fi
 Run the helper in the foreground and watch its live stdout for `state=in-progress` heartbeats. If your agent environment buffers command output until exit, start the helper in the background and poll `/tmp/milestone-review-${REVIEW_ID}.status` separately instead of treating heartbeats as post-hoc-only data.

 After the command completes:
+
 - If `REVIEWER_CLI=cursor`, extract the final review text:

 ```bash
@@ -418,6 +500,7 @@ jq -r '.result' /tmp/milestone-review-${REVIEW_ID}.json > /tmp/milestone-review-
 ```

 - If `REVIEWER_CLI=codex`, extract `CODEX_SESSION_ID` from `/tmp/milestone-review-${REVIEW_ID}.runner.out` after the helper or fallback run. If the review text is only in `.runner.out`, move or copy the actual review body into `/tmp/milestone-review-${REVIEW_ID}.md` before verdict parsing.
+- If `REVIEWER_CLI=opencode`, the `jq` extraction above covers output capture. If it falls through, copy runner output: `cp /tmp/milestone-review-${REVIEW_ID}.runner.out /tmp/milestone-review-${REVIEW_ID}.md`. On Round 1, also attempt to capture the session id for optional use in subsequent rounds: `OPENCODE_SESSION_ID=$(jq -r 'if type == "array" then (.[0] | (.id? // .session_id?)) else (.id? // .session_id?) end // empty' /tmp/milestone-review-${REVIEW_ID}.json 2>/dev/null || true)`
 - If `REVIEWER_CLI=claude` or `REVIEWER_CLI=pi`, promote stdout captured by the helper or fallback runner into the markdown review file:

 ```bash
@@ -435,14 +518,14 @@ Fallback is allowed only when the helper is missing or not executable.
   - `/tmp/milestone-review-${REVIEW_ID}.runner.out`
 3. Present review to the user:

-```
+```markdown
 ## Milestone Review — Round N (reviewer: ${REVIEWER_CLI} / ${REVIEWER_MODEL})

 [Reviewer feedback]
 ```

-4. While the reviewer is still running, keep waiting as long as fresh `state=in-progress note="In progress N"` heartbeats continue to appear roughly once per minute.
-5. Check verdict:
+1. While the reviewer is still running, keep waiting as long as fresh `state=in-progress note="In progress N"` heartbeats continue to appear roughly once per minute.
+2. Check verdict:
   - **VERDICT: APPROVED** with no `P0`, `P1`, or `P2` findings -> proceed to Phase 5 Step 6 (commit & approve)
   - **VERDICT: APPROVED** with only `P3` findings -> optionally fix the `P3` items if they are cheap and safe, then proceed
   - **VERDICT: REVISE** or any `P0`, `P1`, or `P2` finding -> go to Step 5
@@ -459,7 +542,7 @@ Fallback is allowed only when the helper is missing or not executable.

 Summarize revisions for the user:

-```
+```markdown
 ### Revisions (Round N)
 - [Change and reason, one bullet per issue addressed]
 ```
@@ -470,7 +553,6 @@ If a revision contradicts the user's explicit requirements, skip it and note it

 Rewrite `/tmp/milestone-review-${REVIEW_ID}.sh` for the next round. The script should contain the reviewer invocation only; do not run it directly.

-
 **If `REVIEWER_CLI` is `pi`:**

 Fresh call with prior-round context (Pi reviewer calls do not use session resume):
@@ -546,6 +628,59 @@ Keep findings ordered `P0` to `P3`, use `- None.` when a severity has no finding

 If resume fails, fall back to fresh `cursor-agent -p` with context about prior rounds.

+**If `REVIEWER_CLI` is `opencode`:**
+
+Fresh call (recommended default — opencode has no guaranteed stable session ID in headless mode):
+
+```bash
+opencode run \
+  -m ${REVIEWER_MODEL} \
+  --agent plan \
+  --format json \
+  "You previously reviewed this milestone and requested revisions.
+
+Previous feedback summary: [key points from last review]
+
+I've addressed your feedback. Updated milestone payload is in /tmp/milestone-${REVIEW_ID}.md.
+
+Changes made:
+[List specific changes]
+
+Re-review using the same \`## Summary\`, \`## Findings\`, and \`## Verdict\` structure as before.
+Keep findings ordered \`P0\` to \`P3\`, use \`- None.\` when a severity has no findings, and only use \`VERDICT: APPROVED\` when no \`P0\`, \`P1\`, or \`P2\` findings remain. \`P3\` findings are non-blocking." \
+  > /tmp/milestone-review-${REVIEW_ID}.json
+
+jq -r '.[] | select(.type == "message" and .role == "assistant") | .content' \
+  /tmp/milestone-review-${REVIEW_ID}.json \
+  > /tmp/milestone-review-${REVIEW_ID}.md \
+  || cp /tmp/milestone-review-${REVIEW_ID}.json /tmp/milestone-review-${REVIEW_ID}.md
+```
+
+Optional session-resume path (only if `OPENCODE_SESSION_ID` was captured on Round 1 and your installed opencode accepts `-s <id>` reliably in headless mode):
+
+```bash
+opencode run \
+  -s ${OPENCODE_SESSION_ID} \
+  -m ${REVIEWER_MODEL} \
+  --agent plan \
+  --format json \
+  "I've addressed your feedback on this milestone. Updated diff and verification output are in /tmp/milestone-${REVIEW_ID}.md.
+
+Changes made:
+[List specific changes]
+
+Re-review using the same \`## Summary\`, \`## Findings\`, and \`## Verdict\` structure as before.
+Keep findings ordered \`P0\` to \`P3\`, use \`- None.\` when a severity has no findings, and only use \`VERDICT: APPROVED\` when no \`P0\`, \`P1\`, or \`P2\` findings remain. \`P3\` findings are non-blocking." \
+  > /tmp/milestone-review-${REVIEW_ID}.json
+
+jq -r '.[] | select(.type == "message" and .role == "assistant") | .content' \
+  /tmp/milestone-review-${REVIEW_ID}.json \
+  > /tmp/milestone-review-${REVIEW_ID}.md \
+  || cp /tmp/milestone-review-${REVIEW_ID}.json /tmp/milestone-review-${REVIEW_ID}.md
+```
+
+If session resume fails (session expired or not supported), fall back to the fresh-call path above.
+
 Do not run `jq` extraction until after the helper or fallback execution completes, then extract `/tmp/milestone-review-${REVIEW_ID}.md` from the JSON response.

 After updating `/tmp/milestone-review-${REVIEW_ID}.sh`, run the same helper/fallback flow from Round 1.
@@ -580,20 +715,20 @@ After all milestones are approved and committed:
 git merge implement/<plan-folder-name>
 ```

-4. Delete the worktree and its branch:
+1. Delete the worktree and its branch:

 ```bash
 git worktree remove <worktree-path>
 git branch -d implement/<plan-folder-name>
 ```

-5. Mark plan status as `completed` in `story-tracker.md`.
+1. Mark plan status as `completed` in `story-tracker.md`.

 ### Phase 8: Final Report

 Present summary:

-```
+```markdown
 ## Implementation Complete

 **Plan:** <plan-folder-name>
@@ -619,6 +754,7 @@ fi
 ```

 Rules:
+
 - Telegram is the only supported notification path. Do not use desktop notifications, `say`, email, or any other notifier.
 - Notification failures are non-blocking, but they must be surfaced to the user.
 - Before stopping for any user interaction, approval, or manual decision, send a Telegram summary first if configured.
@@ -627,12 +763,14 @@ Rules:
 ## Tracker Discipline (MANDATORY)

 Before starting any story:
+
 1. Open `story-tracker.md`
 2. Mark story `in-dev`
 3. Add notes if relevant
 4. Then begin implementation

 After completing any story:
+
 1. Mark story `completed`
 2. Review pending stories
 3. Update Last Updated and Stories Complete counts