@mstar-harness/opencode 0.6.22 → 0.7.0

package/harness-skills/mstar-compound/references/category-mapping.md

@@ -0,0 +1,37 @@
+# Category mapping: problem_type → directory under {KNOWLEDGE_DIR}
+
+## Bug track
+
+| problem_type | directory | track |
+|---|---|---|
+| `build_error` | `build-errors/` | bug |
+| `test_failure` | `test-failures/` | bug |
+| `runtime_error` | `runtime-errors/` | bug |
+| `performance_issue` | `performance-issues/` | bug |
+| `database_issue` | `database-issues/` | bug |
+| `security_issue` | `security-issues/` | bug |
+| `ui_bug` | `ui-bugs/` | bug |
+| `integration_issue` | `integration-issues/` | bug |
+| `logic_error` | `logic-errors/` | bug |
+| `config_error` | `config-errors/` | bug |
+
+## Knowledge track
+
+| problem_type | directory | track |
+|---|---|---|
+| `best_practice` | `best-practices/` | knowledge |
+| `convention` | `conventions/` | knowledge |
+| `architecture_pattern` | `architecture-patterns/` | knowledge |
+| `design_pattern` | `design-patterns/` | knowledge |
+| `tooling_decision` | `tooling-decisions/` | knowledge |
+| `testing_pattern` | `testing-patterns/` | knowledge |
+| `api_design` | `api-design/` | knowledge |
+| `workflow_issue` | `workflow-patterns/` | knowledge |
+| `developer_experience` | `developer-experience/` | knowledge |
+| `documentation_gap` | `documentation/` | knowledge |
+
+## Rules
+
+1. The `category` field in frontmatter must match the directory name (without trailing slash).
+2. Prefer the narrowest applicable `problem_type`. Use `best_practice` only when no narrower knowledge-track value fits.
+3. When creating a new directory under `{KNOWLEDGE_DIR}`, add it to this mapping and create an empty directory.

package/harness-skills/mstar-compound/references/concepts-vocabulary.md

@@ -0,0 +1,44 @@
+# CONCEPTS.md vocabulary rules
+
+`CONCEPTS.md` **must** live at the repository root (`<repo-root>/CONCEPTS.md`, same level as `.git/` and `AGENTS.md`), **never** inside `{HARNESS_DIR}` or any subdirectory. It defines the words that mean something specific in this codebase — substrate that `{KNOWLEDGE_DIR}` and `AGENTS.md` can cite without redefinition.
+
+## How terms enter
+
+Two paths:
+
+- **Accretion** — a learning surfaces a term whose meaning wasn't obvious, so it gets defined. Catches *peripheral* terms (friction surfaces them).
+- **Seeding** — proactively defines **core domain nouns** the area's declared domain model exposes. Catches *stable-central* terms accretion never reaches.
+
+### What earns a slot
+
+A term qualifies when its meaning here is precise enough that a new engineer would need it defined to follow conversations, tickets, or code. General programming vocabulary does not belong.
+
+### Per entry
+
+- **Definition**: one sentence — what the term means in this domain, what makes it distinct from neighbors.
+- A term with non-obvious behavioral rules (lifecycle, cancellation semantics, ownership invariants) earns a second paragraph.
+- When retired synonyms exist: `*Avoid:* old-name, other-name`.
+- No implementation specifics (file paths, class names, table names), no status/date/owner fields, no version-specific claims.
+
+### Organization
+
+Cluster by domain relationship — entities with their states, processes with their stages. A flat list works when the file is small. Reshape as it grows.
+
+### Flagged ambiguities (tail of file)
+
+When two terms were used interchangeably and the team settled on a distinction, record the resolution as a one-line note.
+
+## One illustrative entry
+
+```markdown
+## MyDomain
+
+### Reservation
+A future commitment to seat a Party at a specified date and time.
+*Avoid:* Booking, appointment
+
+A Reservation owns its Party but does not own a Table — Tables are acquired only when the Party arrives, through a Seating. Lifecycle: Booked → Seated → Completed → No-Show.
+
+### Party
+The guests committed to a Reservation. Each Reservation has exactly one Party.
+```

package/harness-skills/mstar-compound/references/schema.yaml

