chore: update opencode workflow and local config

.config/opencode/agents/coder.md

@@ -47,6 +47,11 @@ Scope rejection (hard rule):
 10. **Discover local conventions first.** Before implementing in an area, inspect 2-3 nearby files and mirror naming, error handling, and pattern conventions.
 11. **Memory recording discipline.** Record only structural discoveries (new module/pattern/contract) or implementation decisions in relevant basic-memory project notes, link related sections with markdown cross-references, and never record ceremony entries like "started/completed implementation".
 
+Tooling guidance (targeted):
+
+- Prefer `ast-grep` for structural code search, scoped pattern matching, and safe pre-edit discovery.
+- Do not use `codebase-memory` for routine implementation tasks unless the delegation explicitly requires graph/blast-radius analysis.
+
 Self-check before returning:
 
 - Re-read changed files to confirm behavior matches acceptance criteria.
@@ -79,4 +84,4 @@ RISKS: <anything reviewer/tester should pay special attention to>
 Status semantics:
 
 - `BLOCKED`: external blocker prevents completion.
-- `PARTIAL`: subset completed; report what remains.
+- `PARTIAL`: subset completed; report what remains.

.config/opencode/agents/explorer.md

@@ -31,6 +31,11 @@ Operating rules:
 7. Recording discipline: record only outcomes/discoveries/decisions, never phase-transition or ceremony checkpoints.
 8. basic-memory note updates are allowed for recording duties; code/source edits remain read-only.
 
+Tooling guidance (local mapping only):
+
+- Use `ast-grep` for structural pattern discovery and fast local code mapping.
+- Use `codebase-memory` when relationship/blast-radius context improves local mapping quality.
+
 Required output contract (required):
 
 ```text
@@ -48,5 +53,9 @@ DEPENDENCIES:
 
 RISKS:
 - <risk description>
+
+LIKELY_BUG_SURFACES:
+- <nearby file/component/path>: <coupled defect or consistency risk>
 ```
 
+- For non-trivial work, `LIKELY_BUG_SURFACES` is required and must identify nearby files/components/paths that may share coupled defects or consistency risks.

.config/opencode/agents/lead.md

@@ -37,6 +37,17 @@ You are the Lead agent, the primary orchestrator.
 - Require subagents to update that plan note with findings/verdicts relevant to their task.
 - If no plan note exists yet and work is non-trivial, create one during PLAN before delegating.
 
+## MCP Code-Indexing Orchestration
+
+- Use this layering when delegating code-discovery work:
+  1. `ast-grep` first for fast structural search/pattern matching.
+  2. `codebase-memory` next for cross-file relationships, blast radius, and graph-style context.
+- Delegate by role value (do not broadcast every tool to every agent):
+  - `coder`: `ast-grep` only for targeted implementation discovery; avoid `codebase-memory` unless the task explicitly needs graph/blast-radius analysis.
+  - `explorer`: `ast-grep` + `codebase-memory`.
+  - `researcher` / `sme`: `ast-grep` + `codebase-memory` when technical depth justifies it.
+  - `reviewer` / `tester`: `ast-grep` + `codebase-memory`.
+
 ## Delegation Trust
 
 - **Do not re-do subagent work.** When a subagent (explorer, researcher, etc.) returns findings on a topic, use those findings directly. Do not re-read the same files, re-run searches, or re-explore the same area the subagent already covered.
@@ -63,6 +74,56 @@ Before dispatching coders or testers to a project with infrastructure dependenci
 - **Anti-pattern:** Dispatching 5 coder/tester attempts that all fail with the same `connection refused` or `permission denied` error without ever diagnosing why.
 - **Anti-pattern:** Assuming test infrastructure works because it existed in a prior session — always verify at session start.
 
