kibi-cursor 2.7.4 → 2.7.6

package/.cursor-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "kibi-cursor",
   "displayName": "Kibi",
-  "version": "2.7.4",
+  "version": "2.7.6",
   "description": "Optional Cursor adapter for Kibi. Requires project-local kibi-cli, kibi-mcp, and kibi-core (SWI-Prolog is bundled on Linux and macOS) before the bundled MCP server can start.",
   "license": "AGPL-3.0-or-later",
   "author": {

package/CHANGELOG.md

@@ -1,5 +1,31 @@
 # kibi-cursor
 
+## 2.7.6
+
+### Patch Changes
+
+- Updated dependencies [b9ec91d]
+  - kibi-agent-core@0.7.0
+
+## 2.7.5
+
+### Patch Changes
+
+- 445ced0: Bootstrap no longer plans a declared intent claim as a new requirement when it only restates a requirement that is already in the knowledge base. A claim whose statement or excerpt matches an existing requirement's title, its semantic text or one of its sentences (ignoring case, whitespace and punctuation) is counted as already in the KB and names that requirement; a claim that comes close without matching is still planned, with a diagnostic naming the requirement to review. MCP tools that reject their input now return the same error code the CLI does (for example `VALIDATION_FAILED` for a clause that is not a verbatim fragment), in `structuredContent.error`, instead of a plain text failure.
+  - `kb_plan_bootstrap`: before planning an `intent` claim, the planner reads every current requirement (`kb:current_req/1`, projected to id, title and `semantic_text`) through the engine it already uses for existing ids, only when intent claims are declared. A normalized exact match of the claim's `statement` or `excerpt` against the title, the whole semantic text or one sentence of it adds an `entity_exists` row with `matchedId`, `matchedBy: "restatement"` and `matchedField`, and the per-source accounting counts it as already in the KB. A token-set Jaccard of 0.8 or more (the entity-context restatement threshold) without an exact match keeps the candidate, adds `possible_restatement:<id>` to its evidence and emits a diagnostic. Requirements are compared in id order, so the plan hash stays stable for the same KB and context.
+  - MCP `addTool`: an `InputError` or `OperationError` thrown by a handler (matched by class, or by name and an upper-case `code` when bundled separately) returns `isError: true` with a protocol 1 error envelope (`status: "error"`, `error: { code, message, retryable }`) and the text `Tool <name> failed: [<code>] <message>`, matching the CLI JSON route. Errors without a Kibi code still raise `Tool <name> failed: …`.
+  - `kibi-runtime` exports `codedErrorOf` and `CodedErrorFields`.
+  - Skills: `kibi-bootstrap` 3.14.0 (claims that restate a current requirement count as already in the KB; review "closely restates" diagnostics before approval).
+
+- d960810: A file with no linked symbols is no longer read as a file no rule covers. Before such a file is edited, the Claude Code and Codex hooks name the current requirements whose titles share the file's path words, and a `kb_check` scoped to the file reports the same candidates, so an agent changing `coach-dashboard.html` is pointed at the coach inbox requirement instead of concluding there is no knowledge-base impact. Agents are also told that recording the behavior a change adds is part of finishing it and needs no permission.
+  - `kibi-agent-core`: new `requirement-candidates` module (`pathTopicWords`, `rankRequirementCandidates`, `requirementCandidatesForPath`); `unownedSourceNote` takes the candidates, says that no link does not mean no rule, and drops candidates rather than exceed the snippet budget.
+  - `kibi-cli`: an impact-enabled `kb_check` emits `source_file_unowned` (`info`, non-blocking) for each file in `sourceFiles` that no manifest symbol links to a requirement, including files Kibi does not extract symbols from (HTML templates), with `evidence.candidates`. The unlinked-symbol `symbol_semantic_review_needed` suggestion now says recording the behavior needs no permission.
+  - `kibi-claude`, `kibi-codex`: the unlinked-file edit note names candidate requirements. The Claude Code session-start context no longer says unlinked files get no context, and says recording new behavior needs no permission; ZCode's session-start context says the same.
+  - `kibi-usage` skill 2.19.0: record new behavior without asking; confirm the candidates an unlinked-file note names.
+
+- Updated dependencies [d960810]
+  - kibi-agent-core@0.6.0
+
 ## 2.7.4
 
 ### Patch Changes

package/agent-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
   "name": "kibi",
-  "version": "2.7.4",
+  "version": "2.7.6",
   "description": "Repo-local, per-branch, queryable knowledge base. Portable Agent Plugin packaging Kibi's Agent Skills and MCP server.",
   "author": { "name": "Kibi" },
   "homepage": "https://looted.github.io/kibi/",

package/agent-plugin/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.13.0
+version: 3.14.0
 kibiCompatibility: ">=1.0.0"
 tags:
   - kibi
@@ -24,7 +24,7 @@ Make `kb_status` your first tool call on every bootstrap task. This includes rev
 - **Review a supplied plan or preview, or judge approval readiness or coverage:** call `kb_status`, then run your own read-only `kb_plan_bootstrap` preview. Compare it with the supplied one: hash, candidates, citations, `suppressedCandidates`, `sourceOnlySignals`, and diagnostics. Report what is ready, what is missing or uncited, and any conflicts for the human. Do not apply. End with `kb_status`.
 - **Blocked, partial, failed, or repair:** never conclude from `kb_status` alone. Run a read-only `kb_plan_bootstrap` preview and report its eligibility and next-action fields (for example `planEligible`, `nextAction`). If it names operator-only repair such as `doctor`, report it and stop. Read `resources/branch-lifecycle.md` before migration or repair. End with `kb_status`.
 - **New or thin knowledge base, or apply an approved plan:** follow the procedure below.
-- **Knowledge base already seeded** (`activationMode: attached_seeded_handoff`): follow the same procedure. Kibi generates no discovered candidates here, but it still plans the intent claims you declare, deduplicated against the existing KB: claims already in the KB are counted as already in the KB, and a plan of the rest is `ready` and applies with `kb_apply_plan` after approval. Never fall back to one `kb_compile_intent` plus one write per claim while such a plan exists. Use `kb_compile_intent` only for claims the plan could not write (`sourceOnlySignals`, `suppressed_by_activation`, `invalid_write`), and `kb_search`/`kb_query` for existing knowledge.
+- **Knowledge base already seeded** (`activationMode: attached_seeded_handoff`): follow the same procedure. Kibi generates no discovered candidates here, but it still plans the intent claims you declare, deduplicated against the existing KB: a claim whose entity exists, or whose statement or excerpt restates a current requirement (same words once case and punctuation are ignored), is counted as already in the KB with the matched id, and a plan of the rest is `ready` and applies with `kb_apply_plan` after approval. A diagnostic saying a claim "closely restates" a requirement means that claim is still planned: show both to the human before approval, and drop the claim or link the two with `restates` or `supersedes`. Never fall back to one `kb_compile_intent` plus one write per claim while such a plan exists. Use `kb_compile_intent` only for claims the plan could not write (`sourceOnlySignals`, `suppressed_by_activation`, `invalid_write`), and `kb_search`/`kb_query` for existing knowledge.
 
 ## Goal
 

package/agent-plugin/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.18.0
+version: 2.19.0
 kibiCompatibility: ">=1.0.0"
 tags:
   - kibi
@@ -112,9 +112,11 @@ it is a pointer to the knowledge, never proof. Each line answers one question:
 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
+the file is unowned, not that no rule covers it. When the note names
+requirements whose titles share the path's words, `kb_query` each one and
+treat a match as the governing rule; otherwise find it with `kb_search` and
+`sourceLocations`. Link the symbol that implements it (for markup, the
+component that renders 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.
@@ -136,7 +138,11 @@ still answers and `kibi sync` regenerates the manifest. The search tip and the
 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.
+   Keep the canonical `REQ-* -> SCEN-* -> TEST-*` chain. Recording the
+   behavior a change adds (a requirement with a scenario, and an `implements`
+   link from the symbol) is part of finishing that change, not a separate
+   request: do it without asking. Ask only when the change conflicts with a
+   recorded rule.
 4. Author tracked Markdown/YAML/manifests and relationship shards through Kibi;
    Kibi never Git-stages or commits those files. Do not read or edit `.kb`
    directly.

package/dist/.cursor-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "kibi-cursor",
   "displayName": "Kibi",
-  "version": "2.7.4",
+  "version": "2.7.6",
   "description": "Optional Cursor adapter for Kibi. Requires project-local kibi-cli, kibi-mcp, and kibi-core (SWI-Prolog is bundled on Linux and macOS) before the bundled MCP server can start.",
   "license": "AGPL-3.0-or-later",
   "author": {

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

@@ -1,5 +1,5 @@
 {
-  "kibi-bootstrap/SKILL.md": "41057fc1966b40ed8111a122a0c41c73efa180fb3afbb0d1d1f9ff94625fb97e",
+  "kibi-bootstrap/SKILL.md": "81787f3c3936c57e7d7a354c15a197d8dfd9fad5b3920bd655fe9ce91c8bfcc6",
   "kibi-bootstrap/resources/bootstrap.md": "e93fae88a6853d0092cde7eee33f7d4943a8141e3841bfe3f64ab73247867b6a",
   "kibi-bootstrap/resources/branch-lifecycle.md": "c854264ce888439140883a3fc636db5e522f020dd27b30a5c1ecc4105b64ed13",
   "kibi-bootstrap/resources/operation-access.md": "b5a6a59e72d800c376e7fad79132897623c32a0ce152a1e8d73f9628b444db51",
@@ -13,7 +13,7 @@
   "kibi-traceability/resources/operation-access.md": "39f7972ab7f4ae7479e78f7072bb50e8e6c4cdf4f857425f69d2522d37db437c",
   "kibi-traceability/resources/source-authoring.md": "408c6ee2bef1b84e0194c0538ef929c26a0a617e631b2234247388140dbbdd08",
   "kibi-traceability/resources/traceability.md": "38c290a0bc71bd1692e115f22694743946e2f69630e134acfd43cee5f613fb88",
-  "kibi-usage/SKILL.md": "7c1b469c7bf8332f74196b6a7f40fe5e7ae82d97e36bb8c50cbac2047b8b420c",
+  "kibi-usage/SKILL.md": "1d3ac2064f5c65d702db7445d36d8bc0ed741355d7a25ad301ab326e201d8e76",
   "kibi-usage/resources/branch-lifecycle.md": "f1bf359e9826e83c548f3cd0287f8175a62456527b0132b06b3f9f74aa59b7d6",
   "kibi-usage/resources/fact-lanes.md": "899218f90396aa469b6e34aeb5f7ea1f38bf11bb326102319f376c213859fb33",
   "kibi-usage/resources/kb-improvement.md": "a8408fce27342bdce6415a6718599e53fe00bb33aa1fd3dc42353ec6f61adcd7",

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.13.0
+version: 3.14.0
 kibiCompatibility: ">=1.0.0"
 tags:
   - kibi
@@ -24,7 +24,7 @@ Make `kb_status` your first tool call on every bootstrap task. This includes rev
 - **Review a supplied plan or preview, or judge approval readiness or coverage:** call `kb_status`, then run your own read-only `kb_plan_bootstrap` preview. Compare it with the supplied one: hash, candidates, citations, `suppressedCandidates`, `sourceOnlySignals`, and diagnostics. Report what is ready, what is missing or uncited, and any conflicts for the human. Do not apply. End with `kb_status`.
 - **Blocked, partial, failed, or repair:** never conclude from `kb_status` alone. Run a read-only `kb_plan_bootstrap` preview and report its eligibility and next-action fields (for example `planEligible`, `nextAction`). If it names operator-only repair such as `doctor`, report it and stop. Read `resources/branch-lifecycle.md` before migration or repair. End with `kb_status`.
 - **New or thin knowledge base, or apply an approved plan:** follow the procedure below.
-- **Knowledge base already seeded** (`activationMode: attached_seeded_handoff`): follow the same procedure. Kibi generates no discovered candidates here, but it still plans the intent claims you declare, deduplicated against the existing KB: claims already in the KB are counted as already in the KB, and a plan of the rest is `ready` and applies with `kb_apply_plan` after approval. Never fall back to one `kb_compile_intent` plus one write per claim while such a plan exists. Use `kb_compile_intent` only for claims the plan could not write (`sourceOnlySignals`, `suppressed_by_activation`, `invalid_write`), and `kb_search`/`kb_query` for existing knowledge.
+- **Knowledge base already seeded** (`activationMode: attached_seeded_handoff`): follow the same procedure. Kibi generates no discovered candidates here, but it still plans the intent claims you declare, deduplicated against the existing KB: a claim whose entity exists, or whose statement or excerpt restates a current requirement (same words once case and punctuation are ignored), is counted as already in the KB with the matched id, and a plan of the rest is `ready` and applies with `kb_apply_plan` after approval. A diagnostic saying a claim "closely restates" a requirement means that claim is still planned: show both to the human before approval, and drop the claim or link the two with `restates` or `supersedes`. Never fall back to one `kb_compile_intent` plus one write per claim while such a plan exists. Use `kb_compile_intent` only for claims the plan could not write (`sourceOnlySignals`, `suppressed_by_activation`, `invalid_write`), and `kb_search`/`kb_query` for existing knowledge.
 
 ## Goal
 

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.18.0
+version: 2.19.0
 kibiCompatibility: ">=1.0.0"
 tags:
   - kibi
@@ -112,9 +112,11 @@ it is a pointer to the knowledge, never proof. Each line answers one question:
 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
+the file is unowned, not that no rule covers it. When the note names
+requirements whose titles share the path's words, `kb_query` each one and
+treat a match as the governing rule; otherwise find it with `kb_search` and
+`sourceLocations`. Link the symbol that implements it (for markup, the
+component that renders 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.
@@ -136,7 +138,11 @@ still answers and `kibi sync` regenerates the manifest. The search tip and the
 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.
+   Keep the canonical `REQ-* -> SCEN-* -> TEST-*` chain. Recording the
+   behavior a change adds (a requirement with a scenario, and an `implements`
+   link from the symbol) is part of finishing that change, not a separate
+   request: do it without asking. Ask only when the change conflicts with a
+   recorded rule.
 4. Author tracked Markdown/YAML/manifests and relationship shards through Kibi;
    Kibi never Git-stages or commits those files. Do not read or edit `.kb`
    directly.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "kibi-cursor",
-  "version": "2.7.4",
+  "version": "2.7.6",
   "description": "Kibi Cursor plugin - thin adapter for Cursor MCP integration and editor hooks",
   "type": "module",
   "main": "dist/index.js",
@@ -59,7 +59,7 @@
     }
   },
   "dependencies": {
-    "kibi-agent-core": "^0.5.0"
+    "kibi-agent-core": "^0.7.0"
   },
   "devDependencies": {
     "@types/node": "latest",

package/skills/.canon-hash.json

@@ -1,5 +1,5 @@
 {
-  "kibi-bootstrap/SKILL.md": "41057fc1966b40ed8111a122a0c41c73efa180fb3afbb0d1d1f9ff94625fb97e",
+  "kibi-bootstrap/SKILL.md": "81787f3c3936c57e7d7a354c15a197d8dfd9fad5b3920bd655fe9ce91c8bfcc6",
   "kibi-bootstrap/resources/bootstrap.md": "e93fae88a6853d0092cde7eee33f7d4943a8141e3841bfe3f64ab73247867b6a",
   "kibi-bootstrap/resources/branch-lifecycle.md": "c854264ce888439140883a3fc636db5e522f020dd27b30a5c1ecc4105b64ed13",
   "kibi-bootstrap/resources/operation-access.md": "b5a6a59e72d800c376e7fad79132897623c32a0ce152a1e8d73f9628b444db51",
@@ -13,7 +13,7 @@
   "kibi-traceability/resources/operation-access.md": "39f7972ab7f4ae7479e78f7072bb50e8e6c4cdf4f857425f69d2522d37db437c",
   "kibi-traceability/resources/source-authoring.md": "408c6ee2bef1b84e0194c0538ef929c26a0a617e631b2234247388140dbbdd08",
   "kibi-traceability/resources/traceability.md": "38c290a0bc71bd1692e115f22694743946e2f69630e134acfd43cee5f613fb88",
-  "kibi-usage/SKILL.md": "7c1b469c7bf8332f74196b6a7f40fe5e7ae82d97e36bb8c50cbac2047b8b420c",
+  "kibi-usage/SKILL.md": "1d3ac2064f5c65d702db7445d36d8bc0ed741355d7a25ad301ab326e201d8e76",
   "kibi-usage/resources/branch-lifecycle.md": "f1bf359e9826e83c548f3cd0287f8175a62456527b0132b06b3f9f74aa59b7d6",
   "kibi-usage/resources/fact-lanes.md": "899218f90396aa469b6e34aeb5f7ea1f38bf11bb326102319f376c213859fb33",
   "kibi-usage/resources/kb-improvement.md": "a8408fce27342bdce6415a6718599e53fe00bb33aa1fd3dc42353ec6f61adcd7",

package/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.13.0
+version: 3.14.0
 kibiCompatibility: ">=1.0.0"
 tags:
   - kibi
@@ -24,7 +24,7 @@ Make `kb_status` your first tool call on every bootstrap task. This includes rev
 - **Review a supplied plan or preview, or judge approval readiness or coverage:** call `kb_status`, then run your own read-only `kb_plan_bootstrap` preview. Compare it with the supplied one: hash, candidates, citations, `suppressedCandidates`, `sourceOnlySignals`, and diagnostics. Report what is ready, what is missing or uncited, and any conflicts for the human. Do not apply. End with `kb_status`.
 - **Blocked, partial, failed, or repair:** never conclude from `kb_status` alone. Run a read-only `kb_plan_bootstrap` preview and report its eligibility and next-action fields (for example `planEligible`, `nextAction`). If it names operator-only repair such as `doctor`, report it and stop. Read `resources/branch-lifecycle.md` before migration or repair. End with `kb_status`.
 - **New or thin knowledge base, or apply an approved plan:** follow the procedure below.
-- **Knowledge base already seeded** (`activationMode: attached_seeded_handoff`): follow the same procedure. Kibi generates no discovered candidates here, but it still plans the intent claims you declare, deduplicated against the existing KB: claims already in the KB are counted as already in the KB, and a plan of the rest is `ready` and applies with `kb_apply_plan` after approval. Never fall back to one `kb_compile_intent` plus one write per claim while such a plan exists. Use `kb_compile_intent` only for claims the plan could not write (`sourceOnlySignals`, `suppressed_by_activation`, `invalid_write`), and `kb_search`/`kb_query` for existing knowledge.
+- **Knowledge base already seeded** (`activationMode: attached_seeded_handoff`): follow the same procedure. Kibi generates no discovered candidates here, but it still plans the intent claims you declare, deduplicated against the existing KB: a claim whose entity exists, or whose statement or excerpt restates a current requirement (same words once case and punctuation are ignored), is counted as already in the KB with the matched id, and a plan of the rest is `ready` and applies with `kb_apply_plan` after approval. A diagnostic saying a claim "closely restates" a requirement means that claim is still planned: show both to the human before approval, and drop the claim or link the two with `restates` or `supersedes`. Never fall back to one `kb_compile_intent` plus one write per claim while such a plan exists. Use `kb_compile_intent` only for claims the plan could not write (`sourceOnlySignals`, `suppressed_by_activation`, `invalid_write`), and `kb_search`/`kb_query` for existing knowledge.
 
 ## Goal
 

package/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.18.0
+version: 2.19.0
 kibiCompatibility: ">=1.0.0"
 tags:
   - kibi
@@ -112,9 +112,11 @@ it is a pointer to the knowledge, never proof. Each line answers one question:
 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
+the file is unowned, not that no rule covers it. When the note names
+requirements whose titles share the path's words, `kb_query` each one and
+treat a match as the governing rule; otherwise find it with `kb_search` and
+`sourceLocations`. Link the symbol that implements it (for markup, the
+component that renders 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.
@@ -136,7 +138,11 @@ still answers and `kibi sync` regenerates the manifest. The search tip and the
 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.
+   Keep the canonical `REQ-* -> SCEN-* -> TEST-*` chain. Recording the
+   behavior a change adds (a requirement with a scenario, and an `implements`
+   link from the symbol) is part of finishing that change, not a separate
+   request: do it without asking. Ask only when the change conflicts with a
+   recorded rule.
 4. Author tracked Markdown/YAML/manifests and relationship shards through Kibi;
    Kibi never Git-stages or commits those files. Do not read or edit `.kb`
    directly.