@@ -0,0 +1,122 @@
+# Knowledge documentation schema for {KNOWLEDGE_DIR}
+# Canonical frontmatter contract. Two tracks: bug and knowledge.
+
+tracks:
+  bug:
+    description: "Defects, failures, and errors that were diagnosed and fixed"
+    problem_types:
+      - build_error
+      - test_failure
+      - runtime_error
+      - performance_issue
+      - database_issue
+      - security_issue
+      - ui_bug
+      - integration_issue
+      - logic_error
+      - config_error
+  knowledge:
+    description: "Practices, patterns, conventions, decisions, and workflow improvements"
+    problem_types:
+      - best_practice
+      - documentation_gap
+      - workflow_issue
+      - developer_experience
+      - architecture_pattern
+      - design_pattern
+      - tooling_decision
+      - convention
+      - api_design
+      - testing_pattern
+
+required_fields:
+  module:
+    type: string
+    description: "Module, component, or area affected"
+
+  date:
+    type: string
+    pattern: '^\d{4}-\d{2}-\d{2}$'
+    description: "Date documented (YYYY-MM-DD)"
+
+  problem_type:
+    type: enum
+    values:
+      - build_error
+      - test_failure
+      - runtime_error
+      - performance_issue
+      - database_issue
+      - security_issue
+      - ui_bug
+      - integration_issue
+      - logic_error
+      - config_error
+      - developer_experience
+      - workflow_issue
+      - best_practice
+      - documentation_gap
+      - architecture_pattern
+      - design_pattern
+      - tooling_decision
+      - convention
+      - api_design
+      - testing_pattern
+    description: "Primary category — determines track (bug vs knowledge)"
+
+  category:
+    type: string
+    description: "Directory name under {KNOWLEDGE_DIR} (see category-mapping.md)"
+
+  severity:
+    type: enum
+    values:
+      - critical
+      - high
+      - medium
+      - low
+    description: "Impact severity"
+
+track_rules:
+  bug:
+    required:
+      symptoms:
+        type: array
+        description: "Observable symptoms (errors, broken behavior)"
+      root_cause:
+        type: string
+        description: "Fundamental technical cause"
+      resolution_type:
+        type: enum
+        values:
+          - code_fix
+          - migration
+          - config_change
+          - test_fix
+          - dependency_update
+          - environment_setup
+          - workflow_improvement
+          - documentation_update
+          - tooling_addition
+        description: "Type of fix applied"
+  knowledge:
+    optional:
+      applies_when:
+        type: array
+        description: "Conditions or situations where this guidance applies"
+
+optional_fields:
+  plan_id:
+    type: string
+    description: "Link to status.json plans[].id"
+  tags:
+    type: array
+    max_items: 8
+    description: "Search keywords, lowercase, hyphen-separated"
+  last_updated:
+    type: string
+    pattern: '^\d{4}-\d{2}-\d{2}$'
+    description: "Date of last substantive update (added when updating an existing doc)"
+  related_components:
+    type: array
+    description: "Other components involved"

package/harness-skills/mstar-compound-refresh/SKILL.md

