kibi-cursor 2.9.0 → 2.9.2

package/.cursor-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "kibi-cursor",
   "displayName": "Kibi",
-  "version": "2.9.0",
+  "version": "2.9.2",
   "description": "Optional Cursor adapter for Kibi. Requires project-local kibi-cli, kibi-mcp, and kibi-core (SWI-Prolog is bundled on Linux and macOS) before the bundled MCP server can start.",
   "license": "AGPL-3.0-or-later",
   "author": {

package/CHANGELOG.md

@@ -1,5 +1,40 @@
 # kibi-cursor
 
+## 2.9.2
+
+### Patch Changes
+
+- 45036a3: Signoff guidance no longer tells agents to attach `latest.html` as a file. Chat apps (the Claude apps, Slack and most others) show an attached HTML file as raw source or a download, so agents now share the page only as a rendered page, such as a Claude Artifact, and otherwise leave the message text as the whole view. Updates the kibi-decisions and kibi-commit-review skills (1.2.1), the `kibi signoff` page note and the stop-hook reminder.
+- Updated dependencies [45036a3]
+  - kibi-agent-core@0.9.1
+
+## 2.9.1
+
+### Patch Changes
+
+- 39721a1: Every requirement now reports how strong the evidence behind it is, and passing end-to-end tests are no longer called proof.
+  - `kb_coverage` / `kibi coverage` rows carry `evidenceLevel`: `proved` (a re-checkable certificate covers every case; no proof kind issues one yet, so nothing reaches it today), `tested` (fresh end-to-end receipts cover every linked scenario), `asserted` (a person stands behind the requirement: it was approved, or it is firm by `firmness` or a non-agent origin, but nothing current checks it) or `unverified` (an agent wrote it and no person approved it). Each row lists the `evidence[]` entries that earned the level, with `kind`, `scope` and `level`, and the summary counts rows per level under `evidenceLevels`.
+  - The HTML report shows each requirement's level next to its id and counts the asserted and unverified requirements; its headline is now "Tested end to end" and the badge reads `% tested`. `kibi signoff` adds the level to each requirement's proof line when it is weaker than tested. The `kibi coverage` table gains an `Evidence` column and prints the per-level counts as `asserted=… proved=… tested=… unverified=…`. `kibi signoff` now counts a top-level `approved_by` as approval, as the evidence level does, so an approved agent requirement no longer shows as awaiting approval.
+  - The `kibi-usage` skill (2.23.0) explains the levels and tells agents never to report an asserted or unverified requirement as tested or proven.
+
+  **Migration (breaking).**
+  - The requirement proof contract is now `kibi.requirement-proof.v4`. `proofStatus: proven` is renamed `tested`; filter with `--status tested` (`statuses: ["tested"]`), since `proven` is rejected.
+  - Coverage summaries rename `proofProven` to `proofTested`. `kibi proof impact` results rename `proofProven` / `currentUnproven` to `proofTested` / `currentUntested`, `kb_apply_plan` closeout `proofState: proven` is now `tested`, and the diagnostic usage field `coverage_proven_count` is `coverage_tested_count`.
+  - `proof/baseline.json` files move to `kibi.proof-baseline.v3` with `proofTested`, `currentUntested` and `proofStatus: tested`. `kibi proof impact` still reads a committed v2 baseline, treating its `proven` rows as `tested`, so rewrite the file in the same commit you upgrade in or the next one.
+  - No knowledge-base migration is needed: nothing stored in `.kb/` changes.
+
+- a1c7479: `kibi check` and `kb_check` now prove that the knowledge base is consistent, and leave a certificate for each answer that an independent checker re-checks.
+
+  The new canonical `kb-consistency` rule states four theorems about the facts current requirements name and produces a `kibi.certificates.v1` certificate for each: property facts are consistent (a model per subject, property and scope, or an irreducible contradiction core with one model per dropped fact), predicate facts and allow/deny decisions are consistent (one truth value per atom, one decision per key, or the two facts that disagree), and stored rules are stratified (a stratum per rule predicate, or a negation cycle). A separate checker module re-checks every certificate by evaluation only; it never runs the search that found it and does not load `checks.pl`. Each contradiction it re-verifies is a blocking violation that names the core facts and the requirements behind them, with the certificate under `evidence.certificate`; a certificate the checker rejects also blocks.
+
+  The property theorem is joint, so facts that contradict only together (every pair still admits a value) are reported even though the pairwise `domain-contradictions` rule is silent. `kibi check --staged` runs the rule too, so a commit that introduces such a contradiction is blocked. Contexts the checker cannot compare (mixed value types or units, unsupported operators or polarities, cores whose validity windows never overlap) are reported by the new advisory `kb-consistency-unresolved` rule and never count as consistent. Opposing rule pairs and scenario feasibility are not certified yet.
+
+  Certificates are regenerated on each run and are not committed. `kibi check --write-certificates <file>` saves the bundle, and `kibi check --certificates <file>` re-checks a saved one and prints the `kibi.verification.v1` report (a verdict of `proved`, `disproved` or `unresolved` per theorem, and every rejected certificate with the reason). The kibi-usage skill (2.24.0) tells agents how to act on the new findings. The kibi-freshness skill (2.1.0) now checks consistency with `domain-contradictions`, `kb-consistency` and `kb-consistency-unresolved` instead of the pairwise rule alone, reports a `kb-consistency` core as a conflict to resolve by superseding or changing a requirement, and reports an unresolved context as unresolved.
+
+  **Migration (breaking for KBs with joint contradictions).** No knowledge-base change is needed. A knowledge base whose facts contradict only jointly now fails `kibi check` until one of the requirements is changed or superseded; the violation names the core and the requirements to choose from. Integrations that pass a fixed `--rules` list or `rules` input are unaffected until they add `kb-consistency`.
+
+  Evidence levels and `kibi signoff` now count an agent-written requirement as approved only through `origin.approved_by`, the field `agent-requirement-unapproved` already reads. The top-level `approved_by` approves an exception, and an agent can write it, so on its own it no longer raises a requirement to `asserted` or shows it as approved in signoff.
+
 ## 2.9.0
 
 ### Minor Changes

package/agent-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
   "name": "kibi",
-  "version": "2.9.0",
+  "version": "2.9.2",
   "description": "Repo-local, per-branch, queryable knowledge base. Portable Agent Plugin packaging Kibi's Agent Skills and MCP server.",
   "author": { "name": "Kibi" },
   "homepage": "https://looted.github.io/kibi/",

package/agent-plugin/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.1
 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/agent-plugin/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.2.1
 kibiCompatibility: ">=1.0.0"
 tags:
   - kibi

package/agent-plugin/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/agent-plugin/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.0.0
+version: 2.1.0
 kibiCompatibility: ">=1.0.0"
 tags:
   - kibi
@@ -53,7 +53,7 @@ echo '{}' | npx --no-install kibi status --input -
   `committed_with_repairs`, follow required typed `nextActions`; never retry the
   original operation.
 
-For every freshness, branch, or completion question, call `kb_status` first, then `kb_query` the entities and source files that status names, then `kb_check` as the last Kibi call before answering. Never skip the query step, even when status alone seems to answer the question. If another query or write follows a check, run `kb_check` again before answering. When asked whether requirements are consistent or proven, run `kb_query`, then `kb_check` with the domain-contradictions rule, then `kb_coverage`, and read whether the analysis was complete. Report any unmodeled or unknown clause as incomplete analysis, not as consistent. Only when every clause is fully modeled and compatible, state plainly that no conflict was found. For authorized knowledge changes, keep the exact supplied target and intended relationship edges, and discover and query those targets first. Validate the payload with `kb_upsert` and `dryRun: true`, then perform the authorized `kb_upsert` with that same payload and read the result back exactly before the final checks. A passing dry run is validation, not completion. Distinct authorized payloads may need several sequential writes, each validated and read back, but never retry a mutation that already committed. If a mutation returns `committed_with_repairs`, follow its typed `nextActions` instead of repeating the original operation.
+For every freshness, branch, or completion question, call `kb_status` first, then `kb_query` the entities and source files that status names, then `kb_check` as the last Kibi call before answering. Never skip the query step, even when status alone seems to answer the question. If another query or write follows a check, run `kb_check` again before answering. When asked whether requirements are consistent or proven, run `kb_query`, then `kb_check` with the rules `domain-contradictions`, `kb-consistency` and `kb-consistency-unresolved`, then `kb_coverage`, and read whether the analysis was complete. `domain-contradictions` compares facts two at a time; `kb-consistency` checks every fact of a property together, so a clean pairwise result is not proof. Report a `kb-consistency` violation as a conflict, name every requirement it lists, and give superseding or changing one of them as the next step; never edit or delete facts to make the check pass. Report a context `kb-consistency-unresolved` names as unresolved, never as consistent, with the step that would make it comparable. Report any unmodeled or unknown clause as incomplete analysis, not as consistent. Only when every clause is fully modeled and compatible, state plainly that no conflict was found. For authorized knowledge changes, keep the exact supplied target and intended relationship edges, and discover and query those targets first. Validate the payload with `kb_upsert` and `dryRun: true`, then perform the authorized `kb_upsert` with that same payload and read the result back exactly before the final checks. A passing dry run is validation, not completion. Distinct authorized payloads may need several sequential writes, each validated and read back, but never retry a mutation that already committed. If a mutation returns `committed_with_repairs`, follow its typed `nextActions` instead of repeating the original operation.
 
 ## Guidance
 

package/agent-plugin/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.22.0
+version: 2.24.0
 kibiCompatibility: ">=1.0.0"
 tags:
   - kibi
@@ -168,7 +168,7 @@ End every task with these five independent fields:
 taskOutcome: complete | interim | blocked
 kbState: clean_fresh | stale | dirty | legacy_compat | not_evaluated
 verificationState: fresh | dirty | unavailable | not_evaluated
-proofState: proven | mixed | unresolved | not_evaluated
+proofState: tested | mixed | unresolved | not_evaluated
 limitationDisposition: none | accepted | unaccepted | not_applicable
 ```
 

package/agent-plugin/skills/kibi-usage/resources/proof.md

@@ -1,6 +1,6 @@
 # Proof and Verification Workflow
 
-Use this resource when a requirement must be proven before handoff, when
+Use this resource when a requirement must be tested end to end before handoff, when
 wiring a proof-bearing test, or when `kb_ingest_proof` or `kibi prove`
 rejected evidence.
 
@@ -97,9 +97,9 @@ Cosmetic edits (descriptions, labels) never stale proof. Execution-relevant
 edits (command, artifact, targets, options, bindings, contract) change the
 effective fingerprint and do.
 
-## What counts toward proofProven
+## What counts toward proofTested
 
-A requirement is proven only by its scenarios' tests, and a scenario test
+A requirement reaches `proofStatus: tested` only through its scenarios' tests, and a scenario test
 counts only when it is an **end-to-end** test with a valid, fresh, passing
 receipt for the current snapshot.
 
@@ -109,7 +109,7 @@ receipt for the current snapshot.
   `source` path contains `e2e`) counts as end-to-end; anything else is
   `unknown` scope.
 - A `unit` or `integration` receipt is still recorded on the test entity, but
-  it does not move `proofProven` for a behavioural requirement: the
+  it does not move `proofTested` for a behavioural requirement: the
   requirement keeps the `missing_passing_e2e` gap in `proofGaps`. The one
   exception is a scenario whose specifying requirements are all grounded only
   in component-scope UI predicates (`ui_pattern`, `same_pattern`,
@@ -120,6 +120,38 @@ receipt for the current snapshot.
   receipt does not change it, and a `passing` status without a fresh receipt
   proves nothing.
 
+## Evidence levels
+
+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.
+- `tested`: `proofStatus` is `tested`; fresh E2E receipts cover every linked
+  scenario.
+- `asserted`: a person stands behind the statement (approved, or firm by
+  `firmness` or a non-agent origin) but nothing current checks it.
+- `unverified`: an agent wrote it, no person approved it, nothing checks it.
+
+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.
+
+## Knowledge-base certificates
+
+`kb_check` (`kibi check`) proves facts about the KB itself in its
+`kb-consistency` rule and re-checks each answer with an independent checker:
+property facts are consistent (a model per subject, property and scope, or an
+irreducible contradiction core), predicate facts and allow/deny decisions are
+consistent, and stored rules are stratified. It catches facts that contradict
+only together, which the pairwise `domain-contradictions` rule misses. A
+`kb-consistency` violation names the core facts and the requirements behind
+them: supersede or change one of those requirements; never edit the facts so
+the check passes. Quote a `kb-consistency-unresolved` diagnostic as
+unresolved, never as consistent. Opposing rule pairs and scenario
+feasibility are not certified yet; their own rules still decide them.
+
 ## Attempt semantics (factual, never optimistic)
 
 - `attempts: {status: "complete", entries: [...]}` — known history; the

package/agent-plugin/skills/kibi-usage/resources/workflows.md

@@ -9,7 +9,7 @@ success flag):
 taskOutcome: complete | interim | blocked
 kbState: clean_fresh | stale | dirty | legacy_compat | not_evaluated
 verificationState: fresh | dirty | unavailable | not_evaluated
-proofState: proven | mixed | unresolved | not_evaluated
+proofState: tested | mixed | unresolved | not_evaluated
 limitationDisposition: none | accepted | unaccepted | not_applicable
 ```
 

package/dist/.cursor-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "kibi-cursor",
   "displayName": "Kibi",
-  "version": "2.9.0",
+  "version": "2.9.2",
   "description": "Optional Cursor adapter for Kibi. Requires project-local kibi-cli, kibi-mcp, and kibi-core (SWI-Prolog is bundled on Linux and macOS) before the bundled MCP server can start.",
   "license": "AGPL-3.0-or-later",
   "author": {

package/dist/skills/.canon-hash.json

@@ -4,12 +4,12 @@
   "kibi-bootstrap/resources/branch-lifecycle.md": "c854264ce888439140883a3fc636db5e522f020dd27b30a5c1ecc4105b64ed13",
   "kibi-bootstrap/resources/operation-access.md": "b5a6a59e72d800c376e7fad79132897623c32a0ce152a1e8d73f9628b444db51",
   "kibi-bootstrap/resources/source-authoring.md": "bf296e62f69474e01797d6cb9469bf624551dca834dd188abb6e705bd96fa586",
-  "kibi-commit-review/SKILL.md": "d593f4f879be9aec0ddcd4003612a97fe6fa64298602ff6922f780e2a3ba4152",
+  "kibi-commit-review/SKILL.md": "cf08d0e4d4d6883b04c2059f4a4fa135531aff7a22f64f7d67f50318dff67972",
   "kibi-commit-review/resources/staged-gate.md": "993e5a08ab2be5ccd95695ec5f7600cd32ef6d75d1a9b962202183aa05fec51f",
-  "kibi-decisions/SKILL.md": "384749d6a9196c978a6df5a0d89fffe1fab7bad9554bc77e6bc45282567c4184",
+  "kibi-decisions/SKILL.md": "4953fa62ada7309e5cd0e845fdc7de0e8a34cdc4adca85303689a120ad28586e",
   "kibi-decisions/resources/decision-records.md": "1244ab963f78cfd47fc88dc9700bbfdbe2fad8a0d84da1fb7c40d718ccca710a",
-  "kibi-decisions/resources/signoff-views.md": "f5de0c378de9094949b372485d6e1f06398eb1c60cd234077a89af312f3c9d07",
-  "kibi-freshness/SKILL.md": "f1ccfa35dae113d7b3b2a61c455c1791dbc79732972d4604fbb82e002ff3c836",
+  "kibi-decisions/resources/signoff-views.md": "123da13a3f2b30b5672044a1284626e218d3088411f84f2692746f95e06c1393",
+  "kibi-freshness/SKILL.md": "7474b7c22ca915006e930850274bc71efaf2e03dcf60d41a2936b70d64547052",
   "kibi-freshness/resources/branch-lifecycle.md": "ebc01b19fe3dca8df5fc0175978963f6f1204f71f7c805cb2a5fb1b277ac78e4",
   "kibi-freshness/resources/operation-access.md": "4e1db9294ee540cd29b8b3a2532a81e7894d5b4228b39e99ba48b37212f489f3",
   "kibi-freshness/resources/source-authoring.md": "41a0547ce4d2a112a0f3671d36720f07c447864db3b473e94eb88a8ce2d371ff",
@@ -18,15 +18,15 @@
   "kibi-traceability/resources/operation-access.md": "39f7972ab7f4ae7479e78f7072bb50e8e6c4cdf4f857425f69d2522d37db437c",
   "kibi-traceability/resources/source-authoring.md": "408c6ee2bef1b84e0194c0538ef929c26a0a617e631b2234247388140dbbdd08",
   "kibi-traceability/resources/traceability.md": "38c290a0bc71bd1692e115f22694743946e2f69630e134acfd43cee5f613fb88",
-  "kibi-usage/SKILL.md": "c95fc81dfed557a46353df0ec3e9ab3cdf7fda8f3cf0a0062aec57d839873d4f",
+  "kibi-usage/SKILL.md": "e8efe1c31c601042cdcd3c96cb9cd81b009458410053a6cf5a44852dd0a1bcbf",
   "kibi-usage/resources/branch-lifecycle.md": "f1bf359e9826e83c548f3cd0287f8175a62456527b0132b06b3f9f74aa59b7d6",
   "kibi-usage/resources/fact-lanes.md": "899218f90396aa469b6e34aeb5f7ea1f38bf11bb326102319f376c213859fb33",
   "kibi-usage/resources/kb-improvement.md": "a8408fce27342bdce6415a6718599e53fe00bb33aa1fd3dc42353ec6f61adcd7",
   "kibi-usage/resources/logic-ir.md": "0e8ce8aad07433ab4803ec169149ff6c4e1cf8cf010af18fa6fd67862d9be807",
   "kibi-usage/resources/operation-access.md": "eb455796c066787ffd3fae8db0db1d3e87a84265a57f06ae61e30103cd6aed66",
-  "kibi-usage/resources/proof.md": "2348819078034dd3df25664c4c707ff98f17520bbbd335bff4f48611cf672bb3",
+  "kibi-usage/resources/proof.md": "d44ced11dca304495cab186eea84bf33fbd9932653821559a7f20b4f1c8d5606",
   "kibi-usage/resources/relationship-directions.md": "0fdd67032c2d15299f772845fc4f807eb9435b09507bd87a5911ab33db2f143d",
   "kibi-usage/resources/source-authoring.md": "cad93f1e0ae08a676f2de7492f9227677880302327e74d159618fea86ca50abe",
   "kibi-usage/resources/ui-requirements.md": "f99c2a9a73bbb7bd92ce1f231db3056d544588be149a5b0d3f7cc6f28bc9eee9",
-  "kibi-usage/resources/workflows.md": "9cfdcf8c21ad92ed5c72e0f350e9b1ab678ff263670e2c34d7d9277933ead1bf"
+  "kibi-usage/resources/workflows.md": "53c6889f375988a89a4cce8e68e79c7f621b15cc81cff915d61733642db87153"
 }

package/dist/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.1
 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/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.2.1
 kibiCompatibility: ">=1.0.0"
 tags:
   - kibi

package/dist/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/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.0.0
+version: 2.1.0
 kibiCompatibility: ">=1.0.0"
 tags:
   - kibi
@@ -53,7 +53,7 @@ echo '{}' | npx --no-install kibi status --input -
   `committed_with_repairs`, follow required typed `nextActions`; never retry the
   original operation.
 
-For every freshness, branch, or completion question, call `kb_status` first, then `kb_query` the entities and source files that status names, then `kb_check` as the last Kibi call before answering. Never skip the query step, even when status alone seems to answer the question. If another query or write follows a check, run `kb_check` again before answering. When asked whether requirements are consistent or proven, run `kb_query`, then `kb_check` with the domain-contradictions rule, then `kb_coverage`, and read whether the analysis was complete. Report any unmodeled or unknown clause as incomplete analysis, not as consistent. Only when every clause is fully modeled and compatible, state plainly that no conflict was found. For authorized knowledge changes, keep the exact supplied target and intended relationship edges, and discover and query those targets first. Validate the payload with `kb_upsert` and `dryRun: true`, then perform the authorized `kb_upsert` with that same payload and read the result back exactly before the final checks. A passing dry run is validation, not completion. Distinct authorized payloads may need several sequential writes, each validated and read back, but never retry a mutation that already committed. If a mutation returns `committed_with_repairs`, follow its typed `nextActions` instead of repeating the original operation.
+For every freshness, branch, or completion question, call `kb_status` first, then `kb_query` the entities and source files that status names, then `kb_check` as the last Kibi call before answering. Never skip the query step, even when status alone seems to answer the question. If another query or write follows a check, run `kb_check` again before answering. When asked whether requirements are consistent or proven, run `kb_query`, then `kb_check` with the rules `domain-contradictions`, `kb-consistency` and `kb-consistency-unresolved`, then `kb_coverage`, and read whether the analysis was complete. `domain-contradictions` compares facts two at a time; `kb-consistency` checks every fact of a property together, so a clean pairwise result is not proof. Report a `kb-consistency` violation as a conflict, name every requirement it lists, and give superseding or changing one of them as the next step; never edit or delete facts to make the check pass. Report a context `kb-consistency-unresolved` names as unresolved, never as consistent, with the step that would make it comparable. Report any unmodeled or unknown clause as incomplete analysis, not as consistent. Only when every clause is fully modeled and compatible, state plainly that no conflict was found. For authorized knowledge changes, keep the exact supplied target and intended relationship edges, and discover and query those targets first. Validate the payload with `kb_upsert` and `dryRun: true`, then perform the authorized `kb_upsert` with that same payload and read the result back exactly before the final checks. A passing dry run is validation, not completion. Distinct authorized payloads may need several sequential writes, each validated and read back, but never retry a mutation that already committed. If a mutation returns `committed_with_repairs`, follow its typed `nextActions` instead of repeating the original operation.
 
 ## Guidance
 

package/dist/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.22.0
+version: 2.24.0
 kibiCompatibility: ">=1.0.0"
 tags:
   - kibi
@@ -168,7 +168,7 @@ End every task with these five independent fields:
 taskOutcome: complete | interim | blocked
 kbState: clean_fresh | stale | dirty | legacy_compat | not_evaluated
 verificationState: fresh | dirty | unavailable | not_evaluated
-proofState: proven | mixed | unresolved | not_evaluated
+proofState: tested | mixed | unresolved | not_evaluated
 limitationDisposition: none | accepted | unaccepted | not_applicable
 ```
 

package/dist/skills/kibi-usage/resources/proof.md

@@ -1,6 +1,6 @@
 # Proof and Verification Workflow
 
-Use this resource when a requirement must be proven before handoff, when
+Use this resource when a requirement must be tested end to end before handoff, when
 wiring a proof-bearing test, or when `kb_ingest_proof` or `kibi prove`
 rejected evidence.
 
@@ -97,9 +97,9 @@ Cosmetic edits (descriptions, labels) never stale proof. Execution-relevant
 edits (command, artifact, targets, options, bindings, contract) change the
 effective fingerprint and do.
 
-## What counts toward proofProven
+## What counts toward proofTested
 
-A requirement is proven only by its scenarios' tests, and a scenario test
+A requirement reaches `proofStatus: tested` only through its scenarios' tests, and a scenario test
 counts only when it is an **end-to-end** test with a valid, fresh, passing
 receipt for the current snapshot.
 
@@ -109,7 +109,7 @@ receipt for the current snapshot.
   `source` path contains `e2e`) counts as end-to-end; anything else is
   `unknown` scope.
 - A `unit` or `integration` receipt is still recorded on the test entity, but
-  it does not move `proofProven` for a behavioural requirement: the
+  it does not move `proofTested` for a behavioural requirement: the
   requirement keeps the `missing_passing_e2e` gap in `proofGaps`. The one
   exception is a scenario whose specifying requirements are all grounded only
   in component-scope UI predicates (`ui_pattern`, `same_pattern`,
@@ -120,6 +120,38 @@ receipt for the current snapshot.
   receipt does not change it, and a `passing` status without a fresh receipt
   proves nothing.
 
+## Evidence levels
+
+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.
+- `tested`: `proofStatus` is `tested`; fresh E2E receipts cover every linked
+  scenario.
+- `asserted`: a person stands behind the statement (approved, or firm by
+  `firmness` or a non-agent origin) but nothing current checks it.
+- `unverified`: an agent wrote it, no person approved it, nothing checks it.
+
+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.
+
+## Knowledge-base certificates
+
+`kb_check` (`kibi check`) proves facts about the KB itself in its
+`kb-consistency` rule and re-checks each answer with an independent checker:
+property facts are consistent (a model per subject, property and scope, or an
+irreducible contradiction core), predicate facts and allow/deny decisions are
+consistent, and stored rules are stratified. It catches facts that contradict
+only together, which the pairwise `domain-contradictions` rule misses. A
+`kb-consistency` violation names the core facts and the requirements behind
+them: supersede or change one of those requirements; never edit the facts so
+the check passes. Quote a `kb-consistency-unresolved` diagnostic as
+unresolved, never as consistent. Opposing rule pairs and scenario
+feasibility are not certified yet; their own rules still decide them.
+
 ## Attempt semantics (factual, never optimistic)
 
 - `attempts: {status: "complete", entries: [...]}` — known history; the

package/dist/skills/kibi-usage/resources/workflows.md

@@ -9,7 +9,7 @@ success flag):
 taskOutcome: complete | interim | blocked
 kbState: clean_fresh | stale | dirty | legacy_compat | not_evaluated
 verificationState: fresh | dirty | unavailable | not_evaluated
-proofState: proven | mixed | unresolved | not_evaluated
+proofState: tested | mixed | unresolved | not_evaluated
 limitationDisposition: none | accepted | unaccepted | not_applicable
 ```
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "kibi-cursor",
-  "version": "2.9.0",
+  "version": "2.9.2",
   "description": "Kibi Cursor plugin - thin adapter for Cursor MCP integration and editor hooks",
   "type": "module",
   "main": "dist/index.js",
@@ -59,7 +59,7 @@
     }
   },
   "dependencies": {
-    "kibi-agent-core": "^0.9.0"
+    "kibi-agent-core": "^0.9.1"
   },
   "devDependencies": {
     "@types/node": "latest",

package/skills/.canon-hash.json

@@ -4,12 +4,12 @@
   "kibi-bootstrap/resources/branch-lifecycle.md": "c854264ce888439140883a3fc636db5e522f020dd27b30a5c1ecc4105b64ed13",
   "kibi-bootstrap/resources/operation-access.md": "b5a6a59e72d800c376e7fad79132897623c32a0ce152a1e8d73f9628b444db51",
   "kibi-bootstrap/resources/source-authoring.md": "bf296e62f69474e01797d6cb9469bf624551dca834dd188abb6e705bd96fa586",
-  "kibi-commit-review/SKILL.md": "d593f4f879be9aec0ddcd4003612a97fe6fa64298602ff6922f780e2a3ba4152",
+  "kibi-commit-review/SKILL.md": "cf08d0e4d4d6883b04c2059f4a4fa135531aff7a22f64f7d67f50318dff67972",
   "kibi-commit-review/resources/staged-gate.md": "993e5a08ab2be5ccd95695ec5f7600cd32ef6d75d1a9b962202183aa05fec51f",
-  "kibi-decisions/SKILL.md": "384749d6a9196c978a6df5a0d89fffe1fab7bad9554bc77e6bc45282567c4184",
+  "kibi-decisions/SKILL.md": "4953fa62ada7309e5cd0e845fdc7de0e8a34cdc4adca85303689a120ad28586e",
   "kibi-decisions/resources/decision-records.md": "1244ab963f78cfd47fc88dc9700bbfdbe2fad8a0d84da1fb7c40d718ccca710a",
-  "kibi-decisions/resources/signoff-views.md": "f5de0c378de9094949b372485d6e1f06398eb1c60cd234077a89af312f3c9d07",
-  "kibi-freshness/SKILL.md": "f1ccfa35dae113d7b3b2a61c455c1791dbc79732972d4604fbb82e002ff3c836",
+  "kibi-decisions/resources/signoff-views.md": "123da13a3f2b30b5672044a1284626e218d3088411f84f2692746f95e06c1393",
+  "kibi-freshness/SKILL.md": "7474b7c22ca915006e930850274bc71efaf2e03dcf60d41a2936b70d64547052",
   "kibi-freshness/resources/branch-lifecycle.md": "ebc01b19fe3dca8df5fc0175978963f6f1204f71f7c805cb2a5fb1b277ac78e4",
   "kibi-freshness/resources/operation-access.md": "4e1db9294ee540cd29b8b3a2532a81e7894d5b4228b39e99ba48b37212f489f3",
   "kibi-freshness/resources/source-authoring.md": "41a0547ce4d2a112a0f3671d36720f07c447864db3b473e94eb88a8ce2d371ff",
@@ -18,15 +18,15 @@
   "kibi-traceability/resources/operation-access.md": "39f7972ab7f4ae7479e78f7072bb50e8e6c4cdf4f857425f69d2522d37db437c",
   "kibi-traceability/resources/source-authoring.md": "408c6ee2bef1b84e0194c0538ef929c26a0a617e631b2234247388140dbbdd08",
   "kibi-traceability/resources/traceability.md": "38c290a0bc71bd1692e115f22694743946e2f69630e134acfd43cee5f613fb88",
-  "kibi-usage/SKILL.md": "c95fc81dfed557a46353df0ec3e9ab3cdf7fda8f3cf0a0062aec57d839873d4f",
+  "kibi-usage/SKILL.md": "e8efe1c31c601042cdcd3c96cb9cd81b009458410053a6cf5a44852dd0a1bcbf",
   "kibi-usage/resources/branch-lifecycle.md": "f1bf359e9826e83c548f3cd0287f8175a62456527b0132b06b3f9f74aa59b7d6",
   "kibi-usage/resources/fact-lanes.md": "899218f90396aa469b6e34aeb5f7ea1f38bf11bb326102319f376c213859fb33",
   "kibi-usage/resources/kb-improvement.md": "a8408fce27342bdce6415a6718599e53fe00bb33aa1fd3dc42353ec6f61adcd7",
   "kibi-usage/resources/logic-ir.md": "0e8ce8aad07433ab4803ec169149ff6c4e1cf8cf010af18fa6fd67862d9be807",
   "kibi-usage/resources/operation-access.md": "eb455796c066787ffd3fae8db0db1d3e87a84265a57f06ae61e30103cd6aed66",
-  "kibi-usage/resources/proof.md": "2348819078034dd3df25664c4c707ff98f17520bbbd335bff4f48611cf672bb3",
+  "kibi-usage/resources/proof.md": "d44ced11dca304495cab186eea84bf33fbd9932653821559a7f20b4f1c8d5606",
   "kibi-usage/resources/relationship-directions.md": "0fdd67032c2d15299f772845fc4f807eb9435b09507bd87a5911ab33db2f143d",
   "kibi-usage/resources/source-authoring.md": "cad93f1e0ae08a676f2de7492f9227677880302327e74d159618fea86ca50abe",
   "kibi-usage/resources/ui-requirements.md": "f99c2a9a73bbb7bd92ce1f231db3056d544588be149a5b0d3f7cc6f28bc9eee9",
-  "kibi-usage/resources/workflows.md": "9cfdcf8c21ad92ed5c72e0f350e9b1ab678ff263670e2c34d7d9277933ead1bf"
+  "kibi-usage/resources/workflows.md": "53c6889f375988a89a4cce8e68e79c7f621b15cc81cff915d61733642db87153"
 }

