@mstar-harness/opencode 0.6.3 → 0.6.5

package/harness-skills/mstar-coding-behavior/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: mstar-coding-behavior
-description: Morning Star (启明星) 跨角色通用编码行为准则 —— Think Before Coding（显式假设、不静默猜测）、Simplicity First（最小实现、拒绝投机抽象）、Surgical Changes（只改与任务直接相关的行、不顺手重构、不 piggyback）、Goal-Driven Execution（把模糊请求转为可验证结果、Step → verify 微模板、证据驱动的完成声明）。任何实现、调试、重构、审查任务都应优先 Read 本 skill；`@fullstack-dev` / `@frontend-dev` / `@fullstack-dev-2` / `@architect` / `@qa-engineer` / `@ops-engineer` / `@prompt-engineer` 动手前必读；QC 审查员核对变更是否只做了该做的手术时必读。本 skill 不覆盖分支门禁、QC/QA 路由、Assignment 权限、Done 所有权等不变量（那些以 `mstar-harness-core` 为准）。
+description: Morning Star (启明星) 跨角色通用编码行为准则 —— Think Before Coding（显式假设、不静默猜测）、Simplicity First（最小耐久切片，拒绝未登记临时方案）、Surgical Changes（只改与任务直接相关的行、不顺手重构、不 piggyback）、Goal-Driven Execution（把模糊请求转为可验证结果、Step → verify 微模板；分批必须留 roadmap）。任何实现、调试、重构、审查任务都应优先 Read 本 skill；`@fullstack-dev` / `@frontend-dev` / `@fullstack-dev-2` / `@architect` / `@qa-engineer` / `@ops-engineer` / `@prompt-engineer` 动手前必读；QC 审查员核对变更是否只做了该做的手术时必读。本 skill 不覆盖分支门禁、QC/QA 路由、Assignment 权限、Done 所有权等不变量（那些以 `mstar-harness-core` 为准）。
 ---
 
 ## Load order（必读顺序）
@@ -43,16 +43,24 @@ Quick check:
 
 ## 2) Simplicity First
 
-Core idea: implement the minimum that satisfies the request and acceptance criteria.
+Core idea: implement the smallest durable slice that satisfies the request and acceptance criteria.
 
 - Do not add features, flags, or configurability that were not requested.
 - Avoid introducing new abstractions for single-use logic.
-- Prefer straightforward local fixes over framework-level reshaping.
+- Prefer straightforward local fixes over framework-level reshaping **only when they fit the target design**.
 - Reject speculative error handling for impossible paths unless required by project policy.
+- Do not confuse "minimum" with "temporary." A small implementation must still align with the long-term target state, stable interfaces, and known follow-up plan.
+- If a workaround is necessary, label it as `temporary`, explain why it is unavoidable, and record the removal path in the plan/status artifact before claiming the task is complete.
 
 Default rule:
 
-- If 200 lines can be 50 with the same behavior and clarity, prefer the smaller solution.
+- If 200 lines can be 50 with the same behavior, clarity, and durable architecture, prefer the smaller solution.
+
+Durability check:
+
+- Can this slice be extended by the next batch without undoing its core shape?
+- Are deferred items captured in an existing roadmap / task board / residual tracker, not just mentioned in chat?
+- Would a reviewer understand whether this is the final approach, a staged slice, or a temporary workaround?
 
 ## 3) Surgical Changes
 
@@ -74,8 +82,10 @@ Core idea: convert vague requests into verifiable outcomes and iterate until ver
 
 - Define concrete success criteria before major edits.
 - For multi-step tasks, use brief `Step -> verify` checkpoints.
+- For split delivery, maintain a durable roadmap: current slice, later slices, dependencies, owner/trigger, and completion condition.
 - Prefer evidence-backed completion claims (tests, command output, reproducible checks).
 - If verification fails, loop on diagnosis and fix before declaring completion.
+- Do not finish with "next plan / later / follow-up" only in prose. If the work is not fully complete, the remaining work must be written to the plan/status artifact or the task must report `Partial` / `Blocked`.
 
 Micro template:
 

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

