@haposoft/cafekit 0.7.21 → 0.7.23
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/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@haposoft/cafekit",
|
|
3
|
-
"version": "0.7.
|
|
3
|
+
"version": "0.7.23",
|
|
4
4
|
"description": "Spec-Driven Development workflow for AI coding assistants. Supports Claude Code and Antigravity with spec-first workflows plus Claude Code hapo: skills.",
|
|
5
5
|
"author": "Haposoft <nghialt@haposoft.com>",
|
|
6
6
|
"license": "MIT",
|
|
@@ -30,7 +30,7 @@ DO NOT write implementation code until an approved spec exists.
|
|
|
30
30
|
| "No need to scout first" | Coding without knowing the architecture is blind. ALWAYS call `inspect` to scan files. |
|
|
31
31
|
| "Review process is too tedious, let me just finish it myself" | The system needs an audit trail through agents. ALWAYS delegate via `Task` tool. |
|
|
32
32
|
|
|
33
|
-
## Absolute
|
|
33
|
+
## Absolute Workflow
|
|
34
34
|
|
|
35
35
|
```mermaid
|
|
36
36
|
flowchart TD
|
|
@@ -40,7 +40,8 @@ flowchart TD
|
|
|
40
40
|
C --> D[Step 3: Implement Code (god-developer)]
|
|
41
41
|
D --> E[Step 4: Auto-Fix Code Review / Max 3 rounds]
|
|
42
42
|
E -->|Fail (code-auditor)| D
|
|
43
|
-
E -->|Pass| F[
|
|
43
|
+
E -->|Pass| F[Step 5: Incremental Docs Sync]
|
|
44
|
+
F --> G[Report Completion]
|
|
44
45
|
```
|
|
45
46
|
|
|
46
47
|
### Step 1: Initialize & Load Spec
|
|
@@ -66,6 +67,12 @@ The moment you finish coding, DO NOT proceed further. Switch to `references/qual
|
|
|
66
67
|
|
|
67
68
|
- Only escalate to the user after 3 consecutive failed review rounds.
|
|
68
69
|
|
|
70
|
+
### Step 5: Incremental Docs Sync
|
|
71
|
+
- After passing the Quality Gate, evaluate if any actual codebase modifications occurred (e.g., check pending files via git status).
|
|
72
|
+
- If files were created or modified: Trigger `docs-keeper` automatically to execute `repomix` and update the global `/docs/` and project logs.
|
|
73
|
+
- **CWD Protocol (CRITICAL):** When spawning `docs-keeper`, you MUST ensure the agent's Current Working Directory (CWD context) is explicitly set to the **Workspace Root**, NOT the inner package directory you were just coding in. Otherwise, `docs-keeper` will search for the root `docs/` folder in the wrong place and crash.
|
|
74
|
+
- Do NOT skip this step! The user explicitly requires documentation to be synced immediately after every `/hapo:develop` action, overriding the default Phase 3-only rule.
|
|
75
|
+
|
|
69
76
|
---
|
|
70
77
|
## Attached References
|
|
71
78
|
- `references/quality-gate.md` - Rules for the Code Review loop.
|
|
@@ -120,7 +120,7 @@ flowchart TD
|
|
|
120
120
|
K --> L
|
|
121
121
|
L --> M["Step 5: Requirements — write EARS"]
|
|
122
122
|
M --> N{Need deep research?}
|
|
123
|
-
N -->|Yes| O["Research: researchers +
|
|
123
|
+
N -->|Yes| O["Research: researchers + inspector + docs"]
|
|
124
124
|
O --> P["Write research.md"]
|
|
125
125
|
N -->|No| P
|
|
126
126
|
P --> Q["Step 6: Design — pick discovery mode"]
|
|
@@ -240,6 +240,7 @@ tasks/
|
|
|
240
240
|
- If a requirement has only 1 natural task, create 1 file (no forced splitting)
|
|
241
241
|
- If a requirement has many acceptance criteria spanning different concerns → split into multiple task files
|
|
242
242
|
- After generating all tasks: verify **every requirement ID** appears as primary in at least one task file — gaps = failure
|
|
243
|
+
- **Legacy Protection:** If the `research.md` identified existing codebase files or tests that will be broken (Blast Radius), you MUST generate explicitly tasked files (e.g., `task-R5-01-update-legacy-tests.md`) to fix those breakages. Do not leave broken tests out of scope.
|
|
243
244
|
|
|
244
245
|
**Dependency ordering:** Tasks within the same requirement are ordered by natural implementation flow. Cross-requirement dependencies use `Dependencies:` field referencing other task file names.
|
|
245
246
|
|
|
@@ -349,7 +350,7 @@ specs/
|
|
|
349
350
|
│ └── ...
|
|
350
351
|
└── reports/ # Auxiliary reports
|
|
351
352
|
├── researcher-01.md
|
|
352
|
-
├──
|
|
353
|
+
├── inspect-report.md
|
|
353
354
|
└── red-team-report.md
|
|
354
355
|
```
|
|
355
356
|
|
|
@@ -6,7 +6,7 @@ Understand the current codebase before designing solutions — ensure the new sp
|
|
|
6
6
|
|
|
7
7
|
## Skip Conditions
|
|
8
8
|
|
|
9
|
-
- Already provided with
|
|
9
|
+
- Already provided with inspector reports → skip, use directly
|
|
10
10
|
|
|
11
11
|
## 4 Mandatory Files to Read First
|
|
12
12
|
|
|
@@ -17,7 +17,12 @@ Understand the current codebase before designing solutions — ensure the new sp
|
|
|
17
17
|
| 3 | `./docs/code-standards.md` | Coding conventions, language-specific patterns | High |
|
|
18
18
|
| 4 | `./docs/design-guidelines.md` | Design system, branding, UI/UX conventions | If exists |
|
|
19
19
|
|
|
20
|
-
|
|
20
|
+
### Validation & Fallback Protocol (MANDATORY)
|
|
21
|
+
1. **Trust but Verify:** If `codebase-summary.md` or `code-standards.md` exists, you MUST verify their technical claims by cross-checking `package.json`, `go.mod`, etc. (e.g., if Docs say Redux but package.json only has Zustand → Flag documentation as STALE in your research).
|
|
22
|
+
2. **The "Blind Flight" Halt:** If ALL 4 mandatory docs are missing in a non-empty repository:
|
|
23
|
+
- **DO NOT** blindly use `inspector` to scan the whole repo.
|
|
24
|
+
- **HALT** the spec process immediately.
|
|
25
|
+
- Ask the User: *"No codebase documentation found. Exploring blind will drain tokens and produce inaccurate specs. Shall I trigger `docs-keeper` or `/hapo:docs` to generate a baseline `codebase-summary.md` first?"*
|
|
21
26
|
|
|
22
27
|
## Analysis Activities
|
|
23
28
|
|
|
@@ -27,28 +32,40 @@ Understand the current codebase before designing solutions — ensure the new sp
|
|
|
27
32
|
- Identify required dependencies
|
|
28
33
|
- Understand build and deployment processes
|
|
29
34
|
|
|
35
|
+
### 2. Core Data Structures (MANDATORY for Enhancements)
|
|
36
|
+
Before designing any logic, you must identify and read the existing schemas:
|
|
37
|
+
- Tell `inspector` to grep for database schema files (`schema.ts`, `schema.prisma`, entities, migrations).
|
|
38
|
+
- Identify Global State setups (Redux stores, Zustand, React Context).
|
|
39
|
+
- Output the relational impact: How will the new feature alter existing tables or state structures?
|
|
40
|
+
|
|
30
41
|
### 2. Pattern Recognition
|
|
31
42
|
- Study existing patterns in codebase
|
|
32
43
|
- Identify conventions and architectural decisions
|
|
33
44
|
- Note consistency in implementation approaches
|
|
34
45
|
- Understand error handling patterns
|
|
35
46
|
|
|
36
|
-
###
|
|
47
|
+
### 4. Integration Planning
|
|
37
48
|
- Identify how new features integrate with existing architecture
|
|
38
49
|
- Map dependencies between components
|
|
39
50
|
- Understand data flow and state management
|
|
40
51
|
- Consider backward compatibility
|
|
41
52
|
|
|
42
|
-
###
|
|
43
|
-
|
|
44
|
-
-
|
|
45
|
-
-
|
|
46
|
-
-
|
|
53
|
+
### 5. Blast Radius & Regression Check
|
|
54
|
+
Write a "Collateral Damage" section in your `research.md`:
|
|
55
|
+
- List EXACTLY which existing files will need to be modified.
|
|
56
|
+
- **Test Invalidation:** Identify which existing `.test.ts` or `.spec.ts` files will break because of these modifications.
|
|
57
|
+
- Ensure the mitigation for these breaking changes is passed downstream to the Task generation phase.
|
|
58
|
+
|
|
59
|
+
### 6. Inspector Usage (when needed)
|
|
60
|
+
- Use inspector agents for targeted file discovery in large codebases
|
|
61
|
+
- Each inspector targets a specific aspect of the task
|
|
62
|
+
- Wait for all inspectors to report before analysis
|
|
63
|
+
- Save results to `reports/inspect-report.md`
|
|
47
64
|
|
|
48
65
|
## Best Practices
|
|
49
66
|
|
|
50
67
|
- Start with documentation before diving into code
|
|
51
|
-
- Use
|
|
68
|
+
- Use inspectors for targeted file discovery
|
|
52
69
|
- Document patterns found for consistency
|
|
53
70
|
- Note any inconsistencies or technical debt
|
|
54
71
|
- Consider impact on existing features
|
|
@@ -18,7 +18,7 @@ Provide tools and methods to gather necessary information before writing require
|
|
|
18
18
|
| 3 | **Docs seeker** | Look up framework/package docs from official sources | Need to understand external APIs/libraries, find best practices |
|
|
19
19
|
| 4 | **GitHub analysis** (`gh`) | Read action logs, PRs, issues, discussions | Need context from project history, understand past decisions |
|
|
20
20
|
| 5 | **Repomix remote** (`repomix --remote <url>`) | Generate codebase summary from remote repo | Reference how other repos solve similar problems. *(If not installed, use WebFetch as fallback)* |
|
|
21
|
-
| 6 | **
|
|
21
|
+
| 6 | **Inspector agents** | Search for files across large codebases | Find relevant files faster than grep in large projects |
|
|
22
22
|
| 7 | **Debugger delegation** | Hand off to debugger agent for analysis | Investigate root cause of bugs |
|
|
23
23
|
|
|
24
24
|
## Workflow
|
|
@@ -32,7 +32,7 @@ Before detailing requirements, list unanswered questions:
|
|
|
32
32
|
|
|
33
33
|
### 2. Pick the Right Tool
|
|
34
34
|
- Framework/API questions → Docs seeker
|
|
35
|
-
- Current codebase questions →
|
|
35
|
+
- Current codebase questions → Inspector agents
|
|
36
36
|
- Architecture/approach questions → Researcher agents
|
|
37
37
|
- Complex multi-step reasoning → Sequential thinking
|
|
38
38
|
- Historical decision questions → GitHub analysis
|
|
@@ -46,7 +46,7 @@ Before detailing requirements, list unanswered questions:
|
|
|
46
46
|
### 4. Record Findings
|
|
47
47
|
- Write to `research.md` using template `templates/research.md`
|
|
48
48
|
- Save researcher reports to `reports/researcher-{NN}.md`
|
|
49
|
-
- Save
|
|
49
|
+
- Save inspector reports to `reports/inspect-report.md`
|
|
50
50
|
|
|
51
51
|
## Best Practices
|
|
52
52
|
|