@mstar-harness/opencode 0.6.21 → 0.6.23

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

@@ -49,17 +49,21 @@ 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-compound` | Capturing solved problems as structured knowledge in `{KNOWLEDGE_DIR}`; Discoverability check; CONCEPTS.md synergy |
+| `mstar-compound-refresh` | Auditing/updating/consolidating knowledge docs; maintaining `{KNOWLEDGE_DIR}` accuracy |
+| `mstar-iteration` | Iteration lifecycle: iteration-start (scope/roadmap lock), Autonomous Execute (per-plan dispatch loop), iteration-close (compound + roadmap update) |
+| `mstar-strategy` | Creating/maintaining `STRATEGY.md`; project vision, principles, technology direction |
 | `mstar-host` | Host-specific behavior (auto-detect; `references/opencode.md` / `cursor.md` / `codex.md`) |
 
 ### Role → typical topic skills (after `mstar-harness-core`)
 
 | Role | Typical adds |
 | --- | --- |
-| `project-manager` | `mstar-dispatch-gates`, `mstar-phase-gates`, `mstar-plan-conventions`, `mstar-superpowers-align`, `mstar-roles` ref; + `mstar-review-qc` before QC; + `mstar-branch-worktree` / `mstar-plan-artifacts` as the round requires |
+| `project-manager` | `mstar-dispatch-gates`, `mstar-phase-gates`, `mstar-plan-conventions`, `mstar-superpowers-align`, `mstar-roles` ref; + `mstar-review-qc` before QC; + `mstar-branch-worktree` / `mstar-plan-artifacts` as the round requires; + `mstar-iteration` for iteration lifecycle (start/drive/close); + `mstar-strategy` for strategic alignment; + `mstar-compound` / `mstar-compound-refresh` pre-loaded by `mstar-iteration` § iteration-close |
 | `fullstack-dev*`, `frontend-dev` | `mstar-coding-behavior`, `mstar-dispatch-gates`, `mstar-branch-worktree` (if repo writes); plan path symbols from `mstar-plan-conventions` (minimal); `mstar-design-md` when implementing styled UI |
 | `qc-specialist*` | `mstar-review-qc`, `mstar-branch-worktree`, `mstar-plan-artifacts` (report paths); `mstar-design-md` when reviewing UI |
 | `qa-engineer` | `mstar-review-qc`, `mstar-branch-worktree`, `mstar-plan-artifacts` (closing R#); `mstar-design-md` when verifying visual output |
-| `architect`, `product-manager` | `mstar-phase-gates` (Prepare), `mstar-plan-artifacts` (knowledge/specs); `mstar-design-md` (creator + design intent) |
+| `architect`, `product-manager` | `mstar-phase-gates` (Prepare), `mstar-plan-artifacts` (knowledge/specs); `mstar-design-md` (creator + design intent); `mstar-strategy` (STRATEGY.md creation/maintenance) |
 | `ops-engineer` | `mstar-coding-behavior`, `mstar-branch-worktree` |
 | `prompt-engineer` | All topic skills when editing harness text |
 

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

@@ -30,11 +30,13 @@ For assignees (non-PM):
 
 ## Assignment Template (Canonical)
 
-Every Assignment **MUST** start with a **`You are a leaf executor. You MUST NOT:`** block listing the most likely dispatch violations for THIS assignment's situation. PM customizes per assignment; generic rules (no recursive dispatch, no interpreting routing text as invoke, available ≠ authorized) are the minimum floor. Add assignment-specific anti-patterns that the current role+context combination is prone to.
+Every Assignment **MUST** start with an **IDENTITY → GUARD** block that answers three questions before any task content: (1) WHO am I? (2) What am I NOT? (3) What tools do I NOT have?
+
+The **`**You are a leaf executor. You MUST NOT:**`** section (previously just prohibitions) must now include a positive **IDENTITY** preamble **before** the prohibitions, written as a first-person binding statement. The prohibitions follow as usual. PM customizes per assignment; the IDENTITY preamble + universal floor (no recursive dispatch, no interpreting routing text as invoke, available ≠ authorized) are the minimum. Add assignment-specific anti-patterns that the current role+context combination is prone to.
 
 **How to fill the block (PM guidance)**:
 
-- Always include the universal floor (recursive dispatch, routing-text-as-invoke, tool-availability-misread).
+- Always include the **IDENTITY preamble**: state who the assignee IS (e.g. "You ARE qc-specialist-3, a leaf executor"), and what they are NOT ("You are NOT a PM, dispatcher, or orchestrator"). Follow with the universal floor.
 - Add anti-patterns specific to the assignment context. Examples per role type:
   - **QC reviewers**: "start review before all QC reviewers are dispatched in parallel"; "treat other reviewers' names in routing text as invoke targets"
   - **Multi-track implementers** (`fullstack-dev` + `frontend-dev`): "auto-dispatch to the other track mentioned in Dev routing"
@@ -49,7 +51,18 @@ Every Assignment **MUST** start with a **`You are a leaf executor. You MUST NOT:
 ```markdown
 ## Assignment
 
-**You are a leaf executor. You MUST NOT:**
+**You are a leaf executor. Read this FIRST — before any tool call or skill load.**
+
+**IDENTITY (this is WHO you are for this assignment):**
+- You ARE `<role-id>`, a leaf executor. You personally complete ALL work in this assignment.
+- You are NOT a PM, dispatcher, or orchestrator. You do NOT own any subagents.
+- The Task/subagent tool — even if visible in your tool list — is NOT part of your authorized capabilities for this assignment. Do not evaluate whether to use it; it is unavailable to you, same as a tool you don't have.
+
+**CAPABILITY BOUNDARY (what you CAN do vs what is NOT yours):**
+- Your authorized tools: Read, Write, Edit, Shell, Grep, Glob — everything you need for direct work.
+- NOT yours: Task, subagent invoke, dispatch of any kind.
+
+**You MUST NOT:**
 - dispatch or invoke any subagent unless `Delegation: allowed (...)` appears below
 - treat `@role-id` mentions, `Handoff`, `QA note`, routing tables, or multi-track prose as invoke commands
 - invoke a subagent whose `subagent_type` matches your own `Execute as` role id (recursive dispatch)
@@ -58,6 +71,7 @@ Every Assignment **MUST** start with a **`You are a leaf executor. You MUST NOT:
 - ...
 
 **Execute as**: <role-id>
