kibi-cursor 2.7.3 → 2.7.5
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.cursor-plugin/plugin.json +1 -1
- package/CHANGELOG.md +29 -0
- package/agent-plugin/plugin.json +1 -1
- package/agent-plugin/skills/kibi-bootstrap/SKILL.md +2 -2
- package/agent-plugin/skills/kibi-usage/SKILL.md +18 -7
- package/dist/.cursor-plugin/plugin.json +1 -1
- package/dist/skills/.canon-hash.json +2 -2
- package/dist/skills/kibi-bootstrap/SKILL.md +2 -2
- package/dist/skills/kibi-usage/SKILL.md +18 -7
- package/package.json +2 -2
- package/skills/.canon-hash.json +2 -2
- package/skills/kibi-bootstrap/SKILL.md +2 -2
- package/skills/kibi-usage/SKILL.md +18 -7
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "kibi-cursor",
|
|
3
3
|
"displayName": "Kibi",
|
|
4
|
-
"version": "2.7.
|
|
4
|
+
"version": "2.7.5",
|
|
5
5
|
"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.",
|
|
6
6
|
"license": "AGPL-3.0-or-later",
|
|
7
7
|
"author": {
|
package/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,34 @@
|
|
|
1
1
|
# kibi-cursor
|
|
2
2
|
|
|
3
|
+
## 2.7.5
|
|
4
|
+
|
|
5
|
+
### Patch Changes
|
|
6
|
+
|
|
7
|
+
- 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.
|
|
8
|
+
- `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.
|
|
9
|
+
- 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: …`.
|
|
10
|
+
- `kibi-runtime` exports `codedErrorOf` and `CodedErrorFields`.
|
|
11
|
+
- Skills: `kibi-bootstrap` 3.14.0 (claims that restate a current requirement count as already in the KB; review "closely restates" diagnostics before approval).
|
|
12
|
+
|
|
13
|
+
- 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.
|
|
14
|
+
- `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.
|
|
15
|
+
- `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.
|
|
16
|
+
- `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.
|
|
17
|
+
- `kibi-usage` skill 2.19.0: record new behavior without asking; confirm the candidates an unlinked-file note names.
|
|
18
|
+
|
|
19
|
+
- Updated dependencies [d960810]
|
|
20
|
+
- kibi-agent-core@0.6.0
|
|
21
|
+
|
|
22
|
+
## 2.7.4
|
|
23
|
+
|
|
24
|
+
### Patch Changes
|
|
25
|
+
|
|
26
|
+
- a26ba8c: A firm requirement or ADR can no longer be reworded in place by an agent. `kb_upsert` refuses to change its title, statement or ADR body, or to lower its firmness, unless the write cites new words from the person who owns the rule, and `kb_check` reports the same change made directly to the file. Context sections, tags, status and links stay editable, and superseding with a new firm decision still works as before.
|
|
27
|
+
- `kb_upsert` (dryRun and `kb_apply_plan` steps included) rejects an in-place claim change of a current firm decision without a new `origin.ref` (or `approval_ref` on a requirement): `Entity validation failed: <ID> is a firm decision, so kb_upsert does not change its <fields> in place`.
|
|
28
|
+
- New canonical `kb_check` rule `decision-firm-edited` compares current firm decisions with `HEAD` and blocks a changed claim that cites no new human words; it reports nothing outside a Git checkout or before the first commit.
|
|
29
|
+
- A requirement's claim is its title, its `semantic_text` (or the statement its body derives); an ADR's claim is its title and body. Lowering firmness or replacing the origin with an agent's counts as a change.
|
|
30
|
+
- `kibi-usage` skill 2.18.0 tells agents not to edit firm decisions in place; the `firmness` input schema description now states the origin-derived default and the edit rule.
|
|
31
|
+
|
|
3
32
|
## 2.7.3
|
|
4
33
|
|
|
5
34
|
### Patch Changes
|
package/agent-plugin/plugin.json
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
|
|
3
3
|
"name": "kibi",
|
|
4
|
-
"version": "2.7.
|
|
4
|
+
"version": "2.7.5",
|
|
5
5
|
"description": "Repo-local, per-branch, queryable knowledge base. Portable Agent Plugin packaging Kibi's Agent Skills and MCP server.",
|
|
6
6
|
"author": { "name": "Kibi" },
|
|
7
7
|
"homepage": "https://looted.github.io/kibi/",
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
id: kibi-bootstrap
|
|
3
3
|
name: kibi-bootstrap
|
|
4
4
|
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."
|
|
5
|
-
version: 3.
|
|
5
|
+
version: 3.14.0
|
|
6
6
|
kibiCompatibility: ">=1.0.0"
|
|
7
7
|
tags:
|
|
8
8
|
- kibi
|
|
@@ -24,7 +24,7 @@ Make `kb_status` your first tool call on every bootstrap task. This includes rev
|
|
|
24
24
|
- **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`.
|
|
25
25
|
- **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`.
|
|
26
26
|
- **New or thin knowledge base, or apply an approved plan:** follow the procedure below.
|
|
27
|
-
- **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:
|
|
27
|
+
- **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.
|
|
28
28
|
|
|
29
29
|
## Goal
|
|
30
30
|
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
id: kibi-usage
|
|
3
3
|
name: Kibi Usage
|
|
4
4
|
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.
|
|
5
|
-
version: 2.
|
|
5
|
+
version: 2.19.0
|
|
6
6
|
kibiCompatibility: ">=1.0.0"
|
|
7
7
|
tags:
|
|
8
8
|
- kibi
|
|
@@ -112,9 +112,11 @@ it is a pointer to the knowledge, never proof. Each line answers one question:
|
|
|
112
112
|
A file already shown this session gets only the one-line `Kibi: this edit to
|
|
113
113
|
<path> is inside <symbol>` update; the facts and tests from its first snippet
|
|
114
114
|
still apply. `Kibi: no symbol in <path> is linked to a requirement yet` means
|
|
115
|
-
the file is unowned
|
|
116
|
-
|
|
117
|
-
|
|
115
|
+
the file is unowned, not that no rule covers it. When the note names
|
|
116
|
+
requirements whose titles share the path's words, `kb_query` each one and
|
|
117
|
+
treat a match as the governing rule; otherwise find it with `kb_search` and
|
|
118
|
+
`sourceLocations`. Link the symbol that implements it (for markup, the
|
|
119
|
+
component that renders it) with `implements` through `kb_upsert`. Without a readable manifest (`Kibi: the hook could not read
|
|
118
120
|
.kb/symbols.yaml`) snippets are off for this session; `kb_query({sourceFile})`
|
|
119
121
|
still answers and `kibi sync` regenerates the manifest. The search tip and the
|
|
120
122
|
`.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
|
|
|
136
138
|
2. Resolve genuine ambiguity with the human; use `kb_model` for deterministic
|
|
137
139
|
interpretation and typed facts.
|
|
138
140
|
3. Create endpoints before relationships and upsert small batches sequentially.
|
|
139
|
-
Keep the canonical `REQ-* -> SCEN-* -> TEST-*` chain.
|
|
141
|
+
Keep the canonical `REQ-* -> SCEN-* -> TEST-*` chain. Recording the
|
|
142
|
+
behavior a change adds (a requirement with a scenario, and an `implements`
|
|
143
|
+
link from the symbol) is part of finishing that change, not a separate
|
|
144
|
+
request: do it without asking. Ask only when the change conflicts with a
|
|
145
|
+
recorded rule.
|
|
140
146
|
4. Author tracked Markdown/YAML/manifests and relationship shards through Kibi;
|
|
141
147
|
Kibi never Git-stages or commits those files. Do not read or edit `.kb`
|
|
142
148
|
directly.
|
|
@@ -368,7 +374,11 @@ Search answers, `kb_query` rows and hook snippets show it (snippets label only
|
|
|
368
374
|
wrote it (`origin.kind: agent`): rules people wrote, imported or carried
|
|
369
375
|
over from before origins existed are theirs. `kb_check` blocks an explicit
|
|
370
376
|
`firmness: firm` without `origin.ref` to their words, and a replacement of
|
|
371
|
-
a firm decision that is not itself firm.
|
|
377
|
+
a firm decision that is not itself firm. Never edit a firm decision's
|
|
378
|
+
title, statement or (ADR) body in place, by `kb_upsert` or on disk:
|
|
379
|
+
`kb_upsert` refuses it and `kb_check` reports `decision-firm-edited`
|
|
380
|
+
unless the edit cites new human words in `origin.ref`. Context sections,
|
|
381
|
+
tags, status and links stay editable.
|
|
372
382
|
- `default`: a delegated or agent choice (`firmness: default`, or an
|
|
373
383
|
agent-written decision without `firmness`). Follow it; supersede it only on
|
|
374
384
|
evidence that it is wrong (a failing test, a measured cost, a constraint it
|
|
@@ -381,7 +391,8 @@ conflict a person has to decide. Name the rule (id and what it requires) and
|
|
|
381
391
|
ask whether to change it; do not implement the request and do not supersede
|
|
382
392
|
the rule. Go ahead only when the person has said to change that rule, in this
|
|
383
393
|
task or in reply: then supersede it with `firmness: firm` and `origin.ref` to
|
|
384
|
-
their words,
|
|
394
|
+
their words (or, for a correction they asked for in place, update it with
|
|
395
|
+
`origin.ref` to those words), and say in the final answer which rule changed.
|
|
385
396
|
|
|
386
397
|
Set `firmness` from what a human actually said: only their stated rule is
|
|
387
398
|
`firm` (with `origin.ref`); "do whatever" or your own pick is `default`; a
|
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "kibi-cursor",
|
|
3
3
|
"displayName": "Kibi",
|
|
4
|
-
"version": "2.7.
|
|
4
|
+
"version": "2.7.5",
|
|
5
5
|
"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.",
|
|
6
6
|
"license": "AGPL-3.0-or-later",
|
|
7
7
|
"author": {
|
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
{
|
|
2
|
-
"kibi-bootstrap/SKILL.md": "
|
|
2
|
+
"kibi-bootstrap/SKILL.md": "81787f3c3936c57e7d7a354c15a197d8dfd9fad5b3920bd655fe9ce91c8bfcc6",
|
|
3
3
|
"kibi-bootstrap/resources/bootstrap.md": "e93fae88a6853d0092cde7eee33f7d4943a8141e3841bfe3f64ab73247867b6a",
|
|
4
4
|
"kibi-bootstrap/resources/branch-lifecycle.md": "c854264ce888439140883a3fc636db5e522f020dd27b30a5c1ecc4105b64ed13",
|
|
5
5
|
"kibi-bootstrap/resources/operation-access.md": "b5a6a59e72d800c376e7fad79132897623c32a0ce152a1e8d73f9628b444db51",
|
|
@@ -13,7 +13,7 @@
|
|
|
13
13
|
"kibi-traceability/resources/operation-access.md": "39f7972ab7f4ae7479e78f7072bb50e8e6c4cdf4f857425f69d2522d37db437c",
|
|
14
14
|
"kibi-traceability/resources/source-authoring.md": "408c6ee2bef1b84e0194c0538ef929c26a0a617e631b2234247388140dbbdd08",
|
|
15
15
|
"kibi-traceability/resources/traceability.md": "38c290a0bc71bd1692e115f22694743946e2f69630e134acfd43cee5f613fb88",
|
|
16
|
-
"kibi-usage/SKILL.md": "
|
|
16
|
+
"kibi-usage/SKILL.md": "1d3ac2064f5c65d702db7445d36d8bc0ed741355d7a25ad301ab326e201d8e76",
|
|
17
17
|
"kibi-usage/resources/branch-lifecycle.md": "f1bf359e9826e83c548f3cd0287f8175a62456527b0132b06b3f9f74aa59b7d6",
|
|
18
18
|
"kibi-usage/resources/fact-lanes.md": "899218f90396aa469b6e34aeb5f7ea1f38bf11bb326102319f376c213859fb33",
|
|
19
19
|
"kibi-usage/resources/kb-improvement.md": "a8408fce27342bdce6415a6718599e53fe00bb33aa1fd3dc42353ec6f61adcd7",
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
id: kibi-bootstrap
|
|
3
3
|
name: kibi-bootstrap
|
|
4
4
|
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."
|
|
5
|
-
version: 3.
|
|
5
|
+
version: 3.14.0
|
|
6
6
|
kibiCompatibility: ">=1.0.0"
|
|
7
7
|
tags:
|
|
8
8
|
- kibi
|
|
@@ -24,7 +24,7 @@ Make `kb_status` your first tool call on every bootstrap task. This includes rev
|
|
|
24
24
|
- **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`.
|
|
25
25
|
- **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`.
|
|
26
26
|
- **New or thin knowledge base, or apply an approved plan:** follow the procedure below.
|
|
27
|
-
- **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:
|
|
27
|
+
- **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.
|
|
28
28
|
|
|
29
29
|
## Goal
|
|
30
30
|
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
id: kibi-usage
|
|
3
3
|
name: Kibi Usage
|
|
4
4
|
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.
|
|
5
|
-
version: 2.
|
|
5
|
+
version: 2.19.0
|
|
6
6
|
kibiCompatibility: ">=1.0.0"
|
|
7
7
|
tags:
|
|
8
8
|
- kibi
|
|
@@ -112,9 +112,11 @@ it is a pointer to the knowledge, never proof. Each line answers one question:
|
|
|
112
112
|
A file already shown this session gets only the one-line `Kibi: this edit to
|
|
113
113
|
<path> is inside <symbol>` update; the facts and tests from its first snippet
|
|
114
114
|
still apply. `Kibi: no symbol in <path> is linked to a requirement yet` means
|
|
115
|
-
the file is unowned
|
|
116
|
-
|
|
117
|
-
|
|
115
|
+
the file is unowned, not that no rule covers it. When the note names
|
|
116
|
+
requirements whose titles share the path's words, `kb_query` each one and
|
|
117
|
+
treat a match as the governing rule; otherwise find it with `kb_search` and
|
|
118
|
+
`sourceLocations`. Link the symbol that implements it (for markup, the
|
|
119
|
+
component that renders it) with `implements` through `kb_upsert`. Without a readable manifest (`Kibi: the hook could not read
|
|
118
120
|
.kb/symbols.yaml`) snippets are off for this session; `kb_query({sourceFile})`
|
|
119
121
|
still answers and `kibi sync` regenerates the manifest. The search tip and the
|
|
120
122
|
`.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
|
|
|
136
138
|
2. Resolve genuine ambiguity with the human; use `kb_model` for deterministic
|
|
137
139
|
interpretation and typed facts.
|
|
138
140
|
3. Create endpoints before relationships and upsert small batches sequentially.
|
|
139
|
-
Keep the canonical `REQ-* -> SCEN-* -> TEST-*` chain.
|
|
141
|
+
Keep the canonical `REQ-* -> SCEN-* -> TEST-*` chain. Recording the
|
|
142
|
+
behavior a change adds (a requirement with a scenario, and an `implements`
|
|
143
|
+
link from the symbol) is part of finishing that change, not a separate
|
|
144
|
+
request: do it without asking. Ask only when the change conflicts with a
|
|
145
|
+
recorded rule.
|
|
140
146
|
4. Author tracked Markdown/YAML/manifests and relationship shards through Kibi;
|
|
141
147
|
Kibi never Git-stages or commits those files. Do not read or edit `.kb`
|
|
142
148
|
directly.
|
|
@@ -368,7 +374,11 @@ Search answers, `kb_query` rows and hook snippets show it (snippets label only
|
|
|
368
374
|
wrote it (`origin.kind: agent`): rules people wrote, imported or carried
|
|
369
375
|
over from before origins existed are theirs. `kb_check` blocks an explicit
|
|
370
376
|
`firmness: firm` without `origin.ref` to their words, and a replacement of
|
|
371
|
-
a firm decision that is not itself firm.
|
|
377
|
+
a firm decision that is not itself firm. Never edit a firm decision's
|
|
378
|
+
title, statement or (ADR) body in place, by `kb_upsert` or on disk:
|
|
379
|
+
`kb_upsert` refuses it and `kb_check` reports `decision-firm-edited`
|
|
380
|
+
unless the edit cites new human words in `origin.ref`. Context sections,
|
|
381
|
+
tags, status and links stay editable.
|
|
372
382
|
- `default`: a delegated or agent choice (`firmness: default`, or an
|
|
373
383
|
agent-written decision without `firmness`). Follow it; supersede it only on
|
|
374
384
|
evidence that it is wrong (a failing test, a measured cost, a constraint it
|
|
@@ -381,7 +391,8 @@ conflict a person has to decide. Name the rule (id and what it requires) and
|
|
|
381
391
|
ask whether to change it; do not implement the request and do not supersede
|
|
382
392
|
the rule. Go ahead only when the person has said to change that rule, in this
|
|
383
393
|
task or in reply: then supersede it with `firmness: firm` and `origin.ref` to
|
|
384
|
-
their words,
|
|
394
|
+
their words (or, for a correction they asked for in place, update it with
|
|
395
|
+
`origin.ref` to those words), and say in the final answer which rule changed.
|
|
385
396
|
|
|
386
397
|
Set `firmness` from what a human actually said: only their stated rule is
|
|
387
398
|
`firm` (with `origin.ref`); "do whatever" or your own pick is `default`; a
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "kibi-cursor",
|
|
3
|
-
"version": "2.7.
|
|
3
|
+
"version": "2.7.5",
|
|
4
4
|
"description": "Kibi Cursor plugin - thin adapter for Cursor MCP integration and editor hooks",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"main": "dist/index.js",
|
|
@@ -59,7 +59,7 @@
|
|
|
59
59
|
}
|
|
60
60
|
},
|
|
61
61
|
"dependencies": {
|
|
62
|
-
"kibi-agent-core": "^0.
|
|
62
|
+
"kibi-agent-core": "^0.6.0"
|
|
63
63
|
},
|
|
64
64
|
"devDependencies": {
|
|
65
65
|
"@types/node": "latest",
|
package/skills/.canon-hash.json
CHANGED
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
{
|
|
2
|
-
"kibi-bootstrap/SKILL.md": "
|
|
2
|
+
"kibi-bootstrap/SKILL.md": "81787f3c3936c57e7d7a354c15a197d8dfd9fad5b3920bd655fe9ce91c8bfcc6",
|
|
3
3
|
"kibi-bootstrap/resources/bootstrap.md": "e93fae88a6853d0092cde7eee33f7d4943a8141e3841bfe3f64ab73247867b6a",
|
|
4
4
|
"kibi-bootstrap/resources/branch-lifecycle.md": "c854264ce888439140883a3fc636db5e522f020dd27b30a5c1ecc4105b64ed13",
|
|
5
5
|
"kibi-bootstrap/resources/operation-access.md": "b5a6a59e72d800c376e7fad79132897623c32a0ce152a1e8d73f9628b444db51",
|
|
@@ -13,7 +13,7 @@
|
|
|
13
13
|
"kibi-traceability/resources/operation-access.md": "39f7972ab7f4ae7479e78f7072bb50e8e6c4cdf4f857425f69d2522d37db437c",
|
|
14
14
|
"kibi-traceability/resources/source-authoring.md": "408c6ee2bef1b84e0194c0538ef929c26a0a617e631b2234247388140dbbdd08",
|
|
15
15
|
"kibi-traceability/resources/traceability.md": "38c290a0bc71bd1692e115f22694743946e2f69630e134acfd43cee5f613fb88",
|
|
16
|
-
"kibi-usage/SKILL.md": "
|
|
16
|
+
"kibi-usage/SKILL.md": "1d3ac2064f5c65d702db7445d36d8bc0ed741355d7a25ad301ab326e201d8e76",
|
|
17
17
|
"kibi-usage/resources/branch-lifecycle.md": "f1bf359e9826e83c548f3cd0287f8175a62456527b0132b06b3f9f74aa59b7d6",
|
|
18
18
|
"kibi-usage/resources/fact-lanes.md": "899218f90396aa469b6e34aeb5f7ea1f38bf11bb326102319f376c213859fb33",
|
|
19
19
|
"kibi-usage/resources/kb-improvement.md": "a8408fce27342bdce6415a6718599e53fe00bb33aa1fd3dc42353ec6f61adcd7",
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
id: kibi-bootstrap
|
|
3
3
|
name: kibi-bootstrap
|
|
4
4
|
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."
|
|
5
|
-
version: 3.
|
|
5
|
+
version: 3.14.0
|
|
6
6
|
kibiCompatibility: ">=1.0.0"
|
|
7
7
|
tags:
|
|
8
8
|
- kibi
|
|
@@ -24,7 +24,7 @@ Make `kb_status` your first tool call on every bootstrap task. This includes rev
|
|
|
24
24
|
- **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`.
|
|
25
25
|
- **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`.
|
|
26
26
|
- **New or thin knowledge base, or apply an approved plan:** follow the procedure below.
|
|
27
|
-
- **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:
|
|
27
|
+
- **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.
|
|
28
28
|
|
|
29
29
|
## Goal
|
|
30
30
|
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
id: kibi-usage
|
|
3
3
|
name: Kibi Usage
|
|
4
4
|
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.
|
|
5
|
-
version: 2.
|
|
5
|
+
version: 2.19.0
|
|
6
6
|
kibiCompatibility: ">=1.0.0"
|
|
7
7
|
tags:
|
|
8
8
|
- kibi
|
|
@@ -112,9 +112,11 @@ it is a pointer to the knowledge, never proof. Each line answers one question:
|
|
|
112
112
|
A file already shown this session gets only the one-line `Kibi: this edit to
|
|
113
113
|
<path> is inside <symbol>` update; the facts and tests from its first snippet
|
|
114
114
|
still apply. `Kibi: no symbol in <path> is linked to a requirement yet` means
|
|
115
|
-
the file is unowned
|
|
116
|
-
|
|
117
|
-
|
|
115
|
+
the file is unowned, not that no rule covers it. When the note names
|
|
116
|
+
requirements whose titles share the path's words, `kb_query` each one and
|
|
117
|
+
treat a match as the governing rule; otherwise find it with `kb_search` and
|
|
118
|
+
`sourceLocations`. Link the symbol that implements it (for markup, the
|
|
119
|
+
component that renders it) with `implements` through `kb_upsert`. Without a readable manifest (`Kibi: the hook could not read
|
|
118
120
|
.kb/symbols.yaml`) snippets are off for this session; `kb_query({sourceFile})`
|
|
119
121
|
still answers and `kibi sync` regenerates the manifest. The search tip and the
|
|
120
122
|
`.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
|
|
|
136
138
|
2. Resolve genuine ambiguity with the human; use `kb_model` for deterministic
|
|
137
139
|
interpretation and typed facts.
|
|
138
140
|
3. Create endpoints before relationships and upsert small batches sequentially.
|
|
139
|
-
Keep the canonical `REQ-* -> SCEN-* -> TEST-*` chain.
|
|
141
|
+
Keep the canonical `REQ-* -> SCEN-* -> TEST-*` chain. Recording the
|
|
142
|
+
behavior a change adds (a requirement with a scenario, and an `implements`
|
|
143
|
+
link from the symbol) is part of finishing that change, not a separate
|
|
144
|
+
request: do it without asking. Ask only when the change conflicts with a
|
|
145
|
+
recorded rule.
|
|
140
146
|
4. Author tracked Markdown/YAML/manifests and relationship shards through Kibi;
|
|
141
147
|
Kibi never Git-stages or commits those files. Do not read or edit `.kb`
|
|
142
148
|
directly.
|
|
@@ -368,7 +374,11 @@ Search answers, `kb_query` rows and hook snippets show it (snippets label only
|
|
|
368
374
|
wrote it (`origin.kind: agent`): rules people wrote, imported or carried
|
|
369
375
|
over from before origins existed are theirs. `kb_check` blocks an explicit
|
|
370
376
|
`firmness: firm` without `origin.ref` to their words, and a replacement of
|
|
371
|
-
a firm decision that is not itself firm.
|
|
377
|
+
a firm decision that is not itself firm. Never edit a firm decision's
|
|
378
|
+
title, statement or (ADR) body in place, by `kb_upsert` or on disk:
|
|
379
|
+
`kb_upsert` refuses it and `kb_check` reports `decision-firm-edited`
|
|
380
|
+
unless the edit cites new human words in `origin.ref`. Context sections,
|
|
381
|
+
tags, status and links stay editable.
|
|
372
382
|
- `default`: a delegated or agent choice (`firmness: default`, or an
|
|
373
383
|
agent-written decision without `firmness`). Follow it; supersede it only on
|
|
374
384
|
evidence that it is wrong (a failing test, a measured cost, a constraint it
|
|
@@ -381,7 +391,8 @@ conflict a person has to decide. Name the rule (id and what it requires) and
|
|
|
381
391
|
ask whether to change it; do not implement the request and do not supersede
|
|
382
392
|
the rule. Go ahead only when the person has said to change that rule, in this
|
|
383
393
|
task or in reply: then supersede it with `firmness: firm` and `origin.ref` to
|
|
384
|
-
their words,
|
|
394
|
+
their words (or, for a correction they asked for in place, update it with
|
|
395
|
+
`origin.ref` to those words), and say in the final answer which rule changed.
|
|
385
396
|
|
|
386
397
|
Set `firmness` from what a human actually said: only their stated rule is
|
|
387
398
|
`firm` (with `origin.ref`); "do whatever" or your own pick is `default`; a
|