kibi-runtime 2.14.0 → 2.14.2

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.15.0
+version: 2.15.3
 kibiCompatibility: ">=1.0.0"
 tags:
   - kibi
@@ -82,6 +82,41 @@ different workspace than the one you asked for; its `detail.reason` says why.
 Use the CLI from your working directory instead: `npx --no-install kibi ...`
 runs where you are and needs no `workspaceRoot`.
 
+## Reading a hook snippet
+
+On hosts where Kibi hooks are installed, a short block
+arrives before you read or edit a file whose symbols are linked to
+requirements. It is projected from `.kb/symbols.yaml`, not from the store, so
+it is a pointer to the knowledge, never proof. Each line answers one question:
+
+- `Kibi knowledge for <path> (symbol manifest):` and the `- REQ-… — <symbol
+  titles>` rows: the requirements the file's symbols implement, lead
+  requirement first. Read the lead requirement with `kb_query({id})` before
+  changing behavior.
+- `REQ-… must keep true: FACT-…` (edit only): the ground facts the lead
+  requirement requires. An edit that breaks one of them is a requirement
+  change: supersede and remodel the requirement, do not code around the fact.
+- `Decision: ADR-…` (edit only): the decision behind the lead requirement.
+- `Covered by: TEST-…` and `Test code for: …`: the tests that prove the
+  file's symbols; run or update them with the edit.
+- `The edit is inside <symbol>, which implements REQ-…`: the symbol the edit
+  lands in.
+- `Next layer: …`: the exact `kb_query` and `kb_search(... sourceLocations)`
+  calls that return the full detail.
+- The `kb_check({sourceFiles:[…], includeImpactDiagnostics:true,
+  includeWorkingTreeDiff:true})` line (edit only): run it after the edit. The
+  Stop hook reminds you once per session of files edited without it.
+
+A file already shown this session gets only the one-line `Kibi: this edit to
+<path> is inside <symbol>` update; the facts and tests from its first snippet
+still apply. `Kibi: no symbol in <path> is linked to a requirement yet` means
+the file is unowned: find the governing requirement with `kb_search` and
+`sourceLocations`, then link a symbol to it with `implements` through
+`kb_upsert`. Without a readable manifest (`Kibi: the hook could not read
+.kb/symbols.yaml`) snippets are off for this session; `kb_query({sourceFile})`
+still answers and `kibi sync` regenerates the manifest. The search tip and the
+`.kb/` note appear once per session and need no action.
+
 ## Safe workflow
 
 1. Always discover before you mutate: start with `kb_search`, then exact-filter with `kb_query`. Use
@@ -334,6 +369,8 @@ For each relational clause, call `kb_model` with `mode: "predicates"`, that clau
 reviewed `schemaId`. If `binding_status` is `incomplete`, supply
 `argumentBindings` and retry. Persist `fact_kind: predicate` with the same
 `claim_key` / `claim_text`, then link `REQ -> fact` with `requires_predicate`.
+`claim_key` is derived from `claim_text`, so a ground fact may send the exact
+clause alone and Kibi fills the key in; a sent key must equal the derived one.
 Use `kb_model` with `mode: "requirement"` for strict scalar clauses. Use
 `fact_kind: observation` only for a true ontology gap. The manifest is not
 grounding: run `logic-coverage` so each key binds to one ground fact.

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

@@ -6,7 +6,7 @@ Requirement prose remains the human-readable source. Facts add queryable semanti
 
 Logical coverage is clause-based, not entity-based. Give `kb_model` (`mode: "analyze"`) the complete requirement body and verify that its `clauses` list contains every atomic obligation. Supply the `clauses` input yourself when automatic splitting would combine or omit obligations. For every normative clause:
 
-- preserve the returned stable key as `claim_key` and the exact clause as `claim_text` on its ground fact;
+- put the exact clause as `claim_text` on its ground fact, with the returned stable key as `claim_key` or none (Kibi derives a missing key; a sent key must match);
 - add the key to the exact current `logic_claims` set, removing only stale keys whose propositions no longer exist in the source;
 - link it through exactly one `requires_property` for `property_value`, one `requires_predicate` for `predicate`, or one `requires_rule` for a safe `rule` fact;
 - leave ambiguity and ontology gaps visibly unresolved—observations do not satisfy `logic-coverage`.
