@rasensio/aidlc-content 1.82.0 → 1.84.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/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/docs/roadmap.md

@@ -224,6 +224,14 @@ Each item goes through these steps:
    so there is something to carry it on after you approve.
 4. **PR and CI.** Autopilot pushes the branch and opens the pull request. Green checks queue it;
    a failure relaunches the agent once with the failing checks, and a second failure parks the item.
+   **A job that never ran its tests is not a failure.** Before counting one, autopilot reads the
+   failing checks' Actions jobs; a check counts only when a step in its job concluded `failure`.
+   A job no runner took (no steps) or whose runner went away mid-job (steps `cancelled`, then
+   `skipped`) spends no try and launches no agent: autopilot re-runs it once, and if it still never
+   runs, the item waits as `CI untested`, says the runner is the problem, and notifies you once.
+   Re-run the job when a runner is back and autopilot carries on. Counting these cost two items a
+   CI try each on 2026-10-10, and parked one, for tests that never ran. A check whose job cannot
+   be read counts as before, so this can only ever remove a false failure.
 5. **Your merge, where the stop is the pull request** (the default). Green CI leaves the item as
    `awaiting-merge` and autopilot neither merges nor releases. When you merge, it closes the instance
    out on main — pull, mark the deployment record complete, `aidlc transition`, commit, push — and

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rasensio/aidlc-content",
-  "version": "1.82.0",
+  "version": "1.84.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)