@mstar-harness/opencode 0.5.1 → 0.6.1

package/harness-skills/mstar-plan-artifacts/scripts/tech-debt-rollup.sh

@@ -0,0 +1,115 @@
+#!/usr/bin/env bash
+# Read-only rollup of open residual_findings into tech_debt_summary aggregates.
+# Does not write status.json — PM applies output manually.
+set -euo pipefail
+
+STATUS_FILE="${1:-.agents/status.json}"
+
+if [[ ! -f "$STATUS_FILE" ]]; then
+  echo "error: status file not found: $STATUS_FILE" >&2
+  exit 1
+fi
+
+if ! command -v jq >/dev/null 2>&1; then
+  echo "error: jq is required" >&2
+  exit 1
+fi
+
+# Merge canonical + legacy maps (canonical keys win). Legacy "warning" -> low.
+# Skip entries with lifecycle != open (default open when omitted).
+read -r -d '' JQ_FILTER <<'JQEOF' || true
+def norm_sev:
+  if . == "warning" then "low"
+  elif . == null or . == "" then "medium"
+  else .
+  end;
+
+def is_open:
+  (.lifecycle // "open") == "open";
+
+(.residual_findings // {}) as $canon
+| (.metadata.residual_findings // {}) as $legacy
+| ($canon + $legacy) as $merged
+| [
+    $merged
+    | to_entries[]
+    | .key as $plan
+    | .value[]
+    | select(is_open)
+    | . + { _plan_id: $plan }
+  ] as $items
+| {
+    total_open: ($items | length),
+    by_severity: (
+      ["critical", "high", "medium", "low", "nit"]
+      | map(. as $s
+        | { ($s): ([$items[] | select((.severity | norm_sev) == $s)] | length) })
+      | add
+    ),
+    by_target: (
+      $items
+      | map(.target // "unspecified")
+      | group_by(.)
+      | map({ key: .[0], value: length })
+      | from_entries
+    ),
+    by_plan: (
+      $items
+      | group_by(._plan_id)
+      | map({ key: .[0]._plan_id, value: length })
+      | from_entries
+    )
+  }
+JQEOF
+
+COMPUTED=$(jq -c "$JQ_FILTER" "$STATUS_FILE")
+STORED=$(jq -c '.metadata.tech_debt_summary // null' "$STATUS_FILE")
+
+echo "=== tech_debt_summary (computed from open residual_findings) ==="
+echo "$COMPUTED" | jq '.'
+
+echo ""
+echo "=== stored metadata.tech_debt_summary ==="
+if [[ "$STORED" == "null" ]]; then
+  echo "(none)"
+else
+  echo "$STORED" | jq '.'
+fi
+
+echo ""
+echo "=== consistency check ==="
+
+compare_field() {
+  local field="$1"
+  local computed stored
+  computed=$(echo "$COMPUTED" | jq -c ".$field")
+  if [[ "$STORED" == "null" ]]; then
+    echo "DRIFT: no stored tech_debt_summary (computed $field = $computed)"
+    return 1
+  fi
+  stored=$(echo "$STORED" | jq -c ".$field // null")
+  if [[ "$computed" == "$stored" ]]; then
+    echo "PASS: $field"
+    return 0
+  fi
+  echo "DRIFT: $field"
+  echo "  computed: $computed"
+  echo "  stored:   $stored"
+  return 1
+}
+
+FAIL=0
+compare_field total_open || FAIL=1
+compare_field by_severity || FAIL=1
+compare_field by_target || FAIL=1
+compare_field by_plan || FAIL=1
+
+if [[ "$FAIL" -eq 0 ]]; then
+  echo ""
+  echo "OVERALL: PASS"
+  exit 0
+fi
+
+echo ""
+echo "OVERALL: DRIFT — refresh metadata.tech_debt_summary in status.json"
+exit 1

package/harness-skills/mstar-plan-artifacts/templates/README.md

@@ -1,6 +1,6 @@
 # Plan harness file templates
 
-Copy these into `{HARNESS_DIR}` when bootstrapping a project. Path symbols (`{HARNESS_DIR}`, `{PLAN_DIR}`, …) → **`mstar-plan-conventions`**. Field semantics and residual lifecycle → **`mstar-plan-artifacts/references/status-and-residuals.md`**.
+Copy these into `{HARNESS_DIR}` when bootstrapping a project. Path symbols (`{HARNESS_DIR}`, `{PLAN_DIR}`, …) → **`mstar-plan-conventions`**. Field semantics and residual lifecycle → **`mstar-plan-artifacts/references/status-and-residuals.md`**. Optional rollup: **`../scripts/tech-debt-rollup.sh`** (read-only; see that reference).
 
 | File | Copy to | Notes |
 |------|---------|--------|

package/harness-skills/mstar-roles/SKILL.md

@@ -48,7 +48,7 @@ Treat these as baseline dependencies **where the role touches implementation, re
 | `mstar-review-qc` | QC workflow, template, verdict, high-risk checks |
 | `mstar-coding-behavior` | Implementation/debug/refactor (**not** PM orchestration-only) |
 | `mstar-superpowers-align` | Superpowers plugin on; Assignment `Superpowers` lines |
-| `mstar-host-opencode` / `mstar-host-cursor` | Host-specific behavior (match active host) |
+| `mstar-host` | Host-specific behavior (auto-detect; `references/opencode.md` / `cursor.md` / `codex.md`) |
 
 ### Role → typical topic skills (after `mstar-harness-core`)
 

package/harness-skills/mstar-roles/references/architect.md

@@ -8,7 +8,7 @@
 
 **On demand:** `mstar-branch-worktree` (when committing architecture docs to the business repo).
 
-**Host:** `mstar-host-opencode` | `mstar-host-cursor`.
+**Host:** `mstar-host` (detect; `references/opencode.md` | `cursor.md` | `codex.md`).
 
 ## Role Mission
 

package/harness-skills/mstar-roles/references/frontend-dev.md

@@ -8,7 +8,7 @@
 
 **On demand:** `mstar-branch-worktree` (repo writes); `mstar-phase-gates` (Execute / hotfix when referenced in assignment).
 
-**Host:** `mstar-host-opencode` | `mstar-host-cursor`.
+**Host:** `mstar-host` (detect; `references/opencode.md` | `cursor.md` | `codex.md`).
 
 ## Role Mission
 

package/harness-skills/mstar-roles/references/fullstack-dev-shared.md

@@ -18,7 +18,7 @@ Behavior is shared; track identity is parameterized.
 
 **On demand:** `mstar-branch-worktree` (repo writes, `Working branch`); `mstar-phase-gates` (Execute / hotfix sections when gate fields are in the assignment).
 
-**Host:** `mstar-host-opencode` | `mstar-host-cursor`.
+**Host:** `mstar-host` (detect; `references/opencode.md` | `cursor.md` | `codex.md`).
 
 ## Role Mission
 

package/harness-skills/mstar-roles/references/ops-engineer.md

@@ -8,7 +8,7 @@
 
 **On demand:** `mstar-phase-gates` (hotfix compressed path when assignment says hotfix).
 
-**Host:** `mstar-host-opencode` | `mstar-host-cursor`.
+**Host:** `mstar-host` (detect; `references/opencode.md` | `cursor.md` | `codex.md`).
 
 ## Role Mission
 

package/harness-skills/mstar-roles/references/product-manager.md

@@ -8,7 +8,7 @@
 
 **On demand:** `mstar-branch-worktree` (when committing product docs to the business repo).
 
-**Host:** `mstar-host-opencode` | `mstar-host-cursor`.
+**Host:** `mstar-host` (detect; `references/opencode.md` | `cursor.md` | `codex.md`).
 
 ## Role Mission
 

package/harness-skills/mstar-roles/references/project-manager/dispatch-and-assignment.md

@@ -7,7 +7,7 @@ The concise gate summary remains in `references/project-manager.md`.
 
 - Only `project-manager` dispatches subagents.
 - Each independent Assignment requires one matching host invoke.
-- In tool hosts (OpenCode/Cursor Task), Markdown-only Assignment is not dispatch.
+- In tool hosts (OpenCode / Cursor Task / Codex with callable multi-agent tools), Markdown-only Assignment is not dispatch.
 - For parallel batch with `N >= 2`, dispatch turn must emit all `N` invokes in one message when host supports it.
 
 ## Executor Anti-Recursion Rules
@@ -115,7 +115,7 @@ For assignees (non-PM):
 **Effort note (agent-oriented)**: ...
 ```
 
-## OpenCode-Specific Note
+## Host-Specific Note
 
-For OpenCode host behavior details (dispatch turn shape, paste-only failure mode, invoke-count discipline),
-read the `mstar-host-opencode` skill as the host SSOT.
+For host behavior details (dispatch turn shape, paste-only failure mode, invoke-count discipline),
+read `mstar-host` → the active host reference and `references/parallel-dispatch.md` as host SSOT for dispatch.

package/harness-skills/mstar-roles/references/project-manager/routing-and-dev-allocation.md

@@ -37,35 +37,41 @@ When multiple routes apply, set one `Primary` route in Assignment and treat othe
 
 ## Dev Triangle Balance (`fullstack-dev` / `fullstack-dev-2` / `frontend-dev`)
 
+### Default: spread backend/fullstack work across both tracks
+
+When **>=2 independent** backend/fullstack units exist (on the task board or across sequential batches):
+
+- **Parallel (preferred)** when units are parallelizable: dispatch **`fullstack-dev` + `fullstack-dev-2`** with explicit module boundaries and branch/worktree isolation.
+- **Sequential rotation** when work is not concurrent: alternate `Execute as` between `fullstack-dev` and `fullstack-dev-2` by task/batch order (round-robin).
+
+**Independence gate:** do **not** split genuinely dependent or sequential work across two dev IDs just to use both tracks.
+
+**Single-id path needs justification:** collapsing >=2 independent units onto one backend-capable dev id requires `Dev owner tie-break: single id — <reason>` and Pre-Implement `single_stream_justified: yes` with that reason.
+
 ### When `frontend-dev` is required
 
 - Task category is `visual`, or acceptance depends on page/component/interaction/a11y/frontend performance.
 - UI-bearing fullstack work defaults to split ownership (`frontend-dev` for UI, `fullstack-dev` for API/domain).
 
-### When `fullstack-dev-2` is required
+### When `fullstack-dev-2` is required (concurrent dual-track)
 
 Use a second implementation track when **any** applies:
 
 - Task board has >=2 independently parallelizable implementation units.
 - Medium+ fullstack scope and PM/user expects wall-clock acceleration.
-- Existing flow overloaded on one fullstack track while another independent module exists.
+- One fullstack track is overloaded while another independent module exists.
 
 ### `single-stream` clarification
 
-`Dev routing: single-stream` means no concurrent multi-write dev tracks in this round.
+`Dev routing: single-stream` means no concurrent multi-write dev tracks **in this round**.
 It does **not** force all future batches to one fixed developer ID.
 
-### Round-robin default for equivalent backend/fullstack units
-
-If multiple equivalent non-UI units can be assigned to either `fullstack-dev` or `fullstack-dev-2`,
-default owner tie-break is round-robin by task order unless there is a documented override reason.
-
-Allowed override reasons:
+### Allowed override to single backend-capable dev id
 
 - User explicitly locks owner
-- Module ownership/continuity constraint
+- Module ownership / continuity on one track
 - Hotfix stop-bleeding
-- Only one active write track in this round
+- Only one active write track in this round (true dependency, not preference)
 
 Document override as `Dev owner tie-break: single id — <reason>`.
 

package/harness-skills/mstar-roles/references/project-manager.md

@@ -4,7 +4,7 @@ Before any non-trivial PM action, read in order:
 
 1. `mstar-harness-core` (entry, state machine, Task category, skill index)
 2. `mstar-dispatch-gates` + `mstar-phase-gates` (dispatch + Prepare/Execute gates)
-3. Host adapter: `mstar-host-opencode` (OpenCode) or `mstar-host-cursor` (Cursor)
+3. Host adapter: `mstar-host` (detect host; Read `references/opencode.md`, `cursor.md`, or `codex.md`)
 4. `mstar-plan-conventions` (path discovery, init, Spec branch summary)
 5. `mstar-superpowers-align` (when Superpowers plugin is enabled)
 6. `mstar-review-qc` (same coordination round, **before** any QC dispatch)
@@ -73,6 +73,8 @@ Pick one `Primary` route per Assignment; attach additional gates as needed.
 Detailed conflict priority and dev allocation:
 `references/project-manager/routing-and-dev-allocation.md`.
 
+**Dev spread default:** when the task board has **>=2 independent** backend/fullstack units, prefer **`fullstack-dev` + `fullstack-dev-2`** (parallel with boundaries) or **round-robin** owners across sequential batches. Using a single backend-capable dev id for multiple independent units requires documented justification (`single_stream_justified` in Pre-Implement Gate Check).
+
 ---
 
 ## Non-Bypass Constraints
@@ -87,14 +89,14 @@ Detailed conflict priority and dev allocation:
 
 ## Host Dispatch Rule (Critical)
 
-In invoke-based hosts (OpenCode/Task-style):
+In invoke-based hosts (OpenCode / Cursor Task / Codex with callable multi-agent tools):
 
 - Assignment markdown alone is not dispatch.
 - Each independent Assignment needs one matching invoke.
 - For parallel `N >= 2`, emit all `N` invokes in one dispatch turn when host supports it.
 - Do not claim dispatch completion without matching invokes.
 
-OpenCode host details are SSOT: `mstar-host-opencode` skill.
+Host invoke/dispatch details: `mstar-host` → active host reference and `references/parallel-dispatch.md`.
 
 Dispatch mechanics and templates:
 `references/project-manager/dispatch-and-assignment.md`.
@@ -170,6 +172,7 @@ Anti-patterns:
 - Q10: Is Delegation consistent with Superpowers usage?
 - Q11: For non-trivial plan, is PM Task Board published with coverage?
 - Q12: In invoke-based hosts, were matching invokes actually issued?
+- Q13: With **>=2 independent** backend/fullstack units, are owners spread across `fullstack-dev` and `fullstack-dev-2` (parallel or rotated), or is `single_stream_justified: yes` recorded with a real reason?
 
 ---
 
@@ -202,6 +205,7 @@ Hard block when:
 - Non-trivial plan has required field = `no`
 - Harness-active non-hotfix flow lacks on-disk main plan or status registration
 - `Task category: quick` is used on non-trivial work
+- **>=2 independent** backend/fullstack units on the task board but `single_stream_justified: no` with no spread across `fullstack-dev` / `fullstack-dev-2` and no documented single-id override
 
 ---
 

package/harness-skills/mstar-roles/references/prompt-engineer.md

@@ -8,7 +8,7 @@
 
 **Typically:** `mstar-plan-conventions` (path symbols in examples).
 
-**Host:** `mstar-host-opencode` | `mstar-host-cursor`.
+**Host:** `mstar-host` (detect; `references/opencode.md` | `cursor.md` | `codex.md`).
 
 ## Role Mission
 

package/harness-skills/mstar-roles/references/qa-engineer.md

@@ -8,7 +8,7 @@
 
 **On demand:** `mstar-plan-artifacts` (closing R# after verified fix); `mstar-phase-gates` (gate checklist when assignment references verification phase).
 
-**Host:** `mstar-host-opencode` | `mstar-host-cursor`.
+**Host:** `mstar-host` (detect; `references/opencode.md` | `cursor.md` | `codex.md`).
 
 ## Role Mission
 

package/harness-skills/mstar-roles/references/qc-specialist-shared.md

@@ -20,7 +20,7 @@ Behavior is shared; reviewer identity is parameterized.
 
 **On demand:** `mstar-plan-artifacts` (when PM asks you to cite severity enum for residual registration — QC does not own `status.json` writes).
 
-**Host:** `mstar-host-opencode` | `mstar-host-cursor`.
+**Host:** `mstar-host` (detect; `references/opencode.md` | `cursor.md` | `codex.md`).
 
 ## Role Mission
 

package/harness-skills/mstar-roles/references/writing-specialist.md

@@ -6,7 +6,7 @@
 
 **Typically:** `mstar-plan-conventions` (where deliverables land under `{HARNESS_DIR}` / `docs/`); `mstar-plan-artifacts` (when writing under knowledge or plan trees); `mstar-superpowers-align` (when plugin on).
 
-**Host:** `mstar-host-opencode` | `mstar-host-cursor`.
+**Host:** `mstar-host` (detect; `references/opencode.md` | `cursor.md` | `codex.md`).
 
 ## Role Mission
 

package/harness-skills/pm/SKILL.md

@@ -18,7 +18,7 @@ Use `/pm` as a hard switch for the current session: enter Morning Star PM mode u
 
 If this session runs in Cursor **Plan mode**:
 
-1. After step 1, Read **`mstar-host-cursor`** and **`skills-cursor/mstar-host/references/cursor-plan-mode-bridge.md`**.
+1. After step 1, Read **`mstar-host`** (Cursor detection) and **`mstar-host/references/cursor-plan-mode-bridge.md`**.
 2. Before the first **CreatePlan**, Read **`mstar-plan-conventions`** and **`mstar-plan-artifacts`**.
 3. **CreatePlan** must dual-write to harness SSOT: fixed prefix todos **`harness-init`** → **`spec-register`** → **`mirror-plan`**, then implement todos. Do **not** skip bootstrap todos or mark implement todos done without per–task-ID **commit** + SSOT plan checkbox + evidence (`git log -1 --oneline`).
 4. Before **SwitchMode → Agent**, verify mirror plan file and `status.json` `plan_id` registration per the bridge reference.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mstar-harness/opencode",
-  "version": "0.5.1",
+  "version": "0.6.1",
   "description": "Morning Star harness OpenCode plugin (skills bootstrap and agent loading).",
   "license": "MIT",
   "repository": {
@@ -12,7 +12,6 @@
   "main": "./dist/mstar.js",
   "files": [
     "dist",
-    "skills",
     "harness-skills",
     "harness-agents",
     "AGENTS.md",

package/skills/mstar-host/SKILL.md

@@ -1,131 +0,0 @@
----
-name: mstar-host-opencode
-description: OpenCode host adapter for Morning Star harness. Use this skill whenever running Morning Star in OpenCode, especially for host entry behavior, `opencode.json`-driven role loading, `question`-based structured clarify, `@explore`/`@general` usage boundaries, and PM-triggered named-role invocation (including paste-only dispatch failure: Assignment Markdown without matching subagent/Task tool calls). Always load this after `mstar-harness-core` to keep host behavior aligned with shared gates and routing.
----
-
-# Morning Star × OpenCode Host Adapter
-
-This skill defines host adaptation for **Morning Star running in OpenCode** (capabilities, entry behavior, and noise control).  
-Neutral process rules and invariants remain authoritative in `mstar-harness-core`.
-
-## First Action: Load `mstar-harness-core`
-
-Regardless of whether OpenCode injected root `AGENTS.md` via Global Rules, the agent’s **first action** is to read `mstar-harness-core`.
-
-## Default path (recommended)
-
-Use this default sequence unless a project rule explicitly overrides it:
-
-1. Read `mstar-harness-core`
-2. Read current host adapter (`mstar-host-opencode`)
-3. Load role via `mstar-roles`
-4. Execute with evidence-first completion checks
-
-## Role loading
-
-- **Role shell**: `agents/<id>.md` is referenced by `opencode.json` `agent.<id>`; the file keeps only frontmatter and role binding.
-- **Role body**: stored in `mstar-roles` `references/<id>.md` (or shared references + role parameters).
-- **Plugin orchestration conflict handling**: see `mstar-superpowers-align`.
-
-## OpenCode-specific capabilities (other hosts may differ)
-
-- **Structured clarify**: prefer built-in `question` tool (title, prompt, options, optional custom text). Requires `permission.question` in config (user-maintained; agent must not edit global config without explicit consent).
-- **Built-in subagents**: e.g., `@explore` (read-only navigation), `@general`; still subject to `mstar-harness-core` boundaries for explore usage.
-- **Named roles (`@<agent-id>`)**: roles configured in `opencode.json` `agent.<id>` must be **actually invoked** by PM through host entry points. Printing Assignment Markdown alone does not create subagent sessions.
-- **Per-role models**: different models can be configured per subagent in `opencode.json`.
-
-### OpenCode PM: dispatch order and “no tool = no dispatch” (critical)
-
-Some models **only paste** `## Assignment` in the main thread and **never call** the host subagent / Task entry. That is **not** delegation; downstream work **does not start**. Parallel dispatch makes this worse (two Assignments printed, **zero** invokes).
-
-**Turn model: prerequisite vs dispatch (prevents “bash then one QC” failure)**
-
-- **Prerequisite turn** (optional, any assistant message): use `bash` / `read` / `glob` / `grep` to collect facts (`merge-base`, `Review range`, `git rev-parse`, paths). **Do not** emit **any** subagent/Task **dispatch** for the batch in this same message **unless** `N = 1` and that single tool call *is* the dispatch.
-- **Dispatch turn** (mandatory shape when `N ≥ 2` concurrent assignees): the **first** message where you emit **any** dispatch for that batch must contain **all `N`** host invocations (each with its Assignment body). If you are **not** ready to emit all `N`, emit **zero** dispatches in that message — finish prep, then send **one** message with **`N`** calls.
-
-**Mandatory order in the same assistant turn that issues dispatch**
-
-1. **Finalize** all `N` Assignment payloads (after any prerequisite turn).
-2. **Count** independent Assignments for this turn (`N` = number of distinct `Execute as` sessions you must open).
-3. **Issue `N` host invocations first** (subagent / Task / equivalent), each carrying **one** Assignment body as the task message. For **parallel** work, put **all `N` tool calls in this single assistant message** when the host allows it.
-4. **Only after** those tool calls, optionally post a short user-facing **Status Update** (may repeat Assignment titles as audit trail — **does not** replace the **`N`** invocations in step 3).
-
-**Hard rules**
-
-- **Emit zero until batch-ready**: if `N ≥ 2` and you can only issue **one** invoke right now, **do not issue that one** yet; complete the other payloads, then issue **all `N` in one message**. Partial single-invoke sends are **serial rollout**, not parallel launch.
-- **Do not end** the dispatch turn until **`N` invocations have been emitted** (or you explicitly mark `Blocked` / `dispatch incomplete` with host reason and a follow-up plan).
-- **Dual-track implement** (two dev Assignments) uses the **same** rule as QC tri-review: **`N = 2` ⇒ two invocations in one message** when parallel is required — not one invoke “and we’ll do the second later.”
-- In Status Update for dispatch turns, include **`Subagent invokes issued: N`** (must match Assignment count). If `N` is 0 while Assignments were written → state **`dispatch failed — paste-only`** and fix in the **next** message.
-
-## OpenCode parallel dispatch contract (critical)
-
-When PM dispatches parallel work (especially QC tri-review **or two concurrent implement tracks**), treat "parallel" as a **tool-level requirement**, not only a wording requirement. The **Turn model: prerequisite vs dispatch** rules above apply here too (bash/read prep ≠ partial dispatch).
-
-- **Hard rule**: if 2+ subagents must run in parallel, emit all corresponding subagent/task invocations in the **same assistant message**. **Printing two Assignments without two matching tool calls is a failed dispatch**, not partial success.
-- **QC tri-review**: launch `qc-specialist`, `qc-specialist-2`, and `qc-specialist-3` in one dispatch turn (three invocations in one message block).
-- **Failure mode to avoid**: sending only one invocation and planning to send the others later is a serial rollout, not a successful parallel launch.
-- **Completion claim gate**: do not claim "QC tri-review dispatched in parallel" unless all three invocations were issued in that same dispatch turn.
-
-Quick self-check before sending:
-1. How many independent assignments are required this turn? (`N`)
-2. Am I in a **prerequisite-only** message? If yes, ensure **zero** batch dispatches here unless `N = 1`.
-3. If this message is the **dispatch** message, does it contain **exactly `N`** invocation calls (not `1` when `N = 3`)?
-4. For QC tri-review, is the count **exactly 3** in **one** message in the dispatch turn?
-5. If the **previous** message was prerequisite-only, this message **must** include all **`N`** dispatches (not “start with QC1 only”).
-
-Post-dispatch validation (mandatory for QC tri-review):
-1. Verify the three runtime invocations were started as the intended agent IDs: `qc-specialist`, `qc-specialist-2`, `qc-specialist-3` (not three runs of the same role).
-2. Verify runtime model mapping matches host config intent for each reviewer.
-3. If any role/model mismatch is observed, mark dispatch as invalid, do not enter QC consolidation, and re-dispatch with corrected role/model targeting.
-
-### Prepare phase (`specify` / `plan`) — serial roles still require invoke
-
-Routing in `mstar-roles` **project-manager** may read `@explore → @product-manager → @architect` **sequentially**. That does **not** waive **no tool = no dispatch**: each handoff still needs a real **host invoke** carrying the Assignment for that `agent.<id>` (often **`N = 1`** per dispatch turn). Writing PRD / acceptance / product specify prose, or architecture / contract sections, only in the primary `project-manager` chat — then claiming “plan directory maintenance” — is **not** a substitute when the routing table assigns those bodies to **`product-manager`** or **`architect`**. Cross-check before advancing phases: `mstar-roles` → `references/project-manager.md` → **§1.1.1a Phase routing pre-flight**.
-
-## Gotchas
-
-- `question` availability is host-config dependent; if unavailable, fall back to structured Markdown clarify flow.
-- Printing an Assignment in the main thread is not dispatch; PM must actually invoke the target role.
-- Built-in `@explore` remains read-only orientation, not a substitute for role-owned implementation or review deliverables.
-- More MCPs does not fix process gaps; follow `mstar-phase-gates` and evidence rules first.
-- Topic skills load **on demand** per `mstar-roles` (see hub matrix): `mstar-dispatch-gates`, `mstar-phase-gates`, `mstar-branch-worktree`, `mstar-plan-conventions`, `mstar-plan-artifacts`, `mstar-plan-artifacts`, etc.
-
-## Shared protocol: library documentation retrieval (Context7)
-
-Context7 retrieval is a shared process rule maintained by `mstar-harness-core`.  
-Follow: `mstar-harness-core` skill `references/library-docs-protocol.md`.
-
----
-
-## Session context and plugin injection (noise control)
-
-- **Large platform injections** (for example, long Vercel ecosystem prompts, SessionStart hooks): if unrelated to current stack, they consume context and can conflict with project choices. For non-Vercel projects, disable or make them on-demand (`alwaysApply: false` + explicit trigger description).
-- **Multiple search/docs MCPs**: keep one default channel per capability class.
-
----
-
-## Optional MCPs / skills by capability
-
-This section lists optional enhancements by capability domain, aligned with principles in `mstar-harness-core` `references/open-harness-principles.md` (documentation retrieval, observable verification, structured exploration). User decides whether to enable them; editing global `opencode.json` requires explicit user consent.
-
-| Capability | Purpose | Notes |
-|------|------|------|
-| **Current docs** | Reduce hallucination for versioned APIs/libs | Context7-like MCP or equivalent host-configured docs tool |
-| **Web search** | Time-sensitive issues and migration notes | Avoid overlapping multiple search MCPs for the same purpose |
-| **Code pattern search** | Cross-repo implementation references | Example: `https://mcp.grep.app`; skip if equivalent already configured |
-| **Repo graph / impact analysis** | Dependency/call graph and PR risk | Example: GitNexus |
-| **Browser / E2E verification** | User-visible flow validation and evidence capture | agent-browser, Playwright, aligned with QA observable-evidence requirements |
-| **Git workflow** | Atomic commits and branch closure | e.g., `git-commit`, `finishing-a-development-branch` |
-| **Systematic debugging** | RCA before fix | Superpowers `systematic-debugging` (see `mstar-superpowers-align`) |
-| **OpenViking memory** | Long-term semantic memory (`memsearch` / `memread` / `membrowse` / `memcommit`) | **Only if** the `memsearch` tool is present: follow `mstar-harness-core` `references/openviking-memory-plugin.md`; does not override harness gates |
-
-### Not recommended
-
-- Keeping multiple overlapping search MCPs always enabled.
-- Using more tools to mask phase-gate/process gaps when harness baseline is not yet followed.
-
-## Maintenance boundary (separate from runtime skill)
-
-This skill should contain only **runtime host adaptation** (capabilities and entry behavior).
-
-- Runtime guardrail remains unchanged: agent must not modify `opencode.json`, `secrets.env`, or `.secrets/*` without explicit user consent.