oh-my-opencode 4.13.0 → 4.14.0

package/.agents/skills/codex-qa/SKILL.md

@@ -69,6 +69,21 @@ Windows.
 | `scripts/hook-unit-probe.sh` | the `ultrawork` component injects `<ultrawork-mode>` on an `ulw` UserPromptSubmit (also a manual `--component/--event` mode) |
 | `scripts/tui-smoke.sh` | the real codex TUI boots in the isolated home, renders, and survives (no early exit); captures the pane |
 
+When TUI visual QA evidence is needed, follow
+`docs/reference/web-terminal-visual-qa.md` and do not stop at the raw pane. Replay the
+captured pane through the repository web-terminal helper so the PR can attach a
+stable browser screenshot:
+
+```bash
+node script/qa/web-terminal-visual-qa.mjs --title "Codex TUI QA" \
+  --from-file .omo/evidence/<slug>/codex-tui-pane.txt \
+  --evidence-dir .omo/evidence/<slug>/codex-web-terminal
+```
+
+The helper writes `terminal.txt`, `terminal-ansi.txt`, `terminal.html`,
+`terminal.png`, and `metadata.json`. Use that artifact set for TUI visual QA;
+use `app-server-drive.sh --plugin` for assertion-grade hook behavior.
+
 ## Match QA to your change scope
 
 - **Component / hook logic** (`packages/omo-codex/plugin/components/*`):

package/.agents/skills/codex-qa/references/logging-debug.md

@@ -46,6 +46,18 @@ tmux send-keys -t <sess> "/debug-config" Enter
 tmux capture-pane -t <sess> -p -S -
 ```
 
+For TUI visual QA evidence, replay that pane capture through the browser helper
+from the repository root:
+
+```bash
+node script/qa/web-terminal-visual-qa.mjs --title "Codex TUI /debug-config" \
+  --from-file .omo/evidence/<slug>/codex-debug-config-pane.txt \
+  --evidence-dir .omo/evidence/<slug>/codex-debug-config-web-terminal
+```
+
+Attach the resulting `terminal.png` and keep `metadata.json` with the cleanup
+receipt. The pane proves terminal text; the PNG proves the visual TUI surface.
+
 ## 5. `codex debug` subcommands
 
 `codex debug models` (raw model catalog), `codex debug prompt-input` (the

package/.agents/skills/opencode-qa/SKILL.md

@@ -124,6 +124,23 @@ This launches the TUI under tmux in an isolated sandbox, confirms it renders
 (`capture-pane`), confirms `send-keys` reaches the composer, tears the tmux
 session down, and verifies the real DB session count is unchanged.
 
+When TUI visual QA evidence is needed for a PR, follow
+`docs/reference/web-terminal-visual-qa.md` and attach a browser-rendered
+terminal artifact in addition to the tmux pane. From the repository root, replay
+the captured pane or run a short tmux-backed command through:
+
+```bash
+node script/qa/web-terminal-visual-qa.mjs --title "OpenCode TUI QA" \
+  --from-file .omo/evidence/<slug>/opencode-tui-pane.txt \
+  --evidence-dir .omo/evidence/<slug>/opencode-web-terminal
+```
+
+This writes `terminal.txt`, `terminal-ansi.txt`, `terminal.html`,
+`terminal.png`, and `metadata.json` so the PR can attach a stable TUI visual
+screenshot plus the cleanup receipt. Use `--command "<cmd>"` only for short
+ad-hoc terminal checks; the isolated `scripts/tui-smoke.sh` remains the
+canonical OpenCode TUI smoke.
+
 Honest verdict: tmux is fine for SMOKE (did it boot, render, accept a key) but
 fragile for asserting conversation output (the TUI is a 60fps full-screen app).
 For real behavior assertions use Case A (`opencode run`), Case B (server API +

package/.agents/skills/opencode-qa/references/tui-tmux.md

@@ -14,6 +14,23 @@ Launching the real TUI would create sessions in the real ~/.local/share/opencode
 
 - `scripts/tui-smoke.sh --self-test` launches the TUI under tmux in an isolated sandbox, polls capture-pane for a render marker (version string / "Ask anything" / footer), sends a sentinel keystroke, then kills the tmux session and confirms the real DB is untouched.
 
+## Browser-rendered TUI visual evidence
+
+For PR evidence or any TUI visual QA claim, keep the tmux transcript and add a
+browser-rendered screenshot using the repository helper:
+
+```bash
+node script/qa/web-terminal-visual-qa.mjs --title "OpenCode TUI QA" \
+  --from-file .omo/evidence/<slug>/opencode-tui-pane.txt \
+  --evidence-dir .omo/evidence/<slug>/opencode-web-terminal
+```
+
+The helper replays the terminal frame into `terminal.html`, captures
+`terminal.png` with Chrome when available, writes `metadata.json`, and records
+the cleanup receipt. This is the required TUI visual evidence pattern when the
+review needs to see the screen, while `scripts/tui-smoke.sh` remains the
+isolation/smoke authority.
+
 ## Manual tmux recipe (fenced) - for ad hoc smoke
 
 ```

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