+**Delegation**: forbidden | allowed (...)
 **Who runs this turn (executor lock)**: only `Execute as` role for this message
 **Primary**: <route type>
 **Task category**: `visual` | `deep` | `quick` | `logic` | `ops` | `docs`
@@ -74,7 +88,6 @@ Every Assignment **MUST** start with a **`You are a leaf executor. You MUST NOT:
 **Review range / Diff basis**: <reproducible basis; identical across QC/QA for same scope>
 **Worktree path**: <implementer path if used>
 **QA note**: <PM-scheduled / skipped / self-check>
-**Delegation**: forbidden | allowed (...)
 **Why this agent**: <role-fit>
 **PM Task Board coverage**: <task ids>
 **Roadmap / deferred scope**: <required when staged, partial, or temporary; otherwise N/A>

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

@@ -29,9 +29,14 @@ Your output is a structured QC report plus completion report.
 
 ## Non-Recursive Dispatch Rule (Hard)
 
-- Complete review in this session.
-- Do not spawn sibling QC or implementation roles.
-- Tri-review orchestration is PM-owned; reviewer does not dispatch other reviewers.
+**You ARE `{role_id}`, a QC reviewer — not a PM, not a dispatcher.**
+
+Your Assignment's IDENTITY block at the top already established this. Reinforcing:
+
+- This review is YOUR work, for YOUR hands. Complete every step personally in this session.
+- You do NOT have subagents. Task/subagent is not part of your authorized capabilities.
+- Tri-review orchestration belongs to PM. Your job is to produce ONE report, not to coordinate others.
+- If you ever think "this would be more efficient if I dispatched X" — stop. That thought is the recursive-dispatch trap. You CANNOT dispatch. Return to your direct work.
 
 ## QC NEVER Rules (`{role_id}`)
 

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

@@ -0,0 +1,128 @@
+---
+name: mstar-strategy
+description: Morning Star 全局战略方向 —— 创建并维护 `STRATEGY.md`（项目级战略文档），作为 brainstorm/plan 的上游锚点。定义产品愿景、技术方向、不做事项、决策原则。触发：项目初始化、方向性决策变更、或 PM 要求战略对齐时。
+---
+
+# mstar-strategy（全局战略方向）
+
+## Load order
+
+**Read `mstar-harness-core` first.** Path symbols → **`mstar-plan-conventions`**. On conflict, **`mstar-harness-core` wins**.
+
+## Purpose
+
+`STRATEGY.md` is the project's **upstream anchor** — a concise declaration of what the project is, where it's going, and what principles guide decisions. It is read as grounding by brainstorm, plan, and ideation phases so strategic choices flow into every feature.
+
+Without a strategy document, decisions are made in isolation — each plan misses the larger context.
+
+## 产物存储位置
+
+**SSOT**: `mstar-plan-conventions/references/artifact-storage-paths.md`。STRATEGY.md → `<repo-root>/STRATEGY.md`（与 `.git/`、`AGENTS.md` 同级）。**禁止**放入 `{HARNESS_DIR}`、`docs/` 或任何子目录。
+
+## When to use
+
+| Trigger | Example |
+|---------|---------|
+| Project initialization | "Create STRATEGY.md for this new project" |
+| Directional change | "We're pivoting from monolith to microservices" |
+| PM requests alignment | "Check if this plan aligns with our strategy" |
+| Periodic review | "Review and update STRATEGY.md" |
+
+## STRATEGY.md structure
+
+A good strategy document is opinionated and concise. It should fit in one screen of reading.
+
+### Required sections
+
+```markdown
+# Strategy
+
+## Vision
+<1-2 sentences: what the project aims to become>
+
+## What we build
+<Core product/users/use cases>
+
+## What we don't build
+<Explicit non-goals — as important as goals>
+
+## Guiding Principles
+- <Principle 1>
+- <Principle 2>
+- <Principle 3>
+
+## Technology Direction
+<Key tech choices and rationale>
+
+## Decision Log
+<Major past decisions with context — why, not just what>
+```
+
+### Optional sections
+
+- **Current Focus** — what the team is working on now
+- **Risks & Mitigations** — known strategic risks
+- **Competitive Context** — what alternatives exist and how we differ
+
+## Creating STRATEGY.md
+
+### Phase 1: Gather context
+
+1. Read existing project documentation (README, AGENTS.md, existing specs).
+2. If `{KNOWLEDGE_DIR}` or `{ITERATION_DIR}` exist, scan for architectural decisions and patterns.
+3. If `CONCEPTS.md` exists, use it to understand domain vocabulary.
+
+### Phase 2: Interview
+
+Ask PM these questions (one at a time):
+
+1. "What is the one-sentence vision for this project?"
+2. "Who are the primary users and what do they need most?"
+3. "What are you explicitly NOT building? What's out of scope permanently?"
+4. "What 2-3 principles should guide every technical decision?"
+5. "What technology bets have you made, and why?"
+
+### Phase 3: Draft
+
+Write STRATEGY.md at the repo root. Keep it concise — each section should be 1-3 sentences or a short bullet list.
+
+### Phase 4: Discoverability
+
+Check if AGENTS.md references STRATEGY.md. If not, propose adding:
+
+```markdown
+- `STRATEGY.md` — project vision and guiding principles
+```
+
+Ask for consent before applying.
+
+## Maintaining STRATEGY.md
+
+### Review triggers
+
+- After a major architectural decision
+- When a plan introduces a new technology stack
+- Quarterly review (scheduled by PM)
+
+### Update rules
+
+1. **Be decisive about direction changes.** Don't keep old strategy alongside new — replace it.
+2. **Log decisions with context.** The Decision Log captures *why* a choice was made, not just what.
+3. **Keep it current.** Stale strategy is worse than no strategy — it misdirects plans.
+
+## STRATEGY.md vs other docs
+
+| Document | Purpose | Audience |
+|----------|---------|----------|
+| `STRATEGY.md` | Product/technical direction, principles, decisions | PM, architect, all implementers |
+| `AGENTS.md` | Repo maintenance policy, conventions | Contributors and agents |
+| `CONCEPTS.md` | Domain vocabulary | Anyone reading/writing project docs |
+| Plans in `{PLAN_DIR}/` | Feature-level implementation plan | Implementers, reviewers |
+
+## NOT to do
+
+- Do not write STRATEGY.md as a novel — it should be scannable
+- Do not include implementation details or file paths
+- Do not create without PM/architect input (ask the questions)
+- Do not keep outdated strategy as "historical reference" — git preserves it
+- Do not conflate strategy (direction) with conventions (how-to)

package/harness-skills/pm/SKILL.md

@@ -1,17 +1,17 @@
 ---
 name: pm
-description: "Morning Star PM orchestration entry and autonomous Execute driver. On Cursor/Codex, /pm launches project-manager and keeps dispatch loops running. On OpenCode, switch to project-manager when the active agent is not PM. After Pre-implement GO, checkout the iteration spec_integration_branch, advance all open plans in {HARNESS_DIR}/status.json (per-plan feature branch → merge to integration → repeat until Done), and set host todos before each work unit. Use when user invokes /pm, resumes harness Execute, asks PM to drive an iteration, or OpenCode needs PM role for orchestration."
+description: "Morning Star PM orchestration entry. On Cursor/Codex, /pm launches project-manager. On OpenCode, switch to project-manager when the active agent is not PM. The autonomous Execute flow (per-plan dispatch, iteration management, compound) lives in mstar-iteration — this skill covers PM role identity, host entry, dispatch-first rules, and host-specific concerns."
 ---
 
 # PM — Morning Star orchestration entry
 
-Universal **project-manager** entry and **Execute automation driver**. Orchestrate and dispatch — **not** parent-agent product implementation (host tools do not waive this).
+**PM role launcher and host adapter.** Iteration flow (start → Execute → close) → **`mstar-iteration`** (canonical SSOT). This skill handles: PM role identity per host, boot order, dispatch-first rules, Cursor Plan mode.
 
 ## Host entry (read `mstar-host` first)
 
 | Host | Entry | PM role |
 | --- | --- | --- |
-| **Cursor / Codex** | User invokes **`/pm`** (or explicit “run as PM”) | Force **`project-manager`** for the session; this skill is the launcher + automation driver |
+| **Cursor / Codex** | User invokes **`/pm`** (or explicit "run as PM") | Force **`project-manager`** for the session |
 | **OpenCode** | User may already be on a configured agent | **If active role ≠ `project-manager`**: operate **only** as PM — load `mstar-roles` → `references/project-manager.md`; do **not** stay in dev/QC/architect voice for orchestration. Named invokes still use `@<agent-id>` per Assignment |
 
 Detect host → Read `mstar-host` → `references/cursor.md` | `opencode.md` | `codex.md`.
@@ -20,77 +20,20 @@ Detect host → Read `mstar-host` → `references/cursor.md` | `opencode.md` | `
 
 1. `mstar-harness-core`
 2. `mstar-roles` → `references/project-manager.md`