@@ -0,0 +1,128 @@
+---
+name: mstar-compound-refresh
+description: Morning Star 知识维护 —— 审查 `{KNOWLEDGE_DIR}` 中文档是否仍准确、去重叠合并、清理过期知识。触发：`mstar-compound` 发现可合并文档、定期维护、或显式调用。产出：更新/合并/删除/标记为 stale 的文档 + 维护报告。
+---
+
+# mstar-compound-refresh（知识维护）
+
+## Load order
+
+**Read `mstar-harness-core` first.** Path symbols → **`mstar-plan-conventions`**. On conflict, **`mstar-harness-core` wins**.
+
+## Purpose
+
+Knowledge documents in `{KNOWLEDGE_DIR}` age. Code changes, conventions evolve, patterns become obsolete. `mstar-compound-refresh` audits the knowledge store against the current codebase and makes it trustworthy again.
+
+## 产物与操作路径
+
+**SSOT**: `mstar-plan-conventions/references/artifact-storage-paths.md`。本 skill 仅操作 `{HARNESS_DIR}/knowledge/**/*.md` + `{HARNESS_DIR}/knowledge/README.md` + `<repo-root>/CONCEPTS.md` + `{HARNESS_DIR}/status.json`（引用更新）。**禁止**操作 `docs/`、`{PLAN_DIR}/`、`{ITERATION_DIR}/`、`{SPECS_DIR}/`。
+
+## When to use
+
+| Trigger | Example |
+|---------|---------|
+| `mstar-compound` detected overlapping docs | "Two docs cover N+1 queries — consider refresh" |
+| Scheduled maintenance | "It's been a quarter, let's audit knowledge" |
+| Domain refactored | After a major module rewrite |
+| Explicit user request | `/pm compound-refresh performance-issues` |
+
+## Maintenance outcomes
+
+For each candidate document, classify into one of five outcomes:
+
+| Outcome | Meaning | Default action |
+|---------|---------|----------------|
+| **Keep** | Still accurate and useful | No edit; report reviewed |
+| **Update** | Core solution correct, references drifted | In-place edits (paths, module names, code snippets) |
+| **Consolidate** | Two+ docs overlap heavily, both correct | Merge unique content into canonical doc, delete subsumed |
+| **Replace** | Old doc is misleading; known better replacement exists | Create trustworthy successor, then delete old |
+| **Delete** | No longer useful, applicable, or distinct | Delete — git history preserves it |
+
+## Core rules
+
+1. **Evidence over opinion.** Signals are inputs, not a scorecard. Use engineering judgment.
+2. **Prefer no-write Keep.** Do not update a doc just to leave a review breadcrumb.
+3. **Match docs to reality.** When code differs from doc, update the doc — not ask whether the code change was "intentional."
+4. **Be decisive.** When evidence is clear (file renamed, class moved), apply. Only ask PM when genuinely ambiguous.
+5. **Avoid low-value churn.** Don't edit for typos, polish, or cosmetic changes that don't improve accuracy.
+6. **Delete, don't archive.** No `_archived/` directory. Git history is the archive. `git log --diff-filter=D -- <path>` finds deleted docs.
+7. **Evaluate document-set design.** Check whether two+ docs overlap and should be consolidated. Redundant docs silently drift apart.
+
+## Scope selection
+
+### Default: user-guided
+
+1. Ask PM for scope: "All knowledge docs, a specific category, or a keyword?"
+2. If category: narrow to `{KNOWLEDGE_DIR}/<category>/`.
+3. If keyword: search frontmatter (`module:`, `tags:`, `problem_type:`) and filenames.
+
+### PM-directed: specific scope
+
+PM provides a scope hint (directory name, filename, module name, or keyword). Match in this order:
+1. Directory match under `{KNOWLEDGE_DIR}/`
+2. Frontmatter field match
+3. Filename match
+4. Content search
+
+## Process
+
+### Phase 1: Inventory
+
+1. List all `.md` files under `{KNOWLEDGE_DIR}/` (excluding `README.md` and index files).
+2. Read frontmatter of each candidate.
+3. Group by `category` / `module` for impact clustering.
+
+### Phase 2: Assess per doc
+
+For each doc, check:
+
+1. **Referenced code still exists?** — grep for file paths, class names, function names mentioned.
+2. **Referenced conventions still match?** — check against current `AGENTS.md`, `CONCEPTS.md`, lint configs.
+3. **Solution still the recommended approach?** — has a newer pattern superseded it?
+4. **Overlap with other docs?** — search for same module/tags to find duplicates.
+
+### Phase 3: Classify and act
+
+Classify each doc → Keep / Update / Consolidate / Replace / Delete. Apply changes.
+
+### Phase 4: Update indexes
+
+1. Update `{KNOWLEDGE_DIR}/README.md` index table — update Status column, add/remove rows.
+2. If doc was linked from `status.json` metadata, update references.
+
+### Phase 5: Report
+
+Produce a maintenance report:
+- Docs reviewed (count)
+- Docs kept (count)
+- Docs updated (list with what changed)
+- Docs consolidated (list with which canonical doc merged into)
+- Docs replaced (list with successor path)
+- Docs deleted (list with reason)
+- Docs flagged for PM review (ambiguous cases)
+
+### Phase 6: CONCEPTS.md reconciliation
+
+If `CONCEPTS.md` exists, reconcile it with the refreshed knowledge:
+- Terms mentioned in updated/replaced docs may need updating in CONCEPTS.md
+- Terms no longer referenced may be candidates for removal
+
+If `CONCEPTS.md` doesn't exist but knowledge docs contain qualifying domain terms, propose bootstrapping it (full repo-wide seed). Use `references/concepts-vocabulary.md` from `mstar-compound` for rules (read on demand — cross-skill path resolution via skill directory).
+
+## Cross-skill coordination
+
+`mstar-compound-refresh` reads vocabulary rules from `mstar-compound`'s references. At runtime, resolve the path from the loaded skill directory:
+
+```
+The CONCEPTS.md vocabulary rules are in the mstar-compound skill at:
+references/concepts-vocabulary.md
+Read that file from the mstar-compound skill directory before Phase 6.
+```
+
+## NOT to do
+
+- Do not delete docs without checking for inbound links
+- Do not "archive" — delete instead
+- Do not ask PM about mechanical updates (path fixes, renamed modules)
+- Do not change code to match outdated docs — update docs to match code
+- Do not run without PM approval for destructive actions (Delete, Replace)

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

