pi-aia-asf 0.9.1 → 0.10.0

package/CHANGELOG.md

@@ -7,11 +7,106 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
-## [0.9.1] - 2026-10-03
+## [0.10.0] - 2026-10-07
+
+### Added
+
+- (describe changes for 0.10.0)
+
 
 ### Added
 
-- (describe changes for 0.9.1)
+- **06b Rule 19 — test selection for the inner loop (P25)**. Rule 10's
+  "full test suite green (not a subset)" is a **gate**, and it stays exactly
+  where it is: the run before a commit is always the full suite. What Rule 19
+  relaxes is only the **intermediate red-green-refactor runs inside a single
+  change** — the runs on code you are still editing. The rule is the user's
+  own: **run a partial, impact-area subset only when certain that is
+  warranted; if not certain, or the blast radius *might* be larger, always run
+  full. Default is full** — so the burden of proof sits on the subset, and the
+  cheap direction to be wrong in is also the safe one.
+- **"Certain" is evidence, not a feeling.** A subset run must be preceded by a
+  stated **impact statement** — changed files, tests selected, and *why nothing
+  else can be reached*. Restating the file list does not qualify; no statement
+  means not certain, which means full. On top of that, a **mechanical
+  disqualifier list** removes judgment wherever "might be bigger" is the
+  honest answer: shared/global state, dependencies and lockfile, build/test/CI
+  config or the harness itself, schema/migrations/shared fixtures, public
+  contracts and shared types, cross-module refactor/rename/move/delete — and
+  **any changed file with no entry in the test-impact map**, so a project that
+  has not built a map always runs full. The relaxation only ever applies where
+  the mapping is known, never where it is guessed.
+- **Deliberately not built**: the drafted coin toss and `iteration % N`
+  counter are gone. An LLM cannot roll a dice — asked to flip one it picks the
+  answer that skips the slow run — and an undefined iteration boundary means
+  the trigger silently never fires. A subset streak also cannot survive a
+  commit, because every commit is full-gated. Below a measured ~90s full-suite
+  runtime the assessment is skipped entirely and the suite is just run.
+- **Wired in**: `06b-testing-qa.md` Rule 10's checkbox now says in place that
+  the gate never moves; `06-implementation.md` test-first steps 3 and 4 name
+  the loop/gate split; `SKILL.md` gains two anti-patterns (a subset run with no
+  impact statement, and a subset run passed off as the Rule 10 checkbox) and
+  the index count moves to 19 rules. Covered by
+  `test/test-test-selection.mjs` (26 assertions), which includes a regression
+  guard that **fails if the coin-toss or iteration-counter design ever returns**.
+
+## [0.9.2] - 2026-10-04
+
+### Added
+
+- **`references/06i-completeness.md` — the completeness standard (P24, mandatory)**.
+  Newer models increasingly ship work that *looks* finished: a function whose body is
+  a placeholder, a screen populated with invented records, a report citing a limit
+  nobody checked. Green tests do not catch it — the tests get written against the
+  stub, so the fake looks verified. The reference states the core rule (**ship the
+  real thing, or say out loud what is not real**), the banned patterns (`TODO` /
+  `not implemented` / `coming soon` on a user-reachable path, fake or seed data the
+  user reads as their own, invented facts stated as checked, silently deferred scope,
+  built-but-never-wired, mocks in production paths, config nothing sets), the
+  exceptions that must be **declared, never silent** (the user asked for a scaffold,
+  an approved deferral, a fake at a test seam), how to prove it is real (exercise each
+  part through the entry point the user will use and name that action in the delivery
+  report), and a completeness DoD.
+- **Wired in, not bolted on**: Phase 6 gains a mandatory read block and discipline
+  rule 11; Phase 7 gains the completeness DoD check; the anti-pattern list gains six
+  entries (stub wearing a name, fake data the user reads as their own, invented facts
+  stated as fact, quietly deferred scope, stub presented as complete because its own
+  tests pass, unexplained deliberate stub); the reference index marks 06i as always
+  read. Proportionality holds — small work reads only the core rule and the DoD.
+
+### Requires
+
+- The enforcement side lives in **pi-vigilant 0.6.2**, which scans the files a
+  session changed for stub / fabricated-data / fact-hole markers at final
+  verification and puts the `file:line` evidence in front of the agent. The rule and
+  the check are the same proposal: the agent must finish the work or state the
+  discrepancy.
+
+
+## [0.9.1] - 2026-10-03
+
+### Fixed
+
+- **Extension no longer loads on pi >= 1.0** — pi 1.0 changed the command
+  contract to `registerCommand(name, { description, handler })`, where
+  `handler(args: string, ctx)` returns void and user-visible output goes
+  through `ctx.ui.notify()`. `/asf` and `/asf-approve` were registered as bare
+  functions taking `(args: string[], ctx)` and returning their text, so pi
+  1.0.1 refused to load the package at all:
+  `Command "/asf" registered by extension ".../index.ts" must define handler()`.
+  Both commands now use the options-object form; the argument string is split
+  into subcommand + flags and every gate report is notified. Subcommand
+  behaviour is unchanged.
+
+### Tests
+
+- The test harness mock now enforces the real `RegisteredCommand` contract
+  (it accepted any shape before, which is how this shipped) and exposes
+  `invokeCommand()`, which calls a registered command exactly as pi does and
+  captures `ctx.ui.notify()` output.
+- New `test/test-command-contract.mjs` (16 checks): contract enforcement with a
+  negative control, arg-as-string parsing, case-insensitive subcommands,
+  void return, notify-based output, no bare-function registration left.
 
 
 ## [0.9.0] - 2026-09-27

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pi-aia-asf",
-  "version": "0.9.1",
+  "version": "0.10.0",
   "description": "Ai Applied Agentic Software Factory — codifies the full software development flow: intake, research, spec capture, adversarial analysis, planning with approval gates, test-first implementation, and release. Requires pi-vigilant, pi-smart-web-search, pi-smart-fetch, and pi-aia-browser.",
   "keywords": [
     "pi-package",

package/skills/aia-asf/SKILL.md

@@ -199,6 +199,13 @@ Keep the plan **implementation-ready**: any competent engineer (or agent) can ex
 > bloat), split it by topic and keep the parent as an index — never let it grow until
 > editing breaks.**
 