package/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.1
 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/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.2.1
 kibiCompatibility: ">=1.0.0"
 tags:
   - kibi

package/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/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.0.0
+version: 2.1.0
 kibiCompatibility: ">=1.0.0"
 tags:
   - kibi
@@ -53,7 +53,7 @@ echo '{}' | npx --no-install kibi status --input -
   `committed_with_repairs`, follow required typed `nextActions`; never retry the
   original operation.
 
-For every freshness, branch, or completion question, call `kb_status` first, then `kb_query` the entities and source files that status names, then `kb_check` as the last Kibi call before answering. Never skip the query step, even when status alone seems to answer the question. If another query or write follows a check, run `kb_check` again before answering. When asked whether requirements are consistent or proven, run `kb_query`, then `kb_check` with the domain-contradictions rule, then `kb_coverage`, and read whether the analysis was complete. Report any unmodeled or unknown clause as incomplete analysis, not as consistent. Only when every clause is fully modeled and compatible, state plainly that no conflict was found. For authorized knowledge changes, keep the exact supplied target and intended relationship edges, and discover and query those targets first. Validate the payload with `kb_upsert` and `dryRun: true`, then perform the authorized `kb_upsert` with that same payload and read the result back exactly before the final checks. A passing dry run is validation, not completion. Distinct authorized payloads may need several sequential writes, each validated and read back, but never retry a mutation that already committed. If a mutation returns `committed_with_repairs`, follow its typed `nextActions` instead of repeating the original operation.
+For every freshness, branch, or completion question, call `kb_status` first, then `kb_query` the entities and source files that status names, then `kb_check` as the last Kibi call before answering. Never skip the query step, even when status alone seems to answer the question. If another query or write follows a check, run `kb_check` again before answering. When asked whether requirements are consistent or proven, run `kb_query`, then `kb_check` with the rules `domain-contradictions`, `kb-consistency` and `kb-consistency-unresolved`, then `kb_coverage`, and read whether the analysis was complete. `domain-contradictions` compares facts two at a time; `kb-consistency` checks every fact of a property together, so a clean pairwise result is not proof. Report a `kb-consistency` violation as a conflict, name every requirement it lists, and give superseding or changing one of them as the next step; never edit or delete facts to make the check pass. Report a context `kb-consistency-unresolved` names as unresolved, never as consistent, with the step that would make it comparable. Report any unmodeled or unknown clause as incomplete analysis, not as consistent. Only when every clause is fully modeled and compatible, state plainly that no conflict was found. For authorized knowledge changes, keep the exact supplied target and intended relationship edges, and discover and query those targets first. Validate the payload with `kb_upsert` and `dryRun: true`, then perform the authorized `kb_upsert` with that same payload and read the result back exactly before the final checks. A passing dry run is validation, not completion. Distinct authorized payloads may need several sequential writes, each validated and read back, but never retry a mutation that already committed. If a mutation returns `committed_with_repairs`, follow its typed `nextActions` instead of repeating the original operation.
 
 ## Guidance
 

