kibi-cursor 2.6.7 → 2.6.9

package/.cursor-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "kibi-cursor",
   "displayName": "Kibi",
-  "version": "2.6.7",
+  "version": "2.6.9",
   "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,29 @@
 # kibi-cursor
 
+## 2.6.9
+
+### Patch Changes
+
+- 50b7a65: The kibi-usage skill (2.14.0) now says plainly what moves `proofProven`: only an end-to-end test (by its `verification_scope`) with a fresh passing receipt; unit receipts are recorded but leave the `missing_passing_e2e` gap. Its second-agent recipes now create scenarios with `assumes` links to the facts they rely on, so a new or superseding requirement no longer leaves a "Scenario expects success but assumes nothing" warning. `kibi proof inspect` shows the command each configured integration runs.
+
+  Technical summary: kibi-usage `resources/proof.md` gains a "What counts toward proofProven" section (scope source, unit/integration receipts, the component-scope UI exception, `coverage_depth` following authored status); recipes 1 and 2 of "Second-agent edits" add `assumes` (sent in the scenario's own write) and `expects` only with `assumes`, and re-pointing or closing the old scenario. `kibi proof inspect --json` adds `currentIntegrations: [{ id, producer, command }]` beside the compatible `currentIntegration`, and the text output lists each integration's command. Host skill copies are regenerated.
+
+## 2.6.8
+
+### Patch Changes
+
+- 95d4a9e: A migration plan that `kb_apply_plan` refuses no longer looks like a success. Re-applying a proof-integration plan whose `.kb/proof/integrations.json` already exists (or one whose runner config changed since planning) used to return `status: "success"` with `outcome: "reconciliation_required"`, so an agent reading only the status thought it had worked. It now returns an error result (`status: "error"`, MCP `isError: true`, CLI exit code 1) with code `MIGRATION_PLAN_REFUSED`, `data.outcome: "refused"` and the refusal reason in the message; nothing was changed and nothing needs reconciling.
+
+  Technical summary: `kibi.migration-apply-result.v1` gains `outcome: "refused"` (with `closeout.taskOutcome: "blocked"`) for an application that applied no action and whose every failure was a `MigrationActionRefusedError`: the proof-integration executor's refusals, predicate-schema-alignment drift and malformed invocations, and an action code with no automatic executor. `reconciliation_required` keeps meaning an action failed without being refused. `toKibiResult` turns a refused migration result into an error envelope with effects `not_applicable`; the CLI JSON route now exits 1 for any error envelope it returns (also a rejected bootstrap plan), and the MCP tool wrapper sets `isError: true` for one. `docs/mcp-reference.md` documents each migration outcome and how `kb_delete` reports an authored-entity refusal (status success, `deleted: 0`, the reason in `errors`); `docs/error-reference.md` adds `MIGRATION_PLAN_REFUSED`; kibi-usage describes both.
+
+- 2e54379: `kb_model` (`mode: "predicates"`) now recognises everyday permission statements. "Suspended users must not publish articles." — the kibi-usage skill's own deny example — returns an applicable `permission_rule` candidate instead of an ontology-gap observation, and so do claims such as "Only editors may approve drafts.". Subject and actor keys derived from plurals are spelled correctly: "coaches" becomes `coach` (not `coache`), "policies" becomes `policy`, and singular words such as "access" or "analysis" keep their final "s".
+
+  Technical summary: the `permission_rule` applicability gate keeps its action-cue list and also accepts a common action verb (publish, approve, assign, view, edit, create, submit, share, complete and similar) when it directly follows the permission modal (`may`, `can`, `cannot`, `must not`, `is allowed to`, …), so a quota such as "Uploads must not exceed 10 MB." still does not read as a permission. Both `singularize` helpers (predicate modeling and the semantic advisor) now share `singularizeToken`: `-ches`/`-shes`/`-sses`/`-xes` drop "es", `-ies` becomes "y", and tokens ending in "ss", "us" or "is" are kept; each helper keeps its existing exceptions. kibi-usage 2.13.0 shows the four-argument `permission_rule(suspended_user,publish,articles,deny)` fact that `kb_model` plans for the fact-lanes deny example.
+
+- f4cc71c: Agents setting up proof now learn up front that a `command` integration is judged as one run: when `kibi proof inspect` proposes the package's whole `test` script, `integrationPlanReason` (also printed in the human output now) says that any failing test in the run fails every proof obligation that names the integration, and how to narrow it. The new `kibi proof inspect --command "<command>"` option proposes that command instead of the detected one, so `kibi proof inspect --update <id> --command "…" --json` can narrow an existing integration to the proof-bearing tests. The kibi-usage proof resource also states that every `required_proofs[].symbol_id` must name an existing symbol entity (create it first) and that `proof_bindings[].source_file` must match that symbol's `sourceFile`.
+
+  Technical summary: `proposeProofIntegration` and `buildProofIntegrationPlan` accept an explicit argv (`--command`, parsed as space-separated words or a JSON array of strings) ahead of the `package.json` test script and the detected runner; a plan built from the package test script appends the whole-run note to its reason. kibi-usage 2.13.0 `resources/proof.md`, `docs/cli-reference.md` and `docs/proving-requirements.md` document the option and the whole-run semantics (the latter no longer suggests an update plan can switch to a native producer).
+
 ## 2.6.7
 
 ### Patch 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.6.7",
+  "version": "2.6.9",
   "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-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.12.0
+version: 2.14.0
 kibiCompatibility: ">=1.0.0"
 tags:
   - kibi
@@ -148,7 +148,13 @@ error `BOOTSTRAP_PLAN_REJECTED` can follow earlier committed actions: inspect
 `data.actionResults` and `data.applied`, then re-plan from the current state.
 Its journal is terminal; never recover or replay it. `BOOTSTRAP_PLAN_INVALID`
 fails preflight before bootstrap writes or a new journal; obtain a corrected
-plan. If the status is
+plan. A migration plan whose actions were refused before changing anything
+returns `status: error`, `MIGRATION_PLAN_REFUSED` and `data.outcome:
+refused`: nothing changed, so read the action `detail` and get a new plan.
+`data.outcome: reconciliation_required` (status success) means an action
+failed mid-way: inspect its effect before retrying. `kb_delete` of an
+authored entity returns status success with `deleted: 0`; its `errors` say
+why nothing was deleted. If the status is
 `committed_with_repairs`, the mutation already committed: inspect failed effects,
 execute each required repair action in order, and never retry the original
 operation. Record effect failures, followed actions, and unsafe retries in
@@ -231,7 +237,11 @@ authored. Each one is the order the write path accepts.
    fact, `requires_predicate` to `relationshipTarget` and `specified_by` to
    its scenario: `specified_by` (req → scenario) is sent in the
    requirement's write, never in the scenario's, so create the scenario
-   first. A
+   first, with `assumes` links (scenario → `property_value` fact, sent in
+   the scenario's own write) to the values its outcome relies on. Set
+   `expects` only on a scenario that has `assumes` links; `expects: success`
+   without them only yields `scenario-feasibility-unknown` ("assumes
+   nothing"). A
    `modeled` entry and its grounding link must arrive in the same write
    (`modeled semantic_inventory entries (n) must equal logical grounding
    relationships (m)`); a clause not grounded yet stays `status: missing`
@@ -243,7 +253,12 @@ authored. Each one is the order the write path accepts.
    claim_keys must match logical grounding target claim_keys exactly`.
    Prefer supersession for a change of meaning: analyze the new prose,
    write its facts, write the new requirement (`-v2`) with `supersedes` to
-   the old one, then set the old one to `status: closed`. For a wording fix
+   the old one, then set the old one to `status: closed`. Its scenario
+   follows the same rule as in recipe 1: create the new scenario (with
+   `assumes` to the `property_value` facts it relies on, and `expects` only
+   when it has them) before the `-v2` write that sends `specified_by`, then
+   re-point the old scenario (its `assumes` go in its own write) or close
+   it. For a wording fix
    that keeps the meaning, re-ground in place: analyze the new prose,
    `kb_upsert` each grounding fact with the new `claim_key`/`claim_text`
    (same fact id), then `kb_upsert` the requirement with the new ledger,

package/agent-plugin/skills/kibi-usage/resources/fact-lanes.md

@@ -61,16 +61,16 @@ A schema can close an argument with `argument_constants` (allowed values keyed b
 
 ### Deny predicate
 
-Claim: “Suspended users must not publish articles.” When `permission_rule` fits, preserve its positive schema name and encode prohibition as polarity:
+Claim: “Suspended users must not publish articles.” When `permission_rule` fits, preserve its positive schema name and encode prohibition as polarity. `kb_model` (`mode: "predicates"`) plans this fact for the claim; the built-in schema's fourth argument, `decision`, repeats the polarity:
 
 ```yaml
 id: FACT-SUSPENDED-PUBLISH-DENIED
 status: active
 fact_kind: predicate
 predicate_name: permission_rule
-predicate_args: [suspended_user, publish, article]
+predicate_args: [suspended_user, publish, articles, deny]
 polarity: deny
-canonical_key: permission_rule(suspended_user,publish,article)
+canonical_key: permission_rule(suspended_user,publish,articles,deny)
 claim_key: <advisor-issued key for this exact clause>
 claim_text: Suspended users must not publish articles.
 relationship: { type: requires_predicate, from: REQ-SUSPENDED-PUBLISH-DENIED, to: FACT-SUSPENDED-PUBLISH-DENIED }

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

@@ -51,6 +51,15 @@ proof_bindings:                 # optional provenance metadata
 
 Provenance lives in `proof_bindings`; the contract stays semantic.
 
+- 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`
+  symbol): a production symbol `implements` the requirement and is
+  `covered_by` the test; an executable test symbol is `executable_for` it.
+- `proof_bindings[].source_file`, when set, must equal the named symbol's
+  `sourceFile`: for a production symbol that is the production file, not the
+  spec file that exercises it. Omit it when unsure.
+
 ## Integration configuration
 
 `.kb/proof/integrations.json` (`kibi.proof-integration.v1`) is tracked,
@@ -62,12 +71,21 @@ returns `integrationPlan`, a hash-bound `kibi.migration-plan.v2`, plus the
 proposal to the human, then apply the plan with `kb_apply_plan` (or
 `kibi apply-plan --input -`) passing `plan`, `approvedPlanHash` (the plan's
 `planHash`) and `approvedActionIds`. Once the file exists, a create plan is
-refused; `kibi proof inspect --update <id> --json` plans adding or replacing
-one named integration.
+refused (`status: error`, `MIGRATION_PLAN_REFUSED`, `data.outcome: refused`;
+nothing is written); `kibi proof inspect --update <id> --json` plans adding or
+replacing one named integration.
 
 - `producer: command` — Kibi synthesizes the envelope from the process
   outcome; obligations are bound with `aggregate_run` provenance and the
-  single process invocation counts as the known first attempt.
+  single process invocation counts as the known first attempt. The run is
+  judged as a whole: any failing test in it fails every obligation of every
+  test that names the integration, so a suite with unrelated failures proves
+  nothing. Narrow the command to the proof-bearing tests with
+  `kibi proof inspect --update <id> --command "<command>" --json` (without
+  `--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.
 - `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`
@@ -79,6 +97,29 @@ 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
+
+A requirement is proven only by 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.
+
+- The scope comes from the test entity's `verification_scope`
+  (`end_to_end`, `integration`, `unit`), never from the integration id or the
+  producer. Without `verification_scope`, a test tagged `e2e` (or whose
+  `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
+  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`,
+  `pattern_marker`); a unit or integration test that renders the component
+  may prove it.
+- `coverage_depth` (`kb_coverage`, `kb_find_gaps`) follows the test's
+  authored `status` (`passing`) and scope, not its receipts: a passing
+  receipt does not change it, and a `passing` status without a fresh receipt
+  proves nothing.
+
 ## Attempt semantics (factual, never optimistic)
 
 - `attempts: {status: "complete", entries: [...]}` — known history; the

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

@@ -1,7 +1,7 @@
 {
   "name": "kibi-cursor",
   "displayName": "Kibi",
-  "version": "2.6.7",
+  "version": "2.6.9",
   "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

@@ -13,13 +13,13 @@
   "kibi-traceability/resources/operation-access.md": "39f7972ab7f4ae7479e78f7072bb50e8e6c4cdf4f857425f69d2522d37db437c",
   "kibi-traceability/resources/source-authoring.md": "408c6ee2bef1b84e0194c0538ef929c26a0a617e631b2234247388140dbbdd08",
   "kibi-traceability/resources/traceability.md": "38c290a0bc71bd1692e115f22694743946e2f69630e134acfd43cee5f613fb88",
-  "kibi-usage/SKILL.md": "1401bc9bfd03087befb011a216a17a6351b4e5bf7e7c3ebe4a9855f3149cc721",
+  "kibi-usage/SKILL.md": "4837d4dc8e511fae685c7a3b8f854dd8cf9f6cd3a5dcb18008e4fc745757eae2",
   "kibi-usage/resources/branch-lifecycle.md": "f1bf359e9826e83c548f3cd0287f8175a62456527b0132b06b3f9f74aa59b7d6",
-  "kibi-usage/resources/fact-lanes.md": "97f5a9aaa331835018312d6684038c2b2a0c383827716fb7c9de3faedbee622b",
+  "kibi-usage/resources/fact-lanes.md": "e95c4a729264c81dd45100a4915fdf4f2dead19ce1fa0a0667da90b5e18e06ae",
   "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": "aca6b7407a7235ced86a2a970274af8c863c426473800920cf2faee59c33057a",
+  "kibi-usage/resources/proof.md": "2348819078034dd3df25664c4c707ff98f17520bbbd335bff4f48611cf672bb3",
   "kibi-usage/resources/relationship-directions.md": "0fdd67032c2d15299f772845fc4f807eb9435b09507bd87a5911ab33db2f143d",
   "kibi-usage/resources/source-authoring.md": "a29d411fe86e6e29ce364e4ad5925bda40127c4b328a4c657d5b5f0d9fe98ff1",
   "kibi-usage/resources/ui-requirements.md": "47a42dccbabe1e636d6b89e19e21e1ac0704b6d46a577d913e1482435ab7afb8",

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.12.0
+version: 2.14.0
 kibiCompatibility: ">=1.0.0"
 tags:
   - kibi
@@ -148,7 +148,13 @@ error `BOOTSTRAP_PLAN_REJECTED` can follow earlier committed actions: inspect
 `data.actionResults` and `data.applied`, then re-plan from the current state.
 Its journal is terminal; never recover or replay it. `BOOTSTRAP_PLAN_INVALID`
 fails preflight before bootstrap writes or a new journal; obtain a corrected
-plan. If the status is
+plan. A migration plan whose actions were refused before changing anything
+returns `status: error`, `MIGRATION_PLAN_REFUSED` and `data.outcome:
+refused`: nothing changed, so read the action `detail` and get a new plan.
+`data.outcome: reconciliation_required` (status success) means an action
+failed mid-way: inspect its effect before retrying. `kb_delete` of an
+authored entity returns status success with `deleted: 0`; its `errors` say
+why nothing was deleted. If the status is
 `committed_with_repairs`, the mutation already committed: inspect failed effects,
 execute each required repair action in order, and never retry the original
 operation. Record effect failures, followed actions, and unsafe retries in
@@ -231,7 +237,11 @@ authored. Each one is the order the write path accepts.
    fact, `requires_predicate` to `relationshipTarget` and `specified_by` to
    its scenario: `specified_by` (req → scenario) is sent in the
    requirement's write, never in the scenario's, so create the scenario
-   first. A
+   first, with `assumes` links (scenario → `property_value` fact, sent in
+   the scenario's own write) to the values its outcome relies on. Set
+   `expects` only on a scenario that has `assumes` links; `expects: success`
+   without them only yields `scenario-feasibility-unknown` ("assumes
+   nothing"). A
    `modeled` entry and its grounding link must arrive in the same write
    (`modeled semantic_inventory entries (n) must equal logical grounding
    relationships (m)`); a clause not grounded yet stays `status: missing`
@@ -243,7 +253,12 @@ authored. Each one is the order the write path accepts.
    claim_keys must match logical grounding target claim_keys exactly`.
    Prefer supersession for a change of meaning: analyze the new prose,
    write its facts, write the new requirement (`-v2`) with `supersedes` to
-   the old one, then set the old one to `status: closed`. For a wording fix
+   the old one, then set the old one to `status: closed`. Its scenario
+   follows the same rule as in recipe 1: create the new scenario (with
+   `assumes` to the `property_value` facts it relies on, and `expects` only
+   when it has them) before the `-v2` write that sends `specified_by`, then
+   re-point the old scenario (its `assumes` go in its own write) or close
+   it. For a wording fix
    that keeps the meaning, re-ground in place: analyze the new prose,
    `kb_upsert` each grounding fact with the new `claim_key`/`claim_text`
    (same fact id), then `kb_upsert` the requirement with the new ledger,

package/dist/skills/kibi-usage/resources/fact-lanes.md

@@ -61,16 +61,16 @@ A schema can close an argument with `argument_constants` (allowed values keyed b
 
 ### Deny predicate
 
-Claim: “Suspended users must not publish articles.” When `permission_rule` fits, preserve its positive schema name and encode prohibition as polarity:
+Claim: “Suspended users must not publish articles.” When `permission_rule` fits, preserve its positive schema name and encode prohibition as polarity. `kb_model` (`mode: "predicates"`) plans this fact for the claim; the built-in schema's fourth argument, `decision`, repeats the polarity:
 
 ```yaml
 id: FACT-SUSPENDED-PUBLISH-DENIED
 status: active
 fact_kind: predicate
 predicate_name: permission_rule
-predicate_args: [suspended_user, publish, article]
+predicate_args: [suspended_user, publish, articles, deny]
 polarity: deny
-canonical_key: permission_rule(suspended_user,publish,article)
+canonical_key: permission_rule(suspended_user,publish,articles,deny)
 claim_key: <advisor-issued key for this exact clause>
 claim_text: Suspended users must not publish articles.
 relationship: { type: requires_predicate, from: REQ-SUSPENDED-PUBLISH-DENIED, to: FACT-SUSPENDED-PUBLISH-DENIED }

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

@@ -51,6 +51,15 @@ proof_bindings:                 # optional provenance metadata
 
 Provenance lives in `proof_bindings`; the contract stays semantic.
 
+- 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`
+  symbol): a production symbol `implements` the requirement and is
+  `covered_by` the test; an executable test symbol is `executable_for` it.
+- `proof_bindings[].source_file`, when set, must equal the named symbol's
+  `sourceFile`: for a production symbol that is the production file, not the
+  spec file that exercises it. Omit it when unsure.
+
 ## Integration configuration
 
 `.kb/proof/integrations.json` (`kibi.proof-integration.v1`) is tracked,
@@ -62,12 +71,21 @@ returns `integrationPlan`, a hash-bound `kibi.migration-plan.v2`, plus the
 proposal to the human, then apply the plan with `kb_apply_plan` (or
 `kibi apply-plan --input -`) passing `plan`, `approvedPlanHash` (the plan's
 `planHash`) and `approvedActionIds`. Once the file exists, a create plan is
-refused; `kibi proof inspect --update <id> --json` plans adding or replacing
-one named integration.
+refused (`status: error`, `MIGRATION_PLAN_REFUSED`, `data.outcome: refused`;
+nothing is written); `kibi proof inspect --update <id> --json` plans adding or
+replacing one named integration.
 
 - `producer: command` — Kibi synthesizes the envelope from the process
   outcome; obligations are bound with `aggregate_run` provenance and the
-  single process invocation counts as the known first attempt.
+  single process invocation counts as the known first attempt. The run is
+  judged as a whole: any failing test in it fails every obligation of every
+  test that names the integration, so a suite with unrelated failures proves
+  nothing. Narrow the command to the proof-bearing tests with
+  `kibi proof inspect --update <id> --command "<command>" --json` (without
+  `--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.
 - `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`
@@ -79,6 +97,29 @@ 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
+
+A requirement is proven only by 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.
+
+- The scope comes from the test entity's `verification_scope`
+  (`end_to_end`, `integration`, `unit`), never from the integration id or the
+  producer. Without `verification_scope`, a test tagged `e2e` (or whose
+  `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
+  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`,
+  `pattern_marker`); a unit or integration test that renders the component
+  may prove it.
+- `coverage_depth` (`kb_coverage`, `kb_find_gaps`) follows the test's
+  authored `status` (`passing`) and scope, not its receipts: a passing
+  receipt does not change it, and a `passing` status without a fresh receipt
+  proves nothing.
+
 ## Attempt semantics (factual, never optimistic)
 
 - `attempts: {status: "complete", entries: [...]}` — known history; the

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "kibi-cursor",
-  "version": "2.6.7",
+  "version": "2.6.9",
   "description": "Kibi Cursor plugin - thin adapter for Cursor MCP integration and editor hooks",
   "type": "module",
   "main": "dist/index.js",

package/skills/.canon-hash.json

@@ -13,13 +13,13 @@
   "kibi-traceability/resources/operation-access.md": "39f7972ab7f4ae7479e78f7072bb50e8e6c4cdf4f857425f69d2522d37db437c",
   "kibi-traceability/resources/source-authoring.md": "408c6ee2bef1b84e0194c0538ef929c26a0a617e631b2234247388140dbbdd08",
   "kibi-traceability/resources/traceability.md": "38c290a0bc71bd1692e115f22694743946e2f69630e134acfd43cee5f613fb88",
-  "kibi-usage/SKILL.md": "1401bc9bfd03087befb011a216a17a6351b4e5bf7e7c3ebe4a9855f3149cc721",
+  "kibi-usage/SKILL.md": "4837d4dc8e511fae685c7a3b8f854dd8cf9f6cd3a5dcb18008e4fc745757eae2",
   "kibi-usage/resources/branch-lifecycle.md": "f1bf359e9826e83c548f3cd0287f8175a62456527b0132b06b3f9f74aa59b7d6",
-  "kibi-usage/resources/fact-lanes.md": "97f5a9aaa331835018312d6684038c2b2a0c383827716fb7c9de3faedbee622b",
+  "kibi-usage/resources/fact-lanes.md": "e95c4a729264c81dd45100a4915fdf4f2dead19ce1fa0a0667da90b5e18e06ae",
   "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": "aca6b7407a7235ced86a2a970274af8c863c426473800920cf2faee59c33057a",
+  "kibi-usage/resources/proof.md": "2348819078034dd3df25664c4c707ff98f17520bbbd335bff4f48611cf672bb3",
   "kibi-usage/resources/relationship-directions.md": "0fdd67032c2d15299f772845fc4f807eb9435b09507bd87a5911ab33db2f143d",
   "kibi-usage/resources/source-authoring.md": "a29d411fe86e6e29ce364e4ad5925bda40127c4b328a4c657d5b5f0d9fe98ff1",
   "kibi-usage/resources/ui-requirements.md": "47a42dccbabe1e636d6b89e19e21e1ac0704b6d46a577d913e1482435ab7afb8",

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.12.0
+version: 2.14.0
 kibiCompatibility: ">=1.0.0"
 tags:
   - kibi
@@ -148,7 +148,13 @@ error `BOOTSTRAP_PLAN_REJECTED` can follow earlier committed actions: inspect
 `data.actionResults` and `data.applied`, then re-plan from the current state.
 Its journal is terminal; never recover or replay it. `BOOTSTRAP_PLAN_INVALID`
 fails preflight before bootstrap writes or a new journal; obtain a corrected
-plan. If the status is
+plan. A migration plan whose actions were refused before changing anything
+returns `status: error`, `MIGRATION_PLAN_REFUSED` and `data.outcome:
+refused`: nothing changed, so read the action `detail` and get a new plan.
+`data.outcome: reconciliation_required` (status success) means an action
+failed mid-way: inspect its effect before retrying. `kb_delete` of an
+authored entity returns status success with `deleted: 0`; its `errors` say
+why nothing was deleted. If the status is
 `committed_with_repairs`, the mutation already committed: inspect failed effects,
 execute each required repair action in order, and never retry the original
 operation. Record effect failures, followed actions, and unsafe retries in
@@ -231,7 +237,11 @@ authored. Each one is the order the write path accepts.
    fact, `requires_predicate` to `relationshipTarget` and `specified_by` to
    its scenario: `specified_by` (req → scenario) is sent in the
    requirement's write, never in the scenario's, so create the scenario
-   first. A
+   first, with `assumes` links (scenario → `property_value` fact, sent in
+   the scenario's own write) to the values its outcome relies on. Set
+   `expects` only on a scenario that has `assumes` links; `expects: success`
+   without them only yields `scenario-feasibility-unknown` ("assumes
+   nothing"). A
    `modeled` entry and its grounding link must arrive in the same write
    (`modeled semantic_inventory entries (n) must equal logical grounding
    relationships (m)`); a clause not grounded yet stays `status: missing`
@@ -243,7 +253,12 @@ authored. Each one is the order the write path accepts.
    claim_keys must match logical grounding target claim_keys exactly`.
    Prefer supersession for a change of meaning: analyze the new prose,
    write its facts, write the new requirement (`-v2`) with `supersedes` to
-   the old one, then set the old one to `status: closed`. For a wording fix
+   the old one, then set the old one to `status: closed`. Its scenario
+   follows the same rule as in recipe 1: create the new scenario (with
+   `assumes` to the `property_value` facts it relies on, and `expects` only
+   when it has them) before the `-v2` write that sends `specified_by`, then
+   re-point the old scenario (its `assumes` go in its own write) or close
+   it. For a wording fix
    that keeps the meaning, re-ground in place: analyze the new prose,
    `kb_upsert` each grounding fact with the new `claim_key`/`claim_text`
    (same fact id), then `kb_upsert` the requirement with the new ledger,

package/skills/kibi-usage/resources/fact-lanes.md

@@ -61,16 +61,16 @@ A schema can close an argument with `argument_constants` (allowed values keyed b
 
 ### Deny predicate
 
-Claim: “Suspended users must not publish articles.” When `permission_rule` fits, preserve its positive schema name and encode prohibition as polarity:
+Claim: “Suspended users must not publish articles.” When `permission_rule` fits, preserve its positive schema name and encode prohibition as polarity. `kb_model` (`mode: "predicates"`) plans this fact for the claim; the built-in schema's fourth argument, `decision`, repeats the polarity:
 
 ```yaml
 id: FACT-SUSPENDED-PUBLISH-DENIED
 status: active
 fact_kind: predicate
 predicate_name: permission_rule
-predicate_args: [suspended_user, publish, article]
+predicate_args: [suspended_user, publish, articles, deny]
 polarity: deny
-canonical_key: permission_rule(suspended_user,publish,article)
+canonical_key: permission_rule(suspended_user,publish,articles,deny)
 claim_key: <advisor-issued key for this exact clause>
 claim_text: Suspended users must not publish articles.
 relationship: { type: requires_predicate, from: REQ-SUSPENDED-PUBLISH-DENIED, to: FACT-SUSPENDED-PUBLISH-DENIED }

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

@@ -51,6 +51,15 @@ proof_bindings:                 # optional provenance metadata
 
 Provenance lives in `proof_bindings`; the contract stays semantic.
 
+- 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`
+  symbol): a production symbol `implements` the requirement and is
+  `covered_by` the test; an executable test symbol is `executable_for` it.
+- `proof_bindings[].source_file`, when set, must equal the named symbol's
+  `sourceFile`: for a production symbol that is the production file, not the
+  spec file that exercises it. Omit it when unsure.
+
 ## Integration configuration
 
 `.kb/proof/integrations.json` (`kibi.proof-integration.v1`) is tracked,
@@ -62,12 +71,21 @@ returns `integrationPlan`, a hash-bound `kibi.migration-plan.v2`, plus the
 proposal to the human, then apply the plan with `kb_apply_plan` (or
 `kibi apply-plan --input -`) passing `plan`, `approvedPlanHash` (the plan's
 `planHash`) and `approvedActionIds`. Once the file exists, a create plan is
-refused; `kibi proof inspect --update <id> --json` plans adding or replacing
-one named integration.
+refused (`status: error`, `MIGRATION_PLAN_REFUSED`, `data.outcome: refused`;
+nothing is written); `kibi proof inspect --update <id> --json` plans adding or
+replacing one named integration.
 
 - `producer: command` — Kibi synthesizes the envelope from the process
   outcome; obligations are bound with `aggregate_run` provenance and the
-  single process invocation counts as the known first attempt.
+  single process invocation counts as the known first attempt. The run is
+  judged as a whole: any failing test in it fails every obligation of every
+  test that names the integration, so a suite with unrelated failures proves
+  nothing. Narrow the command to the proof-bearing tests with
+  `kibi proof inspect --update <id> --command "<command>" --json` (without
+  `--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.
 - `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`
@@ -79,6 +97,29 @@ 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
+
+A requirement is proven only by 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.
+
+- The scope comes from the test entity's `verification_scope`
+  (`end_to_end`, `integration`, `unit`), never from the integration id or the
+  producer. Without `verification_scope`, a test tagged `e2e` (or whose
+  `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
+  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`,
+  `pattern_marker`); a unit or integration test that renders the component
+  may prove it.
+- `coverage_depth` (`kb_coverage`, `kb_find_gaps`) follows the test's
+  authored `status` (`passing`) and scope, not its receipts: a passing
+  receipt does not change it, and a `passing` status without a fresh receipt
+  proves nothing.
+
 ## Attempt semantics (factual, never optimistic)
 
 - `attempts: {status: "complete", entries: [...]}` — known history; the