+> **Read `references/06i-completeness.md` before implementing, and again before claiming
+> done.** Ship the real thing or say out loud what is not real: no `// TODO` /
+> not-implemented paths on a user-reachable code path, no fake or seed data the user will
+> read as their own, no invented facts presented as checked, no silently deferred scope,
+> no built-but-never-wired module. A stub is legitimate only when the user asked for one
+> — and then it is declared, never silent.
+
 > **Read `references/06d-delegation.md` before delegating.** Work may be delegated two ways:
 > **intercom** (message another live pi session that owns relevant context — always `list`
 > first, say what you want back, and treat their findings as evidence, not proof; **optional** —
@@ -228,6 +235,7 @@ Execute the task list milestone by milestone. Discipline rules:
 8. **CHANGELOG discipline**: every user-visible change gets a CHANGELOG entry describing exactly what changed (no placeholder text).
 9. **Challenge approved designs (M4)**: if a spec's literal reading creates product tension (e.g. feedback clusters under "Plan" when "Plan = plans"), stop and resolve it with the user before implementing — never implement blindly and call it delivered.
 10. **Trace before claiming delivered (M5)**: the delivery log is a claim; the code is the evidence. Before marking anything ✅, trace the actual code path, confirm the output is consumed by a surface, and confirm the operator-facing outcome test passes.
+11. **No stubs, no fake data, no invented facts (`references/06i-completeness.md`)**: the deliverable is the real implementation. Finish it, or state the discrepancy plainly to the user — what is missing, why, what remains. Never let the user discover the gap by using the product.
 
 ---
 
@@ -239,6 +247,8 @@ Also check the **modularity DoD** from `references/06c-code-quality.md` (Phase 7
 
 Also check the **stability DoD** (`references/06f-stability.md`): if the deliverable makes external calls, it has timeouts and bounded retries (idempotent only). And the **security DoD** (`references/06h-security.md`): no secrets in the repo, no untrusted input reaches a shell/query/path unvalidated, no unbounded resource use on user-controlled input; for agent-like tool surfaces, every tool is least-privilege with an abuse-case test.
 
+Also check the **completeness DoD** (`references/06i-completeness.md`): no stub, placeholder, unimplemented path or fabricated data left on a user-reachable path (or declared to the user with the reason); every part of the ask reachable from where the user enters it, with the exercising command/request/action named in the delivery report; nothing asked for quietly moved to "later"; no claim presented as verified when it was not. `pi-vigilant` scans the changed files for these markers at completion — resolve every finding or explain it; a clean scan is not proof of completeness.
+
 **Large work:** run `/asf verify` — it mechanically validates the **spec-to-code traceability matrix** (M1): every `met` spec must carry `trace` (outcome → codePath → testFile + assertion), testFile must exist, assertion must appear in it. FAIL rows block delivery. **Verify ingested specs from external planning docs too** — the doc's ✅ markers are claims, not evidence.
 
 **Independent reviewer gate (large work, P19):** before delivery, run the
@@ -259,8 +269,8 @@ conflicts). Record the review + triage in the delivery report.
 3. Run `get_task_specs` and verify **every spec** with `update_spec_status` + concrete evidence (test output, build result, code inspection). Unverifiable → `partial` + ask the user. Never self-certify.
 4. **Report honestly**: never claim a check you didn't run; state explicitly anything
    skipped or inconclusive, and distinguish "tests pass" from "works for the user".
-3. If the project is a library/package that the user publishes (npm, GitHub release): **check the release policy** — read `.asf-release.json` at the project root if present (see `references/07-release.md`). It defines **when** (user-stated conditional rules: "when X is true, publish automatically; when Y is true, do this…") and **how** (instructions the ASF drives with judgment — credentials, git sync, publish steps). If the policy authorizes automatic publishing for the current state, drive the release per `how`; otherwise **offer** to run the release and get explicit approval (the default stance: publishing is the user's decision). **Always test on publish / in production, if applicable** — verify the shipped artifact from the registry / smoke-test prod, never assume it works. Optionally offer to set up a CI/CD pipeline for publishing.
-4. Present a completion summary: what was built, specs met, tests passing, how to use it.
+5. If the project is a library/package that the user publishes (npm, GitHub release): **check the release policy** — read `.asf-release.json` at the project root if present (see `references/07-release.md`). It defines **when** (user-stated conditional rules: "when X is true, publish automatically; when Y is true, do this…") and **how** (instructions the ASF drives with judgment — credentials, git sync, publish steps). If the policy authorizes automatic publishing for the current state, drive the release per `how`; otherwise **offer** to run the release and get explicit approval (the default stance: publishing is the user's decision). **Always test on publish / in production, if applicable** — verify the shipped artifact from the registry / smoke-test prod, never assume it works. Optionally offer to set up a CI/CD pipeline for publishing.
+6. Present a completion summary: what was built, specs met, tests passing, how to use it.
 
 ---
 
@@ -298,6 +308,12 @@ conflicts). Record the review + triage in the delivery report.
 - ❌ Breaking existing functionality during a refactor — refactoring preserves behavior
 - ❌ Marking a spec delivered from the delivery log instead of tracing the code — the log is a claim
 - ❌ Shipping machinery no surface consumes — delivered = visible in the product (UI or API)
+- ❌ A `// TODO`, `not implemented`, empty handler or `coming soon` on a user-reachable path — that is an absent feature wearing a name
+- ❌ Fake, seed, demo or lorem-ipsum data on a path the user reads as their own
+- ❌ An invented API signature, config key, endpoint, version or limit stated as fact — verify it or mark it unverified
+- ❌ Quietly deferring part of the ask ("v1 does X") instead of finishing it or telling the user
+- ❌ Presenting a stub as complete because the tests written against it pass
+- ❌ Leaving a deliberate stub unexplained — if the user asked for a scaffold, say so in the report
 - ❌ Trusting unit tests as proof of wiring — assert the operator-facing outcome end-to-end
 - ❌ Trusting an external plan's ✅ (IMPROVEMENT-PLAN / delivery log) — ingest its items as specs and verify them
 - ❌ Implementing a spec literally when it creates product tension — challenge it and resolve with the user
@@ -308,6 +324,8 @@ conflicts). Record the review + triage in the delivery report.
 - ❌ Shipping a delivery summary without the report fields: spec status + evidence, test results, skipped checks, not-tested register (06b Rule 17)
 - ❌ Letting an escaped defect teach nothing — ask which gate should have caught it and close the gap (06b Rule 18)
 - ❌ Self-modifying the ASF's own rules during a task run — standards change only via the review process (P22)
+- ❌ Running a subset of tests inside the loop without a stated impact statement, or when uncertain whether the blast radius is larger — default is full (06b Rule 19)
+- ❌ Treating a subset run as satisfying the Rule 10 full-suite checkbox — the commit/DoD gate is always a real full run (06b Rule 19)
 
 ## Reference index (read on demand — never load all)
 
@@ -322,13 +340,14 @@ reads at most 06b + 06c; large work reads the ones its phase calls for.
 | `04-adversarial.md` | adversarial checklist (spec/architecture/security lenses) | Phase 4 (large) |
 | `05-plan.md` | PLAN.md template + ADRs + quality scenarios + ATAM-lite + views | Phase 5 (large) |
 | `06-implementation.md` | coding discipline, M4/M5, drift self-correction (P20) | Phase 6 |
-| `06b-testing-qa.md` | **mandatory** testing & QA standard (18 rules + DoD) | before writing tests (always) |
+| `06b-testing-qa.md` | **mandatory** testing & QA standard (19 rules + DoD) | before writing tests (always) |
 | `06c-code-quality.md` | **mandatory** modularity standard (9 rules, deep modules, smells) | before structuring code |
 | `06d-delegation.md` | intercom & subagents + independent reviewer gate (P19) | before delegating; Phase 7 review (large) |
 | `06e-code-health.md` | Code Health Gate (+ depth, supply-chain, secrets metrics) | Gate 8 (large) |
 | `06f-stability.md` | stability patterns + error handling + observability (P06/P07/P08) | **if the deliverable makes external calls or is a service** |
 | `06g-test-design.md` | risk-based test derivation + determinism | Phase 6 large (test plan) / non-trivial tests |
 | `06h-security.md` | threat model, ASVS DoD, supply chain, agent tools | Phase 4/5 large; small = one line |
+| `06i-completeness.md` | **mandatory** no stubs / no fabricated data / no invented facts + completeness DoD | before implementing and before claiming done (always) |
 | `07-release.md` | release workflow + **configurable release policy** (`.asf-release.json`: when/how) + test-on-publish | before publishing |
 
 ## ASF self-modification policy (P22)

package/skills/aia-asf/references/06-implementation.md

@@ -15,8 +15,11 @@
 
 1. Write the failing test for the next behavior
 2. Implement the minimum to pass
-3. Run the suite; refactor; re-run
-4. Only commit green
+3. Run the suite; refactor; re-run — steps 3's intermediate runs (not the
+   commit-gate run) may use a selected subset per **06b Rule 19**, and only
+   when certain the subset is warranted; default is full
+4. Only commit green — the pre-commit run is always the FULL suite (06b
+   Rule 10), never a subset, regardless of what ran in step 3
 
 For web interfaces, browser tests via pi-aia-browser are part of the test suite, not an afterthought.
 

