kibi-cursor 2.1.1 → 2.3.0

package/dist/hook-runner.js

@@ -3,13 +3,68 @@
 import fs from "node:fs";
 import path from "node:path";
 import { fileURLToPath, pathToFileURL } from "node:url";
+import { appendHookUsageRows, editTraces, hookTelemetryEnabled, kbUsageTrace, readPackageVersion, } from "kibi-agent-core/hook-usage-log";
+import { stampKibiWorkspace } from "kibi-agent-core/kb-mcp-tools";
+import { createEntitySummarizer, editFocus, fileKnowledgeSnippet, implementedRequirementIds, } from "kibi-agent-core/snippets";
 import { preEditGuidance, readGuidance, writeGuidance } from "./guidance.js";
 import { parseHookInput, parseStdinJson, readStdin } from "./hook-input.js";
 import { addDirtyPaths, clearSessionHookState, hasGuidedPath, loadHookState, recordKbMcpTool, recordPlanDelivered, rememberGuidedPath, resolveStateDir, } from "./hook-state.js";
 import { extractKbMcpToolCall } from "./kb-mcp-tools.js";
 import { BOOTSTRAP_REMINDER, DIRECT_KB_EDIT_WARNING, interfaceAdvisory, stopFollowupMessage, } from "./messages.js";
 import { extractExplicitPathFields, isDirectKbPath, isKbFreshnessRelevantPath, isMeaningfulTrackedPath, toRepoRelativePath, } from "./path-policy.js";