@@ -24,15 +24,17 @@ description: Morning Star (启明星) harness **强制全局入口** —— 信
 
 ## 最小交付循环
 
-`specify → clarify → plan` → `plan(locked) → tasks → implement` → QC 三审 + QA → 沉淀。阶段细则 → **`mstar-phase-gates`**。
+**per-plan**：`specify → clarify → plan` → `plan(locked) → tasks → implement` → QC 三审 + QA → Done。阶段细则 → **`mstar-phase-gates`**。
+
+**迭代级**：`iteration-start → [per-plan cycle × N] → iteration-close（含知识结晶 `mstar-compound`）`。细则 → **`mstar-iteration`**。
 
 ## 加载约定（强制）
 
 | 角色 | 始终 | 按任务追加（典型） |
 |------|------|-------------------|
 | **全部** | 本 skill | — |
-| **`@project-manager`** | 本 skill | `mstar-dispatch-gates`、`mstar-phase-gates`、`mstar-plan-conventions`、`mstar-superpowers-align`、`mstar-roles`；派 QC 前 `mstar-review-qc`；并行/审查 `mstar-branch-worktree`；plan/status/reports `mstar-plan-artifacts`；UI 类 plan Prepare 阶段 `mstar-design-md`（DESIGN.md 门禁）。**不**读 `mstar-coding-behavior` |
-| **实现/审查/QA/运维** | 本 skill + `mstar-coding-behavior` + 角色 ref | 有 git 写：`mstar-branch-worktree`；有 plan 路径：`mstar-plan-conventions`（路径符号节）；QC/QA：`mstar-review-qc`；改 status/residual：`mstar-plan-artifacts`；UI 任务：`mstar-design-md`（读取 DESIGN.md tokens） |
+| **`@project-manager`** | 本 skill | `mstar-dispatch-gates`、`mstar-phase-gates`、`mstar-plan-conventions`、`mstar-superpowers-align`、`mstar-roles`；派 QC 前 `mstar-review-qc`；并行/审查 `mstar-branch-worktree`；plan/status/reports `mstar-plan-artifacts`；UI 类 plan Prepare 阶段 `mstar-design-md`（DESIGN.md 门禁）；迭代管理 `mstar-iteration`（iteration-start/drive/close 含 compound）；战略性工作 `mstar-strategy`。**不**读 `mstar-coding-behavior` |
+| **实现/审查/QA/运维** | 本 skill + `mstar-coding-behavior` + 角色 ref | 有 git 写：`mstar-branch-worktree`；有 plan 路径：`mstar-plan-conventions`（路径符号节）；QC/QA：`mstar-review-qc`；改 status/residual：`mstar-plan-artifacts`；UI 任务：`mstar-design-md`（读取 DESIGN.md tokens）；写入知识库 `{KNOWLEDGE_DIR}`：`mstar-compound`（PM 触发） |
 | **leaf 承接方** | 上栏 + **`mstar-dispatch-gates`**（反递归节） | — |
 
 Routing eval（Cursor 维护）→ `.cursor/skills/mstar-routing-eval/`，**非**运行时必读。
@@ -77,15 +79,19 @@ PM 在 Assignment 写 **`Task category`**（主类 + 可选 `secondary`）：
 
 | Skill | 职责 |
 |-------|------|