package/skills/aia-asf/references/06b-testing-qa.md

@@ -139,7 +139,7 @@ never arrives, the wiring is dead — that is a failed test.
 ## Rule 10 — Definition of done (all must hold)
 
 - [ ] Typecheck/build passes
-- [ ] Full test suite green (not a subset)
+- [ ] Full test suite green (not a subset) — **the gate never moves: this checkbox always means a full run, even when Rule 19 permitted subset runs earlier in the loop that led here**
 - [ ] Regression test added for every bug fixed this cycle
 - [ ] Triggers **and** non-triggers tested for conditional behavior
 - [ ] Shipped artifact inspected (`npm pack` file list) and installed clean-room
@@ -325,3 +325,57 @@ production incident), the fix is not the end — the **loop** is:
 > **Real failure:** a package shipped with a broken `files` allowlist; the
 > fix landed but the *gap* ("no test inspects the packaged artifact") was not
 > closed until Rule 1 was added. The loop is what prevents the next one.
+
+## Rule 19 — Test selection for the inner loop (P25; the DoD gate never moves)
+
+Rule 10's full-suite checkbox is a **gate**, not a loop constraint. The gate
+never relaxes. What this rule relaxes is the **intermediate** runs inside one
+change's own red-green-refactor cycle (06-implementation "Test-first" steps
+1-3) — the runs that happen *before* the commit-gate run, on code you are
+still editing.
+
+**The rule, in the user's own words: run a partial (impact-area) subset only
+when certain that this is warranted; if not certain, or if the blast radius
+might be greater than the impact area, always run full. Default is full.**
+
+- **Burden of proof is on the subset, not on the full run.** Silence,
+  uncertainty, or "probably fine" all mean full. A subset run requires an
+  affirmative, checkable case.
+- **A subset run requires a stated impact statement** in the transcript,
+  before the run: the changed files, the tests selected because of them, and
+  *why nothing else can be reached*. A file list alone is not an impact
+  statement — restating the diff is not an argument for why the blast radius
+  stops there. No statement, or a statement that does not argue the
+  boundary → **not certain → full.**
+- **Certainty is impossible by definition (no judgment call — always full)**
+  when the changed footprint includes any of:
+  - shared/global state, a singleton, a cache, env/config, a feature flag
+  - `package.json`, the lockfile, or any dependency
+  - build, test, lint, or CI config, or the test harness itself
+  - a DB schema, a migration, or a shared fixture
+  - a public API/contract, CLI args, or a wire/shared type
+  - a cross-module refactor, a rename, a file move, or a deletion
+  - **any changed file with no entry in the project's test-impact map** — a
+    project that has not built a map always runs full; the relaxation only
+    ever applies where the mapping is known, never where it is guessed.
+- **The ~90s-and-under guard**: if the full suite's own measured runtime is
+  small enough that an assessment costs more than just running it, skip the
+  assessment and run full — state the measured number once rather than
+  re-litigating it every iteration.
+- **Reporting stays honest (Rule 11/17) no matter which path was taken.** A
+  subset run is reported as a subset run — "ran N/M suites (impact-area: X);
+  full suite not run this iteration" — never as "suite green". The Rule 10
+  checkbox is only ever satisfied by an actual full run, shown in this cycle,
+  regardless of how many subset runs preceded it.
+- **Never an escape from a failing test.** Selection decides *which* suites
+  run; it never decides whether a failing test counts. A failing test is
+  fixed or deleted (Rule 16), never excluded from the run that would have
+  caught it.
+- **If a defect escapes that a full run would have caught**, that is Rule 18:
+  the fix must say so, and the certainty bar for that class of change tightens
+  (added to the "certainty is impossible" list above if it recurs).
+
+This does not change Rule 10, Rule 11, or the commit-gate workflow: a project
+that commits after every green run already runs full before every commit, so
+Rule 19 only ever saves the intermediate runs inside a single change — it
+never reduces what runs before anything is committed.

