scaffold-agent-specs 0.1.3 → 0.1.4

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.
@@ -35,7 +35,8 @@
35
35
  "70196e937a5782962f69c2c0735929059fac6c60b724977ebbfea9d0e4c84b20",
36
36
  "c08f3412d558b6992b0a2e003d5be0de201502846453c2b2da70c2d682d5815a",
37
37
  "bc70d6dee9f3f76affb0636ff804a112885b0973aaa2753ac970fc83d0260b5e",
38
- "a09404a3dce7e2c1f7aa0efce59c5b075943ad768a02b62dc51e08e44a050318"
38
+ "a09404a3dce7e2c1f7aa0efce59c5b075943ad768a02b62dc51e08e44a050318",
39
+ "53776f37c6f55ece45c4b4d32d2a48749031c90e77047d9a730c3f150af0d79f"
39
40
  ],
40
41
  "CLAUDE.md": [
41
42
  "272bcb5a9f136af56c1c93203c21976e02a09ed0a59d2515fad23d24b6c34408"
@@ -43,7 +44,8 @@
43
44
  "docs/WORKFLOW.md": [
44
45
  "0712abf011e6632fcdaee95c9b0c7bcad39808b5d28678c25aa0c05d281f795f",
45
46
  "637e83ce425e97ee9751a8500f5928d1f1ed2536e8d1a02b85bf6e11bc937192",
46
- "9dd7762484311d7a2a59620d4e89c61e4eb68688d9ebe1b3e2f2ac6d114373fd"
47
+ "9dd7762484311d7a2a59620d4e89c61e4eb68688d9ebe1b3e2f2ac6d114373fd",
48
+ "049b5a682f613a0bb2dab7bd39e79645860eb30202d358ed9a879dbe238e84bc"
47
49
  ],
48
50
  "docs/adr/README.md": [
49
51
  "2f27a4a5ecfb92725875c0b859194588b0ed367ac87b7d321ba063062abf25d5"
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "scaffold-agent-specs",
3
- "version": "0.1.3",
3
+ "version": "0.1.4",
4
4
  "description": "A tiny, spec-driven workflow scaffold for AI coding agents",
5
5
  "type": "module",
6
6
  "license": "MIT",
@@ -50,7 +50,7 @@ Existing-feature work and ordinary fixes should follow the user's requested scop
50
50
  - Do not write speculative ADRs during feature discovery or initial specification. Capture proposed approaches and uncertainties in `PLAN.md` instead.
51
51
  - Keep docs concise and accurate; remove stale claims rather than merely appending new text.
52
52
  - Practice **progressive documentation**: create an optional document only to solve a concrete problem. Prefer updating an existing source of truth over producing redundant or empty files.
53
- - If maintained, keep `docs/ARCHITECTURE.md` aligned with the _implemented_ system, `docs/GLOSSARY.md` aligned with shared domain language, and `docs/conventions/` aligned with stable project-specific practices. Create them only when useful, from `.agent-specs/templates/project/` or `.agent-specs/templates/conventions/`. An adopted architecture decision still belongs in an ADR.
53
+ - If maintained, keep `docs/ARCHITECTURE.md` aligned with the _implemented_ system, `docs/GLOSSARY.md` aligned with shared domain language, and `docs/conventions/` aligned with stable project-specific practices. Create them only when useful, from `.agent-specs/templates/project/` or `.agent-specs/templates/conventions/`. When closing a feature, check whether one has become useful and propose it to the user (see [`docs/WORKFLOW.md`](docs/WORKFLOW.md), Phase 5). An adopted architecture decision still belongs in an ADR.
54
54
 
55
55
  ## Verification and completion
56
56
 
@@ -68,6 +68,7 @@ Write the approved scope into `PLAN.md`. Draft acceptance criteria and tasks tha
68
68
  - Review each acceptance criterion against observable evidence. Use `Pass`, `Fail`, `Blocked`, or `Not run`; never invent a result. If a criterion is waived or removed, record the user's approval and update scope accordingly.
69
69
  - Run applicable checks and document anything not run.
70
70
  - Update affected user/developer/project documentation in the same change. Maintain `docs/ARCHITECTURE.md`, `docs/GLOSSARY.md`, and `docs/conventions/` when they exist and are affected by the change.
71
+ - Check whether a missing project document has become useful. If this feature relied on a rule that earlier features also relied on and that the code doesn't make obvious (one whose violation would be a silent bug), propose recording it in `docs/conventions/`. If domain terms are now used across several features, propose `docs/GLOSSARY.md`. Propose rather than create, and include the proposal in your report.
71
72
  - Create ADRs for meaningful architectural decisions **actually adopted**. Normally do this after the implementation is known; for a consequential choice adopted earlier, record it at that point.
72
73
  - Report what shipped, what was validated, any limitations, and whether the feature is complete. A feature is not complete while required acceptance criteria remain failing, blocked, or unverified.
73
74
  - Set the `TASKS.md` status to `Complete` only when that holds; otherwise use `Implemented (verification pending)` and list what remains.