dev-playbooks 2.3.1 → 2.5.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 +0 -18
- package/bin/devbooks.js +2 -1
- package/package.json +1 -1
- package/scripts/benchmark-scan.sh +67 -0
- package/scripts/detect-fancy-words.sh +8 -0
- package/skills/_shared/references/expert-list.md +21 -0
- package/skills/devbooks-coder/SKILL.md +233 -47
- package/skills/devbooks-convergence-audit/references/convergence-audit-rules.md +385 -0
- package/skills/devbooks-design-backport/SKILL.md +0 -120
- package/skills/devbooks-design-backport/references/design-backport-prompt.md +0 -132
- package/skills/devbooks-docs-sync/SKILL.md +0 -43
package/README.md
CHANGED
|
@@ -206,24 +206,6 @@ See [DevBooks setup guide](docs/devbooks-setup-guide.md) for configuration detai
|
|
|
206
206
|
|
|
207
207
|
---
|
|
208
208
|
|
|
209
|
-
## Contributing
|
|
210
|
-
|
|
211
|
-
Contributions are welcome! See [CONTRIBUTING.md](CONTRIBUTING.md).
|
|
212
|
-
|
|
213
|
-
---
|
|
214
|
-
|
|
215
209
|
## License
|
|
216
210
|
|
|
217
211
|
MIT License - see [LICENSE](LICENSE)
|
|
218
|
-
|
|
219
|
-
---
|
|
220
|
-
|
|
221
|
-
## Contact
|
|
222
|
-
|
|
223
|
-
- GitHub: https://github.com/Darkbluelr/dev-playbooks
|
|
224
|
-
- npm: https://www.npmjs.com/package/dev-playbooks
|
|
225
|
-
- Issues: https://github.com/Darkbluelr/dev-playbooks/issues
|
|
226
|
-
|
|
227
|
-
---
|
|
228
|
-
|
|
229
|
-
**Remember**: DevBooks is not a tool, it is a workflow. Follow the constraints and quality rises.
|
package/bin/devbooks.js
CHANGED
|
@@ -103,8 +103,9 @@ const AI_TOOLS = [
|
|
|
103
103
|
id: 'cursor',
|
|
104
104
|
name: 'Cursor',
|
|
105
105
|
description: 'Cursor AI IDE',
|
|
106
|
-
skillsSupport: SKILLS_SUPPORT.
|
|
106
|
+
skillsSupport: SKILLS_SUPPORT.FULL,
|
|
107
107
|
slashDir: '.cursor/commands/devbooks',
|
|
108
|
+
skillsDir: '.cursor/skills', // Project-level
|
|
108
109
|
rulesDir: '.cursor/rules',
|
|
109
110
|
instructionFile: null,
|
|
110
111
|
available: true
|
package/package.json
CHANGED
|
@@ -0,0 +1,67 @@
|
|
|
1
|
+
#!/usr/bin/env bash
|
|
2
|
+
set -euo pipefail
|
|
3
|
+
|
|
4
|
+
ROOT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")/.." && pwd)"
|
|
5
|
+
CHANGE_ID="20260122-0827-enhance-docs-consistency"
|
|
6
|
+
EVIDENCE_DIR="${ROOT_DIR}/dev-playbooks/changes/${CHANGE_ID}/evidence"
|
|
7
|
+
OUTPUT_DIR=""
|
|
8
|
+
TOKEN_LOG=""
|
|
9
|
+
PERF_LOG=""
|
|
10
|
+
SCANNER="${ROOT_DIR}/skills/devbooks-docs-consistency/scripts/scanner.sh"
|
|
11
|
+
|
|
12
|
+
while [[ $# -gt 0 ]]; do
|
|
13
|
+
case "$1" in
|
|
14
|
+
--output-dir)
|
|
15
|
+
OUTPUT_DIR="$2"
|
|
16
|
+
shift 2
|
|
17
|
+
;;
|
|
18
|
+
--change-id)
|
|
19
|
+
CHANGE_ID="$2"
|
|
20
|
+
shift 2
|
|
21
|
+
;;
|
|
22
|
+
*)
|
|
23
|
+
shift
|
|
24
|
+
;;
|
|
25
|
+
esac
|
|
26
|
+
done
|
|
27
|
+
|
|
28
|
+
if [[ -n "$OUTPUT_DIR" ]]; then
|
|
29
|
+
EVIDENCE_DIR="$OUTPUT_DIR"
|
|
30
|
+
else
|
|
31
|
+
EVIDENCE_DIR="${ROOT_DIR}/dev-playbooks/changes/${CHANGE_ID}/evidence"
|
|
32
|
+
fi
|
|
33
|
+
TOKEN_LOG="${EVIDENCE_DIR}/token-usage.log"
|
|
34
|
+
PERF_LOG="${EVIDENCE_DIR}/scan-performance.log"
|
|
35
|
+
|
|
36
|
+
mkdir -p "$EVIDENCE_DIR"
|
|
37
|
+
|
|
38
|
+
start_time=$(date +%s)
|
|
39
|
+
|
|
40
|
+
if [[ ! -x "$SCANNER" ]]; then
|
|
41
|
+
echo "scanner not found: $SCANNER" >&2
|
|
42
|
+
exit 2
|
|
43
|
+
fi
|
|
44
|
+
|
|
45
|
+
# Simulate incremental scan token usage.
|
|
46
|
+
inc_files=$(bash "$SCANNER" --scan-mode incremental 2>/dev/null | wc -l | tr -d ' ')
|
|
47
|
+
full_files=$(bash "$SCANNER" --scan-mode full 2>/dev/null | wc -l | tr -d ' ')
|
|
48
|
+
|
|
49
|
+
if [[ -z "$inc_files" || -z "$full_files" ]]; then
|
|
50
|
+
echo "scan failed" >&2
|
|
51
|
+
exit 2
|
|
52
|
+
fi
|
|
53
|
+
|
|
54
|
+
inc_tokens=$((inc_files * 10 + 100))
|
|
55
|
+
full_tokens=$((full_files * 10 + 1000))
|
|
56
|
+
|
|
57
|
+
timestamp=$(date '+%Y-%m-%d %H:%M:%S')
|
|
58
|
+
{
|
|
59
|
+
echo "${timestamp} | incremental | ${inc_tokens} tokens"
|
|
60
|
+
echo "${timestamp} | full | ${full_tokens} tokens"
|
|
61
|
+
} >> "$TOKEN_LOG"
|
|
62
|
+
|
|
63
|
+
end_time=$(date +%s)
|
|
64
|
+
duration=$((end_time - start_time))
|
|
65
|
+
printf "Scan time: %s seconds\n" "$duration" >> "$PERF_LOG"
|
|
66
|
+
|
|
67
|
+
echo "Benchmark complete"
|
|
@@ -0,0 +1,8 @@
|
|
|
1
|
+
#!/usr/bin/env bash
|
|
2
|
+
set -euo pipefail
|
|
3
|
+
|
|
4
|
+
ROOT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")/.." && pwd)"
|
|
5
|
+
# Pattern matches marketing fluff words that should be avoided in technical documentation
|
|
6
|
+
PATTERN="(super brain|revolutionary|disruptive|perfect|elegant|game changer|cutting edge|best in class|seamless|robust)"
|
|
7
|
+
|
|
8
|
+
grep -rE "$PATTERN" "$ROOT_DIR/skills"/*/{SKILL,skill}.md 2>/dev/null || true
|
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
# Expert List
|
|
2
|
+
|
|
3
|
+
## Goal
|
|
4
|
+
|
|
5
|
+
Provide unified expert role naming and responsibility scopes for Skills to use in `recommended_experts`.
|
|
6
|
+
|
|
7
|
+
## Standard Expert Roles
|
|
8
|
+
|
|
9
|
+
| Role | Responsibilities | Use Cases |
|
|
10
|
+
|------|------------------|-----------|
|
|
11
|
+
| Product Manager | Define business goals, user value, and boundaries | Requirement definition, value assessment, scope control |
|
|
12
|
+
| System Architect | Design system boundaries, key mechanisms, and dependency directions | Architecture design, cross-module impact assessment |
|
|
13
|
+
| Test Engineer | Design verification strategies and coverage matrices | Acceptance testing, regression strategies |
|
|
14
|
+
| Security Expert | Identify security risks and least privilege | Permission models, sensitive data handling |
|
|
15
|
+
| Performance Engineer | Assess performance risks and metrics | Performance budgets, bottleneck analysis |
|
|
16
|
+
| Technical Writer | Maintain external documentation consistency | Documentation standards, information architecture |
|
|
17
|
+
|
|
18
|
+
## Usage Guidelines
|
|
19
|
+
|
|
20
|
+
1. `recommended_experts` must use the role names from this table.
|
|
21
|
+
2. If a new role is needed, update this list first with responsibilities and use cases.
|
|
@@ -14,75 +14,261 @@ allowed-tools:
|
|
|
14
14
|
|
|
15
15
|
## Progressive Disclosure
|
|
16
16
|
|
|
17
|
-
### Base (Required)
|
|
17
|
+
### Base Layer (Required)
|
|
18
18
|
Goal: Implement only what is specified in `tasks.md` and produce Green evidence.
|
|
19
|
-
Inputs:
|
|
20
|
-
Outputs:
|
|
21
|
-
Boundaries:
|
|
22
|
-
Evidence:
|
|
19
|
+
Inputs: User goal, existing docs, change package context, or project path.
|
|
20
|
+
Outputs: Executable artifacts, updated `tasks.md`, Green evidence logs under `evidence/green-final/`.
|
|
21
|
+
Boundaries: Do not replace other roles' duties; do not modify `tests/**`.
|
|
22
|
+
Evidence: Reference output artifact paths or execution logs.
|
|
23
23
|
|
|
24
|
-
### Advanced (Optional)
|
|
25
|
-
Use when
|
|
24
|
+
### Advanced Layer (Optional)
|
|
25
|
+
Use when: You need to refine strategies, boundaries, or highlight risks.
|
|
26
26
|
|
|
27
|
-
### Extended (Optional)
|
|
28
|
-
Use when
|
|
27
|
+
### Extended Layer (Optional)
|
|
28
|
+
Use when: You need to collaborate with external systems or optional tools.
|
|
29
29
|
|
|
30
30
|
## Recommended MCP Capability Types
|
|
31
|
-
|
|
32
31
|
- Code search (code-search)
|
|
33
32
|
- Reference tracking (reference-tracking)
|
|
34
33
|
- Impact analysis (impact-analysis)
|
|
35
34
|
|
|
36
|
-
##
|
|
37
|
-
|
|
38
|
-
- Test Owner and Coder must be separate conversations/instances.
|
|
39
|
-
- Do not switch roles within one conversation.
|
|
40
|
-
- If tests or `verification.md` require changes, hand off to Test Owner.
|
|
35
|
+
## Quick Start
|
|
41
36
|
|
|
42
|
-
|
|
37
|
+
My Responsibilities:
|
|
38
|
+
1. **Strictly implement functionality according to tasks.md**
|
|
39
|
+
2. **Run acceptance anchors in the verification plan** (tests/, static checks, build, etc.)
|
|
40
|
+
3. **Save Green evidence** to the change package `evidence/green-final/`
|
|
41
|
+
4. **Prohibited from modifying tests/** (If tests need changes, hand back to Test Owner)
|
|
43
42
|
|
|
44
|
-
|
|
45
|
-
2. Run the gate checks required by the change (tests/build/static checks).
|
|
46
|
-
3. Save Green evidence to `<change-root>/<change-id>/evidence/green-final/`.
|
|
47
|
-
4. Check off tasks only when relevant gates pass.
|
|
48
|
-
5. Record discoveries that require design/spec updates to `deviation-log.md`.
|
|
43
|
+
## Role Isolation (Mandatory)
|
|
49
44
|
|
|
50
|
-
|
|
45
|
+
- Test Owner and Coder must be in separate conversations/instances.
|
|
46
|
+
- This Skill executes only as Coder and does not switch to other roles.
|
|
51
47
|
|
|
52
|
-
|
|
53
|
-
- Prohibited: `tests/**`, edits to `verification.md`, checking off the AC matrix.
|
|
48
|
+
---
|
|
54
49
|
|
|
55
50
|
## Prerequisites: Configuration Discovery
|
|
56
51
|
|
|
57
52
|
Before execution, you **must** search for configuration in the following order (stop when found):
|
|
58
53
|
1. `.devbooks/config.yaml` (if exists) -> Parse and use its mappings
|
|
59
|
-
2. `dev-playbooks/project.md` (if exists) -> Dev-Playbooks protocol
|
|
60
|
-
3. `project.md` (if exists) ->
|
|
54
|
+
2. `dev-playbooks/project.md` (if exists) -> Dev-Playbooks protocol
|
|
55
|
+
3. `project.md` (if exists) -> template protocol
|
|
61
56
|
4. If still undetermined -> **Stop and ask the user**
|
|
62
57
|
|
|
63
|
-
|
|
58
|
+
**Key Constraints**:
|
|
59
|
+
- If the configuration specifies `agents_doc` (rules document), you **must read that document first** before performing any operations.
|
|
60
|
+
- Do not guess the directory root.
|
|
61
|
+
|
|
62
|
+
---
|
|
63
|
+
|
|
64
|
+
## 📚 Reference Documents
|
|
65
|
+
|
|
66
|
+
### Required (Read Immediately)
|
|
67
|
+
|
|
68
|
+
1. **AI Behavior Guidelines**: `~/.claude/skills/_shared/references/ai-behavior-guidelines.md`
|
|
69
|
+
- Verifiability gatekeeping, structural quality gatekeeping, completeness gatekeeping
|
|
70
|
+
- Basic rules for all skills
|
|
71
|
+
|
|
72
|
+
2. **Code Implementation Prompt**: `references/code-implementation-prompt.md`
|
|
73
|
+
- Complete code implementation guide
|
|
74
|
+
- Execute strictly according to this prompt
|
|
75
|
+
|
|
76
|
+
### Read on Demand
|
|
77
|
+
|
|
78
|
+
3. **Test Execution Strategy**: `references/test-execution-strategy.md`
|
|
79
|
+
- Details on @smoke/@critical/@full tags
|
|
80
|
+
- Async vs. Sync boundaries
|
|
81
|
+
- *When to read*: When you need to understand the test execution strategy
|
|
82
|
+
|
|
83
|
+
4. **Completion Status and Routing**: `references/completion-status-and-routing.md`
|
|
84
|
+
- Completion status classification (MECE)
|
|
85
|
+
- Routing output templates
|
|
86
|
+
- *When to read*: When outputting status upon task completion
|
|
87
|
+
|
|
88
|
+
5. **Hotspot Awareness and Risk Assessment**: `references/hotspot-awareness-and-risk-assessment.md`
|
|
89
|
+
- Hotspot file warnings
|
|
90
|
+
- *When to read*: When risk assessment is needed
|
|
91
|
+
|
|
92
|
+
6. **Low Risk Modification Techniques**: `references/low-risk-modification-techniques.md`
|
|
93
|
+
- Safe refactoring techniques
|
|
94
|
+
- *When to read*: When refactoring is needed
|
|
95
|
+
|
|
96
|
+
7. **Coding Style Guidelines**: `references/coding-style-guidelines.md`
|
|
97
|
+
- Code style specifications
|
|
98
|
+
- *When to read*: When unsure about code style
|
|
99
|
+
|
|
100
|
+
8. **Logging Standard**: `references/logging-standard.md`
|
|
101
|
+
- Log levels and formats
|
|
102
|
+
- *When to read*: When logging needs to be added
|
|
103
|
+
|
|
104
|
+
9. **Error Code Standard**: `references/error-code-standard.md`
|
|
105
|
+
- Error code design
|
|
106
|
+
- *When to read*: When error codes need to be defined
|
|
107
|
+
|
|
108
|
+
---
|
|
109
|
+
|
|
110
|
+
## Core Workflow
|
|
111
|
+
|
|
112
|
+
### 1. Resume from Breakpoint
|
|
113
|
+
|
|
114
|
+
Before starting, you **must** execute:
|
|
115
|
+
|
|
116
|
+
1. **Read Progress**: Open `<change-root>/<change-id>/tasks.md`, identify checked `- [x]` tasks.
|
|
117
|
+
2. **Locate Resume Point**: Find the first `- [ ]` after the "last `[x]`".
|
|
118
|
+
3. **Output Confirmation**: Clearly inform the user of the current progress, for example:
|
|
119
|
+
```
|
|
120
|
+
Detected T1-T6 completed (6/10), resuming from T7.
|
|
121
|
+
```
|
|
122
|
+
|
|
123
|
+
### 2. Real-time Progress Updates
|
|
124
|
+
|
|
125
|
+
> **Core Principle**: Complete one task, check one box immediately. Do not wait until all are done to batch check.
|
|
126
|
+
|
|
127
|
+
**Check-off Timing**:
|
|
128
|
+
|
|
129
|
+
| Timing | Action |
|
|
130
|
+
|--------|--------|
|
|
131
|
+
| Code writing complete | Do not check yet |
|
|
132
|
+
| Compilation passes | Do not check yet |
|
|
133
|
+
| Relevant tests pass | **Check immediately** |
|
|
134
|
+
| Multiple tasks complete together | Check one by one, do not batch |
|
|
135
|
+
|
|
136
|
+
### 3. Implement Code
|
|
137
|
+
|
|
138
|
+
Execute strictly according to `references/code-implementation-prompt.md`.
|
|
139
|
+
|
|
140
|
+
### 4. Run Tests
|
|
141
|
+
|
|
142
|
+
```bash
|
|
143
|
+
# During development: run @smoke frequently
|
|
144
|
+
npm test -- --grep "@smoke"
|
|
145
|
+
|
|
146
|
+
# Before committing: run @critical
|
|
147
|
+
npm test -- --grep "@smoke|@critical"
|
|
148
|
+
|
|
149
|
+
# After commit: CI automatically runs @full (Coder does not wait)
|
|
150
|
+
git push # triggers CI
|
|
151
|
+
```
|
|
152
|
+
|
|
153
|
+
### 5. Output Completion Status
|
|
154
|
+
|
|
155
|
+
Refer to `references/completion-status-and-routing.md`.
|
|
156
|
+
|
|
157
|
+
---
|
|
158
|
+
|
|
159
|
+
## Key Constraints
|
|
160
|
+
|
|
161
|
+
### Role Boundaries
|
|
162
|
+
|
|
163
|
+
| Allowed | Prohibited |
|
|
164
|
+
|---------|------------|
|
|
165
|
+
| Modify `src/**` code | ❌ Modify `tests/**` |
|
|
166
|
+
| Check `tasks.md` items | ❌ Modify `verification.md` |
|
|
167
|
+
| Record deviations to `deviation-log.md` | ❌ Check AC coverage matrix |
|
|
168
|
+
| Run fast-track tests (`@smoke`/`@critical`) | ❌ Set verification.md Status to Verified/Done |
|
|
169
|
+
| Trigger `@full` tests (CI/Background) | ❌ Wait for @full completion (can start next change) |
|
|
170
|
+
|
|
171
|
+
### Code Quality Constraints
|
|
172
|
+
|
|
173
|
+
#### Forbidden Commit Patterns
|
|
174
|
+
|
|
175
|
+
| Pattern | Detection Command | Reason |
|
|
176
|
+
|---------|-------------------|--------|
|
|
177
|
+
| `test.only` | `rg '\.only\s*\(' src/` | Skips other tests |
|
|
178
|
+
| `console.log` | `rg 'console\.log' src/` | Debug code residue |
|
|
179
|
+
| `debugger` | `rg 'debugger' src/` | Debug breakpoint residue |
|
|
180
|
+
| `// TODO` without issue | `rg 'TODO(?!.*#\d+)' src/` | Untrackable todo |
|
|
181
|
+
| `any` type | `rg ': any[^a-z]' src/` | Type safety hole |
|
|
182
|
+
| `@ts-ignore` | `rg '@ts-ignore' src/` | Hides type errors |
|
|
183
|
+
|
|
184
|
+
#### Pre-commit Mandatory Checks
|
|
185
|
+
|
|
186
|
+
```bash
|
|
187
|
+
# 1. Compilation Check (Mandatory)
|
|
188
|
+
npm run compile || exit 1
|
|
189
|
+
|
|
190
|
+
# 2. Lint Check (Mandatory)
|
|
191
|
+
npm run lint || exit 1
|
|
192
|
+
|
|
193
|
+
# 3. Test Check (Mandatory)
|
|
194
|
+
npm test || exit 1
|
|
195
|
+
|
|
196
|
+
# 4. test.only Check (Mandatory)
|
|
197
|
+
if rg -l '\.only\s*\(' tests/ src/**/test/; then
|
|
198
|
+
echo "error: found .only() in tests" >&2
|
|
199
|
+
exit 1
|
|
200
|
+
fi
|
|
201
|
+
|
|
202
|
+
# 5. Debug Code Check (Mandatory)
|
|
203
|
+
if rg -l 'console\.(log|debug)|debugger' src/ --type ts; then
|
|
204
|
+
echo "error: found debug statements" >&2
|
|
205
|
+
exit 1
|
|
206
|
+
fi
|
|
207
|
+
```
|
|
208
|
+
|
|
209
|
+
---
|
|
210
|
+
|
|
211
|
+
## Output Management
|
|
212
|
+
|
|
213
|
+
Prevent large output from polluting context:
|
|
214
|
+
|
|
215
|
+
| Scenario | Handling Method |
|
|
216
|
+
|----------|-----------------|
|
|
217
|
+
| Command output > 50 lines | Keep only first/last 10 lines + middle summary |
|
|
218
|
+
| Test output | Extract key failure info, do not paste full log |
|
|
219
|
+
| Log output | Save to disk at `<change-root>/<change-id>/evidence/`, quote path only |
|
|
220
|
+
| Large file content | Quote path, do not inline |
|
|
221
|
+
|
|
222
|
+
---
|
|
223
|
+
|
|
224
|
+
## Evidence Path Convention
|
|
225
|
+
|
|
226
|
+
**Green evidence must be saved to**:
|
|
227
|
+
```
|
|
228
|
+
<change-root>/<change-id>/evidence/green-final/
|
|
229
|
+
```
|
|
230
|
+
|
|
231
|
+
**Correct Path Examples**:
|
|
232
|
+
```bash
|
|
233
|
+
# Dev-Playbooks default path
|
|
234
|
+
dev-playbooks/changes/<change-id>/evidence/green-final/test-$(date +%Y%m%d-%H%M%S).log
|
|
235
|
+
|
|
236
|
+
# Using script
|
|
237
|
+
devbooks change-evidence <change-id> --label green-final -- npm test
|
|
238
|
+
```
|
|
239
|
+
|
|
240
|
+
---
|
|
241
|
+
|
|
242
|
+
## Deviation Detection and Recording
|
|
243
|
+
|
|
244
|
+
**Reference**: `~/.claude/skills/_shared/references/deviation-detection-routing-protocol.md`
|
|
245
|
+
|
|
246
|
+
During implementation, you **must immediately** write the following situations to `deviation-log.md`:
|
|
247
|
+
|
|
248
|
+
| Situation | Type | Example |
|
|
249
|
+
|-----------|------|---------|
|
|
250
|
+
| Added feature not in tasks.md | NEW_FEATURE | Added warmup() method |
|
|
251
|
+
| Changed constraint in design.md | CONSTRAINT_CHANGE | Timeout changed to 60s |
|
|
252
|
+
| Found edge case not covered by design | DESIGN_GAP | Public interface inconsistent with design |
|
|
253
|
+
| API Signature Change | API_CHANGE | Argument added |
|
|
254
|
+
|
|
255
|
+
---
|
|
256
|
+
|
|
257
|
+
## Context Awareness
|
|
64
258
|
|
|
65
|
-
|
|
259
|
+
Detection rules refer to: `~/.claude/skills/_shared/context-detection-template.md`
|
|
66
260
|
|
|
67
|
-
|
|
68
|
-
2. Implement tasks with a minimal diff.
|
|
69
|
-
3. Run relevant gates; if any gate fails, fix implementation (not tests) and rerun.
|
|
70
|
-
4. Write logs to `evidence/green-final/` and reference them in your output.
|
|
71
|
-
5. Check off completed tasks; do not batch-check.
|
|
72
|
-
6. If you find gaps in design/spec/tasks, write them to `deviation-log.md` and hand off.
|
|
261
|
+
### Modes Supported by This Skill
|
|
73
262
|
|
|
74
|
-
|
|
263
|
+
| Mode | Trigger Condition | Behavior |
|
|
264
|
+
|------|-------------------|----------|
|
|
265
|
+
| **First Implementation** | tasks.md all `[ ]` | Start from MP1.1 |
|
|
266
|
+
| **Resume from Breakpoint** | tasks.md has some `[x]` | Continue from first `[ ]` after last `[x]` |
|
|
267
|
+
| **Gate Fix** | Test failures need fixing | Prioritize failed items |
|
|
75
268
|
|
|
76
|
-
|
|
77
|
-
- `~/.claude/skills/_shared/references/ai-behavior-guidelines.md`
|
|
78
|
-
- `references/code-implementation-prompt.md`
|
|
269
|
+
### Prerequisite Checks
|
|
79
270
|
|
|
80
|
-
|
|
81
|
-
- `
|
|
82
|
-
-
|
|
83
|
-
- `
|
|
84
|
-
- `references/low-risk-modification-techniques.md`
|
|
85
|
-
- `references/coding-style-guidelines.md`
|
|
86
|
-
- `references/logging-standard.md`
|
|
87
|
-
- `references/error-code-standard.md`
|
|
88
|
-
- `~/.claude/skills/_shared/references/deviation-detection-routing-protocol.md`
|
|
271
|
+
- [ ] `tasks.md` exists
|
|
272
|
+
- [ ] `verification.md` exists
|
|
273
|
+
- [ ] Test Owner not executed in current session
|
|
274
|
+
- [ ] `tests/**` has test files
|
|
@@ -0,0 +1,385 @@
|
|
|
1
|
+
# Convergence Audit Rules
|
|
2
|
+
|
|
3
|
+
## Core Principle: Anti-Confusion Design
|
|
4
|
+
|
|
5
|
+
> Golden Rule: Evidence > Declaration. Never trust assertions in documents; they must be confirmed by verifiable evidence.
|
|
6
|
+
|
|
7
|
+
### Scenes Where AI is Easily Confused (Must Prevent)
|
|
8
|
+
|
|
9
|
+
| Confusing Scene | AI Incorrect Behavior | Correct Behavior |
|
|
10
|
+
|-----------------|-----------------------|------------------|
|
|
11
|
+
| Doc says `Status: Done` | Believes it is done | Verify: Are tests really all green? Does evidence exist? |
|
|
12
|
+
| AC matrix all `[x]` | Believes full coverage | Verify: Does the test file for each AC exist and pass? |
|
|
13
|
+
| Doc says "Tests Passed" | Believes passed | Verify: Run actual tests or check CI log timestamps |
|
|
14
|
+
| `evidence/` dir exists | Believes evidence exists | Verify: Is dir non-empty? Is content valid test logs? |
|
|
15
|
+
| tasks.md all `[x]` | Believes implemented | Verify: Do corresponding code files exist with substance? |
|
|
16
|
+
| Commit msg "Fixed" | Believes fixed | Verify: Did relevant tests turn from red to green? |
|
|
17
|
+
|
|
18
|
+
### Anti-Confusion Three Principles
|
|
19
|
+
|
|
20
|
+
```
|
|
21
|
+
1. Distrust Declarations
|
|
22
|
+
- Any "Done/Passed/Covered" declaration in docs is a hypothesis to be verified
|
|
23
|
+
- Default stance: Declarations might be wrong, outdated, or optimistic
|
|
24
|
+
|
|
25
|
+
2. Evidence First
|
|
26
|
+
- Code/Test results are the only truth
|
|
27
|
+
- Log timestamps must be later than the last code modification
|
|
28
|
+
- Empty dir/file = No evidence
|
|
29
|
+
|
|
30
|
+
3. Cross Validation
|
|
31
|
+
- Declaration vs Evidence: Check for consistency
|
|
32
|
+
- Code vs Test: Check for matching
|
|
33
|
+
- Multiple Docs: Check for contradictions
|
|
34
|
+
```
|
|
35
|
+
|
|
36
|
+
---
|
|
37
|
+
|
|
38
|
+
## Verification Checklists (Execute Item by Item)
|
|
39
|
+
|
|
40
|
+
### Check 1: Status Field Truth Verification
|
|
41
|
+
|
|
42
|
+
Doc Declaration: `Status: Done` or `Status: Verified` in `verification.md`
|
|
43
|
+
|
|
44
|
+
Verification Steps:
|
|
45
|
+
```bash
|
|
46
|
+
# 1. Check if verification.md exists
|
|
47
|
+
[[ -f "verification.md" ]] || echo "❌ verification.md does not exist"
|
|
48
|
+
|
|
49
|
+
# 2. Check if evidence/green-final/ has content
|
|
50
|
+
if [[ -z "$(ls -A evidence/green-final/ 2>/dev/null)" ]]; then
|
|
51
|
+
echo "❌ Status claims Done, but evidence/green-final/ is empty"
|
|
52
|
+
fi
|
|
53
|
+
|
|
54
|
+
# 3. Check if evidence timestamp is later than code last modified
|
|
55
|
+
code_mtime=$(stat -f %m src/ 2>/dev/null || stat -c %Y src/)
|
|
56
|
+
evidence_mtime=$(stat -f %m evidence/green-final/* 2>/dev/null | sort -n | tail -1)
|
|
57
|
+
if [[ $evidence_mtime -lt $code_mtime ]]; then
|
|
58
|
+
echo "❌ Evidence time is earlier than code mod, evidence might be stale"
|
|
59
|
+
fi
|
|
60
|
+
```
|
|
61
|
+
|
|
62
|
+
Confusion Detection:
|
|
63
|
+
- ⚠️ Status=Done but evidence/ empty → Fake Completion
|
|
64
|
+
- ⚠️ Status=Done but evidence stale → Stale Evidence
|
|
65
|
+
- ⚠️ Status=Done but tests actually fail → False Status
|
|
66
|
+
|
|
67
|
+
---
|
|
68
|
+
|
|
69
|
+
### Check 2: AC Coverage Matrix Truth Verification
|
|
70
|
+
|
|
71
|
+
Doc Declaration: `[x]` in AC matrix means covered
|
|
72
|
+
|
|
73
|
+
Verification Steps:
|
|
74
|
+
```bash
|
|
75
|
+
# 1. Extract all ACs claimed to be covered
|
|
76
|
+
grep -E '^\| AC-[0-9]+.*[x]' verification.md | while read line; do
|
|
77
|
+
ac_id=$(echo "$line" | grep -oE 'AC-[0-9]+')
|
|
78
|
+
test_id=$(echo "$line" | grep -oE 'T-[0-9]+')
|
|
79
|
+
|
|
80
|
+
# 2. Verify corresponding test exists
|
|
81
|
+
if ! grep -rq "$test_id\|$ac_id" tests/; then
|
|
82
|
+
echo "❌ $ac_id claimed covered, but test not found"
|
|
83
|
+
fi
|
|
84
|
+
done
|
|
85
|
+
|
|
86
|
+
# 3. Actual test run verification (Most reliable)
|
|
87
|
+
npm test 2>&1 | tee /tmp/test-output.log
|
|
88
|
+
if grep -q "FAIL\|Error\|failed" /tmp/test-output.log; then
|
|
89
|
+
echo "❌ AC claimed full coverage, but tests actually failed"
|
|
90
|
+
fi
|
|
91
|
+
```
|
|
92
|
+
|
|
93
|
+
Confusion Detection:
|
|
94
|
+
- ⚠️ AC checked but test file missing → Fake Coverage
|
|
95
|
+
- ⚠️ AC checked but test failed → False Green
|
|
96
|
+
- ⚠️ AC checked but test content empty → Placeholder Test
|
|
97
|
+
|
|
98
|
+
---
|
|
99
|
+
|
|
100
|
+
### Check 3: tasks.md Completion Truth Verification
|
|
101
|
+
|
|
102
|
+
Doc Declaration: `[x]` in tasks.md means completed
|
|
103
|
+
|
|
104
|
+
Verification Steps:
|
|
105
|
+
```bash
|
|
106
|
+
# 1. Extract all claimed completed tasks
|
|
107
|
+
grep -E '^\- \[x\]' tasks.md | while read line; do
|
|
108
|
+
# 2. Extract keywords from task description (func name/file/feature)
|
|
109
|
+
keywords=$(echo "$line" | grep -oE '[A-Za-z]+[A-Za-z0-9]*' | head -5)
|
|
110
|
+
|
|
111
|
+
# 3. Verify implementation in code
|
|
112
|
+
for kw in $keywords; do
|
|
113
|
+
if ! grep -rq "$kw" src/; then
|
|
114
|
+
echo "⚠️ Task claimed done, but keyword not found in code: $kw"
|
|
115
|
+
fi
|
|
116
|
+
done
|
|
117
|
+
done
|
|
118
|
+
|
|
119
|
+
# 4. Check for "Skeleton Code" (signature only, no impl)
|
|
120
|
+
grep -rE 'throw new Error(.*not implemented|TODO|FIXME|pass$|\.\.\.}' src/ && \
|
|
121
|
+
echo "⚠️ Found unimplemented placeholder code"
|
|
122
|
+
```
|
|
123
|
+
|
|
124
|
+
Confusion Detection:
|
|
125
|
+
- ⚠️ Task checked but code missing → Fake Completion
|
|
126
|
+
- ⚠️ Task checked but placeholder code → Skeleton Code
|
|
127
|
+
- ⚠️ Task checked but feature unreachable → Dead Code
|
|
128
|
+
|
|
129
|
+
---
|
|
130
|
+
|
|
131
|
+
### Check 4: Evidence Validity Verification
|
|
132
|
+
|
|
133
|
+
Doc Declaration: `evidence/` dir contains test evidence
|
|
134
|
+
|
|
135
|
+
Verification Steps:
|
|
136
|
+
```bash
|
|
137
|
+
# 1. Check dir exists and non-empty
|
|
138
|
+
if [[ ! -d "evidence" ]] || [[ -z "$(ls -A evidence/)" ]]; then
|
|
139
|
+
echo "❌ evidence/ missing or empty"
|
|
140
|
+
exit 1
|
|
141
|
+
fi
|
|
142
|
+
|
|
143
|
+
# 2. Check evidence file has substantial content
|
|
144
|
+
for f in evidence/**/*; do
|
|
145
|
+
if [[ -f "$f" ]]; then
|
|
146
|
+
lines=$(wc -l < "$f")
|
|
147
|
+
if [[ $lines -lt 5 ]]; then
|
|
148
|
+
echo "⚠️ Evidence file too small: $f ($lines lines)"
|
|
149
|
+
fi
|
|
150
|
+
|
|
151
|
+
# 3. Check if valid test log (contains test framework output traits)
|
|
152
|
+
if ! grep -qE 'PASS|FAIL|✓|✗|passed|failed|test|spec' "$f"; then
|
|
153
|
+
echo "⚠️ Evidence file does not look like test log: $f"
|
|
154
|
+
fi
|
|
155
|
+
fi
|
|
156
|
+
done
|
|
157
|
+
|
|
158
|
+
# 4. Check red-baseline evidence is truly red (has failures)
|
|
159
|
+
if [[ -d "evidence/red-baseline" ]]; then
|
|
160
|
+
if ! grep -rqE 'FAIL|Error|✗|failed' evidence/red-baseline/; then
|
|
161
|
+
echo "❌ red-baseline claims red, but no failures found"
|
|
162
|
+
fi
|
|
163
|
+
fi
|
|
164
|
+
|
|
165
|
+
# 5. Check green-final evidence is truly green (all pass)
|
|
166
|
+
if [[ -d "evidence/green-final" ]]; then
|
|
167
|
+
if grep -rqE 'FAIL|Error|✗|failed' evidence/green-final/; then
|
|
168
|
+
echo "❌ green-final claims green, but contains failures"
|
|
169
|
+
fi
|
|
170
|
+
fi
|
|
171
|
+
```
|
|
172
|
+
|
|
173
|
+
Confusion Detection:
|
|
174
|
+
- ⚠️ evidence/ exists but empty → Empty Evidence
|
|
175
|
+
- ⚠️ Evidence file too small (< 5 lines) → Placeholder Evidence
|
|
176
|
+
- ⚠️ red-baseline no failures → Fake Red
|
|
177
|
+
- ⚠️ green-final has failures → Fake Green
|
|
178
|
+
|
|
179
|
+
---
|
|
180
|
+
|
|
181
|
+
### Check 5: Git History Cross-Validation
|
|
182
|
+
|
|
183
|
+
Principle: Git history doesn't lie, use it to verify doc declarations
|
|
184
|
+
|
|
185
|
+
Verification Steps:
|
|
186
|
+
```bash
|
|
187
|
+
# 1. Check if claimed completed change has corresponding commits
|
|
188
|
+
change_id="xxx"
|
|
189
|
+
commits=$(git log --oneline --all --grep="$change_id" | wc -l)
|
|
190
|
+
if [[ $commits -eq 0 ]]; then
|
|
191
|
+
echo "❌ Change $change_id claimed done, but no git commits found"
|
|
192
|
+
fi
|
|
193
|
+
|
|
194
|
+
# 2. Check if test files added after code (TDD violation)
|
|
195
|
+
for test_file in tests/**/*.test.*; do
|
|
196
|
+
test_added=$(git log --format=%at --follow -- "$test_file" | tail -1)
|
|
197
|
+
# Find corresponding src file
|
|
198
|
+
src_file=$(echo "$test_file" | sed 's/tests/src/' | sed 's/.test//')
|
|
199
|
+
if [[ -f "$src_file" ]]; then
|
|
200
|
+
src_added=$(git log --format=%at --follow -- "$src_file" | tail -1)
|
|
201
|
+
if [[ $test_added -gt $src_added ]]; then
|
|
202
|
+
echo "⚠️ Test added after code (Non-TDD): $test_file"
|
|
203
|
+
fi
|
|
204
|
+
fi
|
|
205
|
+
done
|
|
206
|
+
|
|
207
|
+
# 3. Check for "One-time Big Commit" (Process bypass)
|
|
208
|
+
git log --oneline -20 | while read line; do
|
|
209
|
+
commit=$(echo "$line" | cut -d' ' -f1)
|
|
210
|
+
files_changed=$(git show --stat "$commit" | grep -E '[0-9]+ file' | grep -oE '[0-9]+' | head -1)
|
|
211
|
+
if [[ $files_changed -gt 20 ]]; then
|
|
212
|
+
echo "⚠️ Big commit detected: $commit changed $files_changed files, possibly bypassing incremental verification"
|
|
213
|
+
fi
|
|
214
|
+
done
|
|
215
|
+
```
|
|
216
|
+
|
|
217
|
+
Confusion Detection:
|
|
218
|
+
- ⚠️ Claimed done but no git commit → Fake Change
|
|
219
|
+
- ⚠️ Test added after code → Post-hoc Testing
|
|
220
|
+
- ⚠️ Large file batch commit → Bypass Incremental Verification
|
|
221
|
+
|
|
222
|
+
---
|
|
223
|
+
|
|
224
|
+
### Check 6: Live Test Run Verification (Most Reliable)
|
|
225
|
+
|
|
226
|
+
Principle: Distrust logs, run actual tests
|
|
227
|
+
|
|
228
|
+
Verification Steps:
|
|
229
|
+
```bash
|
|
230
|
+
# 1. Run full tests
|
|
231
|
+
echo "=== Live Test Verification ==="
|
|
232
|
+
npm test 2>&1 | tee /tmp/live-test.log
|
|
233
|
+
|
|
234
|
+
# 2. Check results
|
|
235
|
+
if grep -qE 'FAIL|Error|failed' /tmp/live-test.log; then
|
|
236
|
+
echo "❌ Live test failed, doc declaration untrustworthy"
|
|
237
|
+
grep -E 'FAIL|Error|failed' /tmp/live-test.log
|
|
238
|
+
else
|
|
239
|
+
echo "✅ Live test passed"
|
|
240
|
+
fi
|
|
241
|
+
|
|
242
|
+
# 3. Compare live results with evidence file
|
|
243
|
+
if [[ -f "evidence/green-final/latest.log" ]]; then
|
|
244
|
+
live_pass=$(grep -c 'PASS|✓|passed' /tmp/live-test.log)
|
|
245
|
+
evidence_pass=$(grep -c 'PASS|✓|passed' evidence/green-final/latest.log)
|
|
246
|
+
if [[ $live_pass -ne $evidence_pass ]]; then
|
|
247
|
+
echo "⚠️ Live pass count ($live_pass) ≠ Evidence pass count ($evidence_pass)"
|
|
248
|
+
fi
|
|
249
|
+
fi
|
|
250
|
+
```
|
|
251
|
+
|
|
252
|
+
Confusion Detection:
|
|
253
|
+
- ⚠️ Evidence says green but live run fails → Stale Evidence/Fake Green
|
|
254
|
+
- ⚠️ Live pass count mismatch → Evidence Forgery/Env Diff
|
|
255
|
+
|
|
256
|
+
---
|
|
257
|
+
|
|
258
|
+
## Scoring Algorithm
|
|
259
|
+
|
|
260
|
+
### Trustworthiness Score (0-100)
|
|
261
|
+
|
|
262
|
+
```python
|
|
263
|
+
def calculate_trustworthiness(checks):
|
|
264
|
+
score = 100
|
|
265
|
+
|
|
266
|
+
# Critical Issues (-20 each)
|
|
267
|
+
critical = [
|
|
268
|
+
"Evidence empty",
|
|
269
|
+
"Live test failed",
|
|
270
|
+
"Status claims Done but test failed",
|
|
271
|
+
"green-final contains failures"
|
|
272
|
+
]
|
|
273
|
+
|
|
274
|
+
# Warnings (-10 each)
|
|
275
|
+
warnings = [
|
|
276
|
+
"Evidence stale",
|
|
277
|
+
"AC missing test",
|
|
278
|
+
"Placeholder code",
|
|
279
|
+
"Big commit detected"
|
|
280
|
+
]
|
|
281
|
+
|
|
282
|
+
# Minor Issues (-5 each)
|
|
283
|
+
minor = [
|
|
284
|
+
"Test added after code",
|
|
285
|
+
"Evidence file too small"
|
|
286
|
+
]
|
|
287
|
+
|
|
288
|
+
for issue in checks.critical_issues:
|
|
289
|
+
score -= 20
|
|
290
|
+
for issue in checks.warnings:
|
|
291
|
+
score -= 10
|
|
292
|
+
for issue in checks.minor_issues:
|
|
293
|
+
score -= 5
|
|
294
|
+
|
|
295
|
+
return max(0, score)
|
|
296
|
+
```
|
|
297
|
+
|
|
298
|
+
### Convergence Verdict
|
|
299
|
+
|
|
300
|
+
| Trustworthiness | Verdict | Recommendation |
|
|
301
|
+
|-----------------|---------|----------------|
|
|
302
|
+
| 90-100 | ✅ Trusted Converged | Continue process |
|
|
303
|
+
| 70-89 | ⚠️ Partially Trusted | Need supplementary verification |
|
|
304
|
+
| 50-69 | 🟠 Suspicious | Need rework on some parts |
|
|
305
|
+
| < 50 | 🔴 Untrusted | Sisyphus dilemma, needs full audit |
|
|
306
|
+
|
|
307
|
+
---
|
|
308
|
+
|
|
309
|
+
## Output Format
|
|
310
|
+
|
|
311
|
+
```markdown
|
|
312
|
+
# DevBooks Convergence Audit Report (Anti-Confusion Ed.)
|
|
313
|
+
|
|
314
|
+
## Audit Principles
|
|
315
|
+
Report adopts "Evidence First, Distrust Declarations" principle. All conclusions based on verifiable evidence, not doc assertions.
|
|
316
|
+
|
|
317
|
+
## Declaration vs Evidence Comparison
|
|
318
|
+
|
|
319
|
+
| Check Item | Doc Declaration | Actual Verification | Conclusion |
|
|
320
|
+
|------------|-----------------|---------------------|------------|
|
|
321
|
+
| Status | Done | Live test failed | ❌ Fake Completion |
|
|
322
|
+
| AC Coverage | 5/5 Checked | 2 ACs missing tests | ❌ Fake Coverage |
|
|
323
|
+
| Test Status | All Green | Live run 3 failed | ❌ Stale Evidence |
|
|
324
|
+
| tasks.md | 10/10 Done | 3 tasks code missing | ❌ Fake Completion |
|
|
325
|
+
| evidence/ | Exists | Dir non-empty, valid | ✅ Valid |
|
|
326
|
+
|
|
327
|
+
## Trustworthiness Score
|
|
328
|
+
|
|
329
|
+
**Total**: 45/100 🔴 Untrusted
|
|
330
|
+
|
|
331
|
+
**Deduction Detail**:
|
|
332
|
+
- -20: Status=Done but live test failed
|
|
333
|
+
- -20: AC claims full coverage but 2 missing tests
|
|
334
|
+
- -10: tasks.md 3 tasks missing code
|
|
335
|
+
- -5: Evidence timestamp earlier than code mod
|
|
336
|
+
|
|
337
|
+
## Confusion Detection Results
|
|
338
|
+
|
|
339
|
+
### 🔴 Detected Fake Completion
|
|
340
|
+
1. `change-auth`: Status=Done, but `npm test` failed 3
|
|
341
|
+
2. `fix-cache`: AC-003 Checked, but `tests/cache.test.ts` missing
|
|
342
|
+
|
|
343
|
+
### 🟡 Suspicious Items
|
|
344
|
+
1. `refactor-api`: evidence/green-final/ timestamp 2 days older than code
|
|
345
|
+
2. `feature-login`: tasks.md all checked, but `src/login.ts` contains TODO
|
|
346
|
+
|
|
347
|
+
## Real Status Verdict
|
|
348
|
+
|
|
349
|
+
| Change Pkg | Declared Status | Real Status | Gap |
|
|
350
|
+
|------------|-----------------|-------------|-----|
|
|
351
|
+
| change-auth | Done | Test Failed | 🔴 Critical |
|
|
352
|
+
| fix-cache | Verified | Incomplete Coverage | 🟠 Medium |
|
|
353
|
+
| refactor-api | Ready | Stale Evidence | 🟡 Minor |
|
|
354
|
+
|
|
355
|
+
## Recommended Actions
|
|
356
|
+
|
|
357
|
+
### Immediate Actions
|
|
358
|
+
1. Revert `change-auth` status to `In Progress`
|
|
359
|
+
2. Add tests for `fix-cache` AC-003
|
|
360
|
+
|
|
361
|
+
### Short-term Improvements
|
|
362
|
+
1. Establish evidence freshness check (Evidence must be newer than code)
|
|
363
|
+
2. Force run corresponding tests before checking AC
|
|
364
|
+
|
|
365
|
+
### Process Improvements
|
|
366
|
+
1. Ban manual Status modification; only update via script verification
|
|
367
|
+
2. CI integrate convergence check to block fake completion merge
|
|
368
|
+
```
|
|
369
|
+
|
|
370
|
+
---
|
|
371
|
+
|
|
372
|
+
## Completion Status
|
|
373
|
+
|
|
374
|
+
**Status**: ✅ AUDIT_COMPLETED
|
|
375
|
+
|
|
376
|
+
**Core Findings**:
|
|
377
|
+
- Doc Trustworthiness: X%
|
|
378
|
+
- Detected Fake Completions: N
|
|
379
|
+
- Changes needing rework: M
|
|
380
|
+
|
|
381
|
+
**Next Steps**:
|
|
382
|
+
- Fake Completion → Immediate status revert, re-verify
|
|
383
|
+
- Suspicious → Supplement evidence or re-run tests
|
|
384
|
+
- Trusted → Continue process
|
|
385
|
+
```
|
|
@@ -1,120 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: devbooks-design-backport
|
|
3
|
-
description: devbooks-design-backport: Backport newly discovered constraints, conflicts, or gaps from implementation back to design.md (keeping design as the golden truth), with annotated decisions and impacts. Use when the user says "backport design/update design doc/Design Backport/design-implementation mismatch/need to clarify constraints" etc.
|
|
4
|
-
allowed-tools:
|
|
5
|
-
- Glob
|
|
6
|
-
- Grep
|
|
7
|
-
- Read
|
|
8
|
-
- Write
|
|
9
|
-
- Edit
|
|
10
|
-
---
|
|
11
|
-
|
|
12
|
-
# DevBooks: Design Backport
|
|
13
|
-
|
|
14
|
-
## Workflow Position Awareness
|
|
15
|
-
|
|
16
|
-
> **Core Principle**: Design Backport is now **primarily auto-invoked by Archiver during archive phase**, users typically don't need to call it manually.
|
|
17
|
-
|
|
18
|
-
### My Position in the Overall Workflow
|
|
19
|
-
|
|
20
|
-
```
|
|
21
|
-
proposal → design → test-owner → coder → test-owner(verify) → code-review → [Archive/Spec Gardener]
|
|
22
|
-
↓ ↓
|
|
23
|
-
Record deviations to deviation-log.md Auto-invoke design-backport
|
|
24
|
-
```
|
|
25
|
-
|
|
26
|
-
### Design Decision: Auto Backport
|
|
27
|
-
|
|
28
|
-
**Old Flow** (manual judgment required):
|
|
29
|
-
```
|
|
30
|
-
coder has deviations → user manually calls design-backport → then archive
|
|
31
|
-
```
|
|
32
|
-
|
|
33
|
-
**New Flow** (auto handling):
|
|
34
|
-
```
|
|
35
|
-
coder has deviations → archiver auto-detects and backports during archive → archive
|
|
36
|
-
```
|
|
37
|
-
|
|
38
|
-
### When Manual Call is Still Needed
|
|
39
|
-
|
|
40
|
-
| Scenario | Need Manual Call? |
|
|
41
|
-
|----------|-------------------|
|
|
42
|
-
| Normal flow (deviations in deviation-log.md) | ❌ Auto-handled during archive |
|
|
43
|
-
| Need immediate backport (don't wait for archive) | ✅ Manual call |
|
|
44
|
-
| Severe design-implementation conflict needs decision | ✅ Manual call and discuss |
|
|
45
|
-
|
|
46
|
-
---
|
|
47
|
-
|
|
48
|
-
## Prerequisites: Configuration Discovery (Protocol-Agnostic)
|
|
49
|
-
|
|
50
|
-
- `<truth-root>`: Current truth directory root
|
|
51
|
-
- `<change-root>`: Change package directory root
|
|
52
|
-
|
|
53
|
-
Before execution, you **must** search for configuration in the following order (stop when found):
|
|
54
|
-
1. `.devbooks/config.yaml` (if exists) → Parse and use its mappings
|
|
55
|
-
2. `dev-playbooks/project.md` (if exists) → Dev-Playbooks protocol, use default mappings
|
|
56
|
-
3. `project.md` (if exists) → Template protocol, use default mappings
|
|
57
|
-
4. If still undetermined → **Stop and ask the user**
|
|
58
|
-
|
|
59
|
-
**Key Constraints**:
|
|
60
|
-
- If `agents_doc` (rules document) is specified in configuration, **you must read that document first** before executing any operations
|
|
61
|
-
- Do not guess directory roots
|
|
62
|
-
- Do not skip reading the rules document
|
|
63
|
-
|
|
64
|
-
## Execution Method
|
|
65
|
-
|
|
66
|
-
1) First read and follow: `~/.claude/skills/_shared/references/ai-behavior-guidelines.md` (verifiability + structural quality gating).
|
|
67
|
-
2) Strictly execute according to the complete prompt: `references/design-backport-prompt.md`.
|
|
68
|
-
|
|
69
|
-
---
|
|
70
|
-
|
|
71
|
-
## Context Awareness
|
|
72
|
-
|
|
73
|
-
This Skill automatically detects context before execution, identifying content that needs to be backported.
|
|
74
|
-
|
|
75
|
-
Detection rules reference: `skills/_shared/context-detection-template-context-detection.md`
|
|
76
|
-
|
|
77
|
-
### Detection Flow
|
|
78
|
-
|
|
79
|
-
1. Detect whether `design.md` exists
|
|
80
|
-
2. Detect whether new discoveries (conflicts/constraints/gaps) were found during implementation
|
|
81
|
-
3. Compare differences between design and implementation
|
|
82
|
-
|
|
83
|
-
### Modes Supported by This Skill
|
|
84
|
-
|
|
85
|
-
| Mode | Trigger Condition | Behavior |
|
|
86
|
-
|------|-------------------|----------|
|
|
87
|
-
| **Conflict Backport** | Design-implementation conflict detected | Record conflict points and resolutions |
|
|
88
|
-
| **Constraint Backport** | New implementation constraints discovered | Add constraint conditions to design |
|
|
89
|
-
| **Gap Backport** | Scenarios not covered by design detected | Add missing design decisions |
|
|
90
|
-
|
|
91
|
-
### Detection Output Example
|
|
92
|
-
|
|
93
|
-
```
|
|
94
|
-
Detection Results:
|
|
95
|
-
- design.md: Exists
|
|
96
|
-
- Discoveries: 2 new constraints, 1 design conflict
|
|
97
|
-
- Running Mode: Constraint Backport + Conflict Backport
|
|
98
|
-
```
|
|
99
|
-
|
|
100
|
-
---
|
|
101
|
-
|
|
102
|
-
|
|
103
|
-
## Progressive Disclosure
|
|
104
|
-
### Base (Required)
|
|
105
|
-
Goal: Clarify this Skill's core outputs and usage scope.
|
|
106
|
-
Inputs: User goals, existing documents, change package context, or project path.
|
|
107
|
-
Outputs: Executable artifacts, next-step guidance, or recorded paths.
|
|
108
|
-
Boundaries: Does not replace other roles; does not touch `tests/`.
|
|
109
|
-
Evidence: Reference output paths or execution records.
|
|
110
|
-
|
|
111
|
-
### Advanced (Optional)
|
|
112
|
-
Use when you need to refine strategy, boundaries, or risk notes.
|
|
113
|
-
|
|
114
|
-
### Extended (Optional)
|
|
115
|
-
Use when you need to coordinate with external systems or optional tools.
|
|
116
|
-
|
|
117
|
-
## Recommended MCP Capability Types
|
|
118
|
-
- Code search (code-search)
|
|
119
|
-
- Reference tracking (reference-tracking)
|
|
120
|
-
- Impact analysis (impact-analysis)
|
|
@@ -1,132 +0,0 @@
|
|
|
1
|
-
# Design Backport Prompt
|
|
2
|
-
|
|
3
|
-
> **Role**: You are the strongest mind in design evolution, combining the wisdom of Michael Nygard (architecture decision records), Martin Fowler (evolutionary design), and Kent Beck (incremental improvement). Your design sync must meet expert-level standards.
|
|
4
|
-
|
|
5
|
-
Highest directive (top priority):
|
|
6
|
-
- Before executing this prompt, read `~/.claude/skills/_shared/references/ai-behavior-guidelines.md` and follow all protocols within it.
|
|
7
|
-
|
|
8
|
-
# Prompt: Backport Design Docs When Implementation Plans Exceed Design Scope
|
|
9
|
-
|
|
10
|
-
> Use case: You discover new constraints/concepts/acceptance criteria in the implementation plan (tasks/plan) that are not covered in the design docs (design/spec), causing drift between "plan-driven implementation" and "design-driven acceptance."
|
|
11
|
-
|
|
12
|
-
Artifact locations (protocol agnostic):
|
|
13
|
-
- Design doc usually at: `<change-root>/<change-id>/design.md`
|
|
14
|
-
- Implementation plan usually at: `<change-root>/<change-id>/tasks.md`
|
|
15
|
-
- Spec delta usually at: `<change-root>/<change-id>/specs/<capability>/spec.md`
|
|
16
|
-
- Current truth at: `<truth-root>/` (do not backport by editing historical archives; update current truth with a new change package)
|
|
17
|
-
|
|
18
|
-
> Goal: Backport content that *should be part of design* into the design doc to reduce divergence in testing, implementation, and acceptance.
|
|
19
|
-
|
|
20
|
-
---
|
|
21
|
-
|
|
22
|
-
## What Can Be Backported to the Design Doc
|
|
23
|
-
|
|
24
|
-
Only backport plan items that meet at least one of the following (i.e., **Design-level**):
|
|
25
|
-
|
|
26
|
-
1. **External semantics or user-visible behavior**
|
|
27
|
-
|
|
28
|
-
- New/changed key user flows (explicit state machines, async sessions, cancellable/timeouts)
|
|
29
|
-
- External contracts (API input/output shapes, error semantics, required fields, compatibility windows)
|
|
30
|
-
|
|
31
|
-
2. **System-level invariants / red lines**
|
|
32
|
-
|
|
33
|
-
- Cost/resource limits (e.g., prohibit N^2 LLM calls, hard caps like `max_llm_calls`, budget-triggered degradation)
|
|
34
|
-
- Reliability/security red lines (e.g., multi-tenant isolation on by default, external untrusted boundaries, default isolation for injection)
|
|
35
|
-
|
|
36
|
-
3. **Core data contracts and evolution strategy**
|
|
37
|
-
|
|
38
|
-
- `schema_version`, required event envelope fields, idempotency key principles, compatibility strategy (DLQ/migration/replay)
|
|
39
|
-
- Minimum standards for what must be replayable/auditable/traceable
|
|
40
|
-
|
|
41
|
-
4. **Cross-cutting concerns**
|
|
42
|
-
|
|
43
|
-
- Observability metrics, SLO/KPI, alerting and operational strategies
|
|
44
|
-
- Lifecycle/retention policies (Valid/Quarantine/Garbage goals and rules)
|
|
45
|
-
- Gradual rollout/rollback paths and feature flags
|
|
46
|
-
|
|
47
|
-
5. **Key tradeoffs and decisions**
|
|
48
|
-
|
|
49
|
-
- Why choose A over B, alternatives, risks, fallback strategies
|
|
50
|
-
- New/changed Non-goals or Open Questions
|
|
51
|
-
|
|
52
|
-
---
|
|
53
|
-
|
|
54
|
-
## What Must NOT Be Backported
|
|
55
|
-
|
|
56
|
-
The following are **Implementation-level** and should not be written into design docs (unless promoted to formal design decisions):
|
|
57
|
-
|
|
58
|
-
- Specific file paths, class/function names, table/field names (unless they are stable architectural boundaries that must align)
|
|
59
|
-
- PR splitting advice, task execution order, temporary scripts/commands
|
|
60
|
-
- Over-detailed algorithm pseudocode (backport inputs/outputs/invariants/complexity limits/fallbacks instead of code)
|
|
61
|
-
- One-off implementation conveniences without long-term value or verification
|
|
62
|
-
|
|
63
|
-
---
|
|
64
|
-
|
|
65
|
-
## Conflict Resolution (Plan vs Design)
|
|
66
|
-
|
|
67
|
-
- **Design doc is the golden truth**: if plan conflicts with design, do not overwrite design with the plan.
|
|
68
|
-
- Two acceptable paths:
|
|
69
|
-
|
|
70
|
-
1) **Proposal-style backport**: write plan content into the design doc as "Proposed Design Change" and mark it as needing decision/confirmation;
|
|
71
|
-
|
|
72
|
-
2) **Defer**: mark plan items as `DEFERRED/UNSCOPED` until design is clarified.
|
|
73
|
-
|
|
74
|
-
- When backporting, explicitly label it as "new design decision/supplemental constraint" and explain reasons and impact scope.
|
|
75
|
-
|
|
76
|
-
---
|
|
77
|
-
|
|
78
|
-
## Output Requirements
|
|
79
|
-
|
|
80
|
-
1. **Diff checklist**: list "plan exceeds design" candidate items (group by plan ID), with classification: `Design-level / Implementation-level / Out-of-scope`.
|
|
81
|
-
|
|
82
|
-
2. **Design backport patch**: write all `Design-level` content back into the design doc with minimal edits, placed in the most appropriate sections (e.g., non-goals/design principles/risks & fallback/contracts/milestones/key decisions).
|
|
83
|
-
|
|
84
|
-
3. **Traceability updates**: for each backported design item, state acceptance method (A/B/C) and acceptance anchors, and require updates to:
|
|
85
|
-
- Traceability matrix (prefer updating `<change-root>/<change-id>/verification.md`; sync to `docs/` only if needed externally)
|
|
86
|
-
- Manual acceptance checklist (prefer updating `MANUAL-*` in `<change-root>/<change-id>/verification.md`; sync to `docs/` only if needed externally)
|
|
87
|
-
- If new/updated automation anchors are needed: list tests/static checks to add (tests/commands/markers)
|
|
88
|
-
|
|
89
|
-
---
|
|
90
|
-
|
|
91
|
-
## Ready-to-Copy Prompt
|
|
92
|
-
|
|
93
|
-
```text
|
|
94
|
-
You are the "Design Doc Editor." Your goal is to backport design-level content from the implementation plan into the design doc, making it traceable and verifiable.
|
|
95
|
-
|
|
96
|
-
Inputs:
|
|
97
|
-
|
|
98
|
-
- Design doc: `<change-root>/<change-id>/design.md` (or an equivalent path you provide)
|
|
99
|
-
- Implementation plan: `<change-root>/<change-id>/tasks.md` (or an equivalent path you provide)
|
|
100
|
-
|
|
101
|
-
Tasks:
|
|
102
|
-
|
|
103
|
-
1) Read the implementation plan and identify all items that are missing or under-specified in the design doc (group by section).
|
|
104
|
-
|
|
105
|
-
2) Classify each candidate item:
|
|
106
|
-
|
|
107
|
-
- Design-level (should be backported): impacts external semantics/user flows/system red lines/data contracts/evolution strategy/operations/governance/key decisions
|
|
108
|
-
- Implementation-level (do not backport): implementation details, file paths, PR splitting, execution order, pseudocode details
|
|
109
|
-
- Out-of-scope (do not backport and defer): not in scope or future phase not yet confirmed by design
|
|
110
|
-
|
|
111
|
-
3) For Design-level items only, backport into the design doc:
|
|
112
|
-
|
|
113
|
-
- Place in the most appropriate existing section; add small sections if needed, but do not restructure the whole doc
|
|
114
|
-
- Write in "design constraints/decisions" tone; avoid implementation detail
|
|
115
|
-
- If it conflicts with existing design: do not overwrite conclusions; add a "Proposed Design Change/Open Question" with reason, impact, and decision points
|
|
116
|
-
- Update the design doc's "last updated" metadata (if present)
|
|
117
|
-
|
|
118
|
-
4) Output:
|
|
119
|
-
|
|
120
|
-
- A) Candidate list with classifications (by plan ID)
|
|
121
|
-
- B) Minimal patch to the design doc (only added/modified paragraphs)
|
|
122
|
-
- C) Traceability and anchor updates (prioritized):
|
|
123
|
-
- Which tests/static checks to add/update (A-class anchors)
|
|
124
|
-
- Which manual/hybrid acceptance items to add/update (B/C anchors, prefer `<change-root>/<change-id>/verification.md`)
|
|
125
|
-
- How to update the traceability matrix (prefer `<change-root>/<change-id>/verification.md`)
|
|
126
|
-
|
|
127
|
-
Constraints:
|
|
128
|
-
|
|
129
|
-
- Do not write file paths, class/function names, DB table names, or other implementation details into the design doc unless they are stable architectural boundaries.
|
|
130
|
-
- Do not paste large pseudocode blocks; you may state invariants, complexity limits, and fallback strategies.
|
|
131
|
-
- Keep language consistent with the design doc (English by default; include domain terms if needed).
|
|
132
|
-
```
|
|
@@ -1,43 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: devbooks-docs-sync
|
|
3
|
-
description: devbooks-docs-sync: Deprecated alias. Use devbooks-docs-consistency for documentation consistency checks.
|
|
4
|
-
allowed-tools:
|
|
5
|
-
- Glob
|
|
6
|
-
- Grep
|
|
7
|
-
- Read
|
|
8
|
-
- Edit
|
|
9
|
-
- Write
|
|
10
|
-
- Bash
|
|
11
|
-
---
|
|
12
|
-
|
|
13
|
-
# DevBooks: Docs Sync (Deprecated Alias)
|
|
14
|
-
|
|
15
|
-
## Progressive Disclosure
|
|
16
|
-
|
|
17
|
-
### Base (Required)
|
|
18
|
-
Goal: Route to `devbooks-docs-consistency`.
|
|
19
|
-
Inputs: user request and project/change context.
|
|
20
|
-
Outputs: deprecation notice + next step.
|
|
21
|
-
Boundaries: this alias should not add new behavior.
|
|
22
|
-
Evidence: reference the target skill path.
|
|
23
|
-
|
|
24
|
-
### Advanced (Optional)
|
|
25
|
-
Use when you need: compatibility notes for existing automation.
|
|
26
|
-
|
|
27
|
-
### Extended (Optional)
|
|
28
|
-
Use when you need: faster search/impact via optional MCP capabilities.
|
|
29
|
-
|
|
30
|
-
## Recommended MCP Capability Types
|
|
31
|
-
- Code search (code-search)
|
|
32
|
-
- Reference tracking (reference-tracking)
|
|
33
|
-
- Impact analysis (impact-analysis)
|
|
34
|
-
|
|
35
|
-
## Deprecation
|
|
36
|
-
|
|
37
|
-
- Old name: `devbooks-docs-sync`
|
|
38
|
-
- Current name: `devbooks-docs-consistency`
|
|
39
|
-
- Use `skills/devbooks-docs-consistency/SKILL.md`
|
|
40
|
-
|
|
41
|
-
## Next
|
|
42
|
-
|
|
43
|
-
Run `devbooks-docs-consistency` for the same context (change-scoped or global).
|