-3. Before first **implement** (non-hotfix): `mstar-dispatch-gates` + host reference
+3. Before first **implement** dispatch: `mstar-dispatch-gates` + host reference
 4. Before **QC**: `mstar-review-qc`
-5. **On demand:** `mstar-phase-gates`, `mstar-plan-conventions`, `mstar-plan-artifacts`, `mstar-branch-worktree`, `mstar-superpowers-align`
+5. **Iteration flow** (start / Execute / close): **`mstar-iteration`** — canonical SSOT for per-plan dispatch loop, integration branch, compound round. Do **not** re-describe the flow in this skill.
+6. **On demand:** `mstar-phase-gates`, `mstar-plan-conventions`, `mstar-plan-artifacts`, `mstar-branch-worktree`, `mstar-superpowers-align`
 
-Prepare/Execute gates, routing, Assignment templates, Task Board, QC tri-review, residuals → topic skills + PM references (not repeated here).
-
-## When to activate autonomous Execute
-
-Run **§ Autonomous Execute driver** when **all** are true:
-
-1. Harness has **`{HARNESS_DIR}/status.json`** (default `.mstar/status.json`) with at least one plan **not** `Done`
-2. **Pre-implement gate = GO** (`plan` locked, tasks ready — see `mstar-phase-gates` / PM Pre-Implement Gate Check)
-3. User intent is **continue Execute** (`/pm`, “推进 iteration”, “继续 plans”, or equivalent)
-
-If Prepare is incomplete → follow phase gates first; do **not** skip to implement dispatch.
-
-## Autonomous Execute driver
-
-**Goal:** finish the **active iteration** (all non-`Done` rows in `status.json.plans[]`) via dispatch loops — may span **multiple** `plan_id`s; do **not** stop after one plan while siblings remain open.
-
-### 0. Session todos (before any dispatch)
-
-Host UI todos are **session guardrails**, not SSOT. Set them **before** each plan wave so scope does not drift:
-
-| Host | Tool | Minimum set |
-| --- | --- | --- |
-| **Cursor** | `TodoWrite` or CreatePlan todos | Current `plan_id`; next batch (implement / QC / QA); branch checkpoint |
-| **Codex** | `update_plan` / Goal or Plan UI todos | Same intent — mirror active `plan_id` + next gate |
-| **OpenCode** | Host todo/plan UI if present | Same intent |
-
-SSOT remains `{HARNESS_DIR}/status.json` + `{PLAN_DIR}/` — todos track **this session’s next moves**, not replace status.
-
-### 1. Read backlog
-
-1. Read **`mstar-plan-artifacts`** + **`{HARNESS_DIR}/status.json`**
-2. List plans where `status` ∈ `{Todo, InProgress, InReview, Blocked}` (priority: `InProgress` → `InReview` → `Todo` → unblock `Blocked` if PM can)
-3. Read **`metadata.spec_integration_branch`** / **`merge_target`** and **`primary_spec`** links (`mstar-plan-conventions`)
-
-### 2. Iteration integration branch (Git cwd)
-
-1. Resolve **Spec / iteration integration branch** from `status.json` (`spec_integration_branch` on plan metadata or iteration-level registration — see `mstar-plan-artifacts/references/status-and-residuals.md`)
-2. **Checkout or create** that branch on the **business repo** cwd PM will orchestrate from; confirm with `git branch --show-current`
-3. If missing from metadata → **stop**, Read `mstar-plan-conventions` + confirm with user per `mstar-branch-worktree` (PM branch confirmation template); record in plan + status **same round**
-
-This branch is the **merge target** for each plan’s work until **all** plans under the iteration are `Done`.
-
-### 3. Per-plan loop (until all `Done`)
-
-For each active `plan_id`:
-
-1. **Plan start — feature branch:** Assignment uses **`Working branch: create <plan-feature-branch> from <spec_integration_branch>`** (or PM-approved equivalent). One **dedicated plan implementation branch** per `plan_id`; parallel tracks inside a plan → topic branches from integration + worktrees (`mstar-branch-worktree`).
-2. **Implement → InReview:** dispatch-only loops (`§ Dispatch-first`); update `status.json` + main plan after each Completion Report v2
-3. **QC → QA → Done:** tri-review + QA per `mstar-review-qc`; PM marks `Done` only when gates pass
-4. **Plan complete — merge back:** merge **plan feature branch** (and any integrated topic heads) **into `spec_integration_branch`**; resolve conflicts **before** next plan or QC on shared scope
-5. **Next plan** from step 1 on updated integration branch
-
-When **every** plan in the iteration is `Done` → optional PR from `spec_integration_branch` to `main` per `mstar-plan-conventions` (unless Assignment `Branch policy` says otherwise).
-
-### 4. Push discipline
-
-- **No** routine “should I continue?” on harness basics — decide, record in Assignment if needed, **dispatch**
-- Unknowns → **Read** `mstar-*`; **`Blocked`** or user only for stop, secrets, irreversible scope gaps, or post-read rule conflict
-- Actual Git ≠ plan/`status.json` `working_branch` → **same round** update plan + status **or** worktree dispatches before next implement
+Prepare/Execute gates, routing, Assignment templates, Task Board, QC tri-review, residuals, compound → topic skills + PM references (not repeated here).
 
 ## Dispatch-first (`implement`)
 
 | Do | Don't |
 | --- | --- |