@@ -1,11 +1,11 @@
 ---
 name: work-with-pr
-description: "Full PR lifecycle in an isolated git worktree: implement via the ulw-loop skill with mandatory evidence-bound manual QA → detailed 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 a worktree per PR driven by parallel subagents or a team. Unbounded loop: any failing gate sends you back to fix-and-re-QA inside the 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 + 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."
 ---
 
 # Work With PR — Full PR Lifecycle
 
-You are executing a complete PR lifecycle: from isolated 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 the 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 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.
 
 **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).
 
@@ -15,7 +15,7 @@ You are executing a complete PR lifecycle: from isolated worktree setup, through
 Phase 0: Setup         → Split into atomic PRs, then branch + worktree per PR (parallel when independent)
 Phase 1: Implement     → Drive the work through the ulw-loop skill:
                          evidence-bound manual QA per success criterion, atomic commits
-Phase 2: PR Creation   → Push, create a detailed English PR targeting dev
+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)
@@ -30,7 +30,7 @@ Phase 4: Merge         → Auto-merge by default; wait until actually merged, th
 
 ## Phase 0: Setup
 
-Create an isolated worktree so the user's main working directory stays clean — the user 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 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.
 
 <setup>
 
@@ -137,7 +137,9 @@ Fix any failure before pushing; each fix is its own atomic commit.
 git push -u origin "$BRANCH_NAME"
 ```
 
-Write the PR body in English, detailed enough that a reviewer understands the change without reading the diff. The Verification section is where the manual-QA evidence from Phase 1 earns its place — cite what you actually drove and where the artifact lives, not just that tests passed.
+Write the PR body in English for a human reviewer who has not followed the implementation thread. It must explain the work in plain terms, group changes by reviewer-relevant area instead of dumping files, and make QA evidence auditable without forcing the reviewer to guess what each log proves. Cite sanitized artifacts; do not paste raw secret-bearing logs, env dumps, tokens, auth headers, or private credentials into the PR.
+
+If the PR body needs screenshots or terminal PNGs, follow `docs/reference/github-attachment-upload.md`: upload via GitHub user attachments from an authenticated web session, include only the final `https://github.com/user-attachments/assets/<uuid>` URLs, and never commit temporary images, use release assets, use external hosts, or log cookies/tokens.
 
 ```bash
 gh pr create \
@@ -146,14 +148,20 @@ gh pr create \
   --title "$PR_TITLE" \
   --body "$(cat <<'EOF'
 ## Summary
-[2-4 sentences: what this PR does, why it's needed, and the approach taken]
+[2-4 sentences in plain language: what changed, why it changed, and how observable behavior is different after this PR.]
 
 ## Changes
-[Bullet list of key changes, grouped by area; enough that a reviewer can map each bullet to the diff]
+[Group bullets by reviewer-relevant area, not by file. Each bullet should say what changed and how a reviewer can map it to the diff.]
+
+## QA & Evidence
+For each automated command or manual QA action:
+- **What was tested:** [command or surface driven, with the behavior it was meant to prove]
+- **Observed result:** [actual result, including before/after when relevant]
+- **Artifact:** [`path/to/sanitized-log-or-report`]
+- **Why sufficient:** [which risk or success criterion this evidence covers]
 
-## Verification
-**Automated:** `bun run typecheck` ✅ · `bun test` ✅ · `bun run build` ✅
-**Manual QA:** [per success criterion — the channel driven (tmux/HTTP/browser/GUI), what you observed, and the evidence artifact path]
+## Risks & Residuals
+[Map each meaningful risk to the evidence above and state the conclusion: mitigated, accepted, or blocked. Include unavailable gates here with the concrete reason.]
 
 ## Related Issues
 [Link to issue if applicable]

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

@@ -1,11 +1,11 @@
 ---
 name: work-with-pr
-description: "Full PR lifecycle in an isolated git worktree: implement via the ulw-loop skill with mandatory evidence-bound manual QA → detailed 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 a worktree per PR driven by parallel subagents or a team. Unbounded loop: any failing gate sends you back to fix-and-re-QA inside the 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 + 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."
 ---
 
 # Work With PR — Full PR Lifecycle
 
-You are executing a complete PR lifecycle: from isolated 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 the 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 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.
 
 **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).
 
@@ -15,7 +15,7 @@ You are executing a complete PR lifecycle: from isolated worktree setup, through
 Phase 0: Setup         → Split into atomic PRs, then branch + worktree per PR (parallel when independent)
 Phase 1: Implement     → Drive the work through the ulw-loop skill:
                          evidence-bound manual QA per success criterion, atomic commits
-Phase 2: PR Creation   → Push, create a detailed English PR targeting dev
+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)
@@ -30,7 +30,7 @@ Phase 4: Merge         → Auto-merge by default; wait until actually merged, th
 
 ## Phase 0: Setup
 
-Create an isolated worktree so the user's main working directory stays clean — the user 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 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.
 
 <setup>
 
@@ -137,7 +137,9 @@ Fix any failure before pushing; each fix is its own atomic commit.
 git push -u origin "$BRANCH_NAME"
 ```
 