@@ -68,14 +68,16 @@ id: FACT-SUSPENDED-PUBLISH-DENIED
 status: active
 fact_kind: predicate
 predicate_name: permission_rule
-predicate_args: [suspended_user, publish, articles, deny]
+predicate_args: [suspended_user, publish, article, deny]
 polarity: deny
-canonical_key: permission_rule(suspended_user,publish,articles,deny)
+canonical_key: permission_rule(suspended_user,publish,article,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 }
 ```
 
+Inferred bindings drop the article and singularise the resource (`articles` becomes `article`, `any analysis request` and `analysis requests` both become `analysis_request`), so an allow and a deny on the same actor, action and resource share one key. Grants read the same as `allowed`: `may`, `can`, `is allowed to`, `are permitted to`, `must be able to`, `are able to`, `have permission to` and `are entitled to` all select `permission_rule` with `polarity: assert`.
+
 If another current requirement links an `assert` fact with the same predicate namespace, name, and ordered arguments, `domain-contradictions` reports the pair. More complex semantic conflicts require a shared canonical schema and arguments; do not assume Kibi can prove arbitrary equivalence between differently shaped predicates.
 
 The full logical representation of a requirement is the conjunction of all of its linked ground property and predicate terms. Conditions, exceptions, permissions, and ordering constraints remain explicit arguments of their declared schemas. Contradiction detection therefore depends on equivalent prose reusing the same predicate name, argument roles, ordered canonical values, and opposing polarity rather than inventing synonymous terms.

package/dist/skills/kibi-usage/resources/ui-requirements.md

@@ -126,8 +126,8 @@ diagnostics (`symbol_semantic_review_needed`).
    `requires_predicate`.
 3. Scalar placement/alignment/order clauses: `kb_model` (`mode: "requirement"`), apply the strict
    subject/property plan and `constrains` / `requires_property`.
-4. Preserve `claim_key` / `claim_text`; merge every key into the requirement
-   `logic_claims` manifest.
+4. Preserve `claim_key` / `claim_text` (a missing key is derived from the
+   text); merge every key into the requirement `logic_claims` manifest.
 5. `kb_upsert` with `dryRun: true`, create endpoints first, then sequential `kb_upsert`.
 6. `kb_check` with `logic-coverage`, `predicate-verifiability`, `domain-contradictions`,
    then a final unfiltered `kb_check`.

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

@@ -203,7 +203,7 @@ Optional per-project workflow for recording what the screen should look like. No
 2. Run `kb_model` with `mode: "analyze"` on the description; audit or supply `clauses`.
 3. For relational layout clauses ("X must remain visually aligned with Y"), call `kb_model` with `mode: "predicates"`, apply the returned `fact_kind: predicate` plan with `predicate_name: visual_layout_rule` and `requires_predicate`.
 4. For scalar placement, alignment, and ordering clauses, call `kb_model` with `mode: "requirement"` and apply strict `fact_kind: subject` / `fact_kind: property_value` facts linked with `constrains` / `requires_property`. Model header order as indexed property keys (`nav_order_1`, `nav_order_2`, ...) against one subject region.
-5. Preserve `claim_key` / `claim_text` on every ground fact and merge every key into the requirement `logic_claims` manifest.
+5. Preserve `claim_key` / `claim_text` on every ground fact (a missing `claim_key` is derived from `claim_text`) and merge every key into the requirement `logic_claims` manifest.
 6. Model UI components as `symbol` entities with `sourceFile` and `symbol_role: behavioral`, linked `implements` to the requirement.
 7. `kb_upsert` with `dryRun: true`, create endpoints first, then sequential `kb_upsert`. Run `kb_check` with `logic-coverage`, `predicate-verifiability`, and `domain-contradictions`, then a final unfiltered `kb_check`.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "kibi-runtime",
-  "version": "2.14.0",
+  "version": "2.14.2",
   "description": "Narrow first-party runtime contracts and adapters for Kibi operations.",
   "type": "module",
   "main": "./dist/index.js",
@@ -18,8 +18,8 @@
   },
   "dependencies": {
     "gray-matter": "^4.0.3",
-    "kibi-core": "^0.20.0",
-    "kibi-plugin-builtin": "^0.5.0",
+    "kibi-core": "^0.21.0",
+    "kibi-plugin-builtin": "^0.5.1",
     "kibi-swipl": "^1.0.1"
   },
   "devDependencies": {