@rasensio/aidlc-content 1.40.2 → 1.41.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rasensio/aidlc-content",
-  "version": "1.40.2",
+  "version": "1.41.0",
   "type": "module",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",

package/skills/20-requirements.md

@@ -46,22 +46,33 @@ See **The context rule** (`.aidlc/resources/rules/context.md`).
    - Testable (an observable outcome)
    - Independent (not relying on unstated assumptions)
    - **Identified**: write every criterion as a list item `- AC-<n>: <text>` (bold variants `- **AC-<n>**: ...` and `- **AC-<n>:** ...` are also valid). Assign `AC-1`, `AC-2`, ... sequentially. IDs are never renumbered or reused — an amended criterion keeps its meaning or is retired: mark it `- AC-<n> (retired YYYY-MM-DD, superseded by AC-<m>): <text>` and issue a new ID. The testing-phase gate parses these IDs and fails on any active criterion without a referencing test.
+   - **Shaped**, when the criterion is a behaviour. Write the text after the colon in one of four shapes, each naming its own test — the condition to set up and the response to check:
+     - Event — `- AC-1: WHEN the user presses Save, THE SYSTEM SHALL write the draft to disk`
+     - State — `- AC-2: WHILE the draft is unsaved, THE SYSTEM SHALL show a dot in the tab`
+     - Unwanted — `- AC-3: IF the disk is full, THEN THE SYSTEM SHALL keep the draft in memory and say so`
+     - Optional — `- AC-4: WHERE autosave is on, THE SYSTEM SHALL save the draft every 30 seconds`
+
+     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.
 4. **Set scope boundaries.** Explicitly state what is NOT included.
 5. **Non-functional requirements.** Address performance, security, accessibility, and compatibility where relevant.
 6. **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.
 
 ## Bugfix Reproduction (bugfix template)
 
-When the instance uses the `bugfix` template, this phase produces `reproduction.md` instead of full requirements:
+When the instance uses the `bugfix` template, this phase produces `reproduction.md` and a bugfix-shaped `requirements.md`:
 
 1. **Reproduce first.** Capture: observed behavior, expected behavior, minimal reproduction steps, affected versions/environment. A bug that cannot be reproduced gets documented as such — with the evidence tried — before any fix work.
 2. **Acceptance criteria** for the fix follow the same `AC-<n>` ID rules as regular requirements (the reproduction steps typically become the test).
-3. **Propose defect linkage (`caused_by`).** Identify which instance(s) likely introduced the defect:
+3. **Write `requirements.md` in three sections, in this order.** The testing gate reads criteria from `requirements.md` only, so they go here, not in `reproduction.md`:
+   - **Current behaviour** — what happens today. Description only; no IDs.
+   - **Expected behaviour** — what the fix makes happen. Each line an `AC-<n>` criterion.
+   - **Unchanged behaviour** — what works next to the fix today and must still work after it. Each line an `AC-<n>` criterion, so the gate demands a test for it. If you find nothing, write "None found" and say why; never leave the section out.
+4. **Propose defect linkage (`caused_by`).** Identify which instance(s) likely introduced the defect:
    - `git blame` the defective lines and match commits to instance branches (`fix|feat|chore/<YYYYMMDD>-<name>`)
    - Query the knowledge graph for the module's history
    - Check instance state dirs and the registry for names
    Present the candidates *as guesses* with the evidence. The user confirms, edits, or declines — `caused_by` is **never written without explicit user confirmation**, and declining leaves the field absent (absent = unknown, never an error).
-4. **Write the confirmed linkage** to `instance.yaml` as a list: `caused_by: [<instance>, ...]` (single cause = one-element list). Validate every name against existing state dirs or registry entries — an unknown name needs re-confirmation; reject the bugfix's own name (no self-reference).
+5. **Write the confirmed linkage** to `instance.yaml` as a list: `caused_by: [<instance>, ...]` (single cause = one-element list). Validate every name against existing state dirs or registry entries — an unknown name needs re-confirmation; reject the bugfix's own name (no self-reference).
 
 ## Exit Criteria
 

package/skills/50-testing.md

@@ -47,6 +47,8 @@ See **The context rule** (`.aidlc/resources/rules/context.md`).
    - Integration tests for component interactions
    - Property-based tests where inputs have broad domains
    - **Reference AC IDs.** When `requirements.md` defines `AC-n` criteria, each test names the criteria it verifies — in the test name or a comment (e.g. `// AC-3`). The testing-phase gate scans test files for these references and fails on any active criterion with none. If two instances define the same ID, qualify the reference as `<instance>/AC-n`.
+   - **Test the shape.** A `WHEN`/`WHILE`/`IF`/`WHERE` criterion names its own test: set up the condition, assert the `SHALL` response. An `IF` criterion is tested by causing the unwanted condition, not by the happy path.
+   - **Unchanged behaviour (bugfix).** Each criterion in that section of `requirements.md` gets a test that passes before the fix and after it. Run it once against the unfixed code to see it pass.
 3. **Run tests.** Execute the project's test suite. All new tests must pass.
 4. **Document results.** Write the phase's required artifact (see Required Artifacts above) with:
    - Test plan (what was tested and why)