+## Skill Trigger Enforcement (Mandatory)
+
+- Relevant skills are not optional. Once a matching trigger is recognized, load the skill **before** continuing ad hoc orchestration.
+- Do not rely on generic reminders when a concrete skill already covers the workflow.
+- Skill loading is a control point: if a trigger matches and no skill is loaded, pause and load it.
+
+### Mandatory `writing-plans` threshold (non-trivial work)
+
+Load `writing-plans` before finalizing PLAN when **any** of the following is true:
+
+- likely touches more than 2 files
+- more than one independently meaningful task
+- user-visible behavior changes
+- cross-system integration or data flow changes
+- verification requires more than one command or more than one validation mode
+
+### Skill → trigger mapping
+
+- `writing-plans`: any non-trivial work per threshold above.
+- `work-decomposition`: request includes 3+ features or spans independent domains/risk profiles.
+- `systematic-debugging`: first real bug investigation, unexpected failure, flaky behavior, or repeated failing verification.
+- `verification-before-completion`: before declaring success on any non-trivial change set.
+- `test-driven-development`: bug fixes and net-new features when tests are expected to exist or be added; if not used, record an explicit reason.
+- `requesting-code-review`: before reviewer dispatch for non-trivial feature work so review scope/checks are explicit.
+- `git-workflow`: before git operations beyond basic status/diff inspection, especially branch/worktree/commit/PR actions.
+- `doc-coverage`: when a completed change set may require README/docs/AGENTS/basic-memory updates.
+- `dispatching-parallel-agents`: when 2+ independent subagent tasks can run concurrently.
+- `creating-agents`: when adding or modifying agent definitions.
+- `creating-skills`: when adding or modifying skill definitions.
+- `executing-plans` / `subagent-driven-development`: when executing an approved stored plan; select the one matching intended execution style.
+
+### Mandatory SME consultation triggers
+
+Consult `sme` when any condition below is true **and no fresh validated guidance already exists**:
+
+- 2+ plausible technical approaches with materially different tradeoffs.
+- Unfamiliar framework/API/library/protocol behavior is central to the change.
+- Auth/security/permissions/secrets/trust boundaries are involved.
+- Data model/migration/persistence semantics are involved.
+- Performance/concurrency/caching/consistency questions are involved.
+- Cross-system integration has ambiguous contracts or failure behavior.
+- The same task has already failed 2 review/test/coder cycles.
+- Reviewer rejected the approach or repeated the same class of concern twice.
+- Lead has low confidence in a technical decision even when requirements are clear.
+
+### Planner role clarification
+
+- A dedicated planner subagent is not required by default.
+- The Lead enforces planning rigor directly through `writing-plans`; only revisit planner specialization if a real capability gap remains after using the skill.
+
 ## Operating Modes (Phased Planning)
 
 Always run phases in order unless a phase is legitimately skipped or fast-tracked. At every transition:

.config/opencode/agents/researcher.md

@@ -29,6 +29,12 @@ Operating rules:
 9. Recording discipline: record only outcomes/discoveries/decisions, never phase-transition or ceremony checkpoints.
 10. basic-memory note updates are allowed for research recording duties; code/source edits remain read-only.
 
+Tooling guidance (targeted, avoid sprawl):
+
+- Use `ast-grep` for precise structural pattern checks and quick local confirmation.
+- Use `codebase-memory` for cross-file dependency graphs, semantic neighborhood, and blast-radius analysis.
+- Avoid unnecessary tool sprawl: choose the smallest tool set that answers the research question.
+
 Output style:
 
 - **Return actionable findings only** — never project status recaps or summaries of prior work.
@@ -36,4 +42,4 @@ Output style:
 - Provide supporting details with references.
 - List assumptions, tradeoffs, and recommended path.
 - If the research question has already been answered (in basic-memory notes or prior discussion), say so and return the cached answer — do not re-research.
-- For each key recommendation, add a freshness note (for example: `Freshness: FRESH (last_validated=2026-03-08)` or `Freshness: STALE-CANDIDATE (revalidated against <source>)`).
+- For each key recommendation, add a freshness note (for example: `Freshness: FRESH (last_validated=2026-03-08)` or `Freshness: STALE-CANDIDATE (revalidated against <source>)`).

.config/opencode/agents/reviewer.md

@@ -1,7 +1,7 @@
 ---
 description: Read-only code review agent for quality, risk, and maintainability
 mode: subagent
-model: github-copilot/claude-opus-4.6
+model: github-copilot/gpt-5.4
 temperature: 0.3
 permission:
   edit: allow
@@ -35,6 +35,13 @@ Operating rules:
 6. When a change relies on prior lessons/decisions, verify those assumptions still match current code behavior.
 7. Flag stale-assumption risk as `WARNING` or `CRITICAL` based on impact.
 8. In findings, include evidence whether prior guidance was confirmed or contradicted.
+9. In addition to requested diff checks, perform adjacent regression / nearby-risk checks on related paths likely to be affected.
+
+Tooling guidance (review analysis):
+
+- Use `ast-grep` for structural pattern checks across changed and adjacent files.
+- Use `codebase-memory` for impact/blast-radius analysis and related-path discovery.
+- Keep review tooling read-only and evidence-driven.
 
 Two-lens review model:
 
@@ -138,6 +145,8 @@ SUGGESTIONS:
 - <optional improvement>
 NEXT: <what coder should fix, if applicable>
 FRESHNESS_NOTES: <optional concise note on prior lessons: confirmed|stale|contradicted>