-Write the PR body in English, detailed enough that a reviewer understands the change without reading the diff. The Verification section is where the manual-QA evidence from Phase 1 earns its place — cite what you actually drove and where the artifact lives, not just that tests passed.
+Write the PR body in English for a human reviewer who has not followed the implementation thread. It must explain the work in plain terms, group changes by reviewer-relevant area instead of dumping files, and make QA evidence auditable without forcing the reviewer to guess what each log proves. Cite sanitized artifacts; do not paste raw secret-bearing logs, env dumps, tokens, auth headers, or private credentials into the PR.
+
+If the PR body needs screenshots or terminal PNGs, follow `docs/reference/github-attachment-upload.md`: upload via GitHub user attachments from an authenticated web session, include only the final `https://github.com/user-attachments/assets/<uuid>` URLs, and never commit temporary images, use release assets, use external hosts, or log cookies/tokens.
 
 ```bash
 gh pr create \
@@ -146,14 +148,20 @@ gh pr create \
   --title "$PR_TITLE" \
   --body "$(cat <<'EOF'
 ## Summary
-[2-4 sentences: what this PR does, why it's needed, and the approach taken]
+[2-4 sentences in plain language: what changed, why it changed, and how observable behavior is different after this PR.]
 
 ## Changes
-[Bullet list of key changes, grouped by area; enough that a reviewer can map each bullet to the diff]
+[Group bullets by reviewer-relevant area, not by file. Each bullet should say what changed and how a reviewer can map it to the diff.]
+
+## QA & Evidence
+For each automated command or manual QA action:
+- **What was tested:** [command or surface driven, with the behavior it was meant to prove]
+- **Observed result:** [actual result, including before/after when relevant]
+- **Artifact:** [`path/to/sanitized-log-or-report`]
+- **Why sufficient:** [which risk or success criterion this evidence covers]
 
-## Verification
-**Automated:** `bun run typecheck` ✅ · `bun test` ✅ · `bun run build` ✅
-**Manual QA:** [per success criterion — the channel driven (tmux/HTTP/browser/GUI), what you observed, and the evidence artifact path]
+## Risks & Residuals
+[Map each meaningful risk to the evidence above and state the conclusion: mitigated, accepted, or blocked. Include unavailable gates here with the concrete reason.]
 
 ## Related Issues
 [Link to issue if applicable]

package/README.md

@@ -167,11 +167,11 @@ The recommended `bunx`/`npx` invocation is `oh-my-openagent install` (or the ori
 
 ### Telemetry
 
-Anonymous telemetry is enabled by default to track active installations (DAU/WAU/MAU). For both products, a single event is sent **at most once per UTC day per machine** using a SHA256-hashed installation identifier (never the raw hostname), and PostHog person profiles are not created. The main plugin emits `oh_my_openagent_daily_active`; the Codex CLI Light edition emits `omo_codex_daily_active` from two sources (`install_completed` and `session_start`).
+Anonymous telemetry is enabled by default to track active installations (DAU/WAU/MAU). For both products, a single event is sent **at most once per UTC day per machine** using a SHA256-hashed installation identifier (never the raw hostname), and PostHog person profiles are not created. The main plugin emits `omo_daily_active` from plugin load (`plugin_loaded`) and CLI run (`run_started`) sources; the Codex CLI Light edition emits `omo_codex_daily_active` from two sources (`install_completed` and `session_start`).
 
 Opt out per product:
 
-- Main plugin: `OMO_DISABLE_POSTHOG=1` or `OMO_SEND_ANONYMOUS_TELEMETRY=0`
+- Main plugin: set `"telemetry": false` in oh-my-openagent config, `OMO_DISABLE_POSTHOG=1`, or `OMO_SEND_ANONYMOUS_TELEMETRY=0`
 - Codex CLI Light edition: `OMO_CODEX_DISABLE_POSTHOG=1` or `OMO_CODEX_SEND_ANONYMOUS_TELEMETRY=0` (the global flags also disable Codex)
 
 See [Privacy Policy](docs/legal/privacy-policy.md) and [Terms of Service](docs/legal/terms-of-service.md).

package/dist/cli/doctor/checks/telemetry.d.ts

@@ -0,0 +1,2 @@
+import type { CheckResult } from "../framework/types";
+export declare function checkTelemetry(): Promise<CheckResult>;

package/dist/cli/doctor/framework/constants.d.ts

@@ -19,6 +19,7 @@ export declare const CHECK_IDS: {
     readonly TUI_PLUGIN: "tui-plugin";
     readonly TOOLS: "tools";
     readonly MODELS: "models";
+    readonly TELEMETRY: "telemetry";
     readonly TEAM_MODE: "team-mode";
     readonly CODEX: "codex";
 };

package/dist/cli/doctor/framework/doctor-target.d.ts

@@ -1,2 +1,2 @@
 export type DoctorTarget = "opencode" | "codex";
-export declare function resolveDoctorTarget(invocationName: string | undefined): DoctorTarget;
+export declare function resolveDoctorTarget(invocationName: string | undefined, platform?: DoctorTarget): DoctorTarget;