-| **Loop:** `## Assignment` → invoke → Completion Report v2 → report-to-status → next batch | Parent **Write/Edit/Shell** on product code to “move faster” |
+| **Loop:** `## Assignment` → invoke → Completion Report v2 → report-to-status → next batch | Parent **Write/Edit/Shell** on product code to "move faster" |
 | **1 Assignment ⇒ 1 invoke** when host supports Task/@agent (`mstar-dispatch-gates`) | Assignment markdown only, no matching invoke |
-| Put merge/branch/handoff from **this thread** into Assignment | Skip subagent because context is “already here” |
+| Put merge/branch/handoff from **this thread** into Assignment | Skip subagent because context is "already here" |
 
 - **NEVER** implement while staying PM — QC 3× comes later; **implement still delegates** dev roles.
 - **Delegate scope / PM whitelist:** `mstar-roles` → PM Execution Boundary.
@@ -108,4 +51,4 @@ CreatePlan / SwitchMode: Read **`mstar-host/references/cursor-plan-mode-bridge.m
 3. `mstar-harness-core` + runtime `mstar-*`  
 4. This skill  
 
-**Dispatch-first + `mstar-dispatch-gates`** win over “fast parent agent” unless user overrides.
+**Dispatch-first + `mstar-dispatch-gates`** win over "fast parent agent" unless user overrides.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mstar-harness/opencode",
-  "version": "0.6.21",
+  "version": "0.6.23",
   "description": "Morning Star harness OpenCode plugin (skills bootstrap and agent loading).",
   "license": "MIT",
   "repository": {