package/skills/aia-asf/references/06i-completeness.md

@@ -0,0 +1,67 @@
+# Completeness — no stubs, no fabricated data, no invented facts
+
+**Read when:** before writing implementation, and again before claiming done — for
+every deliverable with real behaviour. **Skip when:** never. Small work needs only
+the Core rule and the DoD checklist at the bottom.
+
+Newer models can produce work that *looks* finished: a function with the right name
+whose body is a placeholder, a screen populated with invented records, a report that
+cites a limit nobody checked. Green tests do not disprove it — the tests were written
+against the stub. This reference is the standing answer.
+
+## Core rule
+
+**Ship the real thing, or say out loud what is not real.**
+
+Complete means: the user can use what they asked for, through the entry point they
+will actually use. Not: the files exist, the suite is green, the shape looks right.
+There is no third option — an undeclared gap is a defect, however tidy it looks.
+
+## Never ship silently
+
+| Pattern | Why it is a lie |
+|---|---|
+| `// TODO`, `FIXME`, `not implemented`, `coming soon`, `pass`, empty handler, `throw new Error("not implemented")` on a user-reachable path | The feature is absent; the name says it is present |
+| Fake / seed / demo data on a user path — hardcoded users, invented prices, lorem ipsum, `example.com`, `+1 555-…`, `dummy`/`fake`/`sample` records | The user reads invention as their own data |
+| Invented facts presented as checked — API signatures, config keys, endpoints, version numbers, limits, quotas | Confidence without verification is the expensive kind of wrong |
+| Silently deferred scope — "v1 covers X" when X+Y was asked | A stub with better marketing |
+| Built-but-never-wired — the module exists and is tested, but nothing calls it, no route reaches it, no surface consumes it | The user cannot get to the feature at all |
+| Mocks or fakes in production code paths | Test seams belong at test seams (06b) |
+| A config/env value the code reads but nothing sets, or a key the code never reads | The switch does nothing |
+
+## Legitimate exceptions — declared, never silent
+
+1. **The user asked for it**: a scaffold, spike, stub, mock or placeholder was the
+   requested deliverable. Keep it, and state in the delivery report that it is
+   deliberate and what it stands in for.
+2. **An approved deferral**: a scope conflict, missing credential, or external
+   dependency stopped part of the work. Record it as an open item: what is missing,
+   why, what remains.
+3. **A fake at a test seam**: legitimate, and stays out of shipped paths.
+
+Anything else: **finish it.** If it cannot be finished in this run, the discrepancy
+goes in the final message in plain words — never discovered by the user through use.
+
+## Prove it is real (Phase 7)
+
+- **Exercise each part through the entry point the user will use** — the CLI command,
+  the HTTP request, the UI action, the installed package — and name that action in the
+  delivery report. "Implemented the export endpoint" is a claim; "`curl -s
+  localhost:3000/export.csv` returned 412 rows" is evidence.
+- **Data-shaped output**: show one real record end to end. If data is seeded, label it
+  seeded and say where the real source plugs in.
+- **Factual claims**: cite where verified (doc URL, tool output, schema, measured run)
+  or mark it unverified. Never launder an assumption into a statement of fact.
+- **The host audits you**: `pi-vigilant` scans the files this session changed for
+  stub / fabricated-data / fact-hole markers and puts the findings in front of you at
+  completion. Resolve every finding or explain it — and a clean scan is *not* proof of
+  completeness: deferral and wiring remain your check, not the scanner's.
+
+## Definition of Done — completeness
+
+- [ ] No stub, unimplemented path, placeholder or fabricated data remains on a
+      user-reachable path — or it is declared to the user with the reason.
+- [ ] Every part of the ask is reachable from where the user enters it; the delivery
+      report names the command / request / action that exercised each part.
+- [ ] Nothing asked for was quietly moved to "later" without the user being told.
+- [ ] No claim in the deliverable or the report is presented as verified when it was not.