@rasensio/aidlc-content 1.47.0 → 1.48.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/package.json +1 -1
- package/skills/20-requirements.md +3 -1
- package/skills/30-design.md +3 -0
package/package.json
CHANGED
|
@@ -27,6 +27,7 @@ Read only:
|
|
|
27
27
|
ideation artifact as input
|
|
28
28
|
- the always-read guidance layers named in `.aidlc/guidance/index.yaml` (see **The always-read rule** (`.aidlc/resources/rules/always-read.md`))
|
|
29
29
|
- `.aidlc/context/constitution.md`, when it exists
|
|
30
|
+
- the spec corpus files in `.aidlc/specs/` for the capabilities the change touches — `aidlc spec show` lists them
|
|
30
31
|
|
|
31
32
|
Not the ideation *conversation* — the artifact is what it was written for.
|
|
32
33
|
See **The context rule** (`.aidlc/resources/rules/context.md`).
|
|
@@ -55,7 +56,8 @@ See **The context rule** (`.aidlc/resources/rules/context.md`).
|
|
|
55
56
|
A criterion that is not a behaviour — a performance budget, a docs change, a file that must exist — stays a plain sentence. A plain criterion is valid: the gate checks the ID, never the shape.
|
|
56
57
|
4. **Set scope boundaries.** Explicitly state what is NOT included.
|
|
57
58
|
5. **Non-functional requirements.** Address performance, security, accessibility, and compatibility where relevant.
|
|
58
|
-
6. **
|
|
59
|
+
6. **Write the change as a spec delta.** `.aidlc/specs/<capability>.md` says what the system does today. Read the files your change touches, then end `requirements.md` with a `## Spec delta` section: one `### ADDED <capability>: <requirement name>`, `### MODIFIED …` or `### REMOVED …` block per change. ADDED and MODIFIED blocks hold the requirement's full new text, written as what the system does. MODIFIED and REMOVED blocks start with `Base: <revision>`, copied from `aidlc spec show <capability>`. Capabilities are lowercase kebab-case names; a new one is created by its first ADDED block. Run `aidlc spec fold <instance> --dry-run` before the phase closes — it reports every error and conflict, and the same fold runs at completion, where a conflict blocks it. Skip the section when the change alters no lasting behaviour, as most bugfixes do not.
|
|
60
|
+
7. **For open decisions**: When a decision would change what `requirements.md` says, ask it through the **Question Protocol** (`.aidlc/resources/rules/question-protocol.md`) — questions for this phase go to `.aidlc/state/<instance>/requirements-questions.md`. Prefer drafting `requirements.md` early with the unresolved points marked as explicit decision blocks: users decide better reacting to a concrete draft than answering abstract questions. Fold each answer into the draft and leave the question file as the record of what was decided and why.
|
|
59
61
|
|
|
60
62
|
## Bugfix Reproduction (bugfix template)
|
|
61
63
|
|
package/skills/30-design.md
CHANGED
|
@@ -26,6 +26,9 @@ Read only:
|
|
|
26
26
|
- the always-read guidance layers named in `.aidlc/guidance/index.yaml` (see **The always-read rule** (`.aidlc/resources/rules/always-read.md`))
|
|
27
27
|
- `.aidlc/context/architecture.md` and `style-guide.md`
|
|
28
28
|
- `.aidlc/context/constitution.md`, when it exists
|
|
29
|
+
- the spec corpus files in `.aidlc/specs/` named by `requirements.md`'s `## Spec delta` section —
|
|
30
|
+
the current spec, which is what the design is built against. Not a past instance's
|
|
31
|
+
`requirements.md`: it describes a change, and later instances may have changed it again.
|
|
29
32
|
|
|
30
33
|
The seams the requirements touch are then read from the *source*, as step 3 of the
|
|
31
34
|
instructions says — a handful of files, not a survey, and not the previous phase's
|