kibi-runtime 2.13.1 → 2.13.3

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-runtime",
-  "version": "2.13.1",
+  "version": "2.13.3",
   "description": "Narrow first-party runtime contracts and adapters for Kibi operations.",
   "type": "module",
   "main": "./dist/index.js",
@@ -18,7 +18,7 @@
   },
   "dependencies": {
     "gray-matter": "^4.0.3",
-    "kibi-core": "^0.18.1",
+    "kibi-core": "^0.19.0",
     "kibi-plugin-builtin": "^0.5.0",
     "kibi-swipl": "^1.0.1"
   },