@@ -71,6 +71,8 @@ PM 在 Assignment 写 **`Task category`**（主类 + 可选 `secondary`）：
 
 可追踪清单（plan `tasks` 或 Todo）；偏离时 PM 拉回；完成前须可核对证据（**`mstar-superpowers-align`** · `verification-before-completion`）。
 
+**Durable Roadmap Gate**：凡声明“分批 / 后续 / next plan / later / temporary workaround”的非热修任务，必须在 `{PLAN_DIR}` 主 plan、CreatePlan mirror、`status.json`/residual、或 PM Task Board 中写清后续路线（批次、依赖、owner/触发条件、完成定义）。只在对话或 Completion Report 里说“以后做”不算可追踪，不能进入 implement GO 或 Done。
+
 ## 专题 skill 索引
 
 | Skill | 职责 |
@@ -128,6 +130,7 @@ Read **`mstar-host`** after this skill; detect host per its table, then Read the
 | 角色文件塞流程长文 | 用专题 skill |
 | 无证据宣称完成 | `mstar-coding-behavior` / verification |
 | CreatePlan 不落盘 / 无 `.agents` mirror | `mstar-host` · `cursor-plan-mode-bridge` |
+| 临时方案 / 后续计划只写在对话里 | `mstar-phase-gates` · Durable Roadmap Gate |
 
 ## 可选：OpenViking Memory
 

package/harness-skills/mstar-host/references/cursor-plan-mode-bridge.md

@@ -72,6 +72,7 @@ Set `updated_at` on `status.json` to today (`YYYY-MM-DD`). Commit harness files
 
 - YAML or markdown frontmatter with `plan_id`, title, status (`Todo` / `InProgress` — not `Done` unless PM/QA authority).
 - **Task list** as markdown checkboxes (`- [ ]` / `- [x]`) matching CreatePlan implement todos.
+- **Roadmap / deferred scope** section when delivery is staged, partial, or uses a temporary workaround.
 - Link: “SSOT status: `{HARNESS_DIR}/status.json` → `plans[]` / `residual_findings`.”
 
 After **CreatePlan**, keep CreatePlan body and mirror file **in sync** when scope changes (update both in the same coordination round).
@@ -94,6 +95,14 @@ Use this structure in CreatePlan `plan` markdown; mirror the same sections into
 - clarify: [done|n/a]
 - plan: [done|in progress]
 
+## Roadmap / deferred scope
+
+- Target state: <complete outcome>
+- Current slice: <what this plan/batch delivers>
+- Later slices: <batch/order/owner or trigger>
+- Deferred scope / temporary workaround removal: <tracking location or N/A>
+- Final Done definition: <condition for full completion>
+
 ## Tasks (mirror as checkboxes in SSOT plan file)
 
 ### Bootstrap (fixed prefix — complete before implement)