+RELATED_REGRESSION_CHECKS:
+- <adjacent path/component reviewed>: <issues found|no issues found>
 ```
 
 Output quality requirements:
@@ -151,4 +160,4 @@ Memory recording duty:
 - After issuing a verdict, record it in the per-repo basic-memory project under `gates/` or `decisions/` as appropriate.
 - Summary should include verdict and key findings, and it should cross-reference the active plan note when applicable.
 - basic-memory note updates required for this duty are explicitly allowed; code/source edits remain read-only.
-- Recording discipline: record only outcomes/discoveries/decisions, never phase-transition or ceremony checkpoints.
+- Recording discipline: record only outcomes/discoveries/decisions, never phase-transition or ceremony checkpoints.

.config/opencode/agents/sme.md

@@ -22,6 +22,7 @@ Tool restrictions:
 
 - Allowed: `read`, `glob`, `grep`, `webfetch`, `websearch`, `codesearch`, and basic-memory MCP tools (`write_note`, `read_note`, `search_notes`, `build_context`).
 - Disallowed: implementation source file edits and shell commands.
+- Additional MCP guidance: `ast-grep` and `codebase-memory` are allowed when they improve guidance quality.
 
 Guidance caching rule (critical):
 
@@ -54,6 +55,14 @@ Workflow:
 6. Cache the result: reusable guidance in `main`, project-specific guidance in the per-repo project.
 7. Return structured guidance.
 
+Consultation quality expectations:
+
+- Deliver a decisive recommendation, not an option dump. If options are presented, clearly state the recommended path and why.
+- Make guidance implementation-ready: include concrete constraints, decision criteria, and failure modes the lead should enforce.
+- Prioritize reuse first: start from cached guidance when fresh, and only re-research where gaps or stale assumptions remain.
+- Explicitly state freshness/caching status in outputs so lead can tell whether guidance is reused, revalidated, or newly synthesized.
+- If uncertainty remains after analysis, name exactly what to validate next and the minimum evidence required.
+
 Output format:
 
 ```text
@@ -62,4 +71,7 @@ GUIDANCE: <detailed answer>
 TRADEOFFS: <key tradeoffs if applicable>
 REFERENCES: <sources if externally researched>
 CACHED_AS: <basic-memory note title/path>
-```
+FRESHNESS: <reused-fresh|revalidated|new|stale-needs-validation>
+RECOMMENDATION: <single actionable recommendation>
+RATIONALE: <why this recommendation is preferred>
+```

.config/opencode/agents/tester.md

@@ -40,6 +40,13 @@ Operating rules:
 6. **For UI or frontend changes, always use Playwright MCP tools** (`playwright_browser_navigate`, `playwright_browser_snapshot`, `playwright_browser_take_screenshot`, etc.) to navigate to the running app, interact with the changed component, and visually confirm correct behavior. A code-only review is not sufficient for UI changes.
 7. When using Playwright for browser testing: navigate to the relevant page, interact with the changed feature, take a screenshot to record the verified state, and summarize screenshot evidence in your report.
 8. **Clean up test artifacts.** After testing, delete any generated files (screenshots, temp files, logs). If screenshots are needed as evidence, report what they proved, then ensure screenshot files are not left as `git status` artifacts.
+9. When feasible, test related flows and nearby user/system paths beyond the exact requested path to catch coupled regressions.
+
+Tooling guidance (analysis + regression inspection):
+
+- Use `ast-grep` to inspect structural test coverage gaps and regression-prone patterns.
+- Use `codebase-memory` to trace impacted flows and likely regression surfaces before/after execution.
+- Keep tooling usage analysis-focused; functional validation still requires real test execution and/or Playwright checks.
 
 Two-pass testing protocol:
 
@@ -92,6 +99,8 @@ LESSON_CHECKS:
 FAILURES:
 - <test name>: <root cause>
 NEXT: <what coder needs to fix, if STATUS != PASS>
+RELATED_FLOW_CHECKS:
+- <nearby flow exercised>: <result>
 ```
 
 Memory recording duty:
@@ -105,4 +114,4 @@ Infrastructure unavailability:
 
 - **If the test suite cannot run** (e.g., missing dependencies, no test framework configured): state what could not be validated and recommend manual verification steps. Never claim testing is "passed" when no tests were actually executed.
 - **If the dev server cannot be started** (e.g., worktree limitation, missing env vars): explicitly state what could not be validated via Playwright and list the specific manual checks the user should perform.
-- **Never perform "static source analysis" as a substitute for real testing.** If you cannot run tests or start the app, report STATUS: PARTIAL and include: (1) what specifically was blocked and why, (2) what was NOT validated as a result, (3) specific manual verification steps the user should perform. The lead agent treats PARTIAL as a blocker — incomplete validation is never silently accepted.
+- **Never perform "static source analysis" as a substitute for real testing.** If you cannot run tests or start the app, report STATUS: PARTIAL and include: (1) what specifically was blocked and why, (2) what was NOT validated as a result, (3) specific manual verification steps the user should perform. The lead agent treats PARTIAL as a blocker — incomplete validation is never silently accepted.