kibi-cli 2.31.0 → 2.32.0

package/src/public/skills/kibi-commit-review/resources/staged-gate.md

@@ -30,11 +30,16 @@ symbols_manifest_stale: .kb/symbol-coordinates.yaml is stale or missing for stag
 | `symbol-coverage` | A changed symbol, or a symbol whose staged manifest entry changed, fails the full-check rule on the staged knowledge. | The symbol `implements` the requirement and is `covered_by` a test that verifies it: through the requirement's scenario (`verified_by` scenario -> test) when it has one, else `verified_by` requirement -> test. A direct requirement -> test link does not count while a scenario exists. The finding's suggestion names the missing link (see `kibi-traceability`). |
 | `kibi_impact_override_missing_rationale` | A `Kibi-Impact: none` declaration has no `Rationale:` line. | Add the rationale, or drop the declaration and stage real evidence. |
 | `entity-context-missing` (staged entity) | A staged requirement, scenario, test, ADR or observation fact has fewer than 12 words of context. | Upsert a sectioned `document.body` (see `kibi-usage`, Entity body contract). |
-| `domain-contradictions`, `scenario-feasibility`, `exception-claim-keys` (staged `.kb/` change) | The staged knowledge introduces a violation the last commit did not have. | Fix the knowledge; a contradiction with a recorded rule goes to the person (`kibi-decisions`). |
+| `domain-contradictions`, `kb-consistency`, `scenario-feasibility`, `exception-claim-keys` (staged `.kb/` change) | The staged knowledge introduces a violation the last commit did not have. `kb-consistency` also catches facts that contradict only together and names their requirements. | Fix the knowledge; a contradiction with a recorded rule goes to the person (`kibi-decisions`). |
 | Proposition-complete ingestion | A staged requirement's semantic inventory is missing or no longer matches its prose. | Re-derive it (`kb_model` analyze with the complete prose) or run `kibi migrate` for drift. |
 | `kibi check-generated --staged` drift | The staged `.kb/symbols.yaml` or `.kb/symbol-coordinates.yaml` differs from a refresh computed from the index. | `kibi sync --refresh-symbol-coordinates`, review the diff, stage only the intended hunks (`git add -p`). |
 | `Staged impact review failed: impact_review_invalid: ...` | The base commit has `.kibi/impact-policy.json` and the staged `.kibi/impact-review.json` is missing, stale or incomplete. The message names the cause (missing review path, stale fingerprint, ...). | Prepare a fresh record (below). Any later staged change makes the fingerprints stale again, so prepare it last. |
 
+The staged gate does not judge evidence levels: the `evidence-floor` rule
+runs only in a full `kibi check`. A firm requirement staged without an
+end-to-end proof passes the commit and fails that check later (see
+`kibi-decisions` for `required_evidence`).
+
 ## Advisory findings
 
 These warn but do not block. Read them; they are often the real review.

package/src/public/skills/kibi-decisions/SKILL.md

@@ -2,7 +2,7 @@
 id: kibi-decisions
 name: kibi-decisions
 description: "Use when the person states a rule or decision (must, never, always, from now on, we decided), when a Kibi hook asks to confirm or warns about an edit to code that implements a firm requirement, when the Stop hook says source files changed but nothing was recorded, when kb_check quotes requirement_statement_unverified, or when a request conflicts with a recorded requirement or ADR. Covers reading firmness and origin, recording a person's rule as firm with origin.ref, superseding with a Why this changed section, the kb_compile_intent unresolved/reviewCandidates/conflictReviews loop, asking before overriding a firm rule, and putting decisions to the person as one numbered kibi signoff --questions view."
-version: 1.2.0
+version: 1.3.0
 kibiCompatibility: ">=1.0.0"
 tags:
   - kibi
@@ -74,6 +74,13 @@ name the missing capability. Never read or edit `.kb/` files directly.
   quoting their words and where they said them, a sectioned `document.body`,
   a scenario, and an `implements` link from the code that enforces it. Use
   `kb_compile_intent` first when the rule may touch several requirements.