package/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.22.0
+version: 2.24.0
 kibiCompatibility: ">=1.0.0"
 tags:
   - kibi
@@ -168,7 +168,7 @@ End every task with these five independent fields:
 taskOutcome: complete | interim | blocked
 kbState: clean_fresh | stale | dirty | legacy_compat | not_evaluated
 verificationState: fresh | dirty | unavailable | not_evaluated
-proofState: proven | mixed | unresolved | not_evaluated
+proofState: tested | mixed | unresolved | not_evaluated
 limitationDisposition: none | accepted | unaccepted | not_applicable
 ```
 

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

@@ -1,6 +1,6 @@
 # Proof and Verification Workflow
 
-Use this resource when a requirement must be proven before handoff, when
+Use this resource when a requirement must be tested end to end before handoff, when
 wiring a proof-bearing test, or when `kb_ingest_proof` or `kibi prove`
 rejected evidence.
 
@@ -97,9 +97,9 @@ Cosmetic edits (descriptions, labels) never stale proof. Execution-relevant
 edits (command, artifact, targets, options, bindings, contract) change the
 effective fingerprint and do.
 
-## What counts toward proofProven
+## What counts toward proofTested
 
-A requirement is proven only by its scenarios' tests, and a scenario test
+A requirement reaches `proofStatus: tested` only through its scenarios' tests, and a scenario test
 counts only when it is an **end-to-end** test with a valid, fresh, passing
 receipt for the current snapshot.
 
@@ -109,7 +109,7 @@ receipt for the current snapshot.
   `source` path contains `e2e`) counts as end-to-end; anything else is
   `unknown` scope.
 - A `unit` or `integration` receipt is still recorded on the test entity, but
-  it does not move `proofProven` for a behavioural requirement: the
+  it does not move `proofTested` for a behavioural requirement: the
   requirement keeps the `missing_passing_e2e` gap in `proofGaps`. The one
   exception is a scenario whose specifying requirements are all grounded only
   in component-scope UI predicates (`ui_pattern`, `same_pattern`,
@@ -120,6 +120,38 @@ receipt for the current snapshot.
   receipt does not change it, and a `passing` status without a fresh receipt
   proves nothing.
 
+## Evidence levels
+
+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.
+- `tested`: `proofStatus` is `tested`; fresh E2E receipts cover every linked
+  scenario.
+- `asserted`: a person stands behind the statement (approved, or firm by
+  `firmness` or a non-agent origin) but nothing current checks it.
+- `unverified`: an agent wrote it, no person approved it, nothing checks it.
+
+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.
+
+## Knowledge-base certificates
+
+`kb_check` (`kibi check`) proves facts about the KB itself in its
+`kb-consistency` rule and re-checks each answer with an independent checker:
+property facts are consistent (a model per subject, property and scope, or an
+irreducible contradiction core), predicate facts and allow/deny decisions are
+consistent, and stored rules are stratified. It catches facts that contradict
+only together, which the pairwise `domain-contradictions` rule misses. A
+`kb-consistency` violation names the core facts and the requirements behind
+them: supersede or change one of those requirements; never edit the facts so
+the check passes. Quote a `kb-consistency-unresolved` diagnostic as
+unresolved, never as consistent. Opposing rule pairs and scenario
+feasibility are not certified yet; their own rules still decide them.
+
 ## Attempt semantics (factual, never optimistic)
 
 - `attempts: {status: "complete", entries: [...]}` — known history; the

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

@@ -9,7 +9,7 @@ success flag):
 taskOutcome: complete | interim | blocked
 kbState: clean_fresh | stale | dirty | legacy_compat | not_evaluated
 verificationState: fresh | dirty | unavailable | not_evaluated
-proofState: proven | mixed | unresolved | not_evaluated
+proofState: tested | mixed | unresolved | not_evaluated
 limitationDisposition: none | accepted | unaccepted | not_applicable
 ```