@mstar-harness/opencode 0.6.21 → 0.6.23

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-dispatch-gates/SKILL.md

@@ -7,14 +7,17 @@ description: Morning Star 派发与委派门禁 —— 仅 PM 可增派 subagent
 
 **首次 Read 本 skill 前：必须先 Read `mstar-harness-core`（SKILL.md）。** 同仓 worktree、QC/QA 检出字段 → **`mstar-branch-worktree`**。冲突时 **以 `mstar-harness-core` 为准**。
 
-## 调度防串扰（强制）
+## 🚨 承接方：如果你是 leaf executor，先读本节！（你的 Assignment 开头 IDENTITY 块已告诉你身份）
 
-- 只有 **`@project-manager`** 可以决定增加/并行 subagent；承接方**默认不得二次分派**。
-- **`Execute as: <role-id>`** = 承接方**亲自**完成本单，**不是**再起同名 subagent 或嵌套同 `subagent_type` 的 Task（禁止**递归误派**）。
-- 额外代理仅以 **`Delegation: allowed (...)`** 为准；未显式写时视为 **`Delegation: forbidden`**。
-- Assignment 正文中的 `@xxx` 默认按「文本引用」解释，**不**视为自动调用命令。
-- 承接方若判断必须增加 subagent，应先回报 **`Blocked`** 请 PM 重分派。
-- **Superpowers `subagent-driven-development`**：per-task 子步**勿**用 `@qc-specialist*`；用 `@general` / `generalPurpose` 或 PM 标明的 informal `@qa-engineer`。详见 **`mstar-superpowers-align`**。
+> **如果你此刻的 Assignment 中 `Delegation: forbidden`（或未写 `Delegation: allowed`），则你属于 leaf executor。本节是你的行为边界，必须在你做任何决定之前读完。**
+>
+> **先回到你 Assignment 最顶部的 `**IDENTITY**` 块重读一遍** —— 那里已经告诉你：你是谁、你不是谁、Task 工具不属于你。本节是那个身份断言的加固版。
+
+**身份断言（牢记，不动摇）：**
+- **你就是** `Execute as` 写的那个角色。你**不是 PM**，不是调度者，不是 `dispatching-parallel-agents` 的使用者。
+- Task/subagent 工具即使在你的工具列表里出现，它**不属于你**。把它当作你没见过的工具 —— 不是"不能用"，是"你没有"。
+- 所有工作由你**本人**在当前会话内完成（Read / Write / Edit / Shell / Grep / Glob）。任何"这样做更高效"的想法都不构成 dispatch 的理由。
+- 遇到超出能力范围的需求 → 写 `## Blocked` 回报 PM，**不是**尝试 dispatch。Blocked 是你能发出的正确信号，dispatch 不是。
 
 ## 承接方反递归红线（NEVER / DO NOT；leaf executor 必读）
 
@@ -35,7 +38,16 @@ description: Morning Star 派发与委派门禁 —— 仅 PM 可增派 subagent
 3. 下一动作是不是「Task / subagent_type=…」？是 → 停手，改为 Read / Write / Shell / Edit，或 **`Blocked`**。
 4. 命中任一 NEVER → 写 `## Blocked — recursive dispatch refused (<which NEVER>)` 回报 PM，**不**继续 invoke。
 
-**Assignment 顶部反模式块**：每个 PM Assignment 开头均有 **`**You are a leaf executor. You MUST NOT:**`** 块，PM 按此 Assignment 的角色+上下文定制反模式清单。leaf executor 收到 Assignment 后须 **首先** 阅读该块；命中任一条 → **停止**（亲自完成或 `Blocked`）。详见 **`mstar-roles/references/project-manager/dispatch-and-assignment.md`**。
+**Assignment 顶部反模式块**：每个 PM Assignment 开头均有 **`**You are a leaf executor. You MUST NOT:**`** 块（含 IDENTITY + CAPABILITY BOUNDARY + prohibitions），PM 按此 Assignment 的角色+上下文定制反模式清单。leaf executor 收到 Assignment 后须 **首先** 阅读该块；命中任一条 → **停止**（亲自完成或 `Blocked`）。详见 **`mstar-roles/references/project-manager/dispatch-and-assignment.md`**。
+
+## 调度防串扰（强制；leaf executor 已在上方读过反递归红线，此处为完整规则供 PM/对照用）
+
+- 只有 **`@project-manager`** 可以决定增加/并行 subagent；承接方**默认不得二次分派**。
+- **`Execute as: <role-id>`** = 承接方**亲自**完成本单，**不是**再起同名 subagent 或嵌套同 `subagent_type` 的 Task（禁止**递归误派**）。
+- 额外代理仅以 **`Delegation: allowed (...)`** 为准；未显式写时视为 **`Delegation: forbidden`**。
+- Assignment 正文中的 `@xxx` 默认按「文本引用」解释，**不**视为自动调用命令。
+- 承接方若判断必须增加 subagent，应先回报 **`Blocked`** 请 PM 重分派。
+- **Superpowers `subagent-driven-development`**：per-task 子步**勿**用 `@qc-specialist*`；用 `@general` / `generalPurpose` 或 PM 标明的 informal `@qa-engineer`。详见 **`mstar-superpowers-align`**。
 
 ## 并发分派完整性门禁（PM 强制）
 

package/harness-skills/mstar-dispatch-gates/references/leaf-executor-checklist.md

@@ -2,9 +2,13 @@
 
 > Load **`mstar-harness-core`** first, then **`mstar-dispatch-gates`** SKILL.md.
 >
-> **First**: read the `**You are a leaf executor. You MUST NOT:**` block at the top of your Assignment. Those anti-patterns are customized for your specific role+context and are the authoritative dispatch boundaries for this assignment.
+> **First**: read the `**IDENTITY**` and `**CAPABILITY BOUNDARY**` blocks at the top of your Assignment. Those tell you who you ARE and what tools are NOT yours. Then read the `**You are a leaf executor. You MUST NOT:**` prohibitions. Those anti-patterns are customized for your specific role+context and are the authoritative dispatch boundaries for this assignment.
 
-Before any Task/subagent call:
+**Preamble — internalize before any action:**
+
+I am a leaf executor. I personally complete all work. Task/subagent is NOT my tool. If I think about dispatching, I stop and return to my direct work or write `Blocked`.
+
+Before any Task/subagent call (if I somehow forget the preamble):
 
 1. What is my **`Execute as`**?
 2. Does the Assignment include **`Delegation: allowed (...)`**? If no → **no** Task/subagent.

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`） |