-| **`mstar-harness-core`** | 本文件：入口、状态机、Task category、explore、索引、护栏 |
-| `mstar-phase-gates` | Prepare/Execute、意图门禁、hotfix、可验证编辑 |
+| `mstar-harness-core` | 本文件：入口、状态机、Task category、explore、索引、护栏 |
+| `mstar-phase-gates` | per-plan 双阶段门禁：Prepare/Execute、意图门禁、hotfix、可验证编辑 |
+| `mstar-iteration` | 迭代管理：iteration-start（锁定范围/Roadmap）、Phase 2 Autonomous Execute（per-plan 派发循环：分支→实现→QC→QA→Done→合并）、iteration-close（收口 compound、更新 roadmap） |
 | `mstar-dispatch-gates` | 派发、Delegation、反递归、并行 invoke、QC 同消息三审 |
 | `mstar-branch-worktree` | 功能分支、worktree、QC/QA 检出对齐 |
-| `mstar-plan-conventions` | `{HARNESS_DIR}` 发现、初始化、Spec 分支模型摘要 |
+| `mstar-plan-conventions` | `{HARNESS_DIR}` 发现、初始化、Spec 分支模型摘要、产物路径 SSOT |
 | `mstar-plan-artifacts` | 主 plan、reports、`status.json`、residual、knowledge、Done 归档 |
 | `mstar-design-md` | DESIGN.md 设计系统规范 —— 创建/审计/维护 design tokens，三级检查清单，light/dark 双主题 |
-| `mstar-review-qc` | QC 工作流、模板、verdict、residual 留档 |
+| `mstar-review-qc` | QC 工作流、模板、verdict、residual 留档、deep review 透镜 |
 | `mstar-coding-behavior` | Think / Simplicity / Surgical / Debugging / Goal-Driven / Communication |
+| `mstar-compound` | 知识结晶 —— 已解决问题→结构化知识文档，双轨（Bug/Knowledge），「是否值得结晶」自检清单，重叠检测，可发现性检查，CONCEPTS.md 协同 |
+| `mstar-compound-refresh` | 知识维护 —— 审查/更新/合并/删除 `{KNOWLEDGE_DIR}` 文档 |
+| `mstar-strategy` | `STRATEGY.md` 全局战略方向 —— 产品愿景、技术方向、决策原则 |
 | `mstar-superpowers-align` | Superpowers × harness 优先级与短语 |
 | `mstar-roles` | 角色正文 hub |
 | `mstar-host` | 宿主适配（自动识别；`references/opencode.md` / `cursor.md` / `codex.md` / `parallel-dispatch.md`） |

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

