@rasensio/aidlc-content 1.81.0 → 1.83.0

package/docs/index.yaml

@@ -42,7 +42,7 @@ entries:
     title: The lifecycle
     file: lifecycle.md
     source: packages/cli/src/core
-    commands: [init, start, continue, status, transition, gate, menu, amend, templates, spec, cross-check, revert]
+    commands: [init, start, continue, status, transition, gate, menu, amend, templates, spec, cross-check, revert, verify]
 
   - id: state-and-concurrency
     kind: topic

package/docs/knowledge-graph.md

@@ -33,6 +33,17 @@ aidlc knowledge context --scope phase --phase design
 `discover` scans a codebase and seeds the graph — that is how a brownfield project starts. After that,
 record findings as you make them rather than at the end.
 
+**Re-running `discover` only fills gaps.** It replaces a description only when it is empty or still
+one that discovery itself wrote, and never changes an entity's name, source, author, confidence or
+tags. A module it finds is written into the existing entry with the same name or source path, not
+added under a second id; when two entries match, it writes nothing for that module and prints a
+warning naming them. A fact that did not change is not rewritten, so a re-run on an unchanged repo
+leaves an empty diff. The reason is this repo's own graph: a second run replaced a seven-line
+hand-written description with "Module at packages/cli/src/core/ (has index)", added 14 thin copies of
+modules already written up under other ids, and touched about 100 files. Discovery and
+`knowledge add` now take separate paths for this reason — a person adding a description means to
+replace the old one, and discovery never does.
+
 To add several entities at once, pipe YAML documents (separated by `---`) to
 `aidlc knowledge add --stdin`. A `tags:` string there means what `--tags` means: comma-separated.
 **Every document is checked before any is written**, and a run that fails writes nothing. That rule

package/docs/lifecycle.md

@@ -71,7 +71,7 @@ instance, phase and artifact names filled in. When the `CI` environment variable
 words that block for a pipeline and names no command that changes lifecycle state. `--json` output
 carries no such block.
 
-Two gates are worth knowing because they block real work:
+Two gates are worth knowing because they block real work (three, in verified mode):
 
 - The **traceability gate** requires every active acceptance criterion in `requirements.md` to be
   referenced by some test. Criteria are written `- AC-1: <text>`, and tests refer to them as
@@ -85,6 +85,18 @@ Two gates are worth knowing because they block real work:
 - The **ownership gate** checks that the session transitioning a phase is the one that claimed it.
   This one has an override, and the honest observation from the retrospectives is that having the
   override meant it got waved through by reflex on every phase.
+- The **receipt gate** exists because `test-results.md` is written by the agent, and nothing ran the
+  tests to check it. Opt in with `assurance: { default: verified }` and a person-chosen
+  `verify: { command: pnpm test }` in `.aidlc/config.yaml`. `aidlc verify <instance>` then runs that
+  command and writes `receipt.json` — the commit, whether the tree was dirty, hashes of the command
+  and its output (never the output itself), the exit code and the duration. Leaving testing needs a
+  receipt that passed, on a clean tree, for the current command, with nothing outside the
+  instance's state directory changed since; the instance's own files may change, so committing the
+  receipt does not make it stale. Transitions only read the receipt and never run the suite. In CI,
+  `aidlc gate <instance> testing --verify` reuses a matching receipt or runs the command itself — a
+  checkout on a merge ref never matches, so expect the re-run there. Without the `assurance` key
+  nothing changes. The receipt is not tamper-proof yet: an agent could still write the file by hand
+  until a guard on that lands.
 
 Bare `aidlc`, or `aidlc menu`, opens the console if you would rather not remember the commands:
 `/help` lists them, `/doctor` runs one, plain words go to your agent, and autopilot changes print

package/package.json

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

package/skills/50-testing.md

@@ -52,6 +52,7 @@ See **The context rule** (`.aidlc/resources/rules/context.md`).
    - **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.
+   - **Verified mode.** When `.aidlc/config.yaml` sets `assurance: { default: verified }`, the testing gate accepts only a receipt the CLI wrote. Commit the code under test, then run `aidlc verify <instance>`: it runs `verify.command` and writes `receipt.json` in the instance state directory. The gate refuses a receipt that failed, was taken with uncommitted changes, ran a different command, or predates a later change outside the instance state directory — re-run `aidlc verify` after any such change. Never write or edit `receipt.json` yourself, and never change `verify.command`; a person sets it.
 4. **Document results.** Write the phase's required artifact (see Required Artifacts above) with:
    - Test plan (what was tested and why)
    - Results (pass/fail counts, any notable findings)