@@ -144,10 +153,27 @@ Before switching from Plan to Agent for implementation (or declaring Plan phase
 - [ ] `status.json` contains `plans[]` entry with matching `id` and `file`
 - [ ] Bootstrap todos `harness-init`, `spec-register`, `mirror-plan` are **done**
 - [ ] CreatePlan implement todos reference **task ids** traceable to SSOT plan checkboxes
+- [ ] If staged/partial/temporary, CreatePlan and SSOT plan both contain `Roadmap / deferred scope`
 - [ ] **Plan Path** for any Assignment uses the SSOT path, not the Cursor plan URI
 
 If any item fails → **Blocked**; finish harness sync before implement.
 
+## Build resume contract
+
+Cursor **Build** resumes the current plan in Agent mode. Do not assume it replays `/pm` or re-enters a role skill automatically.
+
+First action after Build, before product-code edits:
+
+1. Reload the harness entry: `mstar-harness-core` → `mstar-host` Cursor reference → this bridge.
+2. If the plan is a Morning Star plan, resume as `project-manager` for coordination and dispatch only.
+3. Read the SSOT plan and `status.json`; use them as the source of truth over the Cursor plan URI.
+4. For each implement/code todo, require a PM Assignment with `Execute as`, `Delegation`, `Working branch` or `Branch policy`, and SSOT `Plan Path`.
+5. If the Assignment or SSOT state is missing, report **Blocked** and repair the harness state before implementation.
+
+Allowed in the parent Build session: plan/status maintenance, routing decisions, Assignment writing, and host Task dispatch.
+
+Not allowed in the parent Build session by default: product implementation, test implementation, QC execution, QA execution, deployment, or ops changes. Those follow the normal PM dispatch rules unless the user explicitly overrides the harness.
+
 ## PM in Plan mode (`/pm`)
 
 When `/pm` runs under Plan mode:
@@ -166,6 +192,8 @@ When `/pm` runs under Plan mode:
 | Drift between CreatePlan and SSOT plan | Update both in same round |
 | Cursor plan URI as Plan Path | Use `{PLAN_DIR}/...` path |
 | Skip `spec-register` | Add `plans[]` row before implement |
+| Build starts coding in the parent session | Resume PM context; dispatch implement work or block on missing Assignment |
+| Follow-up only in chat / no roadmap section | Add `Roadmap / deferred scope` to CreatePlan and SSOT plan before implement |
 
 ## Related skills
 

package/harness-skills/mstar-host/references/cursor.md

@@ -27,6 +27,8 @@ Each **implement todo**: per–task-ID **git commit** on Working branch → SSOT
 
 Before **SwitchMode → Agent**: mirror plan exists; `status.json` lists `plan_id`; bootstrap todos done. **Never** use only the Cursor plan URI as **Plan Path**.
 
+After **Build**: treat the run as plan resume, not `/pm` replay. Reload `mstar-harness-core` + this Cursor reference, resume Morning Star plans as `project-manager` orchestration, and dispatch implementation through Task unless the user explicitly overrides the harness.
+
 Enforcement: `rules/mstar-cursor-plan-mode.mdc` when plugin active.
 
 ## `/pm` precedence

package/harness-skills/mstar-phase-gates/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: mstar-phase-gates
-description: Morning Star (启明星) Spec-Driven 双阶段门禁 —— Prepare（`specify → clarify → plan`）、Execute（`plan(locked) → tasks → implement`）、意图门禁、clarify 核心纪律（共享理解 / 先探索 / 每问推荐答案）、hotfix 压缩路径、可验证编辑、Phase Gate 最小证据。**必须**在 PM 判定 gate、首次 implement 派单前、产品/架构参与 Prepare、或解释为何不能跳过 plan/clarify 时 Read；`@project-manager` 每轮编排非 hotfix 任务必读；`@product-manager` / `@architect` 写规格与锁 plan 时必读 Prepare 节；实现角色 Read Execute 与 hotfix 例外即可。Task category 与 `quick` 禁豁免规则仍在 `mstar-harness-core`。并行 Superpowers 短语见 `mstar-superpowers-align`。
+description: Morning Star (启明星) Spec-Driven 双阶段门禁 —— Prepare（`specify → clarify → plan`）、Execute（`plan(locked) → tasks → implement`）、意图门禁、长期目标优先、分批 roadmap 强制落盘、clarify 核心纪律（共享理解 / 先探索 / 每问推荐答案）、hotfix 压缩路径、可验证编辑、Phase Gate 最小证据。**必须**在 PM 判定 gate、首次 implement 派单前、产品/架构参与 Prepare、或解释为何不能跳过 plan/clarify 时 Read；`@project-manager` 每轮编排非 hotfix 任务必读；`@product-manager` / `@architect` 写规格与锁 plan 时必读 Prepare 节；实现角色 Read Execute 与 hotfix 例外即可。Task category 与 `quick` 禁豁免规则仍在 `mstar-harness-core`。并行 Superpowers 短语见 `mstar-superpowers-align`。
 ---
 
 ## Load order（必读顺序）
@@ -19,13 +19,15 @@ description: Morning Star (启明星) Spec-Driven 双阶段门禁 —— Prepare
     1. **能查库则查库**：若问题可通过探索代码库（实现、配置、`{SPECS_DIR}`、`{KNOWLEDGE_DIR}`、`{ITERATION_DIR}` 等）得到答案，**先探索、不向用户提问**。
     2. **每问带推荐**：每个仍需用户确认的问题，须给出**推荐答案**（及简短理由），便于快速对齐。
     3. **收口摘要**：`clarify` 结束前列出：已决事项、仍 open 的假设、对 `plan` 的约束。
-- **`plan`** — 技术方案、模块边界/接口契约、风险与回滚点、验证计划。
+- **`plan`** — 技术方案、长期目标状态、模块边界/接口契约、风险与回滚点、验证计划。
   - **意图门禁**：锁 plan 前须能书面写清**真实目标 / 成功判据 / 非目标**三项；否则 Prepare 未通过。
+  - **长期方案优先**：默认先设计目标状态，再裁剪本轮可交付切片；不得以“临时方案 / 混合方案 / 以后再说”替代目标设计。
+  - **Durable Roadmap Gate**：若本轮只做部分范围，plan 必须写明 roadmap（批次、依赖、暂缓项、owner/触发条件、最终完成定义）。只有一句“后续再做 / next plan”视为未通过 plan gate。
 
 ### B. Execute：`plan(locked) → tasks → implement`
 
 - **`plan(locked)`** — 冻结基线；实现中出现新约束时**先回写 plan 再继续**。
-- **`tasks`** — 含依赖顺序、并行标记、完成判据；每任务可追踪到 plan 与验收标准。
+- **`tasks`** — 含依赖顺序、并行标记、完成判据；每任务可追踪到 plan、roadmap 批次与验收标准。
   - **并行标签**：若 PM 将 ≥2 条实现轨 **同时** 分派，须在 `Superpowers` 中写入 `dispatching-parallel-agents`；同仓 ≥2 可写并发时叠 `using-git-worktrees`（见 **`mstar-superpowers-align`** 与 **`mstar-branch-worktree`**）。
 - **`implement`** — 按 tasks 顺序执行并提交自检证据；完成进入 `InReview`；遵循 **`mstar-coding-behavior`**。
 
@@ -65,8 +67,9 @@ description: Morning Star (启明星) Spec-Driven 双阶段门禁 —— Prepare
   - **`clarify` 核心纪律**（见 **`mstar-phase-gates` SKILL.md** Prepare · `clarify`）：逐方面核对至共享理解；沿设计决策树逐枝、一次一决；能探索代码库则先探索；每问附推荐答案；阶段末汇总已决与仍 open 假设。
 - `plan`
   - 目标：给出可执行技术方案与风险控制。
-  - 最小产物：方案、模块边界/接口契约、风险与回滚、验证计划。
+  - 最小产物：目标状态、方案、模块边界/接口契约、风险与回滚、验证计划。
   - **准入**：能书面写出真实目标、成功判据、非目标后再锁 plan（同 `SKILL.md`）。
+  - **分批准入**：若计划不是一次性交付完整范围，须写 `Roadmap / Batch Plan`：本批做什么、后续批次做什么、依赖顺序、暂缓项、owner/触发条件、最终 Done 定义；缺失则 `blocked`。
 
 ### B. Execute
 
@@ -77,7 +80,7 @@ description: Morning Star (启明星) Spec-Driven 双阶段门禁 —— Prepare
   - 最小动作：在 plan 或 notes 记录当前锁定版本（日期或 hash）。
 - `tasks`
   - 目标：把 plan 拆成可执行任务与依赖顺序。
-  - 最小产物：任务列表、并行标记、完成判据、映射到验收标准。
+  - 最小产物：任务列表、并行标记、完成判据、映射到验收标准与 roadmap 批次。
   - **PM**：若并行标记对应「多轨同时 implement」，在对外 **Status Update** 与实现 Assignment 的 **`Superpowers`** 中写入 **`dispatching-parallel-agents`**（或同义短语）；同仓多可写并发时叠 **`using-git-worktrees`**（见 `mstar-superpowers-align`）。
 - `implement`
   - 目标：按任务执行并提交证据，进入审查。
@@ -108,10 +111,11 @@ description: Morning Star (启明星) Spec-Driven 双阶段门禁 —— Prepare
 2. `clarify` 是否完成（高影响歧义是否收敛）？
 3. 意图门禁是否满足（真实目标 / 成功判据 / 非目标已写明）？
 4. `plan` 是否完成并可引用？
-5. `tasks` 是否完成？
-6. Assignment 是否含 **`Task category`**（实现类任务）并与 Owner 一致？
-7. 若中途出现 plan drift，是否先回写再继续？
-8. 实现说明中是否体现"最小解法 + 手术式改动 + 可验证检查"？
+5. 若分批/暂缓/临时绕行，roadmap 是否落在 plan/status 中，而不是只在对话里？
+6. `tasks` 是否完成？
+7. Assignment 是否含 **`Task category`**（实现类任务）并与 Owner 一致？
+8. 若中途出现 plan drift，是否先回写再继续？
+9. 实现说明中是否体现"最小耐久切片 + 手术式改动 + 可验证检查"？
 
 任一项为「否」时，`Gate decision` 必须是 `blocked`。
 

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

@@ -30,6 +30,7 @@ If any item below matches, **stop** and return `Blocked` to `project-manager` in
 - **NEVER** infer you may call `Task` / subagents because the host **lists** `subagent_type` names (`architect`, `fullstack-dev`, …). **Tool availability ≠ delegation authorization**; only **`Delegation: allowed (...)`** grants callees.
 - **NEVER** load and execute Superpowers `dispatching-parallel-agents` yourself to fan out child agents; that skill is **PM-orchestration-only** (see `mstar-superpowers-align`). If parallel runners are needed, report to PM for re-dispatch.
 - **NEVER** treat `Gate Decision: blocked` (material, high-impact ambiguities still open) as permission to hand off “ready for implement” architecture—finish clarify, update the package, or return `Blocked` to PM.
+- **NEVER** use a temporary, mixed, or partial design as the selected approach unless the target architecture and staged roadmap are written in the assigned plan/spec. “Later” without a tracking location is `Blocked`, not a handoff.
 - **NEVER** edit application implementation source, automated tests, CI workflows, Dockerfiles, or secrets-bearing runtime configuration unless the assignment explicitly limits you to doc-only placeholders **and** PM recorded the risk acceptance.
 - **NEVER** persist planning artifacts from `writing-plans` (or equivalent) under upstream `docs/superpowers/plans/`; only `{PLAN_DIR}` per `mstar-plan-conventions`.
 
@@ -79,6 +80,9 @@ Do not create your own branch strategy.
 - Option A: summary + trade-offs
 - Option B: summary + trade-offs
 - Selected Approach: why
+- Long-term Target State
+- Durable Slice for This Batch
+- Roadmap if Split: batches + dependencies + deferred scope + final Done definition
 - Module Boundaries
 - API/Data Contracts
 - Risks and Rollback
@@ -92,6 +96,8 @@ Do not create your own branch strategy.
 # Architecture: <System/Module>
 
 ## Overview
+## Long-term Target State
+## Staged Roadmap
 ## Architecture Diagram
 ## Tech Stack
 ## Module Breakdown

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

@@ -33,6 +33,7 @@ If any item below matches, **stop** and return `Blocked` to `project-manager` in
 - **NEVER** point `writing-plans` output to upstream `docs/superpowers/plans/`; use `{PLAN_DIR}` per `mstar-plan-conventions`.
 - **NEVER** offload PRD/product-doc drafting to `@explore`; short read-only orientation only per `mstar-harness-core`.
 - **NEVER** label a Prepare package as “ready for implement” while `Gate Decision: blocked` for material ambiguities—resolve, document waivers with PM, or return `Blocked`.
+- **NEVER** split delivery by saying “later / follow-up / next phase” without writing the product roadmap, deferred scope, and final completion definition in the assigned plan/spec.
 
 ## Superpowers (When Enabled)
 
@@ -69,6 +70,8 @@ If writing files to business repo, use only PM-assigned `Working branch` / `Bran
 - User Value
 - Scope
 - Non-goals
+- Target State
+- Roadmap if Split
 - Draft DoD
 
 ### Clarify
@@ -86,6 +89,9 @@ If writing files to business repo, use only PM-assigned `Working branch` / `Bran
 ## Target Users
 ## User Stories
 ## Acceptance Criteria
+## Target State
+## Roadmap / Release Slices
+## Deferred Scope and Tracking
 ## Priority
 ## Effort (agent-oriented)
 ```

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

@@ -53,6 +53,7 @@ For assignees (non-PM):
 **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>
 **Task**: <concrete work aligned with coverage>
 **Checkpoint Comment Rule**: commit -> Completion Report v2 -> PM Status Update -> next batch
 **Why batching is safe**: <required when batching >=3 IDs>

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

@@ -116,6 +116,7 @@ If any item below matches, fix the dispatch/plan state or mark `Blocked`—do **
 - **NEVER** point QC at a single dev worktree/`Review cwd` that cannot contain **all** claimed changes from parallel tracks until Git integration lands on one `Working branch` `HEAD` (`mstar-branch-worktree` QC/QA alignment).
 - **NEVER** label `QA: skipped` for report-only QA—still dispatch `@qa-engineer` with report-only mode; QC skip rules are separate and explicit.
 - **NEVER** let non-PM/non-QA roles mark plan `Done`.
+- **NEVER** accept “temporary workaround”, “follow-up later”, “next plan”, or “split into batches” as narrative-only scope management. If work is deferred or staged, write the roadmap/tracking location before implement GO or Done.
 
 ---
 
@@ -127,7 +128,8 @@ Before first implement dispatch (non-hotfix):
 2. `clarify` done (no unresolved high-impact ambiguity)
 3. `plan` done and referenceable
 4. `tasks` + PM Task Board ready for non-trivial plan
-5. New constraints discovered are written back to plan first
+5. Roadmap written when delivery is split, deferred, or temporary
+6. New constraints discovered are written back to plan first
 
 If any fail -> do not dispatch implement.
 
@@ -177,6 +179,7 @@ Anti-patterns:
 - 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?
+- Q14: If this is partial/staged/temporary, is the roadmap/tracking location written in the plan/status artifacts rather than only in prose?
 
 ---
 
@@ -195,6 +198,8 @@ Pre-implement Gate Check:
 - non_trivial_plan: yes|no
 - PM_Task_Board_published: yes|no
 - batch_strategy_defined: yes|no
+- roadmap_written: yes|no|n/a
+- roadmap_location: <Plan section / PM Task Board / status.json / residual id / n/a>
 - assignment_batch_index: <e.g. 1/3>
 - coverage_ids: <e.g. T1,T2>
 - reason_if_single_assignment: <required when only one batch>
@@ -208,6 +213,8 @@ Hard block when:
 
 - Non-trivial plan has required field = `no`
 - Harness-active non-hotfix flow lacks on-disk main plan or status registration
+- `assignment_batch_index` is not `1/1` but `roadmap_written` is not `yes`
+- Any temporary workaround or deferred scope lacks a durable tracking location
 - `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
 
@@ -218,6 +225,7 @@ Hard block when:
 Before first implement dispatch:
 
 - Publish PM Task Board with ID/owner/deps/parallel/coverage mapping
+- If delivery spans batches, include the full roadmap: batch order, deferred scope, dependencies, owner/trigger, and final Done definition
 - Every implement Assignment declares `PM Task Board coverage`
 - Default batch size 1-2 IDs; `>=3` requires `Why batching is safe`
 - Completion rhythm: commit -> Completion Report v2 -> PM Status Update -> next dispatch

package/package.json

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