@mstar-harness/opencode 3.1.2 → 3.2.0

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

@@ -7,7 +7,7 @@ description: Morning Star 全局战略方向 —— 创建并维护 `STRATEGY.md
 
 ## Load order
 
-**Read `mstar-harness-core` first.** Path symbols → **`mstar-plan-conventions`**. On conflict, **`mstar-harness-core` wins**.
+**Read `mstar-harness-core` first.** Path symbols → **`mstar-conventions`**. On conflict, **`mstar-harness-core` wins**.
 
 ## Purpose
 
@@ -17,7 +17,7 @@ Without a strategy document, decisions are made in isolation — each plan misse
 
 ## 产物存储位置
 
-**SSOT**: `mstar-plan-conventions/references/artifact-storage-paths.md`。STRATEGY.md → `<repo-root>/STRATEGY.md`（与 `.git/`、`AGENTS.md` 同级）。**禁止**放入 `{HARNESS_DIR}`、`docs/` 或任何子目录。
+**SSOT**: `mstar-conventions/references/artifact-storage-paths.md`。STRATEGY.md → `<repo-root>/STRATEGY.md`（与 `.git/`、`AGENTS.md` 同级）。**禁止**放入 `{HARNESS_DIR}`、`docs/` 或任何子目录。
 
 ## When to use
 
@@ -68,15 +68,9 @@ A good strategy document is opinionated and concise. It should fit in one screen
 
 ## Creating STRATEGY.md
 
-### Phase 1: Gather context
+Creating and maintaining `STRATEGY.md` follows the **project knowledge bootstrap**: **`mstar-compound-refresh`** → `references/project-knowledge-bootstrap.md` **Phase 2 (Distill STRATEGY.md)** — survey context → interview → draft/review → stale/partial/current handling. The six-section structure and the engine check above stay authoritative here.
 
-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):
+### Interview (ask PM the 5 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?"
@@ -84,33 +78,9 @@ Ask PM these questions (one at a time):
 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
+### Maintenance
 
-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.
+Review triggers: after a major architectural decision, when a plan introduces a new technology stack, or quarterly (PM-scheduled). Update rules: be decisive about direction changes (replace, don't keep old strategy alongside new); log decisions with context (why, not just what); keep it current — stale strategy is worse than no strategy.
 
 ## STRATEGY.md vs other docs
 
@@ -131,7 +101,7 @@ Ask for consent before applying.
 
 ## Workflow
 
-主链：**创建**（Phase 1 收集上下文 → Phase 2 访谈 PM → Phase 3 落盘 `<repo-root>/STRATEGY.md` → Phase 4 可发现性检查）→ **维护**（方向变更时果断替换旧策略、Decision Log 记决策理由、保持最新）→ **定期评审**（重大架构决策后 / 新技术栈引入时 / 季度评审）。作为 brainstorm / plan 的上游锚点被引用。
+主链：**创建/维护**（survey → 访谈 = 五问 → draft/review → 更新/替换/跳过）细节 → **`mstar-compound-refresh`** `references/project-knowledge-bootstrap.md` **Phase 2**。作为 brainstorm / plan 的上游锚点被引用。
 
 ## Evidence
 
@@ -141,4 +111,4 @@ Ask for consent before applying.
 
 - 迭代级战略对齐（iteration-start §1.1 读 STRATEGY.md）→ **`mstar-iteration`**
 - 知识维护 / bootstrap（战略变更后的知识对账）→ **`mstar-compound-refresh`**
-- 路径符号与产物存储 SSOT → **`mstar-plan-conventions`**
+- 路径符号与产物存储 SSOT → **`mstar-conventions`**

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mstar-harness/opencode",
-  "version": "3.1.2",
+  "version": "3.2.0",
   "description": "Morning Star harness OpenCode plugin — skills bootstrap + engine-backed runtime hooks (status lint, dispatch validation, Enforcement: hard gates).",
   "license": "MIT",
   "repository": {

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

@@ -1,7 +0,0 @@
-# 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`**. Optional rollup: engine `techDebtRollup` import (read-only; see that reference).
-
-| File | Copy to | Notes |
-|------|---------|--------|
-| `status.empty.json` | `{HARNESS_DIR}/status.json` | The **v2 root register** shape (`version: 2`, `updated_at`, `workflows: []`) — see **`mstar-plan-artifacts` SKILL.md** + `references/status-and-residuals.md`. Replace `updated_at` with the real date. Per-lifecycle snapshot / register / lease fields are created at runtime by engine writers (`workflows/<id>/snapshot.json`, `projects/<id>/residuals.json`) — not in the empty template. |