@@ -0,0 +1,273 @@
+---
+name: mstar-iteration
+description: Morning Star 迭代管理 —— iteration-start（锁定迭代范围与 roadmap）、Autonomous Execute（per-plan 派发循环：分支→实现→QC→QA→Done→合并，含跨 plan 进度追踪与 push 纪律）、iteration-close（收口知识结晶 `mstar-compound`、更新 roadmap、标记迭代完成）。触发：PM 启动新迭代、跨 plan 编排时、或迭代内所有 plan Done 后。迭代 compass 落盘 `{ITERATION_DIR}/<iteration-id>-delivery-compass.md`；per-plan 状态 SSOT 仍为 `{HARNESS_DIR}/status.json`。适用于一次迭代锁定几个 spec 点（specify+clarify）、多个 plan、每个 plan 多个 tasks 的实践模式。
+---
+
+# mstar-iteration（迭代管理）
+
+## Load order
+
+**Read `mstar-harness-core` first.** Path symbols → **`mstar-plan-conventions`**. Per-plan gates → **`mstar-phase-gates`**. Knowledge crystallization → **`mstar-compound`**. On conflict, **`mstar-harness-core` wins**.
+
+## 设计思路
+
+mstar 实践模式通常是：一次迭代锁定几个 spec 点（`specify + clarify`），产生多个 `plan`，每个 plan 含多个 tasks。**per-plan 生命周期有完整的闭环**（Prepare → Execute → QC → Done）。Compound 不是 per-plan 活动——它是**迭代级收口**，在迭代内所有 plan Done 后，沉淀一轮知识。
+
+本 skill 管理三个迭代节点：
+
+```
+iteration-start → [per-plan lifecycle × N] → iteration-close → PR → merge
+     │                                               │
+     │ 锁定范围、创建 compass                        │ compound、更新 roadmap
+     │ 登记 plans 到 compass                         │ 标记迭代完成
+     │ 创建 integration 分支                          │ commit 到 integration 分支
+     │                                               │
+     └──────── iteration-drive（跨 plan 追踪）────────┘
+```
+
+**关键定位**：iteration-close 是 iteration-drive 命令的**最后一个 Phase**，在 integration 分支上执行，**完成后再创建 PR**。所有 compound 产物（knowledge docs、compass 更新、CONCEPTS.md）作为迭代交付的一部分随 PR 合入 main。一次迭代 = 一个 PR。
+
+**per-plan 状态 SSOT**：`{HARNESS_DIR}/status.json`（per-plan Todo/InProgress/InReview/Done）。
+**迭代状态 SSOT**：`{ITERATION_DIR}/<id>-delivery-compass.md` frontmatter `status` + `{ITERATION_DIR}/README.md` 索引。
+
+## 产物存储位置
+
+**SSOT**: `mstar-plan-conventions/references/artifact-storage-paths.md`。迭代 compass → `{ITERATION_DIR}/<iteration-id>-delivery-compass.md`；迭代索引 → `{ITERATION_DIR}/README.md`。
+
+---
+
+## Phase 1: iteration-start（启动迭代）
+
+PM 在新迭代启动时执行。
+
+### 1.1 收集上下文
+
+1. 读 `{ITERATION_DIR}/README.md`（若存在），了解历史迭代
+2. 读 `STRATEGY.md`（若存在），对齐战略方向（见 `mstar-strategy`）
+3. 如果有未完成的 roadmap 残余（上一迭代标记为 `next` 的 plan），纳入本次迭代范围候选
+
+### 1.2 定义迭代范围
+
+与用户/产品对齐后，确定：
+
+| 字段 | 说明 |
+|------|------|
+| **Iteration ID** | 唯一标识，推荐 `v<major>.<minor>` 或 `iter-<YYYY-QN>` |
+| **范围** | 本迭代要锁定的 spec 点（问题陈述清单） |
+| **Plans** | 预期在本迭代中完成的 plan 列表（允许中途增减） |
+| **里程碑** | 关键节点与日期 |
+| **验收标准** | 迭代级别的 Done 定义 |
+| **非目标** | 明确排除在本次迭代外的事项 |
+| **Roadmap 上下文** | 本迭代在整体 roadmap 中的位置（本批做什么 / 下批做什么） |
+
+### 1.3 创建迭代 compass
+
+写入 `{ITERATION_DIR}/<iteration-id>-delivery-compass.md`：
+
+```markdown
+---
+iteration_id: <id>
+start_date: YYYY-MM-DD
+status: active
+plans: []
+---
+
+# <iteration-id> Delivery Compass
+
+## Scope
+<本迭代要锁定的 spec 点>
+
+## Plans
+
+| plan_id | Name | Status | Notes |
+|---------|------|--------|-------|
+| <id> | <name> | Todo | |
+| ... | ... | ... | |
+
+## Milestones
+| Milestone | Target date | Status |
+|-----------|-------------|--------|
+
+## Acceptance Criteria
+- <迭代级验收项>
+
+## Non-Goals
+- <明确排除的事项>
+
+## Roadmap Position
+- 本批：<what this iteration delivers>
+- 下批：<what comes next, owner, trigger>
+```
+
+### 1.4 更新索引
+
+在 `{ITERATION_DIR}/README.md` 中添加一行（首次创建时建立表头）：
+
+| Document | Iteration | Description | Status |
+|----------|-----------|-------------|--------|
+| `<iteration-id>-delivery-compass.md` | `<iteration-id>` | `<简短描述>` | `active` |
+
+### 1.5 登记到 status.json（可选）
+
+若使用 `status.json`，在 `plans[].metadata` 中为受影响的 plan 设置 `iteration_refs`。
+
+---
+
+## Phase 2: Autonomous Execute（per-plan 派发驱动）
+
+**本 Phase 是本 skill 的核心**——定义 per-plan 派发循环的完整流程：前置条件检查、session todos、backlog 读取、integration 分支管理、per-plan dispatch 循环（分支→实现→QC→QA→Done→合并）、dispatch-first 约束、push 纪律。PM 读取本 Phase 即可执行迭代。
+
+### 2.0 前置条件（三道闸）
+
+进入 Autonomous Execute 前必须满足：
+
+1. `{HARNESS_DIR}/status.json` 中至少一条 plan `status` ≠ `Done`
+2. **Pre-implement gate = GO**：plan 已 locked、tasks ready（见 `mstar-phase-gates`）
+3. 用户意图为 **continue Execute**（`/pm`、"推进 iteration"、"继续 plans" 等）
+
+任一 false → **stop**。Prepare 未完成 → 引导先跑 `/iteration-start`。
+
+### 2.1 Session todos（派发前设护栏）
+
+每个 plan wave 启动前设定 host todos，防止范围漂移：
+
+| Host | 工具 | 最小集合 |
+|------|------|---------|
+| **Cursor** | `TodoWrite` / CreatePlan todos | 当前 `plan_id`；下一批 gates（implement/QC/QA）；分支 checkpoint |
+| **Codex** | `update_plan` / Goal UI | 同上 |
+| **OpenCode** | host todo/plan UI（如有） | 同上 |
+
+SSOT = `{HARNESS_DIR}/status.json` + `{PLAN_DIR}/`。todos 只追踪本轮下一步。
+
+### 2.2 Read backlog
+
+1. 读 `mstar-plan-artifacts` + `{HARNESS_DIR}/status.json`
+2. 列出 `status` ∈ `{Todo, InProgress, InReview, Blocked}` 的 plan（优先级：`InProgress` → `InReview` → `Todo` → unblock `Blocked`）
+3. 读 `metadata.spec_integration_branch` / `merge_target` / `primary_spec` 链接
+
+### 2.3 Integration branch
+
+1. 从 `status.json` 解析 `spec_integration_branch`
+2. **checkout 或创建**该分支；`git branch --show-current` 确认
+3. 若 metadata 缺失 → **stop**，读 `mstar-plan-conventions` + 用户确认（`mstar-branch-worktree`）；同轮写入 plan + status
+
+此分支是本迭代内所有 plan feature branch 的 merge target。
+
+### 2.4 Per-plan loop（直到全部 Done）
+
+对每个 active `plan_id`：
+
+1. **Plan start — feature branch**：Assignment 用 `Working branch: create <plan-feature-branch> from <spec_integration_branch>`。一个 plan 一条专用实现分支；内部并行 → topic branches + worktrees（`mstar-branch-worktree`）
+2. **Implement → InReview**：dispatch-only 循环（`§ 2.5`）；每次 Completion Report v2 后更新 `status.json` + 主 plan
+3. **QC → QA → Done**：三审 + QA（`mstar-review-qc`）；gate 全部通过后 PM 标记 `Done`
+4. **Plan complete — merge back**：合并 plan feature branch → `spec_integration_branch`；在下一 plan 或 QC 前解决冲突
+5. **Cross-plan 进度同步**：更新 `{ITERATION_DIR}/<iteration-id>-delivery-compass.md` 的 `## Plans` 表状态列
+6. **Next plan** 从步骤 1 继续
+
+全部 plan `Done` → 停止循环，进入 **Phase 3: iteration-close**。
+
+### 2.5 Dispatch-first（implement 派发约束）
+
+| Do | Don't |
+|----|------|
+| **Loop:** `## Assignment` → invoke → Completion Report v2 → 更新 status → next | PM 亲自 Write/Edit/Shell 产品代码 |
+| 1 Assignment ⇒ 1 invoke | Assignment 只写 markdown 不 invoke |
+| merge/branch/handoff 写入 Assignment | 因"上下文已有"而跳过 subagent |
+
+- **NEVER** implement while staying PM — 实现一律 delegate dev 角色
+- Delegate scope：`mstar-roles` → PM Execution Boundary
+- 例外：用户显式要求 PM thread 实现；hotfix（`mstar-phase-gates`）
+
+### 2.6 Push 纪律
+
+- 不因 harness 基础问题常问"是否继续"—— 决策、记录、**dispatch**
+- 未知 → 读 `mstar-*`；**`Blocked`** 或仅对 stop/secrets/不可逆范围缺口/冲突后升级
+- 实际 Git ≠ `working_branch` → **同轮**更新 plan + status
+
+---
+
+## Phase 3: iteration-close（收口迭代）
+
+PM 在迭代内全部 plan Done 后执行。**本 Phase 在 integration 分支上运行**，产出物 commit 到 integration 分支，随迭代 PR 合入 main。触发方：`commands/iteration-drive.md`（在 Autonomous Execute loop 全部 Done 后自动进入）。
+
+### 3.1 前置检查
+
+确认以下条件全部满足后，方可进入 iteration-close：
+
+- [ ] 所有 compass 中登记的 plan 状态均为 `Done`
+- [ ] 所有 plan 的 residual findings 已收口（closed 或 accepted）
+- [ ] `{ITERATION_DIR}/<iteration-id>-delivery-compass.md` 各 plan 状态已同步到最新
+- [ ] 迭代验收标准已达成或显式豁免
+
+### 3.2 知识结晶（Compound）—— 迭代级核心收口
+
+**Compound 在此执行，不在 per-plan Done 后独立执行。**
+
+PM 触发 `mstar-compound`（可批量）：
+
+1. **收集素材**：回顾本迭代所有 plan 的实现、debug、review 过程，识别以下类型的可结晶知识：
+   - 非平凡 bug 修复及其诊断过程
+   - 新引入的架构模式或约定
+   - 工具链决策及其理由
+   - 跨 plan 重复出现的模式
+   - 有价值的排错经验
+
+2. **逐条结晶**：对每条识别出的知识，调用 `mstar-compound` 写入 `{KNOWLEDGE_DIR}/<category>/<slug>.md`
+
+3. **是否值得结晶**：PM 使用 `mstar-compound` 中的「是否值得结晶」自检清单逐条评估（见 `mstar-compound` § 是否值得结晶）。
+
+4. **CONCEPTS.md 协同**：若迭代中引入了新的领域词汇，更新 `<repo-root>/CONCEPTS.md`
+
+### 3.3 更新 roadmap
+
+1. 更新 compass 中的 `## Roadmap Position`：
+   - 本批状态标记为 `delivered`
+   - 下批更新为即将开始的内容
+2. 若 `status.json` 中有 `plans[].metadata.roadmap` 字段，同步更新
+3. 若 `STRATEGY.md` 存在，可建议更新 `## Decision Log`（若有重大架构决策）
+
+### 3.4 标记迭代完成 + Commit
+
+1. 将 compass frontmatter `status` 更新为 `completed`，添加 `end_date`
+2. 更新 `{ITERATION_DIR}/README.md` 索引中该迭代行的 Status 为 `completed`
+3. compass 正文末尾追加 Compound Round Summary 和 Retrospective（见 compass 模板）
+
+**Commit 到 integration 分支**：iteration-close 产出的所有 harness 制品必须 commit 到当前 integration 分支，随迭代 PR 合入 main：
+
+```bash
+git add {ITERATION_DIR}/<id>-delivery-compass.md {ITERATION_DIR}/README.md {KNOWLEDGE_DIR}/ CONCEPTS.md
+git commit -m "chore(iteration): close <iteration-id> — compound round, roadmap update"
+git push origin <spec_integration_branch>
+```
+
+### 3.5 可选：触发 compound-refresh
+
+若本轮 compound 新增了较多知识文档，或 compass 标记了可能过时的旧知识，触发 `mstar-compound-refresh` 对有重叠的知识文档做维护。
+
+---
+
+## 迭代 compass 模板
+
+完整模板见 `references/iteration-compass-template.md`。
+
+## 与其它技能的关系
+
+| 技能 | 关系 |
+|------|------|
+| `mstar-dispatch-gates` | Dispatch rules — per-plan loop 引用 |
+| `mstar-phase-gates` | per-plan gate 判定 |
+| `mstar-plan-conventions` | 路径符号（`{ITERATION_DIR}`、`{HARNESS_DIR}`） |
+| `mstar-plan-artifacts` | `status.json` SSOT、`{ITERATION_DIR}` 索引维护 |
+| `mstar-review-qc` | QC 三审 — per-plan loop 引用 |
+| `mstar-branch-worktree` | 分支/merge/worktree 隔离 |
+| `mstar-compound` | iteration-close 中触发知识结晶 |
+| `mstar-compound-refresh` | iteration-close 后可触发知识维护 |
+| `mstar-strategy` | iteration-start 时读 `STRATEGY.md` 对齐方向 |
+
+## NOT to do
+
+- 不要在 per-plan Done 后立即单独 compound——等 iteration-close 统一做
+- 不要在 iteration-drive 中修改 per-plan gate 判定
+- 不要用 compass 替代 `status.json` 作为 plan 状态 SSOT
+- 不要在没有完成 per-plan 前置检查的情况下进入 iteration-close
+- 不要跳过 compound——如果本迭代确实没有可结晶的知识，在 compass 中写 `Compound Round Summary: 无可结晶知识（原因：<简述>）`