k-harness 0.5.0 → 0.6.0
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.
- package/README.md +2 -2
- package/harness/agents/planner.md +3 -3
- package/harness/agents/reviewer.md +1 -0
- package/harness/failure-patterns.md +6 -0
- package/harness/skills/bootstrap.md +1 -0
- package/harness/skills/impact-analysis.md +1 -1
- package/harness/skills/learn.md +7 -2
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -59,7 +59,7 @@ npx k-harness init --ide antigravity
|
|
|
59
59
|
| **Augment Code** | `.augment/rules/core.md` | `.augment/rules/*.md` | `.augment/skills/*/SKILL.md` | `.augment/skills/*/SKILL.md` |
|
|
60
60
|
| **Google Antigravity** | `.agent/rules/core.md` | `.agent/rules/*.md` | `.agent/skills/*/SKILL.md` | `.agent/skills/*/SKILL.md` |
|
|
61
61
|
|
|
62
|
-
All IDEs also get `project-state.md`, `project-brief.md`, `features.md`, `failure-patterns.md`,
|
|
62
|
+
All IDEs also get state files (`project-state.md`, `project-brief.md`, `features.md`, `failure-patterns.md`, `dependency-map.md`) in the `docs/` directory.
|
|
63
63
|
|
|
64
64
|
## What Gets Installed
|
|
65
65
|
|
|
@@ -125,7 +125,7 @@ See [docs/reference.md](docs/reference.md) for detailed descriptions of every sk
|
|
|
125
125
|
| | BMAD v6.2.2 | gstack v0.15.1 | K-Harness |
|
|
126
126
|
|---|---|---|---|
|
|
127
127
|
| Focus | Enterprise SDLC methodology | 1-person software factory | Project direction management |
|
|
128
|
-
| Files | 200+ | ~40 |
|
|
128
|
+
| Files | 200+ | ~40 | ~20 |
|
|
129
129
|
| Dependencies | Node 20+ | Bun + Node + Playwright | Zero |
|
|
130
130
|
| IDE support | 20+ (installer) | 5 (setup --host) | 7 (native format) |
|
|
131
131
|
| Direction management | ❌ | ❌ | ✅ (Direction Guard + pivot + Decision Log) |
|
|
@@ -42,9 +42,9 @@ If `docs/project-brief.md` alone is empty → Warn the user but proceed (the pla
|
|
|
42
42
|
|
|
43
43
|
1. Read `docs/project-brief.md` to understand project vision, goals, **non-goals**, and **Decision Log**
|
|
44
44
|
2. **Direction Alignment**: Verify the requested feature against three checkpoints:
|
|
45
|
-
- **Goal Alignment**: Does it serve a listed Goal? If no clear link
|
|
46
|
-
- **Non-Goal Violation**: Does it fall into Non-Goals? If yes
|
|
47
|
-
- **Decision Consistency**: Does it contradict any Decision Log entry? If yes
|
|
45
|
+
- **Goal Alignment**: Does it serve a listed Goal? If no clear link → **warn but proceed**. Include the warning in the plan output.
|
|
46
|
+
- **Non-Goal Violation**: Does it fall into Non-Goals? If yes → **stop and ask the user**. Do not proceed until the user confirms this is intentional (may need `pivot` skill).
|
|
47
|
+
- **Decision Consistency**: Does it contradict any Decision Log entry? If yes → **stop and warn**. Recommend running the `pivot` skill before proceeding.
|
|
48
48
|
If the request represents a clear direction change → recommend running the `pivot` skill instead of proceeding with planning.
|
|
49
49
|
3. Read `docs/features.md` to understand what already exists
|
|
50
50
|
4. Read `docs/dependency-map.md` to understand current architecture
|
|
@@ -75,6 +75,7 @@ Verify that state file updates actually happened. Check each:
|
|
|
75
75
|
- [ ] **docs/dependency-map.md**: If new modules were created, are they registered? If dependencies changed, are relationships updated?
|
|
76
76
|
- [ ] **docs/failure-patterns.md**: If a bug was fixed that matched a pattern, was frequency incremented?
|
|
77
77
|
- [ ] **docs/project-brief.md**: If a technology or architectural decision was made, is it in Decision Log?
|
|
78
|
+
- [ ] **docs/agent-memory/*.md**: If an agent (reviewer/planner/sprint-manager) was used this session, was its memory updated by the learn skill?
|
|
78
79
|
|
|
79
80
|
For each missing update: flag as `[STATE-AUDIT]` in the output and provide the exact update that should be made.
|
|
80
81
|
|
|
@@ -14,6 +14,12 @@ Keep resolved patterns for regression prevention.
|
|
|
14
14
|
- **Applied in**: testing rules, test-integrity skill, reviewer agent
|
|
15
15
|
- **Status**: Template — activate when first occurrence is logged
|
|
16
16
|
|
|
17
|
+
<!-- Activation example: When this pattern first occurs, update like this:
|
|
18
|
+
- **Occurred**: S1-2
|
|
19
|
+
- **Frequency**: 1
|
|
20
|
+
- **Status**: Active
|
|
21
|
+
On subsequent occurrences, increment Frequency and append to Occurred (e.g., S1-2, S2-1) -->
|
|
22
|
+
|
|
17
23
|
---
|
|
18
24
|
|
|
19
25
|
## FP-002: Type confusion (enum vs union, wrong parameter count)
|
|
@@ -41,6 +41,7 @@ Ask the user these questions (skip any already answered by Phase 1):
|
|
|
41
41
|
3. "What is explicitly OUT of scope? (non-goals)"
|
|
42
42
|
4. "What architecture pattern are you using?" (show detected pattern if found)
|
|
43
43
|
5. "Are there any type decisions or conventions the AI should know about?"
|
|
44
|
+
6. "What is your test command?" (show detected command if found, e.g., `npm test`, `pytest`, `go test ./...`)
|
|
44
45
|
|
|
45
46
|
### Phase 3: Fill State Files
|
|
46
47
|
|
|
@@ -61,7 +61,7 @@ Plan: 4 files to update, all within S3-2 scope
|
|
|
61
61
|
|
|
62
62
|
After completing the analysis, update these files:
|
|
63
63
|
|
|
64
|
-
- [ ] **docs/dependency-map.md**: Update the Interface Change Log table with: Date, Module, Change description, Affected Modules, Status.
|
|
64
|
+
- [ ] **docs/dependency-map.md**: Update the Interface Change Log table with: Date, Module, Change description, Affected Modules, Status. **This is mandatory for ALL interface changes** — do not skip even if the change seems minor.
|
|
65
65
|
- [ ] **docs/project-state.md**: If scope exceeds current Story, add a note to Recent Changes.
|
|
66
66
|
|
|
67
67
|
## Related Failure Patterns
|
package/harness/skills/learn.md
CHANGED
|
@@ -8,11 +8,13 @@ This is K-Harness's memory mechanism — without it, the same mistakes repeat ac
|
|
|
8
8
|
|
|
9
9
|
## When to Apply
|
|
10
10
|
|
|
11
|
-
- Before ending a chat session (recommended as the LAST skill invoked)
|
|
11
|
+
- Before ending a chat session (recommended as the LAST skill invoked, **once per session**)
|
|
12
12
|
- After a debugging session where a non-obvious fix was found
|
|
13
13
|
- After a review revealed a repeated mistake
|
|
14
14
|
- When the user explicitly asks to record a lesson
|
|
15
15
|
|
|
16
|
+
> **Timing**: Invoke this skill **once at session end**, not after each individual skill. It aggregates the entire session's work into state files.
|
|
17
|
+
|
|
16
18
|
## Procedure
|
|
17
19
|
|
|
18
20
|
### Step 1: Review Session Activity
|
|
@@ -63,7 +65,10 @@ For each issue/error that occurred in this session:
|
|
|
63
65
|
If an agent (reviewer, planner, sprint-manager) was used in this session, update its memory file in `docs/agent-memory/`:
|
|
64
66
|
|
|
65
67
|
1. Read `docs/agent-memory/{agent-name}.md`
|
|
66
|
-
2.
|
|
68
|
+
2. If the file only contains placeholder comments (`<!-- 예시:... -->`), initialize it by replacing the comments with actual entries. Example:
|
|
69
|
+
- Before: `<!-- 예시: Wave 1 추정: 정확 -->`
|
|
70
|
+
- After: `- [S1-2] Wave 1 추정: 정확 (3 tasks, 실제 소요 1일)`
|
|
71
|
+
3. Add session-specific learnings to the appropriate section:
|
|
67
72
|
- **reviewer.md**: Review patterns, frequently missed items, statistics
|
|
68
73
|
- **planner.md**: Estimation accuracy, architecture insights, repeated patterns
|
|
69
74
|
- **sprint-manager.md**: Velocity data, scope drift incidents, sizing recommendations
|