@mstar-harness/opencode 0.6.16 → 0.6.19
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: iteration-drive
|
|
3
|
-
description: Drive the active iteration to completion — run the PM Autonomous Execute loop (implement → QC → QA → Done) until all plans are Done, then optionally create PR to main
|
|
3
|
+
description: Drive the active iteration to completion — run the PM Autonomous Execute loop (implement → QC → QA → Done) until all plans are Done, then optionally create PR to target branch (default main)
|
|
4
4
|
agent: project-manager
|
|
5
5
|
---
|
|
6
6
|
|
|
@@ -46,5 +46,6 @@ Follow **§ Autonomous Execute driver** from the PM skill exactly:
|
|
|
46
46
|
|
|
47
47
|
When every plan is `Done` in `status.json`:
|
|
48
48
|
|
|
49
|
-
-
|
|
50
|
-
-
|
|
49
|
+
- Resolve the PR target branch from iteration metadata: `status.json` → `target_branch`. Default to `main` if not set.
|
|
50
|
+
- Create a PR from `spec_integration_branch` to the resolved `target_branch`
|
|
51
|
+
- Report a summary: plans completed, branch names, target branch, PR link
|
|
@@ -8,6 +8,14 @@ agent: project-manager
|
|
|
8
8
|
|
|
9
9
|
Start a new Morning Star harness iteration. Follow Prepare gates from `mstar-phase-gates` (specify → clarify → plan).
|
|
10
10
|
|
|
11
|
+
## 0. Boot
|
|
12
|
+
|
|
13
|
+
1. `mstar-harness-core`
|
|
14
|
+
2. `mstar-roles` → `references/project-manager.md`
|
|
15
|
+
3. `skills/pm/SKILL.md` → **§ Host entry** (PM role identity) + **§ Boot** (load order)
|
|
16
|
+
4. `mstar-phase-gates` → Prepare (specify → clarify → plan)
|
|
17
|
+
5. `mstar-plan-conventions`, `mstar-plan-artifacts`
|
|
18
|
+
|
|
11
19
|
## 1. Research
|
|
12
20
|
|
|
13
21
|
Load harness entry, then survey structured and unstructured sources:
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: mstar-coding-behavior
|
|
3
|
-
description: Morning Star (启明星) 跨角色通用编码行为准则 —— Think Before Coding
|
|
3
|
+
description: Morning Star (启明星) 跨角色通用编码行为准则 —— Think Before Coding（先读懂再改、显式假设、不静默猜测）、Simplicity First（YAGNI 优先不写代码、The Ladder 决策层级、删除优于添加、简洁优于聪明、`simplify:` 标记天花板与升级路径、最小耐久切片）、Surgical Changes（改动可追溯、Bug 修根因先 grep 所有调用点、不顺手重构、不 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` 为准）。
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
## Load order（必读顺序）
|
|
@@ -41,16 +41,43 @@ Quick check:
|
|
|
41
41
|
- Can another reviewer see what assumptions were made?
|
|
42
42
|
- If assumptions are wrong, will the user detect it before large edits happen?
|
|
43
43
|
|
|
44
|
+
**Never lazy about understanding.** Shorten the solution, never the reading. Read the task and every file the change touches fully first; trace the actual flow end to end. A small diff in the wrong place is not efficiency — it is a second bug shipped with confidence.
|
|
45
|
+
|
|
44
46
|
## 2) Simplicity First
|
|
45
47
|
|
|
46
48
|
Core idea: implement the smallest durable slice that satisfies the request and acceptance criteria.
|
|
47
49
|
|
|
50
|
+
**Question the need (YAGNI).** Before writing code, ask: does this task need code at all? Can the goal be achieved by deletion, reusing existing logic, or a configuration change? If a path requires no code, take it and explain in one line.
|
|
51
|
+
|
|
52
|
+
**The Ladder.** A reflex hierarchy for every decision — stop at the first rung that holds:
|
|
53
|
+
|
|
54
|
+
1. **Does this need code at all?** Speculative need → skip it (YAGNI).
|
|
55
|
+
2. **Already in this codebase?** A helper, util, type, or pattern that already lives here → reuse it. Look before you write.
|
|
56
|
+
3. **Stdlib / built-in covers it?** Use it.
|
|
57
|
+
4. **Native platform feature covers it?** CSS over JS, DB constraint over app code, OS primitive over a library.
|
|
58
|
+
5. **Already-installed dependency solves it?** Use it. Never add a new dependency for what a few lines can do.
|
|
59
|
+
6. **Can it be one line?** One line.
|
|
60
|
+
7. **Only then:** the minimum durable code that works.
|
|
61
|
+
|
|
62
|
+
The ladder runs after understanding, not instead of it. Two rungs work → take the higher one and move on.
|
|
63
|
+
|
|
64
|
+
**Deletion over addition. Boring over clever.** Removing unnecessary code is a feature. Cleverness is what someone decodes at 3am — prefer a boring, obvious solution that a tired reviewer can verify in seconds.
|
|
65
|
+
|
|
48
66
|
- Do not add features, flags, or configurability that were not requested.
|
|
49
67
|
- Avoid introducing new abstractions for single-use logic.
|
|
50
68
|
- Prefer straightforward local fixes over framework-level reshaping **only when they fit the target design**.
|
|
51
69
|
- Reject speculative error handling for impossible paths unless required by project policy.
|
|
70
|
+
|
|
71
|
+
**Simplification markers.** When a deliberate shortcut has a known ceiling (global lock, O(n²) scan, naive heuristic), mark it with a `simplify:` comment that names the ceiling and the upgrade path:
|
|
72
|
+
|
|
73
|
+
```text
|
|
74
|
+
// simplify: global lock on cache misses. Replace with per-key lock if throughput matters.
|
|
75
|
+
```
|
|
76
|
+
|
|
77
|
+
This signals intent — the simplicity is deliberate, not an oversight — and gives the next person the upgrade path without research.
|
|
78
|
+
|
|
52
79
|
- 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.
|
|
53
|
-
- If a workaround is
|
|
80
|
+
- If a workaround is unavoidable, label it as `simplify:` / `temporary`, explain why, and record the removal path in the plan/status artifact before claiming the task is complete.
|
|
54
81
|
|
|
55
82
|
Default rule:
|
|
56
83
|
|
|
@@ -60,7 +87,7 @@ Durability check:
|
|
|
60
87
|
|
|
61
88
|
- Can this slice be extended by the next batch without undoing its core shape?
|
|
62
89
|
- Are deferred items captured in an existing roadmap / task board / residual tracker, not just mentioned in chat?
|
|
63
|
-
- Would a reviewer understand whether this is the final approach, a staged slice, or a
|
|
90
|
+
- Would a reviewer understand whether this is the final approach, a staged slice, or a deliberate simplification?
|
|
64
91
|
|
|
65
92
|
## 3) Surgical Changes
|
|
66
93
|
|
|
@@ -76,6 +103,8 @@ Traceability test:
|
|
|
76
103
|
|
|
77
104
|
- Each hunk should map to a user requirement, acceptance criterion, or required fix-up.
|
|
78
105
|
|
|
106
|
+
**Bug fix = root cause, not symptom.** A bug report names a symptom, not the cause. Before editing, grep every caller of the function or code path you are about to touch. The fix belongs where all callers route through — one guard in the shared function is smaller than a guard in every caller. Patching only the path the ticket names leaves every sibling caller still broken. Fix it once, at the narrowest shared point.
|
|
107
|
+
|
|
79
108
|
## 4) Goal-Driven Execution
|
|
80
109
|
|
|
81
110
|
Core idea: convert vague requests into verifiable outcomes and iterate until verified.
|
|
@@ -87,6 +116,8 @@ Core idea: convert vague requests into verifiable outcomes and iterate until ver
|
|
|
87
116
|
- If verification fails, loop on diagnosis and fix before declaring completion.
|
|
88
117
|
- 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`.
|
|
89
118
|
|
|
119
|
+
**Minimal check for non-trivial logic.** Any non-trivial change (a branch, a loop, a parser, a data transformation, a money or security path) must leave behind ONE runnable check — the smallest thing that fails if the logic breaks. An inline self-check, a quick `assert`-based demo, or one minimal test. No frameworks, no fixtures, no per-function suites unless asked. Trivial one-liners need none — YAGNI applies to tests too.
|
|
120
|
+
|
|
90
121
|
Micro template:
|
|
91
122
|
|
|
92
123
|
```text
|