-import { getSourceLinkedRequirementIds } from "./source-linked-requirements.js";
+import { getSourceLinkedSymbols, } from "./source-linked-requirements.js";
+const MAX_LINKED_REQUIREMENTS = 3;
+/**
+ * The shared kibi-agent-core snippet for a file that implements requirements,
+ * or undefined so the generic Cursor guidance applies. Test-only links
+ * (`covered_by`, `executable_for`) are not requirement ownership here.
+ */
+// implements REQ-cursor-kibi-plugin-v1
+function knowledgeFor(workspaceRoot, linked, surface, focus) {
+    if (implementedRequirementIds(linked.symbols).length === 0)
+        return undefined;
+    return fileKnowledgeSnippet({
+        relativePath: linked.relativePath,
+        symbols: linked.symbols,
+        surface,
+        focus,
+        summarize: createEntitySummarizer(workspaceRoot),
+    });
+}
+let cachedPackageVersion;
+function packageVersion() {
+    // dist/hook-runner.js sits one level below the package root.
+    if (cachedPackageVersion !== undefined)
+        return cachedPackageVersion;
+    cachedPackageVersion = readPackageVersion(path.join(path.dirname(fileURLToPath(import.meta.url)), "..", "package.json"));
+    return cachedPackageVersion;
+}
+/**
+ * Opt-in (`KIBI_DIAGNOSTIC_MODE`) hook rows for the lookup-before-first-edit
+ * telemetry metric: Kibi lookups through MCP or the CLI, and edits with the
+ * requirements the edited files implement.
+ */
+// implements REQ-cursor-kibi-plugin-v1
+function recordToolTelemetry(input, workspaceRoot, stateDir, startedAt, env) {
+    if (!hookTelemetryEnabled(env))
+        return;
+    const kbUsage = kbUsageTrace(input.toolName, input.toolInput);
+    const traces = kbUsage
+        ? [kbUsage]
+        : isKnownEditableTool(input.toolName)
+            ? editTraces(extractExplicitPathFields(input.toolInput).map((candidate) => toRepoRelativePath(candidate, workspaceRoot)), (relativePath) => implementedRequirementIds(getSourceLinkedSymbols(workspaceRoot, relativePath, stateDir)
+                .symbols))
+            : [];
+    appendHookUsageRows({
+        host: "cursor",
+        packageVersion: packageVersion(),
+        workspaceRoot,
+        event: "postToolUse",
+        sessionId: input.conversationId,
+        hostTool: input.toolName,
+        startedAt,
+    }, traces, env);
+}
 const editableTools = new Set([
     "Edit",
     "MultiEdit",
@@ -29,6 +84,26 @@ function hasKibiConfig(cwd) {
     }
     return fs.existsSync(path.join(cwd, ".kb", "manifest.json"));
 }
+/**
+ * The Kibi workspace that owns `directory`: the nearest ancestor with
+ * `.kb/manifest.json`, without crossing a `.git` boundary.
+ */
+export function kibiWorkspaceFor(directory) {
+    if (!directory)
+        return undefined;
+    let current = path.resolve(directory);
+    for (;;) {
+        if (fs.existsSync(path.join(current, ".kb", "manifest.json"))) {
+            return current;
+        }
+        if (fs.existsSync(path.join(current, ".git")))
+            return undefined;
+        const parent = path.dirname(current);
+        if (parent === current)
+            return undefined;
+        current = parent;
+    }
+}
 function isEditLikeTool(toolName) {
     return toolName === undefined || editableTools.has(toolName);
 }
@@ -57,6 +132,7 @@ function resolvePrimaryPath(input) {
     return explicitPaths[0];
 }
 export async function runHook(rawInput, environment = {}) {
+    const startedAt = new Date();
     const input = parseHookInput(rawInput);
     const pluginData = environment.pluginData ?? process.env.PLUGIN_DATA;
     const stateDir = resolveStateDir(pluginData, input.conversationId);
@@ -79,6 +155,14 @@ export async function runHook(rawInput, environment = {}) {
                 return advisory ? { additional_context: advisory } : emptyResult();
             }
         case "preToolUse": {
+            // Name the agent's workspace on every Kibi MCP call so the launcher
+            // answers from it, also for agents working in a git worktree. The
+            // per-call cwd wins over workspace_roots, which can be the window's
+            // folders rather than the agent's checkout.
+            const stamped = stampKibiWorkspace(input.toolName, input.toolInput, kibiWorkspaceFor(input.cwd ?? input.workspaceRoots?.[0]));
+            if (stamped) {
+                return { updated_input: stamped };
+            }
             const explicitPaths = extractExplicitPathFields(input.toolInput);
             const hasDirectKbEdit = isEditLikeTool(input.toolName) && explicitPaths.some(isDirectKbPath);
             if (hasDirectKbEdit) {
@@ -96,12 +180,14 @@ export async function runHook(rawInput, environment = {}) {
             if (hasGuidedPath(state, "pre-edit", relativePath)) {
                 return emptyResult();
             }
+            const linked = getSourceLinkedSymbols(cwd, primaryPath, stateDir);
             const guidance = preEditGuidance(primaryPath, {
                 cwd,
                 hasKibi: kibiReady,
                 mcpState: state.mcpState,
                 workspaceTrusted,
-                linkedRequirementIds: getSourceLinkedRequirementIds(cwd, primaryPath, stateDir),
+                linkedRequirementIds: implementedRequirementIds(linked.symbols).slice(0, MAX_LINKED_REQUIREMENTS),
+                knowledge: knowledgeFor(cwd, linked, "edit", editFocus(path.resolve(cwd, primaryPath), input.toolInput)),
             });
             if (!guidance) {
                 return emptyResult();
@@ -124,6 +210,7 @@ export async function runHook(rawInput, environment = {}) {
                 hasKibi: kibiReady,
                 mcpState: state.mcpState,
                 workspaceTrusted,
+                knowledge: knowledgeFor(cwd, getSourceLinkedSymbols(cwd, primaryPath, stateDir), "read"),
             });
             if (!guidance) {
                 return { permission: "allow" };
@@ -135,6 +222,14 @@ export async function runHook(rawInput, environment = {}) {
             };
         }
         case "postToolUse": {
+            if (kibiReady) {
+                try {
+                    recordToolTelemetry(input, cwd, stateDir, startedAt, environment.env);
+                }
+                catch {
+                    // Telemetry is best effort and must never change the hook's output.
+                }
+            }
             const kbToolCall = extractKbMcpToolCall(input.toolName, input.toolInput);
             if (kbToolCall) {
                 recordKbMcpTool(stateDir, kbToolCall.toolName, {
@@ -170,6 +265,7 @@ export async function runHook(rawInput, environment = {}) {
                     hasKibi: kibiReady,
                     mcpState: state.mcpState,
                     workspaceTrusted,
+                    knowledge: knowledgeFor(cwd, getSourceLinkedSymbols(cwd, primaryPath, stateDir), "read"),
                 });
                 if (!guidance) {
                     return emptyResult();

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

@@ -1,6 +1,6 @@
 {
-  "kibi-bootstrap/SKILL.md": "adf7ebe4985ee871e2f1d2d89fd90a20c596fa24460bfec4df525bdcebd3f1d6",
-  "kibi-bootstrap/resources/bootstrap.md": "e46d5dec74204d0652d4cba7061676c76c2f066bf6d98b073efa9fa44557be80",
+  "kibi-bootstrap/SKILL.md": "de228e10d65b428d4ea3e2229fa106407da60521fb8da8387ce6a52242b3a349",
+  "kibi-bootstrap/resources/bootstrap.md": "566f44253c7f1258a56dc4f0770128d451ca7757c6901febc5a0e596ed4621e0",
   "kibi-bootstrap/resources/branch-lifecycle.md": "c854264ce888439140883a3fc636db5e522f020dd27b30a5c1ecc4105b64ed13",
   "kibi-bootstrap/resources/operation-access.md": "b5a6a59e72d800c376e7fad79132897623c32a0ce152a1e8d73f9628b444db51",
   "kibi-bootstrap/resources/source-authoring.md": "bf296e62f69474e01797d6cb9469bf624551dca834dd188abb6e705bd96fa586",
@@ -13,15 +13,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": "83567f8ead944457719e0254ad6bc1dbedda3a70d04266d2ff041a670336dcc6",
+  "kibi-usage/SKILL.md": "251f72f95551c17ac85453024a9e1a78cd3261f62ad13ebea9d2397fdcdad856",
   "kibi-usage/resources/branch-lifecycle.md": "f1bf359e9826e83c548f3cd0287f8175a62456527b0132b06b3f9f74aa59b7d6",
-  "kibi-usage/resources/fact-lanes.md": "7ac928cc6b3d189eee6a9cda282918677d5a222cd7ba9b7f324e6553cd3adce8",
-  "kibi-usage/resources/kb-improvement.md": "17e8b6cf6a0dd43b443a2bfd92e7205d099647a5f1c75fe85413a6cea63d86c6",
-  "kibi-usage/resources/logic-ir.md": "151675d0ffa813cb9e271084102a3af42de369b8f9a0c64866af0cdc4d924063",
-  "kibi-usage/resources/operation-access.md": "e2b8c101c6d8b8204aa2907f48091ed97ff1037c287043586a1aa180b1d80209",
+  "kibi-usage/resources/fact-lanes.md": "97f5a9aaa331835018312d6684038c2b2a0c383827716fb7c9de3faedbee622b",
+  "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": "7391046fbdeece4858b668360c60755f184af6dfedda9dbc67e2fa4574dbce7f",
   "kibi-usage/resources/relationship-directions.md": "0fdd67032c2d15299f772845fc4f807eb9435b09507bd87a5911ab33db2f143d",
   "kibi-usage/resources/source-authoring.md": "80978cea0614484292c7a70d511a3f50458f48ef976bf0675b8bb96abe9d3d36",
-  "kibi-usage/resources/ui-requirements.md": "b7c31ab1affa3ab25ae5242d8fd8c4d546532d1cafc65d84088375317c1682cc",
-  "kibi-usage/resources/workflows.md": "52cadc2b1e41af7d0c3129b721d81bb542fefb97113ba3a7c817f7ab7a1f787e"
+  "kibi-usage/resources/ui-requirements.md": "ea8e8a4c546acb668963ec354cd31711152c3ca3bc7d3078d2252ff9e2cd44a3",
+  "kibi-usage/resources/workflows.md": "bde1cc6f1aaba6cbc1db59cfe23f01986bf95e02e471f2d066ce428d5a81e1f0"
 }

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

@@ -1,8 +1,8 @@
 ---
 id: kibi-bootstrap
 name: kibi-bootstrap
-description: Bootstrap Kibi from the current Git checkout with exact Git attachment, preview approval, source-first writes, and repair-safe completion.
-version: 3.0.0
+description: Bootstrap Kibi from the current Git checkout and the project's existing knowledge sources, with a source interview, cited intent claims, preview approval, source-first writes, and repair-safe completion.
+version: 3.1.1
 kibiCompatibility: ">=1.0.0"
 tags:
   - kibi
@@ -18,20 +18,56 @@ resources:
 ## Goal
 
 Seed branch-local Kibi knowledge for an attached but thin repository without
-creating a parallel human-maintained ticket system. Ask at most four bounded
-context questions only when the planner says repository evidence is
-insufficient; agents own deterministic translation and humans resolve genuine
-ambiguity. A seeded repository hands off to the normal Kibi workflow.
+creating a parallel human-maintained ticket system. Code shows what the
+system does, not why; intent usually lives elsewhere (issue trackers, wikis,
+specs, decision logs). Lead a short interview to find those sources, harvest
+cited intent from them, and let the planner consolidate it with repository
+evidence. Agents own reading and translation; humans name the sources,
+judge their authority, and resolve genuine ambiguity. A seeded repository
+hands off to the normal Kibi workflow.
 
 ## Interface and preview
 
 Use the visible approved MCP surface or the trusted project-local CLI as equal
-peer interfaces. If neither is available, stop. Run `kb_plan_bootstrap` (or
-`plan-bootstrap --input`) read-only. If it returns `needs_context`, ask only its
+peer interfaces. If neither is available, stop. Interview first, then plan,
+then preview the exact plan for approval.
+
+## Interview first
+
+Before planning:
+
+1. Inventory what you can already read: your own MCP connectors and tools
+   (issue trackers such as Jira, YouTrack, Linear, or GitHub Issues; wikis such
+   as Confluence or Notion; drives and design tools), and in-repo docs, ADRs,
+   and specs.
+2. Ask the human, in one message: what the repository is for; which of those
+   sources hold product intent; which are authoritative, supporting, or stale;
+   what is missing; and which product areas matter first. If an important
+   source has no connector, say which one and suggest connecting it, then
+   continue with what is reachable. Never invent access you lack.
+3. Read the confirmed, non-stale sources through your connectors. Harvest one
+   normative statement per behavior, each citing its source and an exact
+   reference (ticket key, page URL, or section anchor). Keep the source's
+   meaning; do not merge, generalize, or resolve conflicts yourself.
+
+Declare the result in `bootstrapContext`: `projectSummary`,
+`knowledgeSources` (id, kind, title, locator, authority, optional connector),
+and `intentClaims` (statement, sourceId, reference, optional excerpt). Kibi
+never contacts those sources; it binds what you declare into the plan hash.
+
+## Plan and approval
+
+Run `kb_plan_bootstrap` (or `plan-bootstrap --input`) read-only with that
+context. Grounded authoritative or supporting claims become cited `req`
+candidates; claims the strict modeler cannot ground come back as authoring
+follow-ups; stale sources produce no candidates; undeclared sources are
+reported in diagnostics. If the plan returns `needs_context`, ask only its
 bounded questions (never more than four), then rerun the planner. Show the
-complete returned `structuredContent.plan`, including its canonical hash, and
-get explicit approval before any write. Pass that plan object unchanged to
-`kb_apply_plan`; do not reconstruct it from preview fields.
+complete returned `structuredContent.plan`, including its canonical hash and
+which candidates cite which sources, and get explicit approval before any
+write. Pass that plan object unchanged to `kb_apply_plan`; do not reconstruct
+it from preview fields. When a claim contradicts the code or another claim,
+put it to the human instead of choosing.
 
 For CLI JSON, use the trusted route with `--input` (for example
 `printf '%s\n' '{}' | kibi status --input -`); MCP and CLI are semantic peers.
@@ -51,6 +87,11 @@ Finish with `kb_check` and `kb_status`.
 Consume the versioned `kibiProtocol: 1` result envelope: inspect `status`, `effects`,
 `diagnostics`, and `nextActions`. On `committed_with_repairs`, execute required
 repair actions and never retry the original mutation.
+On `BOOTSTRAP_PLAN_INVALID`, obtain a corrected preview and approval before
+applying. On `BOOTSTRAP_PLAN_REJECTED`, inspect committed `data.actionResults`
+and re-plan from the current state; the journal is terminal and cannot recover.
+Review `suppressedCandidates`, `sourceOnlySignals`, and diagnostics for invalid,
+ungroundable, unreadable, or over-limit candidates before approving a plan.
 
 Kibi may author tracked Markdown/YAML/manifests and relationship shards
 transactionally, but never Git-stages or commits them. Never read or edit

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

@@ -1,6 +1,11 @@
 # Bootstrap resource
 
-`kb_plan_bootstrap` is read-only and returns `kibi.bootstrap-plan.v1`. Review
+`kb_plan_bootstrap` is read-only and returns `kibi.bootstrap-plan.v1`. Declared
+`knowledgeSources` and cited `intentClaims` are part of `declaredContext` and
+therefore of the plan hash; a candidate built from a claim has `sourceKind:
+intent_claim` and evidence rows `intent_claim:<sourceId>:<reference>`,
+`knowledge_source:<kind>:<locator>`, and `source_authority:<authority>`. Its
+requirement keeps the citation as `text_ref: <sourceId>:<reference>`. Review
 candidate evidence, exact actions, dependencies, expected snapshots, source
 hashes, bounded questions, diagnostics, and the canonical `planHash` before
 approving. A preview does not authorize source edits. After approval, pass the
@@ -9,3 +14,9 @@ approved hash; inspect its typed result
 and follow `nextActions` if it returns `committed_with_repairs`. Direct
 `kb_upsert` is forbidden for every bootstrap task; never manually replay the
 plan through it.
+
+`BOOTSTRAP_PLAN_INVALID` fails before bootstrap writes or a new journal; request
+a corrected plan. `BOOTSTRAP_PLAN_REJECTED` reports a deterministic failure and
+may include earlier committed `data.actionResults`. Re-plan from the current
+state; its terminal journal cannot recover. Review candidate suppressions and
+cited authoring follow-ups, including any `over_limit` entries, before approval.

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.2.0
+version: 2.3.1
 kibiCompatibility: ">=1.0.0"
 tags:
   - kibi
@@ -47,6 +47,18 @@ Use whichever capability is visible and approved. The surfaces are equal peers:
 Hosts may expose prefixed identifiers such as `kibi_kb_search`,
 `kibi_kb_query`, and `kibi_kb_upsert`; map them to the canonical MCP names.
 
+The MCP server keeps its tool list short. Load skills with `kb_skills`
+(`action: "list" | "load" | "read"`; CLI `kibi skill` or `kibi skills
+list|load|read`). Model prose with `kb_model` (`mode: "analyze"` for the
+semantic advisor, `"requirement"` for strict claims, `"predicates"` for
+ontology predicates; CLI `kibi model` or `semantic-advisor`,
+`model-requirement`, `suggest-predicates`). Preflight a write with
+`kb_upsert` plus `dryRun: true` (CLI `upsert` with `"dryRun": true` or
+`validate-upsert`); it validates and writes nothing. Result payloads still name
+catalog operations such as `kb_model_requirement` or `kb_validate_upsert` in
+`recommended_tools` and repair steps; translate them with the list in
+`resources/operation-access.md`.
+
 The CLI JSON route accepts the same business object as MCP:
 
 ```bash
@@ -56,16 +68,36 @@ printf '%s\n' '{"query":"checkout","limit":10}' | npx --no-install kibi search -
 Read `resources/operation-access.md` for the route, result version, effects,
 mutability, and Prolog requirements of each operation.
 
+## Working in a git worktree or another directory
+
+Kibi MCP servers start in one project and answer from its knowledge base.
+Every Kibi MCP tool accepts `workspaceRoot`: when your working directory is not
+the project the server started in (a git worktree, a sibling checkout), pass
+your working directory as `workspaceRoot` on every call. Host plugins with
+pre-tool hooks add it for you. The server answers from that workspace when it
+is a worktree of the same repository or lies under the client's MCP roots.
+
+If a result carries a `workspace_mismatch` diagnostic, the answer came from a
+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`.
+
 ## Safe workflow
 
 1. Always discover before you mutate: start with `kb_search`, then exact-filter with `kb_query`. Use
-   `kb_status` when branch or freshness confidence matters. `kb_search` ranks
-   lexically unless you pass `rankingMode: "intent-v1"`, `semanticFacets`, or
-   `sourceLocations`; use intent mode with grounded facets for conceptual
-   questions and before changing a source file, and keep lexical search for
-   literal identifiers. See `resources/workflows.md` for the mode recipe.
-2. Resolve genuine ambiguity with the human; use semantic advisor/modeling
-   operations for deterministic interpretation and typed facts.
+   `kb_status` when branch or freshness confidence matters. `kb_search`
+   defaults to intent ranking, so you can ask it a question ("what governs
+   checkout rounding?"); its `data.answer` layer lists the current governing
+   requirements with linked facts, scenarios, tests, and ADRs, separates
+   superseded requirements, and labels observations as notes. Each governing
+   requirement also carries a `verdict` (`contradiction`, `infeasible`,
+   `unknown`, or `none`, which is not proof), the `exceptions` that exempt it,
+   and the `unknowns` the checks could not decide. Those links and verdicts are
+   discovery, not proof. Pass `sourceLocations` before changing a source file,
+   and `rankingMode: "legacy"` for literal identifier lookups. See
+   `resources/workflows.md` for the mode recipe.
+2. Resolve genuine ambiguity with the human; use `kb_model` for deterministic
+   interpretation and typed facts.
 3. Create endpoints before relationships and upsert small batches sequentially.
    Keep the canonical `REQ-* -> SCEN-* -> TEST-*` chain.
 4. Author tracked Markdown/YAML/manifests and relationship shards through Kibi;
@@ -77,9 +109,9 @@ mutability, and Prolog requirements of each operation.
 Run `kb_check` with specific rules during iteration and the unfiltered final
 check. Never fire `kb_upsert` calls in parallel; create or confirm endpoint
 entities before linking them. The canonical MCP names are `kb_search`,
-`kb_query`, `kb_upsert`, and `kb_check`.
+`kb_query`, `kb_model`, `kb_upsert`, and `kb_check`.
 
-For a task that explicitly supplies a malformed concrete mutation payload, locate and read that public request artifact before choosing an entity, preserving its exact entity ID, type, requested changes, and every intended relationship and endpoint. Do not substitute a seeded or convenient entity for the requested target. Start with kb_search, then exact-filter those targets with kb_query, and run kb_validate_upsert on that same payload; validation is not completion. Correct only diagnosed pre-commit errors and revalidate the corrected payload. Once authorized, apply the identical corrected and authorized payload with kb_upsert. If it returns committed_with_repairs, treat the mutation as committed, follow only the required repair actions, and neither retry it nor trigger unrelated semantic backfill for a schema-only repair. Exact-read every changed entity and relationship endpoint with kb_query, then finish with an unfiltered kb_check followed by a final kb_status.
+For a task that explicitly supplies a malformed concrete mutation payload, locate and read that public request artifact before choosing an entity, preserving its exact entity ID, type, requested changes, and every intended relationship and endpoint. Do not substitute a seeded or convenient entity for the requested target. Start with kb_search, then exact-filter those targets with kb_query, and run kb_upsert with dryRun: true on that same payload (CLI: validate-upsert); validation is not completion. Correct only diagnosed pre-commit errors and revalidate the corrected payload. Once authorized, apply the identical corrected and authorized payload with kb_upsert. If it returns committed_with_repairs, treat the mutation as committed, follow only the required repair actions, and neither retry it nor trigger unrelated semantic backfill for a schema-only repair. Exact-read every changed entity and relationship endpoint with kb_query, then finish with an unfiltered kb_check followed by a final kb_status.
 
 ## Closeout fields
 
@@ -110,8 +142,13 @@ migration, worktrees, quarantine, restore, and purge.
 ## Typed results and recovery
 
 Every CLI JSON/MCP result has `kibiProtocol`, `operation`, `resultVersion`,
-`status`, `data`, `effects`, `diagnostics`, and typed `nextActions`. Treat
-`status: error` as a failed pre-commit operation. If the status is
+`status`, `data`, `effects`, `diagnostics`, and typed `nextActions`.
+`status: error` normally means a failed pre-commit operation. The bootstrap
+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
 `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
@@ -124,8 +161,35 @@ Existing entities preserve body bytes when `document.body` is omitted; new
 requirements default their body to `semantic_text`. Relationship mutations
 patch canonical shards while preserving unrelated records. Authored entity
 deletion returns a hash-bound approval plan; requirements normally evolve via a
-new entity linked with `supersedes`. Read `resources/source-authoring.md` before
-source writes, deletion approval, or recovery.
+new entity linked with `supersedes`; set the replaced requirement to
+`status: closed` in the same change, because `kb_check` blocks an open
+superseded requirement and supersession cycles. Kibi compiles `source` from
+the entity's own file and never writes an authored `source` field, so
+`kb_upsert` cannot change one. When `kb_check` blocks a leftover value
+(`source-path-dangling`), run `kibi migrate`: its automatic
+`source_path_rewrite` action removes the value, or rewrites it when the file
+moved. Never hand-edit `.kb/` for it. Read `resources/source-authoring.md`
+before source writes, deletion approval, or recovery.
+
+`kb_apply_plan` applies a whole plan atomically: a failure changes nothing.
+An interrupted plan is settled by the next `kb_apply_plan`, `kb_upsert`, or
+`kb_delete` call, or by `kb_apply_plan` with its `recoveryJournalId`; never
+re-apply the original plan. On a detached HEAD, reads answer from a read-only
+snapshot and writes are refused; check out a branch before mutating.
+
+## Origin and approvals
+
+Entities record `origin` (`kind`: `human`, `agent`, `migration`, or `import`,
+plus optional `ref` and `approved_by`). `kb_upsert` records `kind: agent` on
+entities you create; leave `origin.approved_by` to the person who reviews them.
+An exception (a requirement that `exempts` another) exempts nothing until a
+human sets `approved_by`; `kb_check` flags approvals an agent recorded without
+corroboration. Never fill in an approval yourself. Record why a requirement
+exists in `rationale`, or link the ADR that explains it.
+
+Conditional clauses ("only when", "only if", "must not ... unless") compile
+into typed `forbid` rules linked by `requires_rule`, not property facts; one
+`kb_model` or `kb_compile_intent` cannot translate stays an `ontology_gap`.
 
 ## Semantic and proof guardrails
 
@@ -143,20 +207,20 @@ to committed `proof/baseline.json` with `kibi proof impact`.
 
 ## Predicate Ontology Decision Tree
 
-Call `kb_semantic_advisor` on the complete prose before encoding a clause.
+Call `kb_model` with `mode: "analyze"` on the complete prose before encoding a clause.
 Set requirement `logic_claims` to exactly the assertive `claim_key` values.
-For each relational clause, call `kb_suggest_predicates` with that clause and
+For each relational clause, call `kb_model` with `mode: "predicates"`, that clause, and
 `existingLogicClaims`. If lexical rank is a false positive, retry with the
 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`.
-Use `kb_model_requirement` for strict scalar clauses. Use
+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.
 Relationship direction is fixed, and every `from` in a relationship batch
 must equal the upserted entity ID.
 
-For conditional relational claims, after the initial `kb_suggest_predicates` and before any `kb_upsert`—including one needed for a missing schema—call read-only `kb_model_requirement` to preview suitable scalar or typed-rule modeling. Treat the preview as advisory: do not apply an irrelevant result or create unrequested facts, and retain an approved ground-predicate plan when it captures the whole claim. Preserve supplied arity, ordered argument roles, polarity, bound values, and one claim key per actual assertion; never split arguments across clauses or schemas or alter values to force uniqueness.
+For conditional relational claims, after the initial `kb_model` predicates call and before any `kb_upsert`—including one needed for a missing schema—call read-only `kb_model` with `mode: "requirement"` to preview suitable scalar or typed-rule modeling. Treat the preview as advisory: do not apply an irrelevant result or create unrequested facts, and retain an approved ground-predicate plan when it captures the whole claim. Preserve supplied arity, ordered argument roles, polarity, bound values, and one claim key per actual assertion; never split arguments across clauses or schemas or alter values to force uniqueness.
 
 ## Symbol-First Traceability
 

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

@@ -4,7 +4,7 @@ Requirement prose remains the human-readable source. Facts add queryable semanti
 
 ## Atomic Claim Coverage
 
-Logical coverage is clause-based, not entity-based. Give `kb_semantic_advisor` 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:
+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;
 - add the key to the exact current `logic_claims` set, removing only stale keys whose propositions no longer exist in the source;
@@ -17,7 +17,7 @@ Example compound prose: “Checkout requires payment authorization before order
 
 ## Predicate Lane (Relational Claims)
 
-Call `kb_semantic_advisor`, then `kb_suggest_predicates`. Apply a candidate only when its schema meaning and ordered arguments fit the claim. Use the returned `applyPlan` rather than hand-writing unsupported predicate names, and link the requirement to the predicate fact with `requires_predicate`.
+Call `kb_model` with `mode: "analyze"`, then with `mode: "predicates"`. Apply a candidate only when its schema meaning and ordered arguments fit the claim. Use the returned `applyPlan` rather than hand-writing unsupported predicate names, and link the requirement to the predicate fact with `requires_predicate`.
 
 Treat the result as a Prolog-shaped ground term, not executable source: `predicate_name(arg1,...,argN)`. The selected `predicate_schema` fixes the name, arity, argument roles, and order. Store that model through `predicate_name`, `predicate_args`, `canonical_key`, and `polarity`; never interpolate prose into raw Prolog, introduce variables, or use a graph relationship such as `verified_by` as the predicate name.
 
@@ -84,15 +84,15 @@ The full logical representation of a requirement is the conjunction of all of it
 
 Treat the advisor's proposition status as a hard routing decision. `nonlogical`/`subjective` prose is not a logical claim: keep it as one observation when needed and do not add its key to `logic_claims`. `ambiguous` prose stays an ambiguity observation. `ontology_gap` prose stays unresolved unless an approved schema or validated Logic IR is available. Never split a subjective or commentary sentence into synthetic clauses just because it contains conditional words or domain vocabulary.
 
-If authorized input supplies `projectLocalSchemas`, use those signatures as the authority. Create the minimal `predicate_schema` endpoint before lookup, then rerun `kb_suggest_predicates` on the complete relation if the first lookup had no candidate. Apply exactly one ground predicate and one claim key for that relation. For `must not`, `never`, `cannot`, or `forbidden` wording, preserve the positive schema and set `polarity: deny`; do not turn the result into an asserted predicate or invent a negative name. An empty lookup before the declared schema exists is a retry condition, not proof of an ontology gap.
+If authorized input supplies `projectLocalSchemas`, use those signatures as the authority. Create the minimal `predicate_schema` endpoint before lookup, then rerun `kb_model` with `mode: "predicates"` on the complete relation if the first lookup had no candidate. Apply exactly one ground predicate and one claim key for that relation. For `must not`, `never`, `cannot`, or `forbidden` wording, preserve the positive schema and set `polarity: deny`; do not turn the result into an asserted predicate or invent a negative name. An empty lookup before the declared schema exists is a retry condition, not proof of an ontology gap.
 
 ## Typed rule lane
 
-Use a validated `kibi.logic.v1` object for a proposition whose meaning includes a condition, exception, obligation, prohibition, permission, quantifier, cardinality bound, or bounded temporal relation. `kb_model_requirement` returns the `rule_schema` and `rule` facts plus a `requires_rule` edge. The rule stores canonical JSON and a deterministic hash; any rendered Prolog is an audit view and is never executed. Reject raw goals, function symbols, cuts, meta-calls, dynamic predicates, I/O, unsafe variables, unstratified negation, and unbounded aggregation. Keep the exact proposition in `claim_text`, its advisor key in `claim_key`, and its byte span in the semantic ledger. Run `rule-safety` and `rule-verifiability` before treating the rule as modeled.
+Use a validated `kibi.logic.v1` object for a proposition whose meaning includes a condition, exception, obligation, prohibition, permission, quantifier, cardinality bound, or bounded temporal relation. `kb_model` with `mode: "requirement"` returns the `rule_schema` and `rule` facts plus a `requires_rule` edge. The rule stores canonical JSON and a deterministic hash; any rendered Prolog is an audit view and is never executed. Reject raw goals, function symbols, cuts, meta-calls, dynamic predicates, I/O, unsafe variables, unstratified negation, and unbounded aggregation. Keep the exact proposition in `claim_text`, its advisor key in `claim_key`, and its byte span in the semantic ledger. Run `rule-safety` and `rule-verifiability` before treating the rule as modeled.
 
 ### Strict scalar
 
-Claim: “Sessions expire after at most 30 minutes.” This is a scalar limit, not a predicate. Route it through `kb_model_requirement` to a subject plus `property_value` with `operator: lte`, `value_type: int`, and `value_int: 30`, linked by `constrains` and `requires_property`.
+Claim: “Sessions expire after at most 30 minutes.” This is a scalar limit, not a predicate. Route it through `kb_model` with `mode: "requirement"` to a subject plus `property_value` with `operator: lte`, `value_type: int`, and `value_int: 30`, linked by `constrains` and `requires_property`.
 
 ### Ambiguous claim
 

package/dist/skills/kibi-usage/resources/kb-improvement.md

@@ -19,7 +19,7 @@ are in `resources/fact-lanes.md` and the Predicate-First workflow in
 | Process or governance note | `meta` | usually `relates_to` |
 | Runtime or config gate | `flag` | `guards` |
 
-Call `kb_semantic_advisor` on the complete requirement body before encoding a
+Call `kb_model` with `mode: "analyze"` on the complete requirement body before encoding a
 clause. Apply a predicate only when a returned schema fits; otherwise leave an
 ontology-gap observation.
 

package/dist/skills/kibi-usage/resources/logic-ir.md

@@ -4,12 +4,12 @@ Kibi stores human prose as readable requirement text, but verifiable meaning bel
 
 ## Two-pass extraction
 
-1. Run `kb_semantic_advisor` over the complete text. Supply explicit `clauses` when sentence splitting could hide a condition, exception, definition, descriptive assertion, threshold, quantity, or temporal qualifier.
+1. Run `kb_model` with `mode: "analyze"` over the complete text. Supply explicit `clauses` when sentence splitting could hide a condition, exception, definition, descriptive assertion, threshold, quantity, or temporal qualifier.
 2. Audit the returned `propositions` against the original UTF-8 text. Every assertive span must be `modeled`, `ambiguous`, `ontology_gap`, or `missing`; rationale, examples, and subjective commentary are `nonlogical` and remain readable prose.
 3. For each assertive proposition, submit up to three typed `interpretations` when alternatives are plausible. Kibi compares canonical semantic keys; materially different valid interpretations remain unresolved regardless of confidence.
 4. Apply only a validated plan, then read back the requirement, rule schema, rule fact, and all relationship targets. Run `rule-safety`, `rule-verifiability`, `semantic-completeness`, `logic-coverage`, and `domain-contradictions` before the final unfiltered check.
 
-When a project-local schema names several ordered arguments, those arguments are facets of one relation, not separate propositions. Preserve the advisor claim key for the complete relation and do not manufacture clauses for each argument. Supporting `predicate_schema` facts carry the declared signature only; the ground predicate fact carries the claim provenance. Apply the exact `kb_suggest_predicates`/`kb_model_requirement` plan, reducing a rejected schema payload through `kb_validate_upsert` rather than silently downgrading a fitting declared relation to an observation.
+When a project-local schema names several ordered arguments, those arguments are facets of one relation, not separate propositions. Preserve the advisor claim key for the complete relation and do not manufacture clauses for each argument. Supporting `predicate_schema` facts carry the declared signature only; the ground predicate fact carries the claim provenance. Apply the exact `kb_model` predicates/requirement plan, reducing a rejected schema payload through `kb_upsert` with `dryRun: true` rather than silently downgrading a fitting declared relation to an observation.
 
 ## Logic IR shape
 

package/dist/skills/kibi-usage/resources/operation-access.md

@@ -4,11 +4,12 @@ Generated from the public `OperationSpec` catalog. CLI JSON and MCP structured
 content use the same `KibiResult` envelope (protocol 1); result data is versioned
 per operation. Effects are authoritative for mutability and adapter annotations.
 
-| MCP tool name | CLI route | Input mode | Mutability | Requires Prolog | Effects | Interface | Result version | Destructive | Retry safety | Open-world | Output schema |
+| Operation | CLI route | Input mode | Mutability | Requires Prolog | Effects | Interface | Result version | Destructive | Retry safety | Open-world | Output schema |
 |---|---|---|---|---|---|---|---|---|---|---|---|
 | `kb_skills_list` | `skills-list` | --input JSON | read | no | local-read | peer; capability-selected | kibi.kb_skills_list.v1 | no | safe | no | yes |
 | `kb_skills_load` | `skills-load` | --input JSON | read | no | local-read | peer; capability-selected | kibi.kb_skills_load.v1 | no | safe | no | yes |
 | `kb_skills_read` | `skills-read` | --input JSON | read | no | local-read | peer; capability-selected | kibi.kb_skills_read.v1 | no | safe | no | yes |
+| `kb_skills` | `skill` | --input JSON | read | no | local-read | peer; capability-selected | kibi.kb_skills.v1 | no | safe | no | yes |
 | `kb_query` | `query` | --input JSON or flags | read | yes | kb-read | peer; capability-selected | kibi.kb_query.v1 | no | safe | no | yes |
 | `kb_search` | `search` | --input JSON or flags | read | yes | kb-read | peer; capability-selected | kibi.kb_search.v1 | no | safe | no | yes |
 | `kb_status` | `status` | --input JSON or flags | read | no | kb-read, workspace-read | peer; capability-selected | kibi.kb_status.v1 | no | safe | no | yes |
@@ -18,6 +19,7 @@ per operation. Effects are authoritative for mutability and adapter annotations.
 | `kb_semantic_advisor` | `semantic-advisor` | --input JSON | read | no | local-read | peer; capability-selected | kibi.kb_semantic_advisor.v1 | no | safe | no | yes |
 | `kb_model_requirement` | `model-requirement` | --input JSON | read | yes | kb-read | peer; capability-selected | kibi.kb_model_requirement.v1 | no | safe | no | yes |
 | `kb_suggest_predicates` | `suggest-predicates` | --input JSON | read | yes | kb-read | peer; capability-selected | kibi.kb_suggest_predicates.v1 | no | safe | no | yes |
+| `kb_model` | `model` | --input JSON | read | yes | kb-read | peer; capability-selected | kibi.kb_model.v1 | no | safe | no | yes |
 | `kb_plan_bootstrap` | `plan-bootstrap` | --input JSON | read | no | workspace-read | peer; capability-selected | kibi.kb_plan_bootstrap.v1 | no | safe | no | yes |
 | `kb_validate_upsert` | `validate-upsert` | --input JSON | read | yes | kb-read | peer; capability-selected | kibi.kb_validate_upsert.v1 | no | safe | no | yes |
 | `kb_upsert` | `upsert` | --input JSON | write | yes | kb-write, workspace-write | peer; capability-selected | kibi.kb_upsert.v1 | yes | unsafe | no | yes |
@@ -29,6 +31,28 @@ per operation. Effects are authoritative for mutability and adapter annotations.
 | `kb_apply_plan` | `apply-plan` | --input JSON | write | yes | kb-read, kb-write, workspace-read, workspace-write | peer; capability-selected | kibi.kb_apply_plan.v1 | yes | unsafe | no | yes |
 | `kb_ingest_proof` | `ingest-proof` | --input JSON | write | yes | kb-read, kb-write, workspace-read | peer; capability-selected | kibi.kb_ingest_proof.v1 | yes | unsafe | no | yes |
 
+## MCP tools versus catalog operations
+
+The MCP server registers 16 tools. Most carry their catalog operation name; the
+operations below are reached through a consolidated MCP call instead, while the
+CLI keeps their dedicated routes. Result payloads (for example
+`recommended_tools`, `suggested_next_tool`, or repair-plan steps) still name
+catalog operations, so translate them with this list.
+
+- `kb_skills_list`: MCP `kb_skills` with `action: "list"`; CLI `kibi skills list` (`skills-list`)
+- `kb_skills_load`: MCP `kb_skills` with `action: "load"`; CLI `kibi skills load` (`skills-load`)
+- `kb_skills_read`: MCP `kb_skills` with `action: "read"`; CLI `kibi skills read` (`skills-read`)
+- `kb_semantic_advisor`: MCP `kb_model` with `mode: "analyze"`; CLI `kibi semantic-advisor` (`semantic-advisor`)
+- `kb_model_requirement`: MCP `kb_model` with `mode: "requirement"`; CLI `kibi model-requirement` (`model-requirement`)
+- `kb_suggest_predicates`: MCP `kb_model` with `mode: "predicates"`; CLI `kibi suggest-predicates` (`suggest-predicates`)
+- `kb_validate_upsert`: MCP `kb_upsert` with `dryRun: true`; CLI `kibi validate-upsert` (`validate-upsert`)
+- `kb_sparql_remote`: MCP `kb_sparql_remote`, registered only when `KIBI_MCP_OPTIONAL_TOOLS` names it; CLI `kibi sparql-remote` (`sparql-remote`)
+
+The consolidated tools also have their own CLI routes: `kibi skill` for
+`kb_skills` and `kibi model` for `kb_model`. `kb_job_status` is likewise
+opt-in through `KIBI_MCP_OPTIONAL_TOOLS`; without it, `kb_check` with
+`async: true` runs synchronously.
+
 ## JSON execution recipe
 
 Use a trusted project-local, non-installing runner. Stdin contains one UTF-8 JSON
@@ -41,3 +65,7 @@ printf '%s\n' '{"query":"authentication","limit":10}' | npx --no-install kibi se
 `_diagnostic_telemetry` is adapter metadata, not business input. Never copy it
 into entity properties. On `committed_with_repairs`, follow typed required
 `nextActions` and do not retry the original mutation.
+
+`workspaceRoot` is an MCP-only routing argument naming the directory a call is
+about (see the kibi-usage skill). The CLI JSON routes do not accept it; they
+always run in the current directory.

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

@@ -82,14 +82,14 @@ diagnostics (`symbol_semantic_review_needed`).
 
 ## Workflow
 
-1. `kb_semantic_advisor` on the full description; audit or supply `clauses`.
-2. Relational clauses: `kb_suggest_predicates`, apply the predicate plan and
+1. `kb_model` (`mode: "analyze"`) on the full description; audit or supply `clauses`.
+2. Relational clauses: `kb_model` (`mode: "predicates"`), apply the predicate plan and
    `requires_predicate`.
-3. Scalar placement/alignment/order clauses: `kb_model_requirement`, apply the strict
+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.
-5. `kb_validate_upsert`, create endpoints first, then sequential `kb_upsert`.
+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`.