kibi-cli 2.31.0 → 2.32.0

package/dist/public/proof-receipt.js

@@ -1,6 +1,17 @@
 import { canonicalJson, proofContractHash, } from "./proof-fingerprint.js";
-import { PROOF_RECEIPT_VERSION, PROOF_RESULT_OUTCOMES, PROOF_RUN_OUTCOMES, } from "./proof-protocol.js";
+import { PROOF_KINDS, PROOF_RECEIPT_VERSION, PROOF_RECEIPT_VERSIONS, PROOF_RESULT_OUTCOMES, PROOF_RUN_OUTCOMES, isCertificateProofKind, } from "./proof-protocol.js";
 export const PROOF_RECEIPT_MAX_AGE_SECONDS = 7 * 24 * 60 * 60;
+/**
+ * How a certificate binds to a claim its contract names in proves: derived
+ * (Kibi checked it against the claim's fact; the only verdict that proves),
+ * attested (the fact has no derivation; the author vouches) or rejected.
+ */
+// implements REQ-kibi-claim-bound-proofs
+export const CLAIM_BINDING_VERDICTS = [
+    "derived",
+    "attested",
+    "rejected",
+];
 export const PROOF_RECEIPT_OUTCOMES = [
     "passed",
     "failed",
@@ -12,7 +23,7 @@ export const PROOF_RECEIPT_OUTCOMES = [
 ];
 export const PROOF_RECEIPT_SCHEMA = {
     type: "object",
-    description: "Kibi-derived kibi.proof-receipt.v1. Receipts are never caller-authored; kb_ingest_proof derives them from kibi.proof-run.v1 artifacts.",
+    description: "Kibi-derived kibi.proof-receipt.v2 (kibi.proof-receipt.v1 entries are still read). Receipts are never caller-authored; kb_ingest_proof derives them from kibi.proof-run.v1 artifacts.",
     required: [
         "version",
         "receipt_id",
@@ -34,7 +45,7 @@ export const PROOF_RECEIPT_SCHEMA = {
         "proof_results",
     ],
     properties: {
-        version: { type: "string", const: PROOF_RECEIPT_VERSION },
+        version: { type: "string", enum: [...PROOF_RECEIPT_VERSIONS] },
         receipt_id: {
             type: "string",
             pattern: "^PR-[A-Za-z0-9][A-Za-z0-9._:-]{7,127}$",
@@ -131,6 +142,32 @@ export const PROOF_RECEIPT_SCHEMA = {
                 additionalProperties: false,
             },
         },
+        kind: { type: "string", enum: [...PROOF_KINDS] },
+        evidence_level: { type: "string", enum: ["proved", "tested"] },
+        certificate: { type: "object" },
+        certificate_digest: { type: "string", pattern: "^[a-f0-9]{64}$" },
+        certificate_rejection: { type: "string", minLength: 1 },
+        claim_bindings: {
+            type: "array",
+            description: "Certificate kinds: how the certificate binds to each claim its contract names in proves, judged at ingest. derived means Kibi derived the certificate's obligation from the claim's grounding fact and the certificate satisfies it; attested means no derivation exists and the author vouches for it (never proved); rejected names why.",
+            items: {
+                type: "object",
+                required: ["claim_key", "binding"],
+                properties: {
+                    claim_key: { type: "string", minLength: 1 },
+                    requirement_id: { type: "string", minLength: 1 },
+                    fact_id: { type: "string", minLength: 1 },
+                    binding: {
+                        type: "string",
+                        enum: [...CLAIM_BINDING_VERDICTS],
+                    },
+                    scope: { type: "string", enum: ["code", "intent"] },
+                    obligation: { type: "object" },
+                    reason: { type: "string", minLength: 1 },
+                },
+                additionalProperties: false,
+            },
+        },
         gaps: {
             type: "array",
             items: {
@@ -209,12 +246,14 @@ function validFingerprintComponents(value) {
         hex64(row.bindings) &&
         hex64(row.producer));
 }
-/** Structural validation of one kibi.proof-receipt.v1 entry. */
+/** Structural validation of one kibi.proof-receipt.v1 or v2 entry. */
 export function validProofReceiptShape(testId, receipt) {
     const row = isRecord(receipt) ? receipt : null;
     if (!row)
         return false;
-    if (row.version !== PROOF_RECEIPT_VERSION)
+    if (!PROOF_RECEIPT_VERSIONS.includes(row.version))
+        return false;
+    if (row.version === PROOF_RECEIPT_VERSION && !validV2Fields(row))
         return false;
     if (typeof row.receipt_id !== "string" ||
         !/^PR-[A-Za-z0-9][A-Za-z0-9._:-]{7,127}$/.test(row.receipt_id))
@@ -268,9 +307,46 @@ export function validProofReceiptShape(testId, receipt) {
         return false;
     return !finishedAtPrecedesStartedAt(startedAt, finishedAt);
 }
+// implements REQ-kibi-code-proof-kinds
+function validV2Fields(row) {
+    if (!PROOF_KINDS.includes(row.kind))
+        return false;
+    if (row.evidence_level !== "proved" && row.evidence_level !== "tested")
+        return false;
+    if (row.evidence_level === "proved" &&
+        (row.outcome !== "passed" ||
+            !isCertificateProofKind(row.kind) ||
+            !isRecord(row.certificate) ||
+            !hex64(row.certificate_digest) ||
+            row.certificate_rejection !== undefined))
+        return false;
+    if (row.certificate !== undefined && !isRecord(row.certificate))
+        return false;
+    if (row.certificate_digest !== undefined && !hex64(row.certificate_digest))
+        return false;
+    if (row.certificate_rejection !== undefined &&
+        !nonEmptyString(row.certificate_rejection))
+        return false;
+    if (row.claim_bindings !== undefined &&
+        !validClaimBindings(row.claim_bindings))
+        return false;
+    return true;
+}
+// implements REQ-kibi-claim-bound-proofs
+function validClaimBindings(value) {
+    return (Array.isArray(value) &&
+        value.every((entry) => isRecord(entry) &&
+            nonEmptyString(entry.claim_key) &&
+            CLAIM_BINDING_VERDICTS.includes(entry.binding) &&
+            (entry.scope === undefined ||
+                entry.scope === "code" ||
+                entry.scope === "intent") &&
+            (entry.obligation === undefined || isRecord(entry.obligation)) &&
+            (entry.reason === undefined || nonEmptyString(entry.reason))));
+}
 /**
  * Full-history validation for proof_receipts: unique ids, per-test binding,
- * supported scope, ordered timestamps, and structurally valid v1 entries.
+ * supported scope, ordered timestamps, and structurally valid v1 or v2 entries.
  */
 export function proofReceiptHistoryErrors(testId, verificationScope, receipts) {
     const errors = [];
@@ -291,7 +367,7 @@ export function proofReceiptHistoryErrors(testId, verificationScope, receipts) {
             errors.push(`${prefix}.test_id must equal '${testId}'`);
         }
         if (!validProofReceiptShape(testId, receipt)) {
-            errors.push(`${prefix} must be a structurally valid kibi.proof-receipt.v1 bound to '${testId}'`);
+            errors.push(`${prefix} must be a structurally valid kibi.proof-receipt.v2 (or v1) bound to '${testId}'`);
             continue;
         }
         const finishedAt = timestamp(receipt.finished_at);

package/dist/public/schemas/entity.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"entity.d.ts","sourceRoot":"","sources":["../../../src/public/schemas/entity.ts"],"names":[],"mappings":"AAwTA,QAAA,MAAM,YAAY,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAwazC,CAAC;AAEF,eAAe,YAAY,CAAC"}
+{"version":3,"file":"entity.d.ts","sourceRoot":"","sources":["../../../src/public/schemas/entity.ts"],"names":[],"mappings":"AAyTA,QAAA,MAAM,YAAY,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAybzC,CAAC;AAEF,eAAe,YAAY,CAAC"}

package/dist/public/schemas/entity.js

@@ -16,6 +16,7 @@
  along with this program.  If not, see <https://www.gnu.org/licenses/>.
  */
 import { ENTITY_ORIGIN_SCHEMA } from "../entity-origin.js";
+import { EVIDENCE_LEVELS } from "../evidence-levels.js";
 import { PROOF_BINDINGS_SCHEMA, PROOF_CONTRACT_SCHEMA, } from "../proof-protocol.js";
 import { PROOF_RECEIPT_SCHEMA } from "../proof-receipt.js";
 // Typed fact field enums per proposal
@@ -338,6 +339,11 @@ const entitySchema = {
             enum: ["firm", "default", "exploratory"],
             description: "Requirement and ADR only. How firmly the decision was made. firm: a human stated it as a rule; it needs a ref (origin.ref, or approval_ref on a requirement) to their words, and only a human may change it. default: a delegated or agent choice; a later agent may supersede it with evidence. exploratory: a flagged guess, expected to be revisited. When absent, it reads as default if an agent wrote the entity (origin.kind agent) and as firm otherwise (a person's, imported or migrated decision); set it explicitly when recording a decision.",
         },
+        required_evidence: {
+            type: "string",
+            enum: [...EVIDENCE_LEVELS],
+            description: "Requirement-only. The weakest evidence level this current requirement accepts; the evidence-floor check rule fails while its computed evidence level is lower. proved: a re-checkable certificate covers every case. tested: fresh passing E2E receipts cover every linked scenario. asserted: a person stands behind it. unverified: no floor. When absent, it is tested for a firm requirement and unverified otherwise.",
+        },
         expects: {
             type: "string",
             enum: ["success", "rejection", "error"],
@@ -509,8 +515,17 @@ const entitySchema = {
         subject_key: { type: "string" },
         property_key: { type: "string" },
         operator: { type: "string", enum: ["eq", "neq", "lt", "lte", "gt", "gte"] },
-        value_type: { type: "string", enum: ["string", "int", "number", "bool"] },
+        value_type: {
+            type: "string",
+            enum: ["string", "int", "number", "bool", "set"],
+        },
         value_string: { type: "string" },
+        value_set: {
+            type: "array",
+            items: { type: "string", minLength: 1 },
+            minItems: 1,
+            uniqueItems: true,
+        },
         value_int: { type: "integer" },
         value_number: { type: "number" },
         value_bool: { type: "boolean" },
@@ -609,6 +624,7 @@ const entitySchema = {
                         { required: ["value_int"] },
                         { required: ["value_number"] },
                         { required: ["value_bool"] },
+                        { required: ["value_set"] },
                         { required: ["unit"] },
                         { required: ["scope"] },
                         { required: ["polarity"] },
@@ -681,6 +697,7 @@ const entitySchema = {
                         { required: ["approval_ref"] },
                         { required: ["rationale"] },
                         { required: ["exempts_claims"] },
+                        { required: ["required_evidence"] },
                     ],
                 },
             },

package/dist/public/skills/kibi-bootstrap/SKILL.md

@@ -2,7 +2,7 @@
 id: kibi-bootstrap
 name: kibi-bootstrap
 description: "Use for any Kibi bootstrap or onboarding task: seeding a new or thin knowledge base; reviewing a bootstrap or onboarding plan, preview, or evidence; judging approval readiness or coverage; diagnosing a blocked, partial, or failed bootstrap or its repair; applying an approved bootstrap plan; or asking the human which knowledge sources hold intent. Covers kb_status first, source interview, cited intent claims, read-only kb_plan_bootstrap preview, explicit approval, exact-plan kb_apply_plan, and repair-safe close-out."
-version: 3.16.0
+version: 3.17.0
 kibiCompatibility: ">=1.0.0"
 tags:
   - kibi
@@ -43,7 +43,7 @@ Seed branch-local Kibi knowledge from cited product intent, without creating a p
 9. **Read back** with `kb_query` and `kb_search` to confirm writes and citations.
 10. **Close out** with `kb_check`, then `kb_status`.
 11. **Deepen.** Bootstrap is complete; the KB is now half-way, holding cited `req` entries and review facts but no scenarios, tests or predicates. Load `kibi-usage` and continue in the normal Kibi workflow, one area at a time, telling the human what you author:
-    - **Unplanned claims.** For every claim suppressed as `invalid_write` and every `sourceOnlySignals` entry ("Author requirement …"), restate the claim's statement and citation (`sourceId:reference`), model it with `kb_model` (`mode: "requirement"`, or `mode: "predicates"` for domain claims), and write the result with `kb_upsert` (`dryRun: true` first) with `origin: {kind: "import", ref: "<sourceId:reference>"}` and `firmness: "firm"`, as the plan does for the claims it writes. Without an explicit origin `kb_upsert` records the requirement as the agent's own `default` choice, which a later agent may supersede without asking.
+    - **Unplanned claims.** For every claim suppressed as `invalid_write` and every `sourceOnlySignals` entry ("Author requirement …"), restate the claim's statement and citation (`sourceId:reference`), model it with `kb_model` (`mode: "requirement"`, or `mode: "predicates"` for domain claims), and write the result with `kb_upsert` (`dryRun: true` first) with `origin: {kind: "import", ref: "<sourceId:reference>"}` and `firmness: "firm"` and `required_evidence: "asserted"`, as the plan does for the claims it writes; raise the floor (drop `required_evidence`) only once an end-to-end proof covers the requirement. Without an explicit origin `kb_upsert` records the requirement as the agent's own `default` choice, which a later agent may supersede without asking.
     - **Scenarios.** Write scenarios from the cited ticket's acceptance criteria, one scenario per criterion, not bulk drafts from the requirement title; ask the human when the source states none. Give each a plain title, the scenario prose in `document.body` (never in `properties`), and `assumes` links to the `property_value` facts whose values the scenario relies on. Set `expects` only when the scenario links `assumes` facts (or its criterion names concrete values that become them); `expects` without `assumes` only yields a feasibility-unknown warning, so a draft tagged `needs-human-review` omits `expects`. Then link the requirement with `specified_by` (upsert the `req` with its stored `title`, a `status` and that relationship only). Example: criterion "Given an annotation in draft state, when the user deletes it, the draft is cleared" becomes `{"type":"scenario","id":"SCEN-annotation-delete-clears-draft","properties":{"title":"Deleting a draft annotation clears the draft","status":"active","expects":"success"},"document":{"body":"Given an annotation in draft state, when the user deletes it, then the draft is cleared and nothing is published.\n\nThe acceptance criterion comes from the cited ticket; reviewers asked for it so a deleted draft never reappears after reload.\n"},"relationships":[{"type":"assumes","from":"SCEN-annotation-delete-clears-draft","to":"FACT-annotation-state-draft"}]}`, where the assumed fact is a `property_value` (`annotation.state` `eq` `draft`). Link existing tests that exercise it; never invent test evidence.
     - **Predicates.** Run `kb_model` with `mode: "predicates"` and `requirementId` on each persisted requirement and apply a returned plan with `requires_predicate` to its `relationshipTarget` (the planned `FACT-PRED-…` id, never a `SUGGEST-…` candidate id), or record the `review:ontology-gap` observation it returns, with its prose in `document.body`. A non-empty `existingGrounding` means the bootstrap already grounded that claim: on `replace_grounding` leave it unless the human wants the `replacementPlan` swap; on `provide_argument_bindings` retry with the listed arguments bound; on `record_ontology_gap` still write the returned gap observation, which is not a grounding link. Count what `kb_query` shows afterwards, not the calls you made.
     - **Unrecorded ambiguity.** Record any conflict or open question you found but did not declare in step 3 as a cited `fact_kind: observation` tagged `review:conflict` or `review:open-question`.

package/dist/public/skills/kibi-commit-review/SKILL.md

@@ -2,7 +2,7 @@
 id: kibi-commit-review
 name: kibi-commit-review
 description: "Use when kibi check --staged or the Kibi pre-commit hook blocks a commit (kibi_impact_evidence_missing, symbols_manifest_stale, symbol_granularity_violation, symbol-coverage, kibi check-generated drift, Staged impact review failed), or when preparing a commit or pull-request impact review. Covers reading the per-file Detail lines, authoring .kb/symbols.yaml symbol entries through kb_upsert, kibi sync --refresh-symbol-coordinates, staging the tracked Kibi evidence with git add, kb_prepare_impact_review for a staged or diff scope, the kibi signoff requirements summary to show before a commit, and how merge commits and migration renames are judged."
-version: 1.2.0
+version: 1.2.2
 kibiCompatibility: ">=1.0.0"
 tags:
   - kibi
@@ -85,8 +85,9 @@ requirement with its statement (before and after for a rewrite), firmness,
 origin, scenarios and proof state. Put it in your reply unchanged (in the
 messaging tool's message when replies go through one), then add one or two
 sentences on why the requirements changed. Offer the full page with
-`kibi signoff --format html --open`, or attach or publish
-`.kb/briefs/signoff/latest.html` when your host can carry a file or a page;
+`kibi signoff --format html --open`, or publish `.kb/briefs/signoff/latest.html`
+as a rendered page when your host has a page tool (the Artifact tool in Claude
+apps); never attach the `.html` as a file, which chat apps show as raw source;
 past 15 requirements the Markdown stops and only the page lists them all.
 Host details: `kibi-decisions`, `resources/signoff-views.md`. `--no-proof` skips the proof lookup, which reads coverage and is slow
 on a large knowledge base. The summary is not an approval: never set

package/dist/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/dist/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/dist/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/dist/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/dist/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/dist/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/dist/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/dist/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.