kibi-runtime 2.13.0 → 2.13.1

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

@@ -2,7 +2,7 @@
 id: kibi-bootstrap
 name: kibi-bootstrap
 description: "Use for any Kibi bootstrap or onboarding task: seeding a new or thin knowledge base; reviewing a bootstrap or onboarding plan, preview, or evidence; judging approval readiness or coverage; diagnosing a blocked, partial, or failed bootstrap or its repair; applying an approved bootstrap plan; or asking the human which knowledge sources hold intent. Covers kb_status first, source interview, cited intent claims, read-only kb_plan_bootstrap preview, explicit approval, exact-plan kb_apply_plan, and repair-safe close-out."
-version: 3.10.0
+version: 3.11.0
 kibiCompatibility: ">=1.0.0"
 tags:
   - kibi
@@ -46,6 +46,7 @@ Seed branch-local Kibi knowledge from cited product intent, without creating a p
     - **Scenarios.** Write scenarios from the cited ticket's acceptance criteria, one scenario per criterion, not bulk drafts from the requirement title; ask the human when the source states none. Give each a plain title, the scenario prose in `document.body` (never in `properties`), and `assumes` links to the `property_value` facts whose values the scenario relies on. Set `expects` only when the scenario links `assumes` facts (or its criterion names concrete values that become them); `expects` without `assumes` only yields a feasibility-unknown warning, so a draft tagged `needs-human-review` omits `expects`. Then link the requirement with `specified_by` (upsert the `req` with its stored `title`, a `status` and that relationship only). Example: criterion "Given an annotation in draft state, when the user deletes it, the draft is cleared" becomes `{"type":"scenario","id":"SCEN-annotation-delete-clears-draft","properties":{"title":"Deleting a draft annotation clears the draft","status":"active","expects":"success"},"document":{"body":"Given an annotation in draft state, when the user deletes it, then the draft is cleared and nothing is published.\n\nThe acceptance criterion comes from the cited ticket; reviewers asked for it so a deleted draft never reappears after reload.\n"},"relationships":[{"type":"assumes","from":"SCEN-annotation-delete-clears-draft","to":"FACT-annotation-state-draft"}]}`, where the assumed fact is a `property_value` (`annotation.state` `eq` `draft`). Link existing tests that exercise it; never invent test evidence.
     - **Predicates.** Run `kb_model` with `mode: "predicates"` and `requirementId` on each persisted requirement and apply a returned plan with `requires_predicate` to its `relationshipTarget` (the planned `FACT-PRED-…` id, never a `SUGGEST-…` candidate id), or record the `review:ontology-gap` observation it returns, with its prose in `document.body`. A non-empty `existingGrounding` means the bootstrap already grounded that claim: on `replace_grounding` leave it unless the human wants the `replacementPlan` swap; on `provide_argument_bindings` retry with the listed arguments bound; on `record_ontology_gap` still write the returned gap observation, which is not a grounding link. Count what `kb_query` shows afterwards, not the calls you made.
     - **Unrecorded ambiguity.** Record any conflict or open question you found but did not declare in step 3 as a cited `fact_kind: observation` tagged `review:conflict` or `review:open-question`.
+    - **Proof integration.** Run `kibi proof inspect --json`. When it returns an `integrationPlan` (a `command` integration for the detected test runner), show the human the proposed command and `contractDefaults`, and on approval apply that exact plan with `kb_apply_plan` (`plan`, `approvedPlanHash` = its `planHash`, `approvedActionIds`); it writes `.kb/proof/integrations.json`, which you never hand-write. With no runner detected, report that proof stays deferred. Proof-bearing tests then name the integration in `proof_contract.integration`, and `kibi prove` records their evidence.
     Finish with `kb_check` and `kb_status`.
 12. **Report** calls made, result statuses, applied scope, what step 11 authored, gaps, and follow-ups. Classify as complete, partial, awaiting approval, or blocked.
 

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.11.0
+version: 2.12.0
 kibiCompatibility: ">=1.0.0"
 tags:
   - kibi
@@ -219,11 +219,19 @@ authored. Each one is the order the write path accepts.
    `semantic_inventory_version`, `semantic_source_field` and
    `semantic_source_hash`, the prose into `semantic_text`, `propositions`
    into `semantic_inventory` and the assertive `claim_key`s into
-   `logic_claims`. `kb_model` mode `predicates` per clause; `kb_upsert` the
-   returned `applyPlan` fact first (it carries the clause's `claim_key`).
-   Then write the requirement in one `kb_upsert` with the ledger (that
-   clause `status: modeled`), a sectioned `document.body`, `constrains` to
-   the subject fact and `requires_predicate` to `relationshipTarget`. A
+   `logic_claims`. Reuse (or `kb_upsert`) the subject fact, then call
+   `kb_model` mode `predicates` per clause with `subjectHint` set to that
+   subject fact's `subject_key`: the requirement constrains nothing yet, so
+   the hint is the planned subject and the planned fact gets its
+   `subject_key` (`subjectKey` is a mode `requirement` parameter; mode
+   `predicates` ignores it and warns). `kb_upsert` the returned `applyPlan`
+   fact first (it carries the clause's `claim_key`). Then write the
+   requirement in one `kb_upsert` with the ledger (that clause `status:
+   modeled`), a sectioned `document.body`, `constrains` to the subject
+   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
    `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`

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

@@ -54,7 +54,16 @@ Provenance lives in `proof_bindings`; the contract stays semantic.
 ## Integration configuration
 
 `.kb/proof/integrations.json` (`kibi.proof-integration.v1`) is tracked,
-Kibi-managed configuration describing evidence production only:
+Kibi-managed configuration describing evidence production only. Never
+hand-write it: `kibi proof inspect --json` proposes a `command` integration
+for the detected test runner (the `package.json` `test` script first) and
+returns `integrationPlan`, a hash-bound `kibi.migration-plan.v2`, plus the
+`contractDefaults` a proof-bearing test's `proof_contract` uses. Show 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.
 
 - `producer: command` — Kibi synthesizes the envelope from the process
   outcome; obligations are bound with `aggregate_run` provenance and the
@@ -82,8 +91,11 @@ effective fingerprint and do.
 
 ## Common rejections
 
-- `No proof integration configuration` — bootstrap has not configured proof
-  for this repository yet; do not hand-wave, run the bootstrap proof step.
+- `No proof integration configuration` — proof is not configured for this
+  repository yet; run `kibi proof inspect --json`, review its
+  `integrationPlan` and apply it with `kb_apply_plan`.
+- `integration '<id>' ... is not configured` — the test names an integration
+  the file lacks; plan it with `kibi proof inspect --update <id> --json`.
 - `captured snapshot is not the live workspace snapshot` — the tree changed
   between capture and ingest; re-run `kibi prove`.
 - `artifact command_argv does not match the configured command` — the

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "kibi-runtime",
-  "version": "2.13.0",
+  "version": "2.13.1",
   "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.0",
+    "kibi-core": "^0.18.1",
     "kibi-plugin-builtin": "^0.5.0",
     "kibi-swipl": "^1.0.1"
   },