@engramm/dev-workflow 0.1.6 → 0.1.7
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 -0
- package/dist/lib/templates.d.ts.map +1 -1
- package/dist/lib/templates.js +13 -0
- package/dist/lib/templates.js.map +1 -1
- package/package.json +1 -1
- package/templates/claude/commands/vault/arch.md +150 -0
- package/templates/claude/commands/vault/project-review.md +179 -0
- package/templates/claude/commands/workflow/dev.md +3 -0
- package/templates/claude/commands/workflow/steps/read.md +6 -0
- package/templates/claude/commands/workflow/steps/vault-updates.md +6 -2
package/README.md
CHANGED
|
@@ -98,6 +98,8 @@ Violation = immediate pipeline abort.
|
|
|
98
98
|
| `/vault:bug` | Record a resolved bug |
|
|
99
99
|
| `/vault:adr` | Record an architecture decision |
|
|
100
100
|
| `/vault:debt` | Record tech debt |
|
|
101
|
+
| `/vault:arch` | Architecture analysis: 2-3 options with trade-offs |
|
|
102
|
+
| `/vault:project-review` | Full project audit: 7 perspectives, A-F scoring |
|
|
101
103
|
| `/vault:deps` | Map module dependencies |
|
|
102
104
|
| `/vault:security-scan` | Security audit |
|
|
103
105
|
| `/vault:test-gaps` | Find untested code |
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"templates.d.ts","sourceRoot":"","sources":["../../src/lib/templates.ts"],"names":[],"mappings":"
|
|
1
|
+
{"version":3,"file":"templates.d.ts","sourceRoot":"","sources":["../../src/lib/templates.ts"],"names":[],"mappings":"AAwNA,wBAAgB,cAAc,CAC5B,YAAY,EAAE,MAAM,EACpB,SAAS,GAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CAAM,GACrC,MAAM,CAiBR;AAED,wBAAgB,aAAa,IAAI,MAAM,EAAE,CAExC"}
|
package/dist/lib/templates.js
CHANGED
|
@@ -184,6 +184,19 @@ Project knowledge is stored in \`.dev-vault/\`:
|
|
|
184
184
|
4. Review: \`/session:review\`
|
|
185
185
|
5. Handover: \`/session:handover\`
|
|
186
186
|
|
|
187
|
+
### Vault write rules (ALWAYS ACTIVE)
|
|
188
|
+
|
|
189
|
+
When the user agrees to a scope change, architecture decision, or deferred work — record IMMEDIATELY:
|
|
190
|
+
|
|
191
|
+
- **Architecture/scope decision** (user says "yes" to a proposal) → \`vault_record(type: "adr", title, content)\`
|
|
192
|
+
- **Work deferred** (user agrees to postpone something) → \`vault_record(type: "debt", title, content)\`
|
|
193
|
+
- **New gotcha discovered** → append to \`.dev-vault/knowledge.md\` section "Gotchas" (Edit tool, APPEND)
|
|
194
|
+
- **Gameplan changed** (phases reordered, tasks moved) → update \`.dev-vault/gameplan.md\` (Edit tool)
|
|
195
|
+
|
|
196
|
+
This applies in ALL contexts: during /workflow:dev (including aborted pipelines), free conversation, /vault:arch. Do NOT wait for pipeline completion. Record when user confirms.
|
|
197
|
+
|
|
198
|
+
Use Edit tool to APPEND to existing vault files. NEVER use Write tool on existing files.
|
|
199
|
+
|
|
187
200
|
## Project
|
|
188
201
|
|
|
189
202
|
<!-- Add project-specific instructions below -->
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"templates.js","sourceRoot":"","sources":["../../src/lib/templates.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,YAAY,EAAE,UAAU,EAAE,MAAM,SAAS,CAAC;AACnD,OAAO,EAAE,IAAI,EAAE,OAAO,EAAE,MAAM,WAAW,CAAC;AAC1C,OAAO,EAAE,aAAa,EAAE,MAAM,UAAU,CAAC;AACzC,OAAO,EAAE,WAAW,EAAE,MAAM,kBAAkB,CAAC;AAC/C,OAAO,EAAE,SAAS,EAAE,MAAM,iBAAiB,CAAC;AAE5C,MAAM,YAAY,GAAG,IAAI,CAAC,OAAO,CAAC,aAAa,CAAC,MAAM,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC,EAAE,IAAI,EAAE,IAAI,CAAC,CAAC;AAC/E,MAAM,aAAa,GAAG,IAAI,CAAC,YAAY,EAAE,WAAW,CAAC,CAAC;AAEtD,MAAM,iBAAiB,GAA2B;IAChD,aAAa,EAAE;;;;;;;;;;;;;;;;;CAiBhB;IAEC,mBAAmB,EAAE;;;;;;;;;;;;;;;;;CAiBtB;IAEC,iBAAiB,EAAE;;;;;;;;;;;CAWpB;IAEC,gBAAgB,EAAE;;;;;;;;;;;CAWnB;IAEC,gBAAgB,EAAE;;;;;;;;;;;;;;;;;;;;CAoBnB;IAEC,eAAe,EAAE;;;;;;;;;;;;;;;;;CAiBlB;IAEC,aAAa,EAAE;;;;;;;;;;;;;;CAchB;IAEC,aAAa,EAAE;;;;;;;;;;;;;;CAchB;IAEC,cAAc,EAAE;;;;;;;;;;;;;;;CAejB;IAEC,mBAAmB,EAAE
|
|
1
|
+
{"version":3,"file":"templates.js","sourceRoot":"","sources":["../../src/lib/templates.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,YAAY,EAAE,UAAU,EAAE,MAAM,SAAS,CAAC;AACnD,OAAO,EAAE,IAAI,EAAE,OAAO,EAAE,MAAM,WAAW,CAAC;AAC1C,OAAO,EAAE,aAAa,EAAE,MAAM,UAAU,CAAC;AACzC,OAAO,EAAE,WAAW,EAAE,MAAM,kBAAkB,CAAC;AAC/C,OAAO,EAAE,SAAS,EAAE,MAAM,iBAAiB,CAAC;AAE5C,MAAM,YAAY,GAAG,IAAI,CAAC,OAAO,CAAC,aAAa,CAAC,MAAM,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC,EAAE,IAAI,EAAE,IAAI,CAAC,CAAC;AAC/E,MAAM,aAAa,GAAG,IAAI,CAAC,YAAY,EAAE,WAAW,CAAC,CAAC;AAEtD,MAAM,iBAAiB,GAA2B;IAChD,aAAa,EAAE;;;;;;;;;;;;;;;;;CAiBhB;IAEC,mBAAmB,EAAE;;;;;;;;;;;;;;;;;CAiBtB;IAEC,iBAAiB,EAAE;;;;;;;;;;;CAWpB;IAEC,gBAAgB,EAAE;;;;;;;;;;;CAWnB;IAEC,gBAAgB,EAAE;;;;;;;;;;;;;;;;;;;;CAoBnB;IAEC,eAAe,EAAE;;;;;;;;;;;;;;;;;CAiBlB;IAEC,aAAa,EAAE;;;;;;;;;;;;;;CAchB;IAEC,aAAa,EAAE;;;;;;;;;;;;;;CAchB;IAEC,cAAc,EAAE;;;;;;;;;;;;;;;CAejB;IAEC,mBAAmB,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAiDtB;CACA,CAAC;AAEF,MAAM,UAAU,cAAc,CAC5B,YAAoB,EACpB,YAAoC,EAAE;IAEtC,MAAM,IAAI,GAA2B,EAAE,IAAI,EAAE,SAAS,EAAE,EAAE,GAAG,SAAS,EAAE,CAAC;IAEzE,MAAM,YAAY,GAAG,IAAI,CAAC,aAAa,EAAE,GAAG,YAAY,KAAK,CAAC,CAAC;IAC/D,IAAI,QAAgB,CAAC;IAErB,IAAI,UAAU,CAAC,YAAY,CAAC,EAAE,CAAC;QAC7B,QAAQ,GAAG,YAAY,CAAC,YAAY,EAAE,OAAO,CAAC,CAAC;IACjD,CAAC;SAAM,CAAC;QACN,MAAM,OAAO,GAAG,iBAAiB,CAAC,YAAY,CAAC,CAAC;QAChD,IAAI,CAAC,OAAO,EAAE,CAAC;YACb,MAAM,IAAI,KAAK,CAAC,uBAAuB,YAAY,EAAE,CAAC,CAAC;QACzD,CAAC;QACD,QAAQ,GAAG,OAAO,CAAC;IACrB,CAAC;IAED,OAAO,WAAW,CAAC,QAAQ,EAAE,IAAI,CAAC,CAAC;AACrC,CAAC;AAED,MAAM,UAAU,aAAa;IAC3B,OAAO,MAAM,CAAC,IAAI,CAAC,iBAAiB,CAAC,CAAC;AACxC,CAAC"}
|
package/package.json
CHANGED
|
@@ -0,0 +1,150 @@
|
|
|
1
|
+
# /vault:arch — Architecture analysis and decision support
|
|
2
|
+
|
|
3
|
+
Read-only analysis of an architecture question. Researches codebase and vault, proposes 2-3 solutions with trade-offs, recommends one. Does NOT write code.
|
|
4
|
+
|
|
5
|
+
## Arguments
|
|
6
|
+
|
|
7
|
+
`/vault:arch "<question>"` — architecture question or decision to analyze.
|
|
8
|
+
|
|
9
|
+
Examples:
|
|
10
|
+
- `/vault:arch "как организовать модуль авторизации?"`
|
|
11
|
+
- `/vault:arch "стоит ли разделить этот сервис на два?"`
|
|
12
|
+
- `/vault:arch "выбор между REST и gRPC"`
|
|
13
|
+
- `/vault:arch "как обрабатывать ошибки в pipeline?"`
|
|
14
|
+
|
|
15
|
+
## Permissions (VIOLATION = ABORT)
|
|
16
|
+
|
|
17
|
+
- Read files: YES
|
|
18
|
+
- Write/Edit files: FORBIDDEN — analysis only, no code changes
|
|
19
|
+
- Bash: FORBIDDEN
|
|
20
|
+
- Vault writes: FORBIDDEN — user decides whether to create ADR after analysis
|
|
21
|
+
|
|
22
|
+
## Procedure
|
|
23
|
+
|
|
24
|
+
### Step 1: Load context
|
|
25
|
+
|
|
26
|
+
MUST read:
|
|
27
|
+
- `.dev-vault/stack.md` — what technologies are available
|
|
28
|
+
- `.dev-vault/conventions.md` — what patterns are established
|
|
29
|
+
- `.dev-vault/knowledge.md` — existing architecture, gotchas
|
|
30
|
+
- `.dev-vault/gameplan.md` — current phase, priorities
|
|
31
|
+
|
|
32
|
+
### Step 2: Research codebase
|
|
33
|
+
|
|
34
|
+
Use Agent (Explore subagent) to:
|
|
35
|
+
1. Find code related to the question (Glob/Grep)
|
|
36
|
+
2. Read relevant files (max 15 files)
|
|
37
|
+
3. Map current architecture around the question area
|
|
38
|
+
4. Identify existing patterns that apply
|
|
39
|
+
5. Check `.dev-vault/architecture/` for related ADR records
|
|
40
|
+
|
|
41
|
+
### Step 3: Analyze from 3 perspectives
|
|
42
|
+
|
|
43
|
+
MUST evaluate from ALL 3:
|
|
44
|
+
|
|
45
|
+
**Maintainability** — how easy to understand, modify, test?
|
|
46
|
+
- Module boundaries clear?
|
|
47
|
+
- Dependencies explicit?
|
|
48
|
+
- Testable in isolation?
|
|
49
|
+
|
|
50
|
+
**Security** — attack surface, trust boundaries?
|
|
51
|
+
- Where does user input enter?
|
|
52
|
+
- What needs authentication/authorization?
|
|
53
|
+
- Data protection implications?
|
|
54
|
+
|
|
55
|
+
**Pragmatism** — effort vs value, simplicity, timeline?
|
|
56
|
+
- How much work for each option?
|
|
57
|
+
- Fits current phase from gameplan?
|
|
58
|
+
- Over-engineering risk?
|
|
59
|
+
|
|
60
|
+
Note conflicts between perspectives explicitly.
|
|
61
|
+
|
|
62
|
+
### Step 4: Propose solutions
|
|
63
|
+
|
|
64
|
+
MUST propose **2-3 solutions** (not 1, not 5+). Each MUST include:
|
|
65
|
+
|
|
66
|
+
1. **Summary** — 1-2 sentences
|
|
67
|
+
2. **How it works** — concrete description with file paths / module names
|
|
68
|
+
3. **Pros** — specific, not generic ("reduces coupling between X and Y")
|
|
69
|
+
4. **Cons** — specific, honest ("adds N files, complexity in Z")
|
|
70
|
+
5. **Fits conventions?** — does it match `.dev-vault/conventions.md`?
|
|
71
|
+
6. **Effort** — small / medium / large
|
|
72
|
+
7. **Risk** — what could go wrong
|
|
73
|
+
|
|
74
|
+
### Step 5: Recommend
|
|
75
|
+
|
|
76
|
+
Pick ONE solution. MUST justify with:
|
|
77
|
+
- Why this one over the others
|
|
78
|
+
- Which perspective it optimizes for and why
|
|
79
|
+
- What trade-offs are accepted
|
|
80
|
+
|
|
81
|
+
## Output format
|
|
82
|
+
|
|
83
|
+
MUST use this exact format:
|
|
84
|
+
|
|
85
|
+
```
|
|
86
|
+
══════════════════════════════════
|
|
87
|
+
ARCH: <question short form>
|
|
88
|
+
══════════════════════════════════
|
|
89
|
+
|
|
90
|
+
Context:
|
|
91
|
+
Project: <name> | Branch: <branch> | Phase: <current from gameplan>
|
|
92
|
+
Related files: <N> analyzed
|
|
93
|
+
Existing patterns: <relevant conventions/patterns found>
|
|
94
|
+
Related ADRs: <list or "none">
|
|
95
|
+
|
|
96
|
+
── Option A: <name> ──
|
|
97
|
+
|
|
98
|
+
<summary>
|
|
99
|
+
|
|
100
|
+
How: <concrete description>
|
|
101
|
+
Pros:
|
|
102
|
+
+ <specific pro>
|
|
103
|
+
+ <specific pro>
|
|
104
|
+
Cons:
|
|
105
|
+
- <specific con>
|
|
106
|
+
- <specific con>
|
|
107
|
+
Conventions: matches / deviates (<what>)
|
|
108
|
+
Effort: small / medium / large
|
|
109
|
+
Risk: <what could go wrong>
|
|
110
|
+
|
|
111
|
+
── Option B: <name> ──
|
|
112
|
+
|
|
113
|
+
<same structure>
|
|
114
|
+
|
|
115
|
+
── Option C: <name> (if applicable) ──
|
|
116
|
+
|
|
117
|
+
<same structure>
|
|
118
|
+
|
|
119
|
+
── Perspective conflicts ──
|
|
120
|
+
|
|
121
|
+
<if perspectives disagree — describe the conflict and how recommendation resolves it>
|
|
122
|
+
|
|
123
|
+
── RECOMMENDATION ──
|
|
124
|
+
|
|
125
|
+
Option <A/B/C>: <name>
|
|
126
|
+
|
|
127
|
+
Justification:
|
|
128
|
+
<why this one>
|
|
129
|
+
<which perspective it optimizes for>
|
|
130
|
+
<what trade-offs accepted>
|
|
131
|
+
|
|
132
|
+
Next steps:
|
|
133
|
+
1. <concrete action>
|
|
134
|
+
2. <concrete action>
|
|
135
|
+
|
|
136
|
+
Record this decision? → /vault:adr
|
|
137
|
+
|
|
138
|
+
══════════════════════════════════
|
|
139
|
+
```
|
|
140
|
+
|
|
141
|
+
## Rules
|
|
142
|
+
|
|
143
|
+
- **Read-only** — NEVER modify any file. VIOLATION = ABORT.
|
|
144
|
+
- **MUST propose 2-3 options** — not 1 ("here's what you should do"), not 5+ (analysis paralysis)
|
|
145
|
+
- **Evidence-based** — every claim MUST reference a specific file or vault entry. No "generally speaking".
|
|
146
|
+
- **Concrete** — "move auth logic to src/auth/middleware.ts" not "consider separating concerns"
|
|
147
|
+
- **Stack-aware** — options MUST be feasible with current stack from stack.md
|
|
148
|
+
- **Convention-aware** — flag if option violates conventions.md, justify why it's worth deviating
|
|
149
|
+
- **No code** — describe what to do, not how to implement. Implementation is coder's job.
|
|
150
|
+
- **Offer ADR** — always end with suggestion to record as ADR if decision is significant
|
|
@@ -0,0 +1,179 @@
|
|
|
1
|
+
# /vault:project-review — Full project audit
|
|
2
|
+
|
|
3
|
+
Read-only comprehensive audit of the project. Checks vault, architecture, tests, security, debt, conventions, and production readiness. Does NOT modify any files.
|
|
4
|
+
|
|
5
|
+
## Permissions
|
|
6
|
+
|
|
7
|
+
- Read files: YES
|
|
8
|
+
- Write/Edit files: FORBIDDEN
|
|
9
|
+
- Bash: ONLY `npm test`, `npm run build`, `npm run lint` (or stack equivalent) — for checking, not fixing
|
|
10
|
+
|
|
11
|
+
## Procedure
|
|
12
|
+
|
|
13
|
+
### Step 1: Load vault context
|
|
14
|
+
|
|
15
|
+
MUST read ALL vault files:
|
|
16
|
+
- `.dev-vault/stack.md`
|
|
17
|
+
- `.dev-vault/conventions.md`
|
|
18
|
+
- `.dev-vault/knowledge.md`
|
|
19
|
+
- `.dev-vault/gameplan.md`
|
|
20
|
+
- `.dev-vault/phases/` — all phase files (check status: done/pending)
|
|
21
|
+
- `.dev-vault/tasks/` — all tasks (check statuses)
|
|
22
|
+
- `.dev-vault/architecture/` — all ADR records
|
|
23
|
+
- `.dev-vault/bugs/` — all bug records
|
|
24
|
+
- `.dev-vault/debt/` — all debt records
|
|
25
|
+
|
|
26
|
+
### Step 2: Scan codebase
|
|
27
|
+
|
|
28
|
+
Use Agent (Explore subagent) to:
|
|
29
|
+
1. Map project structure (top-level dirs, file count per dir)
|
|
30
|
+
2. Read 15-20 representative files (entry points, core modules, tests, configs)
|
|
31
|
+
3. Run `npm test` (or stack equivalent) — record pass/fail count
|
|
32
|
+
4. Run `npm run build` — record success/failure
|
|
33
|
+
5. Search for: TODO, FIXME, HACK, console.log, hardcoded secrets patterns
|
|
34
|
+
|
|
35
|
+
### Step 3: Analyze from 7 perspectives
|
|
36
|
+
|
|
37
|
+
MUST evaluate ALL 7 — do not skip any.
|
|
38
|
+
|
|
39
|
+
**1. Vault completeness**
|
|
40
|
+
- All 4 sections filled (not just frontmatter)?
|
|
41
|
+
- knowledge.md reflects actual architecture (not outdated)?
|
|
42
|
+
- gameplan.md reflects actual progress (phases done match code)?
|
|
43
|
+
- conventions.md matches real code patterns?
|
|
44
|
+
- Unrecorded ADRs, bugs, or debt visible in code?
|
|
45
|
+
|
|
46
|
+
**2. Architecture**
|
|
47
|
+
- Dependency direction correct? (inner layers don't import outer)
|
|
48
|
+
- Single Responsibility: files/modules do one thing?
|
|
49
|
+
- God objects: any file/class doing too much?
|
|
50
|
+
- Layer separation clean? (no domain logic in controllers, no infra in domain)
|
|
51
|
+
- Circular dependencies?
|
|
52
|
+
|
|
53
|
+
**3. Test coverage**
|
|
54
|
+
- All public modules have tests?
|
|
55
|
+
- Tests cover: happy path, edge cases, error paths?
|
|
56
|
+
- Test quality: meaningful assertions, not just "doesn't throw"?
|
|
57
|
+
- Test isolation: no shared state?
|
|
58
|
+
- Integration tests exist for critical paths?
|
|
59
|
+
|
|
60
|
+
**4. Security**
|
|
61
|
+
- OWASP Top 10 patterns in code?
|
|
62
|
+
- Hardcoded secrets, API keys, passwords?
|
|
63
|
+
- Input validation at system boundaries?
|
|
64
|
+
- Auth/AuthZ where needed?
|
|
65
|
+
- Dependencies: known vulnerabilities? (`npm audit` or equivalent)
|
|
66
|
+
|
|
67
|
+
**5. Tech debt**
|
|
68
|
+
- Recorded debt in `.dev-vault/debt/` — still relevant?
|
|
69
|
+
- Unrecorded debt visible in code? (TODO, FIXME, HACK, workarounds)
|
|
70
|
+
- Files over 300 lines?
|
|
71
|
+
- Functions over 30 lines?
|
|
72
|
+
- Dead code, unused imports?
|
|
73
|
+
|
|
74
|
+
**6. Production readiness**
|
|
75
|
+
- Error handling: all external calls have error paths + timeouts?
|
|
76
|
+
- Logging: structured logging, no console.log?
|
|
77
|
+
- Config: no hardcoded values that should be env/config?
|
|
78
|
+
- Graceful shutdown?
|
|
79
|
+
- Idempotent operations where needed?
|
|
80
|
+
|
|
81
|
+
**7. Convention compliance**
|
|
82
|
+
- Code matches `.dev-vault/conventions.md`?
|
|
83
|
+
- Naming consistent? (check 10+ files)
|
|
84
|
+
- File structure matches conventions?
|
|
85
|
+
- Git commit style consistent?
|
|
86
|
+
- Test patterns consistent?
|
|
87
|
+
|
|
88
|
+
### Step 4: Score and report
|
|
89
|
+
|
|
90
|
+
## Output format
|
|
91
|
+
|
|
92
|
+
MUST use this exact format:
|
|
93
|
+
|
|
94
|
+
```
|
|
95
|
+
══════════════════════════════════
|
|
96
|
+
PROJECT REVIEW: <name>
|
|
97
|
+
══════════════════════════════════
|
|
98
|
+
|
|
99
|
+
Branch: <branch>
|
|
100
|
+
Date: <today>
|
|
101
|
+
Files scanned: <N>
|
|
102
|
+
Tests: <N passed> / <N total>
|
|
103
|
+
Build: pass / fail
|
|
104
|
+
|
|
105
|
+
── SCORES ──
|
|
106
|
+
|
|
107
|
+
| Perspective | Score | Issues |
|
|
108
|
+
|---------------------|-------|--------|
|
|
109
|
+
| Vault completeness | A/B/C/D/F | <N> |
|
|
110
|
+
| Architecture | A/B/C/D/F | <N> |
|
|
111
|
+
| Test coverage | A/B/C/D/F | <N> |
|
|
112
|
+
| Security | A/B/C/D/F | <N> |
|
|
113
|
+
| Tech debt | A/B/C/D/F | <N> |
|
|
114
|
+
| Production readiness| A/B/C/D/F | <N> |
|
|
115
|
+
| Convention compliance| A/B/C/D/F | <N> |
|
|
116
|
+
|
|
117
|
+
Overall: <weighted average> / A
|
|
118
|
+
|
|
119
|
+
── CRITICAL (must fix) ──
|
|
120
|
+
|
|
121
|
+
- [SEVERITY] [perspective] <file:line> — <issue>
|
|
122
|
+
Fix: <concrete suggestion>
|
|
123
|
+
|
|
124
|
+
── HIGH (should fix) ──
|
|
125
|
+
|
|
126
|
+
- [SEVERITY] [perspective] <file:line> — <issue>
|
|
127
|
+
Fix: <suggestion>
|
|
128
|
+
|
|
129
|
+
── MEDIUM (consider) ──
|
|
130
|
+
|
|
131
|
+
- [perspective] <issue summary>
|
|
132
|
+
|
|
133
|
+
── VAULT GAPS ──
|
|
134
|
+
|
|
135
|
+
- <what's missing or outdated in vault>
|
|
136
|
+
|
|
137
|
+
── TECH DEBT INVENTORY ──
|
|
138
|
+
|
|
139
|
+
Recorded: <N> items in .dev-vault/debt/
|
|
140
|
+
Unrecorded: <N> items found in code
|
|
141
|
+
- <file:line> — <debt description>
|
|
142
|
+
|
|
143
|
+
── RECOMMENDATIONS ──
|
|
144
|
+
|
|
145
|
+
1. <highest priority action>
|
|
146
|
+
2. <second priority>
|
|
147
|
+
3. <third priority>
|
|
148
|
+
|
|
149
|
+
── GAMEPLAN vs REALITY ──
|
|
150
|
+
|
|
151
|
+
| Phase | Gameplan status | Actual status | Match |
|
|
152
|
+
|-------|----------------|---------------|-------|
|
|
153
|
+
| Phase 1 | done | <code evidence> | yes/no |
|
|
154
|
+
| Phase 2 | done | <code evidence> | yes/no |
|
|
155
|
+
| ... | ... | ... | ... |
|
|
156
|
+
|
|
157
|
+
══════════════════════════════════
|
|
158
|
+
```
|
|
159
|
+
|
|
160
|
+
## Scoring criteria
|
|
161
|
+
|
|
162
|
+
| Score | Meaning |
|
|
163
|
+
|-------|---------|
|
|
164
|
+
| **A** | Excellent — no issues or only style nits |
|
|
165
|
+
| **B** | Good — minor issues, no blockers |
|
|
166
|
+
| **C** | Acceptable — some issues need attention |
|
|
167
|
+
| **D** | Poor — significant issues, blocks production readiness |
|
|
168
|
+
| **F** | Failing — critical issues, not safe to ship |
|
|
169
|
+
|
|
170
|
+
## Rules
|
|
171
|
+
|
|
172
|
+
- **Read-only** — NEVER modify any file. VIOLATION = ABORT.
|
|
173
|
+
- **All 7 perspectives REQUIRED** — do not skip any. Each MUST produce a score.
|
|
174
|
+
- **Evidence-based** — every finding MUST reference a specific file:line. No vague claims.
|
|
175
|
+
- **MUST scan minimum 15 files** — representative sample across all modules
|
|
176
|
+
- **MUST run tests and build** — report actual results, not assumptions
|
|
177
|
+
- **Compare vault with code** — vault says X, code does Y → flag discrepancy
|
|
178
|
+
- **Recorded debt review** — check if existing debt records are still relevant or resolved
|
|
179
|
+
- **No "best-effort"** — if you can't verify something, say "NOT VERIFIED" with reason
|
|
@@ -58,6 +58,9 @@ Step 7: Read steps/test.md → run build + lint + tests
|
|
|
58
58
|
Step 8: Read steps/verify.md → launch Explore agent → COMPLETE / INCOMPLETE
|
|
59
59
|
Step 9: Read steps/commit.md → stage + commit (interactive or autonomous)
|
|
60
60
|
Step 9b: Read steps/vault-updates.md → update daily log, task status
|
|
61
|
+
|
|
62
|
+
ON STOP (pipeline aborted at any step):
|
|
63
|
+
Read steps/vault-updates.md → record findings, ADR, debt BEFORE stopping
|
|
61
64
|
```
|
|
62
65
|
|
|
63
66
|
### Phase mode
|
|
@@ -17,6 +17,9 @@ You are a reader agent. Gather context for the task below.
|
|
|
17
17
|
3. Read relevant files (max 10 files, 500 lines each)
|
|
18
18
|
4. Find dependencies and tests for those files
|
|
19
19
|
5. Find how similar things are done in the project
|
|
20
|
+
6. Scan .dev-vault/architecture/ for ADR records related to this task
|
|
21
|
+
7. Scan .dev-vault/bugs/ for known bugs in affected areas
|
|
22
|
+
8. Scan .dev-vault/debt/ for known debt in affected areas
|
|
20
23
|
|
|
21
24
|
## Output Format
|
|
22
25
|
CONTEXT:
|
|
@@ -26,6 +29,9 @@ Dependencies: [files depending on changes]
|
|
|
26
29
|
Tests: [existing tests for those files]
|
|
27
30
|
Patterns found: [how similar things are solved]
|
|
28
31
|
Relevant code: [key fragments]
|
|
32
|
+
Related ADRs: [from .dev-vault/architecture/ or "none"]
|
|
33
|
+
Known bugs: [from .dev-vault/bugs/ or "none"]
|
|
34
|
+
Known debt: [from .dev-vault/debt/ or "none"]
|
|
29
35
|
END_CONTEXT
|
|
30
36
|
```
|
|
31
37
|
|
|
@@ -1,8 +1,12 @@
|
|
|
1
|
-
# Step 9b: Vault updates (after commit)
|
|
1
|
+
# Step 9b: Vault updates (after commit OR pipeline stop)
|
|
2
2
|
|
|
3
|
-
Orchestrator writes
|
|
3
|
+
Orchestrator writes to vault after successful commit AND when pipeline stops/aborts.
|
|
4
4
|
Use **Edit tool** to append — **never overwrite** existing vault files.
|
|
5
5
|
|
|
6
|
+
**IMPORTANT:** Vault writes MUST happen even if pipeline did not reach COMMIT.
|
|
7
|
+
If pipeline stopped at REVIEW (blocker), TEST (fail), or VERIFY (incomplete) —
|
|
8
|
+
still record findings, decisions, and deferred work before stopping.
|
|
9
|
+
|
|
6
10
|
## 1. Daily log
|
|
7
11
|
|
|
8
12
|
Append to `.dev-vault/daily/<today>.md`:
|