kibi-cursor 0.5.1 → 1.0.0

package/skills/kibi-usage/resources/source-authoring.md

@@ -0,0 +1,31 @@
+# Source-first authoring
+
+Tracked Markdown, YAML, symbol manifests, and relationship shards are the
+authoritative project memory. Prolog/RDF state is a rebuildable compiled
+artifact. Kibi may transactionally write tracked files, but it never stages or
+commits them; ordinary Git workflows remain responsible for review and merge.
+
+`kb_upsert` accepts `document.path` and `document.body`. Existing entities use
+their authored source by default and preserve body bytes when `body` is omitted.
+New requirements use `semantic_text` as their body. If a new entity has zero or
+multiple configured writable targets, provide an explicit workspace-relative
+`document.path`; absolute, traversal, and symlink escapes are rejected.
+
+New files are compiled only while their exact bytes are covered by a pending-
+source receipt. Sync compiles Git-tracked files plus those hash-bound pending
+files; arbitrary untracked files are ignored. Stage the file in Git to absorb
+and remove its receipt. A changed or missing pending file is a blocking hash
+drift diagnostic. Unresolved Git index conflicts are likewise blocking; Kibi
+never chooses a merge winner.
+
+Relationship upserts and relationship deletes patch only the canonical shard,
+preserving unrelated records. Authored entity deletion returns a hash-bound
+plan; approve that plan through `kb_apply_plan`. Evolve requirements with a new
+requirement and `supersedes`, rather than deleting the old semantic claim.
+
+On `committed_with_repairs`, inspect `effects` and execute the typed required
+`nextActions`. Never retry the original mutation after its authoritative commit.
+Cancellation follows the same rule: wait for the terminal journal state. A
+pre-commit rollback is retryable, a committed source with a failed derivative
+is repairable, and an indeterminate outcome is non-retryable until its recovery
+action resolves the journal.

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

@@ -1,5 +1,38 @@
 # Workflows
 
+## Closeout contract
+
+End every task with these five independent fields (not a single inferred
+success flag):
+
+```text
+taskOutcome: complete | interim | blocked
+kbState: clean_fresh | stale | dirty | legacy_compat | not_evaluated
+verificationState: fresh | dirty | unavailable | not_evaluated
+proofState: proven | mixed | unresolved | not_evaluated
+limitationDisposition: none | accepted | unaccepted | not_applicable
+```
+
+`taskOutcome` describes whether the requested objective was completed. The
+other fields describe observed system state. A clean check can coexist with a
+stale or dirty KB; unresolved proof can coexist with a complete maintenance
+task. An accepted limitation is an auditable operator decision, never logical
+grounding, receipt editing, or proof. For every quality diagnostic, record its
+ID, one of `fixed`, `accepted`, or `deferred`, and a rationale. Keep accepted
+ontology gaps and historical telemetry limitations explicit.
+
+Receipt reuse is safe only when the live verification snapshot, contract hash,
+freshness window, and every required case result still match. Otherwise rerun
+the contracted command. If the contract changed, retain every older receipt
+unchanged, append evidence for the current contract, and keep proof unresolved
+with `verification_contract_mismatch` until that current receipt exists.
+Obsolete symbols require current extraction or Git evidence before
+remap/deletion; transfer coverage only when existing test evidence supports it,
+then sync and read back status. Same-version packages with different export
+surfaces are a release defect: require a new package version and label any
+project override temporary. This skill never selects a package manager or
+edits dependency configuration.
+
 ## Discovery to Validation Sequence
 
 The canonical workflow for any KB operation follows this pattern:
@@ -13,9 +46,36 @@ The canonical workflow for any KB operation follows this pattern:
 7. **Create endpoints**: validated `kb_upsert` for new entities, sequentially
 8. **Link**: validated `kb_upsert` with `requires_rule`, `requires_predicate`, `constrains`, or `requires_property`, sequentially
 9. **Validate coverage and consistency**: targeted `rule-safety`, `rule-verifiability`, `semantic-completeness`, `logic-coverage`, `predicate-verifiability`, and `domain-contradictions`, then final full `kb_check`