+  A firm rule needs `tested` evidence by default, so `kb_check`'s
+  `evidence-floor` rule fails on it until an end-to-end test proves its
+  scenario. When the change includes that test, give it a proof contract and
+  run `kibi prove`. Otherwise set `required_evidence: asserted`, say in the
+  body that no end-to-end test proves the rule yet, and report it as
+  asserted, not tested. Kibi's bootstrap and migration give an untested firm
+  rule the same floor.
 - **The person changes a rule:** supersede it (new requirement linked
   `supersedes` new -> old, `firmness: firm` when the old one was firm, a
   `## Why this changed` section of at least 12 words naming their instruction
@@ -124,7 +131,8 @@ Validation is not completion. When a request conflicts with a recorded rule and
 
 End with `kb_check` (and `kb_status` when freshness matters) and say:
 
-- which rules you followed, asked about, recorded or changed (ids, firmness);
+- which rules you followed, asked about, recorded or changed (ids, firmness,
+  evidence level);
 - under "Decisions I changed", each supersede and its evidence;
 - the open question, if a conflict is waiting on the person;
 - or, when the session made no decision, one line saying so.

package/src/public/skills/kibi-decisions/resources/decision-records.md

@@ -43,7 +43,7 @@ says it, link to it instead of restating it. Otherwise write the scenario
 first, then the requirement (the requirement's write sends `specified_by`):
 
 ```json
-{"type":"req","id":"REQ-billing-refund-approval","properties":{"title":"Refunds above 500 EUR need a finance approval","status":"open","priority":"must","firmness":"firm","origin":{"kind":"agent","ref":"session request: \"from now on refunds above 500 EUR must be approved by finance\""}},"relationships":[{"type":"specified_by","from":"REQ-billing-refund-approval","to":"SCEN-billing-refund-approval"}],"document":{"body":"Refunds above 500 EUR need a finance approval.\n\n## Context\n\nThe person asked for this rule while changing the refund flow; reason not stated.\n\n## Source\n\n> from now on refunds above 500 EUR must be approved by finance\n\nSession request."}}
+{"type":"req","id":"REQ-billing-refund-approval","properties":{"title":"Refunds above 500 EUR need a finance approval","status":"open","priority":"must","firmness":"firm","required_evidence":"asserted","origin":{"kind":"agent","ref":"session request: \"from now on refunds above 500 EUR must be approved by finance\""}},"relationships":[{"type":"specified_by","from":"REQ-billing-refund-approval","to":"SCEN-billing-refund-approval"}],"document":{"body":"Refunds above 500 EUR need a finance approval.\n\n## Context\n\nThe person asked for this rule while changing the refund flow; reason not stated. No end-to-end test proves it yet.\n\n## Source\n\n> from now on refunds above 500 EUR must be approved by finance\n\nSession request."}}
 ```
 
 Then link the enforcing symbol with `implements` (and its test with
@@ -58,6 +58,11 @@ validation, not the write.
   `origin.approved_by` to the person.
 - A rule from a document, test or ticket a person wrote is `firm` too, with
   `origin.ref` to that source.
+- `required_evidence: asserted` keeps an untested firm rule from failing
+  the `evidence-floor` check while it is recorded. Drop it (the floor goes
+  back to `tested`) once an end-to-end test with a proof contract and a
+  passing `kibi prove` receipt covers the rule's scenario; never set it below
+  `asserted` on a firm rule.
 - Your own choice is `default`; a guess is `exploratory`. Write the value
   explicitly whenever you record a decision.
 - For strict modeling (claim keys, predicate facts) follow `kibi-usage`,

package/src/public/skills/kibi-decisions/resources/signoff-views.md

@@ -13,7 +13,8 @@ statements and lists that render in any chat or messaging surface. Put it in
 your reply unchanged: never wrap it in a code block, summarize it or retell a
 requirement in your own words. Every run also writes
 `.kb/briefs/signoff/latest.json`, `latest.md` and `latest.html` (git-ignored);
-`latest.html` is a self-contained page with the full view.
+`latest.html` is a self-contained page with the full view, meant to be opened
+in a browser or published as a page, not attached as a file.
 
 ## Showing it on your host
 
@@ -21,7 +22,7 @@ requirement in your own words. Every run also writes
 | --- | --- |
 | Claude Code, Codex, Cursor, ZCode, VS Code chat | Paste the default output; `/kibi-signoff` (Claude Code, Cursor, ZCode) runs it. Offer `kibi signoff --format html --open` for the page |
 | OpenCode terminal | `kibi signoff --format md` and paste the fenced block unchanged: kibi-opencode draws it as a card, and `/kibi-signoff` reopens it |
-| Replies sent through a messaging tool (cloud or project threads, chat bots) | Pass the default output as the message text, and attach or publish `.kb/briefs/signoff/latest.html` next to it when the tool can carry a file or a page |
+| Replies sent through a messaging tool (cloud or project threads, chat bots) | Pass the default output as the message text. Share `latest.html` only as a rendered page: in Claude apps (claude.ai, the mobile and desktop apps, Claude Code on the web) publish it with the Artifact tool and give its link. Never attach the `.html` as a file: the Claude apps, Slack and most chat apps show it as raw source or a download. With no page tool, the message text is the whole view |
 | VS Code or Cursor with the kibi-vscode extension | The **Kibi: Show Requirements Signoff** panel follows every run |
 | Remote machine, no browser | Give the person the path of `latest.html` |
 

package/src/public/skills/kibi-freshness/SKILL.md

@@ -2,7 +2,7 @@
 id: kibi-freshness
 name: kibi-freshness
 description: Check exact Git attachment, branch migration/quarantine, compiled-store freshness, source linkage, and repair state before decisions or writes.
-version: 2.1.0
+version: 2.2.0
 kibiCompatibility: ">=1.0.0"
 tags:
   - kibi
@@ -66,6 +66,10 @@ For every freshness, branch, or completion question, call `kb_status` first, the
   evidence-dependent closeout. Name the exact paths/symbol IDs and whether the
   result is fixed, accepted, or deferred.
 - If entities look stale, refresh context through an approved Kibi capability and then re-query.
+- When asked whether a requirement is proven, quote its `evidenceLevel` and
+  `evidenceFloor` from `kb_coverage`. `pending_reproof` (receipts older than
+  the code) is stale evidence, not proof; `kibi prove` refreshes it, and
+  `kibi check --fresh-evidence` is the check that fails on it.
 - Preserve source-file traceability by carrying `sourceFile`, text references, and validation evidence through discovery, mutation, and completion.
 - Do not read or edit files inside `.kb` directly; use the selected Kibi interface instead.
 - Kibi authors tracked files but never Git-stages or commits them; ordinary Git workflows remain responsible for review and commit.

package/src/public/skills/kibi-traceability/SKILL.md

@@ -2,7 +2,7 @@
 id: kibi-traceability
 name: kibi-traceability
 description: Maintain source-first requirement, scenario, test, symbol, and proof traceability through Kibi's peer interfaces.
-version: 2.0.0
+version: 2.2.0
 kibiCompatibility: ">=1.0.0"
 tags:
   - kibi
@@ -64,3 +64,13 @@ stale snapshots, unavailable receipts, and incomplete grounding explicit.
 Fresh proof requires a current verification snapshot, the exact contracted E2E
 command, an append-only receipt, and current symbol coordinates. Structural
 coverage and a green check are not proof by themselves.
+
+Report each requirement's `evidenceLevel` from `kb_coverage` as it is:
+`proved` only when certificate proofs (exhaustive, typecheck, arithmetic,
+smt) derive every applicable claim, named in each contract's `proves`
+(`claimSummary` and `unprovedClaims` say which are missing), `tested` for fresh passing E2E receipts,
+`asserted` when only a person stands behind it, `unverified` otherwise. Its
+`evidenceFloor` says what `kb_check`'s `evidence-floor` rule requires:
+`below` is a traceability gap to close with links, tests and `kibi prove`;
+`pending_reproof` means the receipts are older than the code and need
+`kibi prove`. Never lower `required_evidence` to clear either.

package/src/public/skills/kibi-usage/SKILL.md

@@ -2,7 +2,7 @@
 id: kibi-usage
 name: Kibi Usage
 description: Use Kibi's source-first, exact-Git, migration-aware, proof-aware operations safely across MCP or the trusted local CLI, including partial completion repair.
-version: 2.24.0
+version: 2.27.0
 kibiCompatibility: ">=1.0.0"
 tags:
   - kibi
@@ -434,9 +434,11 @@ safe normative claims; use `observation` or `meta` for bug/workaround notes and
 tests, symbol ownership, and fresh proof-bearing receipts before claiming proof.
 For an existing product KB that needs semantic backfill, read
 `resources/kb-improvement.md`, and `resources/proof.md` for the proof workflow.
-When a proof ratchet fails, follow Debugging proof regressions in
-`resources/proof.md`: use `kibi proof explain` and compare current proof state
-to committed `proof/baseline.json` with `kibi proof impact`.
+Each current requirement has an evidence floor (`required_evidence`, else
+`tested` when firm); certificate proof kinds (exhaustive, typecheck,
+arithmetic, smt) reach `proved` for the claims their contract names in
+`proves`, and a requirement is proved only when every claim is. When the `evidence-floor` rule fails, follow Debugging
+proof regressions in `resources/proof.md` and use `kibi proof explain`.
 
 ## Predicate Ontology Decision Tree
 

package/src/public/skills/kibi-usage/resources/proof.md

@@ -17,12 +17,18 @@ reports what happened as `kibi.proof-run.v1`; Kibi evaluates proof.
    ```bash
    kibi prove --test TEST-<id>
    # or: kibi prove --requirement REQ-<id> | --integration <id> | --all
+   # add --stale to rerun only tests without a current passing receipt
+   # add --resume to continue an interrupted run (same selector)
    ```
 
+   With `--test`, `--requirement` or `--stale`, a direct `playwright test`
+   integration runs only the selected tests' `proof_bindings[].source_file`
+   specs; wrappers get them as `KIBI_PROOF_SOURCE_FILES`.
+
    `kibi prove` captures the workspace snapshot, runs each integration's
    producer once (`shell: false`), revalidates the snapshot, evaluates the
    artifact against every selected contract, and appends idempotent
-   `kibi.proof-receipt.v1` receipts.
+   `kibi.proof-receipt.v2` receipts (v1 receipts stay valid).
 3. Confirm with `kb_status` (fresh, current snapshot) and `kb_coverage`.
 
 Never hand-write receipts. Kibi derives them from validated
@@ -51,6 +57,13 @@ proof_bindings:                 # optional provenance metadata
 
 Provenance lives in `proof_bindings`; the contract stays semantic.
 
+`success_policy: own_results_first_attempt` judges each obligation by its own
+`native_case` result when the run failed only in execution (other cases
+failed), so one unrelated failing case does not fail every receipt of a
+Playwright suite. Aggregate-run obligations, run-level errors, timeouts,
+interruptions and setup failures still refuse every obligation. Keep
+`all_required_first_attempt` unless the user wants per-case judgement.
+
 - Every `required_proofs[].symbol_id` must name an existing `symbol` entity,
   or `kb_check` reports `proof-contract-symbols`. Create the symbols first
   (`kb_upsert`, narrow method-level granularity, never a `type-shape`
@@ -85,7 +98,10 @@ replacing one named integration.
   `--command` the proposal is the `package.json` `test` script or the
   detected runner again), or make the run attributable per test: have the
   command write a `kibi.proof-test-report.v1` to the path in
-  `KIBI_PROOF_TEST_REPORT` so each test is judged by its own steps.
+  `KIBI_PROOF_TEST_REPORT` so each test is judged by its own steps. The
+  shipped `kibi proof run-steps` does that from `proof/steps.json`
+  (`[{test_id, steps: [[argv...]]}]`); use it as the integration command
+  instead of writing a producer script.
 - `producer: playwright` (or custom) — the child emits `kibi.proof-run.v1`
   itself (bundled reporter: `kibi-cli/playwright-reporter`).
 - `producer: junit` / `tap` — Kibi converts the native report at `artifact`
@@ -126,8 +142,11 @@ Every requirement row also carries `evidenceLevel`, the strength of what backs
 it, and `evidence`, the entries that earned it (each with `kind`, `scope` and
 `level`):
 
-- `proved`: a re-checkable certificate covers every case. No proof kind issues
-  certificates yet, so nothing reaches it today.
+- `proved`: the requirement is `tested` and every applicable claim has a
+  derived, code-scope binding from a fresh certificate that still re-checks
+  (see Certificate proof kinds). The entry has `kind: certificate` and lists
+  the tests. `claimSummary` counts claims per level and `unprovedClaims`
+  lists the claims below proved.
 - `tested`: `proofStatus` is `tested`; fresh E2E receipts cover every linked
   scenario.
 - `asserted`: a person stands behind the statement (approved, or firm by
@@ -138,6 +157,94 @@ Report the level as it is. Never call an `asserted` or `unverified`
 requirement proven or tested, and never call `tested` proved. Firmness is a
 separate axis: it says how sure the person is, not how strong the evidence is.
 
+## Certificate proof kinds
+
+A contract's `kind` says what its evidence can reach. The runner kinds `e2e`
+(the default), `example` and `property` support `tested`. The certificate
+kinds support `proved`, and only when Kibi re-checks the certificate the test
+left:
+
+- `exhaustive`: the test runs a check on every member of a finite domain.
+  Set `domain_source: { symbol_id: SYM-<domain> }` to the symbol that defines
+  the domain (add `export: <name>` when the export is not named like the
+  symbol's title), and import that symbol in the proof file. Kibi loads the
+  export itself (bun, the workspace's tsx, or node; for a `.py` domain
+  `KIBI_PYTHON`, the active or project `.venv`/`venv`, then `python3`:
+  Enum values, dict keys, list/tuple/set items) and rejects a
+  certificate that does not cover exactly its members, so a hand-listed or
+  partial domain stays `tested`. An import from build output is mapped back
+  to its source through `tsconfig.json` `outDir`/`rootDir`.
+- `typecheck`: a witness file that stops compiling when a domain member
+  goes unhandled (a switch ending in a `never` assignment, or a
+  `satisfies Record<Domain, ...>` map). Set `witness.path` and
+  `domain_source`; the witness must import the domain. Kibi compiles the
+  witness itself (strict, with the workspace's TypeScript), so `typescript`
+  must be installed in the workspace.
+- `arithmetic`: a claim on one `int` or `real` variable decided exactly from
+  typed facts. Set `constraint_source: { fact_ids: [FACT-...] }` to the
+  numeric `property_value` facts (one subject and property); the
+  certificate's variable is their `property_key` and its assumptions are
+  exactly their constraints. To read the value from the code instead, set
+  `value_source: [{ symbol_id: SYM-<constant>, export: <name> }]`; Kibi
+  evaluates the number export itself and adds `variable eq value` as an
+  assumption.
+- `smt`: an SMT-LIB query that declares the facts' property as a constant,
+  asserts each `constraint_source` fact constraint and then the claim's
+  negation. Kibi re-runs z3 or cvc5 on it and accepts only `unsat`.
+
+`arithmetic` and `smt` from `constraint_source` alone prove that the
+knowledge base's facts entail the claim, not that code follows the facts:
+their claim bindings have scope `intent` and the claim stays `tested`. Use
+`value_source` (its symbols `covered_by` the test) for scope `code`. A test
+whose numbers are not in typed facts or code constants stays `tested`.
+
+Every certificate contract names the claims it proves in `proves:
+[CLAIM-...]` (blocking `proof-contract-claims` from schema 12). Kibi derives
+each claim's obligation from its grounding fact: a set fact (`value_type:
+set`, `value_set: [...]`) needs the `exhaustive` domain or the `typecheck`
+domain type to be exactly the set; a numeric fact needs the `arithmetic`
+claim or the negated `smt` assertion to be its constraint. The receipt
+records one binding per claim: `derived` (checked, the only kind that
+proves), `attested` (the fact has no derivation; counts as tested) or
+`rejected` with the reason. Model an enumerated claim as a set fact and a
+bound as a numeric fact before writing its certificate. `kibi proof explain
+REQ-...` shows each claim with its bindings.
+
+Build the certificate with `kibi-cli/proof-certificates`
+(`exhaustiveCertificate`, `typecheckCertificate`, `arithmeticCertificate`,
+`smtCertificate`), fail the test when it records a failure
+(`failedMembers`), and call `writeCodeCertificate`; it writes to the
+directory `kibi prove` sets in `KIBI_PROOF_CERTIFICATES` and does nothing
+elsewhere. A Python test writes the same `kibi.code-certificate.v1` JSON
+to that directory itself. Wire the KB: the proof file symbol is
+`executable_for` the test and named in `required_proofs`; the domain symbol
+`implements` the requirement and is `covered_by` the test; the test
+`validates` one of the requirement's scenarios. `proved` is per claim: a
+multi-claim requirement is proved only when certificates derive every
+applicable claim, and reads `tested` with `n/m claims proved` otherwise. A
+rejected certificate leaves the receipt at `tested` with
+`certificate_rejection` naming why; fix the proof, never the receipt. If a
+stored certificate stops re-checking later, coverage and `kibi proof
+explain` list it under `certificateRejections`. Use a
+certificate kind only when the domain or claim is genuinely finite or
+decidable; an e2e test that samples cases stays `tested`.
+
+## Evidence floors
+
+Each current requirement accepts a weakest level, its floor: the
+`required_evidence` field (`proved`, `tested`, `asserted` or `unverified`),
+or, when absent, `tested` for a firm requirement and no floor otherwise.
+`kb_check`'s `evidence-floor` rule fails while the level is below the floor;
+coverage rows show it as `evidenceFloor` (`required`, `source`, `status`).
+A requirement whose receipts are only older than the code is
+`pending_reproof` and passes a plain check; `kibi check --fresh-evidence`
+fails it, and is what CI runs after `kibi prove`.
+
+Fix a finding by raising the level: add the scenario, the end-to-end
+test with a proof contract and the receipts, or have a person approve the
+requirement. Lower `required_evidence` only when a person decides the
+requirement does not need that evidence, and say why in the requirement.
+
 ## Knowledge-base certificates
 
 `kb_check` (`kibi check`) proves facts about the KB itself in its
@@ -182,19 +289,22 @@ feasibility are not certified yet; their own rules still decide them.
 
 ## After code changes
 
-Receipts bind to the snapshot, contract hash, and execution fingerprint at
-run time. Any code or source change moves the snapshot and stales receipts:
-re-run `kibi prove` for the affected selection, then confirm `kb_status` and
-`kb_coverage` before handoff.
+Receipts bind to the contract, the test document (its links excluded) and
+the code of the symbols they cover. A change to that code stales them:
+re-run `kibi prove --stale` (or the affected selection), then confirm
+`kb_status` and `kb_coverage` before handoff. Type-shape symbols covered by a
+unit test count only while that unit test has a current passing receipt, so
+prove unit tests that cover type-shape symbols too.
 
 Full reference: `docs/proving-requirements.md`.
 
 ## Debugging proof regressions
 
-When a proof ratchet fails, diagnose first. Do not treat
-`proof/baseline.json` as the thing to edit.
+When the `evidence-floor` rule fails, diagnose first. Do not lower
+`required_evidence` to make it pass.
 
-1. Do not refresh `proof/baseline.json` as the first fix.
+1. Read the finding: it names the requirement, its level, its floor and where
+   the floor comes from (`explicit` or `firmness`).
 2. Identify the exact requirement and symbol responsible for the regression.
 3. Use Kibi proof diagnostics rather than reverse-engineering
    `requirement_proof.pl`:
@@ -202,14 +312,9 @@ When a proof ratchet fails, diagnose first. Do not treat
    ```bash
    kibi proof explain REQ-<id>
    kibi proof explain SYM-<id>
-   kibi proof impact
+   kibi check --rules evidence-floor
    ```
 
-   `kibi proof impact` compares the current Proof projection to
-   `HEAD:proof/baseline.json` (the committed ratchet snapshot, not the
-   working-tree file). It is diagnostic: fingerprint differences are reported
-   and the command exits 0 on successful evaluation. The strict ratchet remains
-   `scripts/check-proof-baseline.mjs`.
 4. For `missing_production_symbol_coverage`, inspect symbol role, owning
    requirement, `covered_by`, candidate test scope, the requirement scenario
    chain, and the current proof receipt. `kibi proof explain` prints those as
@@ -231,5 +336,5 @@ When a proof ratchet fails, diagnose first. Do not treat
    `covered_by` relationship semantically correct.
 10. Prefer one meaningful E2E scenario covering multiple internal functions
     plus focused unit tests for edge cases, rather than an E2E test per helper.
-11. Refresh the baseline only after a genuine intentional proof-state
-    improvement requires the ratchet snapshot to be updated.
+11. A `pending_reproof` finding under `--fresh-evidence` needs `kibi prove`
+    for the tests behind the requirement, not a KB change.

package/src/public/skills/kibi-usage/resources/workflows.md

@@ -116,7 +116,7 @@ The canonical workflow for any KB operation follows this pattern:
 7. **Create endpoints**: validated `kb_upsert` for new entities, sequentially
 8. **Link**: validated `kb_upsert` with `requires_rule`, `requires_predicate`, `constrains`, or `requires_property`, sequentially
 9. **Validate coverage and consistency**: targeted `rule-safety`, `rule-verifiability`, `semantic-completeness`, `logic-coverage`, `predicate-verifiability`, and `domain-contradictions`, then final full `kb_check`
-10. **Prove execution**: read `kb_status.proofSnapshot`, run `kibi prove` so each configured integration executes once and its `kibi.proof-run.v1` artifact is evaluated against every selected test's `kibi.proof-contract.v1` obligations, appending idempotent `kibi.proof-receipt.v1` receipts; then re-run `kb_coverage`. Never promote durable test status into fresh evidence.
+10. **Prove execution**: read `kb_status.proofSnapshot`, run `kibi prove` so each configured integration executes once and its `kibi.proof-run.v1` artifact is evaluated against every selected test's `kibi.proof-contract.v1` obligations, appending idempotent `kibi.proof-receipt.v2` receipts; then re-run `kb_coverage` and read each requirement's `evidenceLevel` and `evidenceFloor`. Never promote durable test status into fresh evidence.
 11. **Repair incrementally**: require `kb_coverage.repairPlan.scope.complete`, apply only one `ready` dependency batch per requirement, validate before every sequential write, and rerun coverage before selecting the next batch
 12. **Gate workflow evidence**: when `.kb/usage.log` exists, run `kibi usage-metrics --format json --require-acceptance`; repair ranked telemetry diagnostics and never treat stale or insufficient evidence as a pass
 
@@ -144,7 +144,7 @@ choose package managers, ground semantic claims, resolve contradictions, rerun
 E2E tests, rewrite receipt history, remap authored symbols, or accept
 limitations. Those actions remain explicit review/operator/execution steps.
 
-For `e2e_receipt_freshness_low`, query each listed requirement/test gap and run `kibi prove --requirement <id>` (or the covering integration); this appends proof receipts idempotently and preserves history. If `coverage_depth_review` conflicts with a coverage row whose `proofStages.passingE2e.status` is `passed`, report the diagnostic as a stale heuristic and keep any independent proof gaps unresolved.
+For `e2e_receipt_freshness_low`, query each listed requirement/test gap and run `kibi prove --requirement <id>` (or the covering integration); this appends proof receipts idempotently and preserves history. If `coverage_depth_review` conflicts with a coverage row whose `proofStages.passingE2e.status` is `passed`, report the diagnostic as a stale heuristic and keep any independent proof gaps unresolved. For `coarse_anchor_only_review`, the requirement is implemented only by whole-file anchors: link the functions, methods or types that implement it (with `covered_by` to their tests) so its `tested` evidence is tied to that code.
 
 ## Creating a New Feature
 ```
@@ -172,8 +172,8 @@ Do not create a test-fact pair. Facts describe invariants; requirements or scena
 
 1. Confirm the exact `REQ -> SCEN -> TEST` path and require typed `verification_scope: end_to_end`; direct requirement-to-test links do not satisfy the conservative scenario stage.
 2. Read `kb_status` and retain its available `proofSnapshot`. Stop if the runtime reports `unknown`; proof must fail closed when the code identity cannot be computed.
-3. Run the exact E2E command against that snapshot. Record runner, command, start/finish timestamps, outcome, an environment SHA-256, and an artifact/output SHA-256. Do not mint a passed receipt from an authored test status or from an unexecuted assertion.
-4. Preserve every existing receipt byte-for-byte and append the derived `kibi.proof-receipt.v1` object with strictly later `finished_at`. Earlier receipts may bind older contracts or fingerprints; they remain audit history but cannot prove the current contract. Mutation and incremental sync reject history removal, rewriting, and reordering.
+3. Run `kibi prove --test TEST-<id>` (or `--requirement`, `--integration`, `--all`). It runs the configured producer once against that snapshot and appends a `kibi.proof-receipt.v2` receipt per evaluated contract. Never hand-write a receipt, and never mint a passed receipt from an authored test status or from an unexecuted assertion.
+4. Receipts are append-only. Earlier receipts, including `kibi.proof-receipt.v1` ones, may bind older contracts or fingerprints; they remain audit history but cannot prove the current contract. Mutation and incremental sync reject history removal, rewriting, and reordering.
 5. Re-read `kb_status`; if the snapshot changed during the run, discard the candidate as proof and rerun against the new snapshot. Then run `kb_coverage` and inspect `proofStages.passingE2e.receiptEvidence` plus gap codes.
 
 Only the newest receipt matching the live snapshot, current contract hash, and current execution fingerprint qualifies, and it must be passed, no more than seven days old, and no more than five minutes in the future. Wrong-snapshot and older-contract history is retained but cannot prove the current test. `missing_proof_receipt`, `stale_proof_receipt`, `failed_proof_receipt`, `invalid_proof_receipt`, `proof_contract_mismatch`, and `proof_snapshot_unavailable` are repair states, not warnings to waive.