+10. **Prove execution**: read `kb_status.verificationSnapshot`, run each scenario-backed E2E command exactly as declared by its `verification_contract.v1` through `kibi verify`, append the derived `kibi.verification-receipt.v2`, and re-run `kb_coverage`; never promote durable test status into fresh evidence
+11. **Repair incrementally**: require `kb_coverage.repairPlan.scope.complete`, apply only one `ready` dependency batch per requirement, validate before every sequential write, and rerun coverage before selecting the next batch
+12. **Gate workflow evidence**: when `.kb/usage.log` exists, run `kibi usage-metrics --format json --require-acceptance`; repair ranked telemetry diagnostics and never treat stale or insufficient evidence as a pass
 
 Every current requirement without `logic_claims` remains visible as non-blocking backfill debt. Once a manifest and `semantic_inventory` exist, the unfiltered check enforces correspondence to linked ground facts/rules and rejects silently missing assertive propositions.
 
+`kibi.repair-plan.v1` is a deterministic read-only plan, not a mutation script. Its phase order keeps source and proposition analysis ahead of ground endpoints, endpoints ahead of manifests/links, logic ahead of contradictions, scenarios ahead of tests and receipts, and production ownership ahead of coverage and coordinate refresh. A `blocked` batch is waiting on every listed `dependsOn` batch. If pagination makes the plan partial, increase the requirement coverage limit rather than applying an incomplete project view.
+
+`kibi.telemetry-acceptance.v1` evaluates the latest 200 usage events and keeps process health separate from graph correctness. It requires at least 95% complete diagnostic telemetry and, when applicable, exact recent validation before every upsert and a same-requirement/current-hash advisor pass before requirement writes. It also evaluates source lookup misses, comparable complete-scope proof-gap recovery, receipt-specific coverage gaps, and mutation targets retried three or more times. Failed metrics become ranked `category: telemetry` quality diagnostics; missing current coverage fields or evidence older than seven days stays `insufficient_evidence`.
+
+## Agent-guided migration
+
+`kb_status`, unfiltered `kb_check`, and complete-scope `kb_coverage` may return
+the shared `kibi.migration-plan.v2`. Treat it as a typed action graph: inspect
+the canonical `planHash`, scope completeness, dependencies, safety class,
+preconditions, postconditions, and evidence. Apply only ready automatic actions
+with `autoApplicable: true` through an explicitly approved `kb_apply_plan` or
+`kibi migrate --apply-safe` request containing the exact hash and action IDs.
+Never infer an operation from a prose suggestion, and never apply a partial
+plan's destructive symbol or relationship action.
+
+The migration engine may normalize schema/config metadata, cut over validated
+legacy storage with backups, migrate the exact historical branch attachment,
+refresh coordinates, and perform provenance-proven stale cleanup. It does not
+choose package managers, ground semantic claims, resolve contradictions, rerun
+E2E tests, rewrite receipt history, remap authored symbols, or accept
+limitations. Those actions remain explicit review/operator/execution steps.
+
+For `e2e_receipt_freshness_low`, query each listed requirement/test gap and run its exact current contract through `kibi verify`; this appends v2 evidence and preserves older history. If `coverage_depth_review` conflicts with a coverage row whose `proofStages.passingE2e.status` is `passed`, report the diagnostic as a stale heuristic and keep any independent proof gaps unresolved.
+
 ## Creating a New Feature
 ```
 1. kb_search to discover existing requirements and related knowledge
@@ -38,14 +98,24 @@ Every current requirement without `logic_claims` remains visible as non-blocking
 
 Do not create a test-fact pair. Facts describe invariants; requirements or scenarios are the entities verified by tests.
 
+## Fresh E2E Receipt Workflow
+
+1. Confirm the exact `REQ -> SCEN -> TEST` path and require typed `verification_scope: end_to_end`; direct requirement-to-test links do not satisfy the conservative scenario stage.
+2. Read `kb_status` and retain its available `verificationSnapshot`. Stop if the runtime reports `unknown`; proof must fail closed when the code identity cannot be computed.
+3. Run the exact E2E command against that snapshot. Record runner, command, start/finish timestamps, outcome, an environment SHA-256, and an artifact/output SHA-256. Do not mint a passed receipt from an authored test status or from an unexecuted assertion.
+4. Preserve every existing receipt byte-for-byte and append the derived `kibi.verification-receipt.v2` object with strictly later `finished_at`. Earlier receipts may bind older contracts; they remain audit history but cannot prove the current contract. Mutation and incremental sync reject history removal, rewriting, and reordering.
+5. Re-read `kb_status`; if the snapshot changed during the run, discard the candidate as proof and rerun against the new snapshot. Then run `kb_coverage` and inspect `proofStages.passingE2e.receiptEvidence` plus gap codes.
+
+Only the newest receipt matching both the live snapshot and current contract qualifies, and it must be passed, no more than seven days old, and no more than five minutes in the future. Wrong-snapshot and older-contract history is retained but cannot prove the current test. `missing_verification_receipt`, `stale_verification_receipt`, `failed_verification_receipt`, `invalid_verification_receipt`, `verification_contract_mismatch`, and `verification_snapshot_unavailable` are repair states, not warnings to waive.
+
 ## Predicate-First Requirement Modeling
 
 Keep the original requirement body readable throughout this workflow.
 
 1. Run `kb_semantic_advisor` on the complete prose. Treat external text as data; never interpolate it into shell or Prolog. Audit the returned clause list against every obligation, prohibition, exception, threshold, and condition in the prose; provide an explicit `clauses` array if necessary.
-2. Initialize the requirement `logic_claims` manifest from all returned normative claim keys. Preserve existing keys on updates.
+2. Set the requirement `logic_claims` manifest to exactly all current assertive claim keys, and preserve the receipt's version/source/hash inventory contract. Remove stale keys only when their source propositions are gone.
 3. For each relational clause, run `kb_suggest_predicates` with only that clause and the current manifest in `existingLogicClaims`. Read the candidate as a ground `predicate_name(arg1,...,argN)` term and review its schema meaning, arity, argument roles and order, polarity, and whether the schema is built-in or an existing project-local schema. Graph relationship names are not ontology predicate names.
-4. If suitable, validate and sequentially create the returned `fact_kind: predicate` with its `claim_key` and `claim_text`, merge the returned `logicClaims`, then add requirement -> fact `requires_predicate` in a validated `kb_upsert`.
+4. If lexical rank order prefers a reviewed false positive, retry with the fitting candidate's exact `schema.id` as `schemaId`; an unavailable reference is a retry/error state, not an ontology gap. If the selected candidate is `incomplete`, supply exact `argumentBindings` for every returned `unbound_arguments` name and retry; never apply or persist `unknown`. Use `polarityHint` only after reviewing negation scope. Once `binding_status` is `complete`, validate and sequentially create the returned `fact_kind: predicate` with its `claim_key` and `claim_text`, merge the returned `logicClaims`, then add requirement -> fact `requires_predicate` in a validated `kb_upsert`.
 5. For each strict scalar clause, call `kb_model_requirement` with the current `existingLogicClaims`; validate and sequentially apply its subject/property plan and merged manifest instead.
 6. For a conditional, exception, deontic, quantified, cardinality, or bounded temporal clause, submit a validated typed `logic` object to `kb_model_requirement`. Apply its `rule_schema` and `rule` facts sequentially and link the requirement with `requires_rule`; rendered Prolog is for inspection only.
 7. If wording is ambiguous, a candidate is only a lexical false positive, or no schema/IR interpretation fits, create the advised observation review artifact and apply its returned `relates_to` review anchor when present; report that claim key as unresolved. Use `review:ambiguity` for unresolved interpretation, `review:keyword-false-positive` for a vocabulary match that is not a domain assertion, and `review:ontology-gap` only for a true catalog gap. Define a new `predicate_schema` only when the task explicitly authorizes ontology extension and provides a stable signature.

package/agent-plugin/skills/init-kibi/SKILL.md

@@ -1,62 +0,0 @@
----
-id: init-kibi
-name: init-kibi
-description: Bootstrap and model knowledge safely using approved Kibi MCP initialization and mutation workflow.
-version: 1.0.0
-kibiCompatibility: "*"
-tags:
-  - kibi
-  - mcp
-  - bootstrap
-  - agent-guidance
----
-## Goal
-
-Set up or refresh Kibi knowledge for the current branch through approved Kibi interfaces only. Maintain source-file traceability for every repository-backed claim, and require explicit operator approval before any mutation.
-
-## Interface Selection
-
-1. If approved Kibi MCP tools are visible, use the MCP route.
-2. Otherwise, in a trusted workspace, use the canonical project-local CLI fallback: `npx --no-install kibi ...` or `bunx --no-install kibi ...`.
-3. If neither approved MCP tools nor the project-local CLI are available, stop and tell the operator to enable or install Kibi for this workspace.
-4. Never use a global fallback, an installing runner, or any route outside the approved Kibi interface.
-
-Use `kibi-usage/resources/operation-access.md` for the exact operation-to-route mapping. The CLI preview route accepts the same JSON object as `kb_autopilot_generate`:
-
-```bash
-echo '{"maxCandidates":25,"minConfidence":0.8}' | npx --no-install kibi autopilot-generate --input -
-```
-
-## Capability Workflow
-
-- Generate a read-only bootstrap preview with `kb_autopilot_generate`, or the dedicated CLI route `autopilot-generate --input`.
-- Show the generated preview and obtain explicit approval before writes.
-- Apply reviewed entity creation or updates with `kb_upsert`, or `upsert --input`.
-- If cleanup is needed, use `kb_delete`, or `delete --input`, only after checking dependencies and obtaining approval for the specific removal.
-- Finish with `kb_check`, or `check --input`, to validate the branch snapshot.
-
-## Guidance
-
-- Keep mutation requests explicit, small, and sequential.
-- Prefer source-linked entities so future `kb_query` lookups can verify repository context against source files.
-- Preserve traceability by linking facts, claims, scenarios, and tests to concrete project files whenever repository evidence supports it.
-- Do not read or edit files inside `.kb` directly; all changes go through the selected Kibi interface.
-- Ask at most four bounded context questions, and only when repository evidence is insufficient.
-- Stop at the documented operator repair boundary if the setup appears partial, inconsistent, or unsupported by the approved interface.
-
-## Public Training Trajectories
-
-- `init-kibi-bootstrap-analysis-train-1`: Analyze the cold-start repository and produce a read-only bootstrap preview using only the public Kibi MCP surface.
-- `init-kibi-bootstrap-analysis-train-2`: Analyze the cold-start repository and produce a read-only bootstrap preview using only the public Kibi MCP surface.
-- `init-kibi-bounded-context-questions-train-1`: Ask only the bounded context questions needed before bootstrap synthesis using only the public Kibi MCP surface.
-- `init-kibi-bounded-context-questions-train-2`: Ask only the bounded context questions needed before bootstrap synthesis using only the public Kibi MCP surface.
-- `init-kibi-approval-sequential-writes-train-1`: Apply the approved bootstrap plan sequentially and finish with validation using only the public Kibi MCP surface.
-- `init-kibi-approval-sequential-writes-train-2`: Apply the approved bootstrap plan sequentially and finish with validation using only the public Kibi MCP surface.
-- `init-kibi-repair-escalation-train-1`: Identify the partial setup and stop at the documented operator repair boundary using only the public Kibi MCP surface.
-- `init-kibi-repair-escalation-train-2`: Identify the partial setup and stop at the documented operator repair boundary using only the public Kibi MCP surface.
-
-## Training Data
-
-```json
-[{"taskId":"init-kibi-bootstrap-analysis-train-1","family":"bootstrap-analysis","reflection":"Analyze the cold-start repository and produce a read-only bootstrap preview. This is train case 1; use only the public Kibi MCP surface."},{"taskId":"init-kibi-bootstrap-analysis-train-2","family":"bootstrap-analysis","reflection":"Analyze the cold-start repository and produce a read-only bootstrap preview. This is train case 2; use only the public Kibi MCP surface."},{"taskId":"init-kibi-bounded-context-questions-train-1","family":"bounded-context-questions","reflection":"Ask only the bounded context questions needed before bootstrap synthesis. This is train case 1; use only the public Kibi MCP surface."},{"taskId":"init-kibi-bounded-context-questions-train-2","family":"bounded-context-questions","reflection":"Ask only the bounded context questions needed before bootstrap synthesis. This is train case 2; use only the public Kibi MCP surface."},{"taskId":"init-kibi-approval-sequential-writes-train-1","family":"approval-sequential-writes","reflection":"Apply the approved bootstrap plan sequentially and finish with validation. This is train case 1; use only the public Kibi MCP surface."},{"taskId":"init-kibi-approval-sequential-writes-train-2","family":"approval-sequential-writes","reflection":"Apply the approved bootstrap plan sequentially and finish with validation. This is train case 2; use only the public Kibi MCP surface."},{"taskId":"init-kibi-repair-escalation-train-1","family":"repair-escalation","reflection":"Identify the partial setup and stop at the documented operator repair boundary. This is train case 1; use only the public Kibi MCP surface."},{"taskId":"init-kibi-repair-escalation-train-2","family":"repair-escalation","reflection":"Identify the partial setup and stop at the documented operator repair boundary. This is train case 2; use only the public Kibi MCP surface."}]
-```

package/commands/init-kibi.md

@@ -1,21 +0,0 @@
----
-name: init-kibi
-description: Bootstrap Kibi knowledge for the current branch using the MCP autopilot workflow
----
-
-# Initialize Kibi
-
-Bootstrap repo-local Kibi memory without editing `.kb/` files directly.
-
-## Workflow
-
-1. Run `kb_autopilot_generate` for read-only synthesis.
-2. Show the preview and get explicit approval before writes.
-3. Apply approved entities with sequential `kb_upsert`.
-4. Finish with `kb_check`.
-
-## Guidance
-
-- Ask at most four bounded context questions when repository evidence is insufficient.
-- Prefer source-linked entities so future `kb_query` lookups can verify context.
-- Keep mutation batches small and reviewable.

package/dist/commands/init-kibi.md

@@ -1,21 +0,0 @@
----
-name: init-kibi
-description: Bootstrap Kibi knowledge for the current branch using the MCP autopilot workflow
----
-
-# Initialize Kibi
-
-Bootstrap repo-local Kibi memory without editing `.kb/` files directly.
-
-## Workflow
-
-1. Run `kb_autopilot_generate` for read-only synthesis.
-2. Show the preview and get explicit approval before writes.
-3. Apply approved entities with sequential `kb_upsert`.
-4. Finish with `kb_check`.
-
-## Guidance
-
-- Ask at most four bounded context questions when repository evidence is insufficient.
-- Prefer source-linked entities so future `kb_query` lookups can verify context.
-- Keep mutation batches small and reviewable.

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

@@ -1,62 +0,0 @@
----
-id: init-kibi
-name: init-kibi
-description: Bootstrap and model knowledge safely using approved Kibi MCP initialization and mutation workflow.
-version: 1.0.0
-kibiCompatibility: "*"
-tags:
-  - kibi
-  - mcp
-  - bootstrap
-  - agent-guidance
----
-## Goal
-
-Set up or refresh Kibi knowledge for the current branch through approved Kibi interfaces only. Maintain source-file traceability for every repository-backed claim, and require explicit operator approval before any mutation.
-
-## Interface Selection
-
-1. If approved Kibi MCP tools are visible, use the MCP route.
-2. Otherwise, in a trusted workspace, use the canonical project-local CLI fallback: `npx --no-install kibi ...` or `bunx --no-install kibi ...`.
-3. If neither approved MCP tools nor the project-local CLI are available, stop and tell the operator to enable or install Kibi for this workspace.
-4. Never use a global fallback, an installing runner, or any route outside the approved Kibi interface.
-
-Use `kibi-usage/resources/operation-access.md` for the exact operation-to-route mapping. The CLI preview route accepts the same JSON object as `kb_autopilot_generate`:
-
-```bash
-echo '{"maxCandidates":25,"minConfidence":0.8}' | npx --no-install kibi autopilot-generate --input -
-```
-
-## Capability Workflow
-
-- Generate a read-only bootstrap preview with `kb_autopilot_generate`, or the dedicated CLI route `autopilot-generate --input`.
-- Show the generated preview and obtain explicit approval before writes.
-- Apply reviewed entity creation or updates with `kb_upsert`, or `upsert --input`.
-- If cleanup is needed, use `kb_delete`, or `delete --input`, only after checking dependencies and obtaining approval for the specific removal.
-- Finish with `kb_check`, or `check --input`, to validate the branch snapshot.
-
-## Guidance
-
-- Keep mutation requests explicit, small, and sequential.
-- Prefer source-linked entities so future `kb_query` lookups can verify repository context against source files.
-- Preserve traceability by linking facts, claims, scenarios, and tests to concrete project files whenever repository evidence supports it.
-- Do not read or edit files inside `.kb` directly; all changes go through the selected Kibi interface.
-- Ask at most four bounded context questions, and only when repository evidence is insufficient.
-- Stop at the documented operator repair boundary if the setup appears partial, inconsistent, or unsupported by the approved interface.
-
-## Public Training Trajectories
-
-- `init-kibi-bootstrap-analysis-train-1`: Analyze the cold-start repository and produce a read-only bootstrap preview using only the public Kibi MCP surface.
-- `init-kibi-bootstrap-analysis-train-2`: Analyze the cold-start repository and produce a read-only bootstrap preview using only the public Kibi MCP surface.
-- `init-kibi-bounded-context-questions-train-1`: Ask only the bounded context questions needed before bootstrap synthesis using only the public Kibi MCP surface.
-- `init-kibi-bounded-context-questions-train-2`: Ask only the bounded context questions needed before bootstrap synthesis using only the public Kibi MCP surface.
-- `init-kibi-approval-sequential-writes-train-1`: Apply the approved bootstrap plan sequentially and finish with validation using only the public Kibi MCP surface.
-- `init-kibi-approval-sequential-writes-train-2`: Apply the approved bootstrap plan sequentially and finish with validation using only the public Kibi MCP surface.
-- `init-kibi-repair-escalation-train-1`: Identify the partial setup and stop at the documented operator repair boundary using only the public Kibi MCP surface.
-- `init-kibi-repair-escalation-train-2`: Identify the partial setup and stop at the documented operator repair boundary using only the public Kibi MCP surface.
-
-## Training Data
-
-```json
-[{"taskId":"init-kibi-bootstrap-analysis-train-1","family":"bootstrap-analysis","reflection":"Analyze the cold-start repository and produce a read-only bootstrap preview. This is train case 1; use only the public Kibi MCP surface."},{"taskId":"init-kibi-bootstrap-analysis-train-2","family":"bootstrap-analysis","reflection":"Analyze the cold-start repository and produce a read-only bootstrap preview. This is train case 2; use only the public Kibi MCP surface."},{"taskId":"init-kibi-bounded-context-questions-train-1","family":"bounded-context-questions","reflection":"Ask only the bounded context questions needed before bootstrap synthesis. This is train case 1; use only the public Kibi MCP surface."},{"taskId":"init-kibi-bounded-context-questions-train-2","family":"bounded-context-questions","reflection":"Ask only the bounded context questions needed before bootstrap synthesis. This is train case 2; use only the public Kibi MCP surface."},{"taskId":"init-kibi-approval-sequential-writes-train-1","family":"approval-sequential-writes","reflection":"Apply the approved bootstrap plan sequentially and finish with validation. This is train case 1; use only the public Kibi MCP surface."},{"taskId":"init-kibi-approval-sequential-writes-train-2","family":"approval-sequential-writes","reflection":"Apply the approved bootstrap plan sequentially and finish with validation. This is train case 2; use only the public Kibi MCP surface."},{"taskId":"init-kibi-repair-escalation-train-1","family":"repair-escalation","reflection":"Identify the partial setup and stop at the documented operator repair boundary. This is train case 1; use only the public Kibi MCP surface."},{"taskId":"init-kibi-repair-escalation-train-2","family":"repair-escalation","reflection":"Identify the partial setup and stop at the documented operator repair boundary. This is train case 2; use only the public Kibi MCP surface."}]
-```

package/skills/init-kibi/SKILL.md

@@ -1,62 +0,0 @@
----
-id: init-kibi
-name: init-kibi
-description: Bootstrap and model knowledge safely using approved Kibi MCP initialization and mutation workflow.
-version: 1.0.0
-kibiCompatibility: "*"
-tags:
-  - kibi
-  - mcp
-  - bootstrap
-  - agent-guidance
----
-## Goal
-
-Set up or refresh Kibi knowledge for the current branch through approved Kibi interfaces only. Maintain source-file traceability for every repository-backed claim, and require explicit operator approval before any mutation.
-
-## Interface Selection
-
-1. If approved Kibi MCP tools are visible, use the MCP route.
-2. Otherwise, in a trusted workspace, use the canonical project-local CLI fallback: `npx --no-install kibi ...` or `bunx --no-install kibi ...`.
-3. If neither approved MCP tools nor the project-local CLI are available, stop and tell the operator to enable or install Kibi for this workspace.
-4. Never use a global fallback, an installing runner, or any route outside the approved Kibi interface.
-
-Use `kibi-usage/resources/operation-access.md` for the exact operation-to-route mapping. The CLI preview route accepts the same JSON object as `kb_autopilot_generate`:
-
-```bash
-echo '{"maxCandidates":25,"minConfidence":0.8}' | npx --no-install kibi autopilot-generate --input -
-```
-
-## Capability Workflow
-
-- Generate a read-only bootstrap preview with `kb_autopilot_generate`, or the dedicated CLI route `autopilot-generate --input`.
-- Show the generated preview and obtain explicit approval before writes.
-- Apply reviewed entity creation or updates with `kb_upsert`, or `upsert --input`.
-- If cleanup is needed, use `kb_delete`, or `delete --input`, only after checking dependencies and obtaining approval for the specific removal.
-- Finish with `kb_check`, or `check --input`, to validate the branch snapshot.
-
-## Guidance
-
-- Keep mutation requests explicit, small, and sequential.
-- Prefer source-linked entities so future `kb_query` lookups can verify repository context against source files.
-- Preserve traceability by linking facts, claims, scenarios, and tests to concrete project files whenever repository evidence supports it.
-- Do not read or edit files inside `.kb` directly; all changes go through the selected Kibi interface.
-- Ask at most four bounded context questions, and only when repository evidence is insufficient.
-- Stop at the documented operator repair boundary if the setup appears partial, inconsistent, or unsupported by the approved interface.
-
-## Public Training Trajectories
-
-- `init-kibi-bootstrap-analysis-train-1`: Analyze the cold-start repository and produce a read-only bootstrap preview using only the public Kibi MCP surface.
-- `init-kibi-bootstrap-analysis-train-2`: Analyze the cold-start repository and produce a read-only bootstrap preview using only the public Kibi MCP surface.
-- `init-kibi-bounded-context-questions-train-1`: Ask only the bounded context questions needed before bootstrap synthesis using only the public Kibi MCP surface.
-- `init-kibi-bounded-context-questions-train-2`: Ask only the bounded context questions needed before bootstrap synthesis using only the public Kibi MCP surface.
-- `init-kibi-approval-sequential-writes-train-1`: Apply the approved bootstrap plan sequentially and finish with validation using only the public Kibi MCP surface.
-- `init-kibi-approval-sequential-writes-train-2`: Apply the approved bootstrap plan sequentially and finish with validation using only the public Kibi MCP surface.
-- `init-kibi-repair-escalation-train-1`: Identify the partial setup and stop at the documented operator repair boundary using only the public Kibi MCP surface.
-- `init-kibi-repair-escalation-train-2`: Identify the partial setup and stop at the documented operator repair boundary using only the public Kibi MCP surface.
-
-## Training Data
-
-```json
-[{"taskId":"init-kibi-bootstrap-analysis-train-1","family":"bootstrap-analysis","reflection":"Analyze the cold-start repository and produce a read-only bootstrap preview. This is train case 1; use only the public Kibi MCP surface."},{"taskId":"init-kibi-bootstrap-analysis-train-2","family":"bootstrap-analysis","reflection":"Analyze the cold-start repository and produce a read-only bootstrap preview. This is train case 2; use only the public Kibi MCP surface."},{"taskId":"init-kibi-bounded-context-questions-train-1","family":"bounded-context-questions","reflection":"Ask only the bounded context questions needed before bootstrap synthesis. This is train case 1; use only the public Kibi MCP surface."},{"taskId":"init-kibi-bounded-context-questions-train-2","family":"bounded-context-questions","reflection":"Ask only the bounded context questions needed before bootstrap synthesis. This is train case 2; use only the public Kibi MCP surface."},{"taskId":"init-kibi-approval-sequential-writes-train-1","family":"approval-sequential-writes","reflection":"Apply the approved bootstrap plan sequentially and finish with validation. This is train case 1; use only the public Kibi MCP surface."},{"taskId":"init-kibi-approval-sequential-writes-train-2","family":"approval-sequential-writes","reflection":"Apply the approved bootstrap plan sequentially and finish with validation. This is train case 2; use only the public Kibi MCP surface."},{"taskId":"init-kibi-repair-escalation-train-1","family":"repair-escalation","reflection":"Identify the partial setup and stop at the documented operator repair boundary. This is train case 1; use only the public Kibi MCP surface."},{"taskId":"init-kibi-repair-escalation-train-2","family":"repair-escalation","reflection":"Identify the partial setup and stop at the documented operator repair boundary. This is train case 2; use only the public Kibi MCP surface."}]
-```