kibi-cursor 2.9.0 → 2.9.1

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.
Files changed (19) hide show
  1. package/.cursor-plugin/plugin.json +1 -1
  2. package/CHANGELOG.md +27 -0
  3. package/agent-plugin/plugin.json +1 -1
  4. package/agent-plugin/skills/kibi-freshness/SKILL.md +2 -2
  5. package/agent-plugin/skills/kibi-usage/SKILL.md +2 -2
  6. package/agent-plugin/skills/kibi-usage/resources/proof.md +36 -4
  7. package/agent-plugin/skills/kibi-usage/resources/workflows.md +1 -1
  8. package/dist/.cursor-plugin/plugin.json +1 -1
  9. package/dist/skills/.canon-hash.json +4 -4
  10. package/dist/skills/kibi-freshness/SKILL.md +2 -2
  11. package/dist/skills/kibi-usage/SKILL.md +2 -2
  12. package/dist/skills/kibi-usage/resources/proof.md +36 -4
  13. package/dist/skills/kibi-usage/resources/workflows.md +1 -1
  14. package/package.json +1 -1
  15. package/skills/.canon-hash.json +4 -4
  16. package/skills/kibi-freshness/SKILL.md +2 -2
  17. package/skills/kibi-usage/SKILL.md +2 -2
  18. package/skills/kibi-usage/resources/proof.md +36 -4
  19. package/skills/kibi-usage/resources/workflows.md +1 -1
package/.cursor-plugin/plugin.json CHANGED
@@ -1,7 +1,7 @@
1
1
  {
2
2
  "name": "kibi-cursor",
3
3
  "displayName": "Kibi",
4
- "version": "2.9.0",
4
+ "version": "2.9.1",
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,32 @@
1
1
  # kibi-cursor
2
2
 
3
+ ## 2.9.1
4
+
5
+ ### Patch Changes
6
+
7
+ - 39721a1: Every requirement now reports how strong the evidence behind it is, and passing end-to-end tests are no longer called proof.
8
+ - `kb_coverage` / `kibi coverage` rows carry `evidenceLevel`: `proved` (a re-checkable certificate covers every case; no proof kind issues one yet, so nothing reaches it today), `tested` (fresh end-to-end receipts cover every linked scenario), `asserted` (a person stands behind the requirement: it was approved, or it is firm by `firmness` or a non-agent origin, but nothing current checks it) or `unverified` (an agent wrote it and no person approved it). Each row lists the `evidence[]` entries that earned the level, with `kind`, `scope` and `level`, and the summary counts rows per level under `evidenceLevels`.
9
+ - The HTML report shows each requirement's level next to its id and counts the asserted and unverified requirements; its headline is now "Tested end to end" and the badge reads `% tested`. `kibi signoff` adds the level to each requirement's proof line when it is weaker than tested. The `kibi coverage` table gains an `Evidence` column and prints the per-level counts as `asserted=… proved=… tested=… unverified=…`. `kibi signoff` now counts a top-level `approved_by` as approval, as the evidence level does, so an approved agent requirement no longer shows as awaiting approval.
10
+ - The `kibi-usage` skill (2.23.0) explains the levels and tells agents never to report an asserted or unverified requirement as tested or proven.
11
+
12
+ **Migration (breaking).**
13
+ - The requirement proof contract is now `kibi.requirement-proof.v4`. `proofStatus: proven` is renamed `tested`; filter with `--status tested` (`statuses: ["tested"]`), since `proven` is rejected.
14
+ - Coverage summaries rename `proofProven` to `proofTested`. `kibi proof impact` results rename `proofProven` / `currentUnproven` to `proofTested` / `currentUntested`, `kb_apply_plan` closeout `proofState: proven` is now `tested`, and the diagnostic usage field `coverage_proven_count` is `coverage_tested_count`.
15
+ - `proof/baseline.json` files move to `kibi.proof-baseline.v3` with `proofTested`, `currentUntested` and `proofStatus: tested`. `kibi proof impact` still reads a committed v2 baseline, treating its `proven` rows as `tested`, so rewrite the file in the same commit you upgrade in or the next one.
16
+ - No knowledge-base migration is needed: nothing stored in `.kb/` changes.
17
+
18
+ - a1c7479: `kibi check` and `kb_check` now prove that the knowledge base is consistent, and leave a certificate for each answer that an independent checker re-checks.
19
+
20
+ The new canonical `kb-consistency` rule states four theorems about the facts current requirements name and produces a `kibi.certificates.v1` certificate for each: property facts are consistent (a model per subject, property and scope, or an irreducible contradiction core with one model per dropped fact), predicate facts and allow/deny decisions are consistent (one truth value per atom, one decision per key, or the two facts that disagree), and stored rules are stratified (a stratum per rule predicate, or a negation cycle). A separate checker module re-checks every certificate by evaluation only; it never runs the search that found it and does not load `checks.pl`. Each contradiction it re-verifies is a blocking violation that names the core facts and the requirements behind them, with the certificate under `evidence.certificate`; a certificate the checker rejects also blocks.
21
+
22
+ The property theorem is joint, so facts that contradict only together (every pair still admits a value) are reported even though the pairwise `domain-contradictions` rule is silent. `kibi check --staged` runs the rule too, so a commit that introduces such a contradiction is blocked. Contexts the checker cannot compare (mixed value types or units, unsupported operators or polarities, cores whose validity windows never overlap) are reported by the new advisory `kb-consistency-unresolved` rule and never count as consistent. Opposing rule pairs and scenario feasibility are not certified yet.
23
+
24
+ Certificates are regenerated on each run and are not committed. `kibi check --write-certificates <file>` saves the bundle, and `kibi check --certificates <file>` re-checks a saved one and prints the `kibi.verification.v1` report (a verdict of `proved`, `disproved` or `unresolved` per theorem, and every rejected certificate with the reason). The kibi-usage skill (2.24.0) tells agents how to act on the new findings. The kibi-freshness skill (2.1.0) now checks consistency with `domain-contradictions`, `kb-consistency` and `kb-consistency-unresolved` instead of the pairwise rule alone, reports a `kb-consistency` core as a conflict to resolve by superseding or changing a requirement, and reports an unresolved context as unresolved.
25
+
26
+ **Migration (breaking for KBs with joint contradictions).** No knowledge-base change is needed. A knowledge base whose facts contradict only jointly now fails `kibi check` until one of the requirements is changed or superseded; the violation names the core and the requirements to choose from. Integrations that pass a fixed `--rules` list or `rules` input are unaffected until they add `kb-consistency`.
27
+
28
+ Evidence levels and `kibi signoff` now count an agent-written requirement as approved only through `origin.approved_by`, the field `agent-requirement-unapproved` already reads. The top-level `approved_by` approves an exception, and an agent can write it, so on its own it no longer raises a requirement to `asserted` or shows it as approved in signoff.
29
+
3
30
  ## 2.9.0
4
31
 
5
32
  ### Minor 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.9.0",
4
+ "version": "2.9.1",
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/",
package/agent-plugin/skills/kibi-freshness/SKILL.md CHANGED
@@ -2,7 +2,7 @@
2
2
  id: kibi-freshness
3
3
  name: kibi-freshness
4
4
  description: Check exact Git attachment, branch migration/quarantine, compiled-store freshness, source linkage, and repair state before decisions or writes.
5
- version: 2.0.0
5
+ version: 2.1.0
6
6
  kibiCompatibility: ">=1.0.0"
7
7
  tags:
8
8
  - kibi
@@ -53,7 +53,7 @@ echo '{}' | npx --no-install kibi status --input -
53
53
  `committed_with_repairs`, follow required typed `nextActions`; never retry the
54
54
  original operation.
55
55
 
56
- For every freshness, branch, or completion question, call `kb_status` first, then `kb_query` the entities and source files that status names, then `kb_check` as the last Kibi call before answering. Never skip the query step, even when status alone seems to answer the question. If another query or write follows a check, run `kb_check` again before answering. When asked whether requirements are consistent or proven, run `kb_query`, then `kb_check` with the domain-contradictions rule, then `kb_coverage`, and read whether the analysis was complete. Report any unmodeled or unknown clause as incomplete analysis, not as consistent. Only when every clause is fully modeled and compatible, state plainly that no conflict was found. For authorized knowledge changes, keep the exact supplied target and intended relationship edges, and discover and query those targets first. Validate the payload with `kb_upsert` and `dryRun: true`, then perform the authorized `kb_upsert` with that same payload and read the result back exactly before the final checks. A passing dry run is validation, not completion. Distinct authorized payloads may need several sequential writes, each validated and read back, but never retry a mutation that already committed. If a mutation returns `committed_with_repairs`, follow its typed `nextActions` instead of repeating the original operation.
56
+ For every freshness, branch, or completion question, call `kb_status` first, then `kb_query` the entities and source files that status names, then `kb_check` as the last Kibi call before answering. Never skip the query step, even when status alone seems to answer the question. If another query or write follows a check, run `kb_check` again before answering. When asked whether requirements are consistent or proven, run `kb_query`, then `kb_check` with the rules `domain-contradictions`, `kb-consistency` and `kb-consistency-unresolved`, then `kb_coverage`, and read whether the analysis was complete. `domain-contradictions` compares facts two at a time; `kb-consistency` checks every fact of a property together, so a clean pairwise result is not proof. Report a `kb-consistency` violation as a conflict, name every requirement it lists, and give superseding or changing one of them as the next step; never edit or delete facts to make the check pass. Report a context `kb-consistency-unresolved` names as unresolved, never as consistent, with the step that would make it comparable. Report any unmodeled or unknown clause as incomplete analysis, not as consistent. Only when every clause is fully modeled and compatible, state plainly that no conflict was found. For authorized knowledge changes, keep the exact supplied target and intended relationship edges, and discover and query those targets first. Validate the payload with `kb_upsert` and `dryRun: true`, then perform the authorized `kb_upsert` with that same payload and read the result back exactly before the final checks. A passing dry run is validation, not completion. Distinct authorized payloads may need several sequential writes, each validated and read back, but never retry a mutation that already committed. If a mutation returns `committed_with_repairs`, follow its typed `nextActions` instead of repeating the original operation.
57
57
 
58
58
  ## Guidance
59
59
 
package/agent-plugin/skills/kibi-usage/SKILL.md CHANGED
@@ -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.22.0
5
+ version: 2.24.0
6
6
  kibiCompatibility: ">=1.0.0"
7
7
  tags:
8
8
  - kibi
@@ -168,7 +168,7 @@ End every task with these five independent fields:
168
168
  taskOutcome: complete | interim | blocked
169
169
  kbState: clean_fresh | stale | dirty | legacy_compat | not_evaluated
170
170
  verificationState: fresh | dirty | unavailable | not_evaluated
171
- proofState: proven | mixed | unresolved | not_evaluated
171
+ proofState: tested | mixed | unresolved | not_evaluated
172
172
  limitationDisposition: none | accepted | unaccepted | not_applicable
173
173
  ```
174
174
 
package/agent-plugin/skills/kibi-usage/resources/proof.md CHANGED
@@ -1,6 +1,6 @@
1
1
  # Proof and Verification Workflow
2
2
 
3
- Use this resource when a requirement must be proven before handoff, when
3
+ Use this resource when a requirement must be tested end to end before handoff, when
4
4
  wiring a proof-bearing test, or when `kb_ingest_proof` or `kibi prove`
5
5
  rejected evidence.
6
6
 
@@ -97,9 +97,9 @@ Cosmetic edits (descriptions, labels) never stale proof. Execution-relevant
97
97
  edits (command, artifact, targets, options, bindings, contract) change the
98
98
  effective fingerprint and do.
99
99
 
100
- ## What counts toward proofProven
100
+ ## What counts toward proofTested
101
101
 
102
- A requirement is proven only by its scenarios' tests, and a scenario test
102
+ A requirement reaches `proofStatus: tested` only through its scenarios' tests, and a scenario test
103
103
  counts only when it is an **end-to-end** test with a valid, fresh, passing
104
104
  receipt for the current snapshot.
105
105
 
@@ -109,7 +109,7 @@ receipt for the current snapshot.
109
109
  `source` path contains `e2e`) counts as end-to-end; anything else is
110
110
  `unknown` scope.
111
111
  - A `unit` or `integration` receipt is still recorded on the test entity, but
112
- it does not move `proofProven` for a behavioural requirement: the
112
+ it does not move `proofTested` for a behavioural requirement: the
113
113
  requirement keeps the `missing_passing_e2e` gap in `proofGaps`. The one
114
114
  exception is a scenario whose specifying requirements are all grounded only
115
115
  in component-scope UI predicates (`ui_pattern`, `same_pattern`,
@@ -120,6 +120,38 @@ receipt for the current snapshot.
120
120
  receipt does not change it, and a `passing` status without a fresh receipt
121
121
  proves nothing.
122
122
 
123
+ ## Evidence levels
124
+
125
+ Every requirement row also carries `evidenceLevel`, the strength of what backs
126
+ it, and `evidence`, the entries that earned it (each with `kind`, `scope` and
127
+ `level`):
128
+
129
+ - `proved`: a re-checkable certificate covers every case. No proof kind issues
130
+ certificates yet, so nothing reaches it today.
131
+ - `tested`: `proofStatus` is `tested`; fresh E2E receipts cover every linked
132
+ scenario.
133
+ - `asserted`: a person stands behind the statement (approved, or firm by
134
+ `firmness` or a non-agent origin) but nothing current checks it.
135
+ - `unverified`: an agent wrote it, no person approved it, nothing checks it.
136
+
137
+ Report the level as it is. Never call an `asserted` or `unverified`
138
+ requirement proven or tested, and never call `tested` proved. Firmness is a
139
+ separate axis: it says how sure the person is, not how strong the evidence is.
140
+
141
+ ## Knowledge-base certificates
142
+
143
+ `kb_check` (`kibi check`) proves facts about the KB itself in its
144
+ `kb-consistency` rule and re-checks each answer with an independent checker:
145
+ property facts are consistent (a model per subject, property and scope, or an
146
+ irreducible contradiction core), predicate facts and allow/deny decisions are
147
+ consistent, and stored rules are stratified. It catches facts that contradict
148
+ only together, which the pairwise `domain-contradictions` rule misses. A
149
+ `kb-consistency` violation names the core facts and the requirements behind
150
+ them: supersede or change one of those requirements; never edit the facts so
151
+ the check passes. Quote a `kb-consistency-unresolved` diagnostic as
152
+ unresolved, never as consistent. Opposing rule pairs and scenario
153
+ feasibility are not certified yet; their own rules still decide them.
154
+
123
155
  ## Attempt semantics (factual, never optimistic)
124
156
 
125
157
  - `attempts: {status: "complete", entries: [...]}` — known history; the
package/agent-plugin/skills/kibi-usage/resources/workflows.md CHANGED
@@ -9,7 +9,7 @@ success flag):
9
9
  taskOutcome: complete | interim | blocked
10
10
  kbState: clean_fresh | stale | dirty | legacy_compat | not_evaluated
11
11
  verificationState: fresh | dirty | unavailable | not_evaluated
12
- proofState: proven | mixed | unresolved | not_evaluated
12
+ proofState: tested | mixed | unresolved | not_evaluated
13
13
  limitationDisposition: none | accepted | unaccepted | not_applicable
14
14
  ```
15
15
 
package/dist/.cursor-plugin/plugin.json CHANGED
@@ -1,7 +1,7 @@
1
1
  {
2
2
  "name": "kibi-cursor",
3
3
  "displayName": "Kibi",
4
- "version": "2.9.0",
4
+ "version": "2.9.1",
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/dist/skills/.canon-hash.json CHANGED
@@ -9,7 +9,7 @@
9
9
  "kibi-decisions/SKILL.md": "384749d6a9196c978a6df5a0d89fffe1fab7bad9554bc77e6bc45282567c4184",
10
10
  "kibi-decisions/resources/decision-records.md": "1244ab963f78cfd47fc88dc9700bbfdbe2fad8a0d84da1fb7c40d718ccca710a",
11
11
  "kibi-decisions/resources/signoff-views.md": "f5de0c378de9094949b372485d6e1f06398eb1c60cd234077a89af312f3c9d07",
12
- "kibi-freshness/SKILL.md": "f1ccfa35dae113d7b3b2a61c455c1791dbc79732972d4604fbb82e002ff3c836",
12
+ "kibi-freshness/SKILL.md": "7474b7c22ca915006e930850274bc71efaf2e03dcf60d41a2936b70d64547052",
13
13
  "kibi-freshness/resources/branch-lifecycle.md": "ebc01b19fe3dca8df5fc0175978963f6f1204f71f7c805cb2a5fb1b277ac78e4",
14
14
  "kibi-freshness/resources/operation-access.md": "4e1db9294ee540cd29b8b3a2532a81e7894d5b4228b39e99ba48b37212f489f3",
15
15
  "kibi-freshness/resources/source-authoring.md": "41a0547ce4d2a112a0f3671d36720f07c447864db3b473e94eb88a8ce2d371ff",
@@ -18,15 +18,15 @@
18
18
  "kibi-traceability/resources/operation-access.md": "39f7972ab7f4ae7479e78f7072bb50e8e6c4cdf4f857425f69d2522d37db437c",
19
19
  "kibi-traceability/resources/source-authoring.md": "408c6ee2bef1b84e0194c0538ef929c26a0a617e631b2234247388140dbbdd08",
20
20
  "kibi-traceability/resources/traceability.md": "38c290a0bc71bd1692e115f22694743946e2f69630e134acfd43cee5f613fb88",
21
- "kibi-usage/SKILL.md": "c95fc81dfed557a46353df0ec3e9ab3cdf7fda8f3cf0a0062aec57d839873d4f",
21
+ "kibi-usage/SKILL.md": "e8efe1c31c601042cdcd3c96cb9cd81b009458410053a6cf5a44852dd0a1bcbf",
22
22
  "kibi-usage/resources/branch-lifecycle.md": "f1bf359e9826e83c548f3cd0287f8175a62456527b0132b06b3f9f74aa59b7d6",
23
23
  "kibi-usage/resources/fact-lanes.md": "899218f90396aa469b6e34aeb5f7ea1f38bf11bb326102319f376c213859fb33",
24
24
  "kibi-usage/resources/kb-improvement.md": "a8408fce27342bdce6415a6718599e53fe00bb33aa1fd3dc42353ec6f61adcd7",
25
25
  "kibi-usage/resources/logic-ir.md": "0e8ce8aad07433ab4803ec169149ff6c4e1cf8cf010af18fa6fd67862d9be807",
26
26
  "kibi-usage/resources/operation-access.md": "eb455796c066787ffd3fae8db0db1d3e87a84265a57f06ae61e30103cd6aed66",
27
- "kibi-usage/resources/proof.md": "2348819078034dd3df25664c4c707ff98f17520bbbd335bff4f48611cf672bb3",
27
+ "kibi-usage/resources/proof.md": "d44ced11dca304495cab186eea84bf33fbd9932653821559a7f20b4f1c8d5606",
28
28
  "kibi-usage/resources/relationship-directions.md": "0fdd67032c2d15299f772845fc4f807eb9435b09507bd87a5911ab33db2f143d",
29
29
  "kibi-usage/resources/source-authoring.md": "cad93f1e0ae08a676f2de7492f9227677880302327e74d159618fea86ca50abe",
30
30
  "kibi-usage/resources/ui-requirements.md": "f99c2a9a73bbb7bd92ce1f231db3056d544588be149a5b0d3f7cc6f28bc9eee9",
31
- "kibi-usage/resources/workflows.md": "9cfdcf8c21ad92ed5c72e0f350e9b1ab678ff263670e2c34d7d9277933ead1bf"
31
+ "kibi-usage/resources/workflows.md": "53c6889f375988a89a4cce8e68e79c7f621b15cc81cff915d61733642db87153"
32
32
  }
package/dist/skills/kibi-freshness/SKILL.md CHANGED
@@ -2,7 +2,7 @@
2
2
  id: kibi-freshness
3
3
  name: kibi-freshness
4
4
  description: Check exact Git attachment, branch migration/quarantine, compiled-store freshness, source linkage, and repair state before decisions or writes.
5
- version: 2.0.0
5
+ version: 2.1.0
6
6
  kibiCompatibility: ">=1.0.0"
7
7
  tags:
8
8
  - kibi
@@ -53,7 +53,7 @@ echo '{}' | npx --no-install kibi status --input -
53
53
  `committed_with_repairs`, follow required typed `nextActions`; never retry the
54
54
  original operation.
55
55
 
56
- For every freshness, branch, or completion question, call `kb_status` first, then `kb_query` the entities and source files that status names, then `kb_check` as the last Kibi call before answering. Never skip the query step, even when status alone seems to answer the question. If another query or write follows a check, run `kb_check` again before answering. When asked whether requirements are consistent or proven, run `kb_query`, then `kb_check` with the domain-contradictions rule, then `kb_coverage`, and read whether the analysis was complete. Report any unmodeled or unknown clause as incomplete analysis, not as consistent. Only when every clause is fully modeled and compatible, state plainly that no conflict was found. For authorized knowledge changes, keep the exact supplied target and intended relationship edges, and discover and query those targets first. Validate the payload with `kb_upsert` and `dryRun: true`, then perform the authorized `kb_upsert` with that same payload and read the result back exactly before the final checks. A passing dry run is validation, not completion. Distinct authorized payloads may need several sequential writes, each validated and read back, but never retry a mutation that already committed. If a mutation returns `committed_with_repairs`, follow its typed `nextActions` instead of repeating the original operation.
56
+ For every freshness, branch, or completion question, call `kb_status` first, then `kb_query` the entities and source files that status names, then `kb_check` as the last Kibi call before answering. Never skip the query step, even when status alone seems to answer the question. If another query or write follows a check, run `kb_check` again before answering. When asked whether requirements are consistent or proven, run `kb_query`, then `kb_check` with the rules `domain-contradictions`, `kb-consistency` and `kb-consistency-unresolved`, then `kb_coverage`, and read whether the analysis was complete. `domain-contradictions` compares facts two at a time; `kb-consistency` checks every fact of a property together, so a clean pairwise result is not proof. Report a `kb-consistency` violation as a conflict, name every requirement it lists, and give superseding or changing one of them as the next step; never edit or delete facts to make the check pass. Report a context `kb-consistency-unresolved` names as unresolved, never as consistent, with the step that would make it comparable. Report any unmodeled or unknown clause as incomplete analysis, not as consistent. Only when every clause is fully modeled and compatible, state plainly that no conflict was found. For authorized knowledge changes, keep the exact supplied target and intended relationship edges, and discover and query those targets first. Validate the payload with `kb_upsert` and `dryRun: true`, then perform the authorized `kb_upsert` with that same payload and read the result back exactly before the final checks. A passing dry run is validation, not completion. Distinct authorized payloads may need several sequential writes, each validated and read back, but never retry a mutation that already committed. If a mutation returns `committed_with_repairs`, follow its typed `nextActions` instead of repeating the original operation.
57
57
 
58
58
  ## Guidance
59
59
 
package/dist/skills/kibi-usage/SKILL.md CHANGED
@@ -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.22.0
5
+ version: 2.24.0
6
6
  kibiCompatibility: ">=1.0.0"
7
7
  tags:
8
8
  - kibi
@@ -168,7 +168,7 @@ End every task with these five independent fields:
168
168
  taskOutcome: complete | interim | blocked
169
169
  kbState: clean_fresh | stale | dirty | legacy_compat | not_evaluated
170
170
  verificationState: fresh | dirty | unavailable | not_evaluated
171
- proofState: proven | mixed | unresolved | not_evaluated
171
+ proofState: tested | mixed | unresolved | not_evaluated
172
172
  limitationDisposition: none | accepted | unaccepted | not_applicable
173
173
  ```
174
174
 
package/dist/skills/kibi-usage/resources/proof.md CHANGED
@@ -1,6 +1,6 @@
1
1
  # Proof and Verification Workflow
2
2
 
3
- Use this resource when a requirement must be proven before handoff, when
3
+ Use this resource when a requirement must be tested end to end before handoff, when
4
4
  wiring a proof-bearing test, or when `kb_ingest_proof` or `kibi prove`
5
5
  rejected evidence.
6
6
 
@@ -97,9 +97,9 @@ Cosmetic edits (descriptions, labels) never stale proof. Execution-relevant
97
97
  edits (command, artifact, targets, options, bindings, contract) change the
98
98
  effective fingerprint and do.
99
99
 
100
- ## What counts toward proofProven
100
+ ## What counts toward proofTested
101
101
 
102
- A requirement is proven only by its scenarios' tests, and a scenario test
102
+ A requirement reaches `proofStatus: tested` only through its scenarios' tests, and a scenario test
103
103
  counts only when it is an **end-to-end** test with a valid, fresh, passing
104
104
  receipt for the current snapshot.
105
105
 
@@ -109,7 +109,7 @@ receipt for the current snapshot.
109
109
  `source` path contains `e2e`) counts as end-to-end; anything else is
110
110
  `unknown` scope.
111
111
  - A `unit` or `integration` receipt is still recorded on the test entity, but
112
- it does not move `proofProven` for a behavioural requirement: the
112
+ it does not move `proofTested` for a behavioural requirement: the
113
113
  requirement keeps the `missing_passing_e2e` gap in `proofGaps`. The one
114
114
  exception is a scenario whose specifying requirements are all grounded only
115
115
  in component-scope UI predicates (`ui_pattern`, `same_pattern`,
@@ -120,6 +120,38 @@ receipt for the current snapshot.
120
120
  receipt does not change it, and a `passing` status without a fresh receipt
121
121
  proves nothing.
122
122
 
123
+ ## Evidence levels
124
+
125
+ Every requirement row also carries `evidenceLevel`, the strength of what backs
126
+ it, and `evidence`, the entries that earned it (each with `kind`, `scope` and
127
+ `level`):
128
+
129
+ - `proved`: a re-checkable certificate covers every case. No proof kind issues
130
+ certificates yet, so nothing reaches it today.
131
+ - `tested`: `proofStatus` is `tested`; fresh E2E receipts cover every linked
132
+ scenario.
133
+ - `asserted`: a person stands behind the statement (approved, or firm by
134
+ `firmness` or a non-agent origin) but nothing current checks it.
135
+ - `unverified`: an agent wrote it, no person approved it, nothing checks it.
136
+
137
+ Report the level as it is. Never call an `asserted` or `unverified`
138
+ requirement proven or tested, and never call `tested` proved. Firmness is a
139
+ separate axis: it says how sure the person is, not how strong the evidence is.
140
+
141
+ ## Knowledge-base certificates
142
+
143
+ `kb_check` (`kibi check`) proves facts about the KB itself in its
144
+ `kb-consistency` rule and re-checks each answer with an independent checker:
145
+ property facts are consistent (a model per subject, property and scope, or an
146
+ irreducible contradiction core), predicate facts and allow/deny decisions are
147
+ consistent, and stored rules are stratified. It catches facts that contradict
148
+ only together, which the pairwise `domain-contradictions` rule misses. A
149
+ `kb-consistency` violation names the core facts and the requirements behind
150
+ them: supersede or change one of those requirements; never edit the facts so
151
+ the check passes. Quote a `kb-consistency-unresolved` diagnostic as
152
+ unresolved, never as consistent. Opposing rule pairs and scenario
153
+ feasibility are not certified yet; their own rules still decide them.
154
+
123
155
  ## Attempt semantics (factual, never optimistic)
124
156
 
125
157
  - `attempts: {status: "complete", entries: [...]}` — known history; the
package/dist/skills/kibi-usage/resources/workflows.md CHANGED
@@ -9,7 +9,7 @@ success flag):
9
9
  taskOutcome: complete | interim | blocked
10
10
  kbState: clean_fresh | stale | dirty | legacy_compat | not_evaluated
11
11
  verificationState: fresh | dirty | unavailable | not_evaluated
12
- proofState: proven | mixed | unresolved | not_evaluated
12
+ proofState: tested | mixed | unresolved | not_evaluated
13
13
  limitationDisposition: none | accepted | unaccepted | not_applicable
14
14
  ```
15
15
 
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "kibi-cursor",
3
- "version": "2.9.0",
3
+ "version": "2.9.1",
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",
package/skills/.canon-hash.json CHANGED
@@ -9,7 +9,7 @@
9
9
  "kibi-decisions/SKILL.md": "384749d6a9196c978a6df5a0d89fffe1fab7bad9554bc77e6bc45282567c4184",
10
10
  "kibi-decisions/resources/decision-records.md": "1244ab963f78cfd47fc88dc9700bbfdbe2fad8a0d84da1fb7c40d718ccca710a",
11
11
  "kibi-decisions/resources/signoff-views.md": "f5de0c378de9094949b372485d6e1f06398eb1c60cd234077a89af312f3c9d07",
12
- "kibi-freshness/SKILL.md": "f1ccfa35dae113d7b3b2a61c455c1791dbc79732972d4604fbb82e002ff3c836",
12
+ "kibi-freshness/SKILL.md": "7474b7c22ca915006e930850274bc71efaf2e03dcf60d41a2936b70d64547052",
13
13
  "kibi-freshness/resources/branch-lifecycle.md": "ebc01b19fe3dca8df5fc0175978963f6f1204f71f7c805cb2a5fb1b277ac78e4",
14
14
  "kibi-freshness/resources/operation-access.md": "4e1db9294ee540cd29b8b3a2532a81e7894d5b4228b39e99ba48b37212f489f3",
15
15
  "kibi-freshness/resources/source-authoring.md": "41a0547ce4d2a112a0f3671d36720f07c447864db3b473e94eb88a8ce2d371ff",
@@ -18,15 +18,15 @@
18
18
  "kibi-traceability/resources/operation-access.md": "39f7972ab7f4ae7479e78f7072bb50e8e6c4cdf4f857425f69d2522d37db437c",
19
19
  "kibi-traceability/resources/source-authoring.md": "408c6ee2bef1b84e0194c0538ef929c26a0a617e631b2234247388140dbbdd08",
20
20
  "kibi-traceability/resources/traceability.md": "38c290a0bc71bd1692e115f22694743946e2f69630e134acfd43cee5f613fb88",
21
- "kibi-usage/SKILL.md": "c95fc81dfed557a46353df0ec3e9ab3cdf7fda8f3cf0a0062aec57d839873d4f",
21
+ "kibi-usage/SKILL.md": "e8efe1c31c601042cdcd3c96cb9cd81b009458410053a6cf5a44852dd0a1bcbf",
22
22
  "kibi-usage/resources/branch-lifecycle.md": "f1bf359e9826e83c548f3cd0287f8175a62456527b0132b06b3f9f74aa59b7d6",
23
23
  "kibi-usage/resources/fact-lanes.md": "899218f90396aa469b6e34aeb5f7ea1f38bf11bb326102319f376c213859fb33",
24
24
  "kibi-usage/resources/kb-improvement.md": "a8408fce27342bdce6415a6718599e53fe00bb33aa1fd3dc42353ec6f61adcd7",
25
25
  "kibi-usage/resources/logic-ir.md": "0e8ce8aad07433ab4803ec169149ff6c4e1cf8cf010af18fa6fd67862d9be807",
26
26
  "kibi-usage/resources/operation-access.md": "eb455796c066787ffd3fae8db0db1d3e87a84265a57f06ae61e30103cd6aed66",
27
- "kibi-usage/resources/proof.md": "2348819078034dd3df25664c4c707ff98f17520bbbd335bff4f48611cf672bb3",
27
+ "kibi-usage/resources/proof.md": "d44ced11dca304495cab186eea84bf33fbd9932653821559a7f20b4f1c8d5606",
28
28
  "kibi-usage/resources/relationship-directions.md": "0fdd67032c2d15299f772845fc4f807eb9435b09507bd87a5911ab33db2f143d",
29
29
  "kibi-usage/resources/source-authoring.md": "cad93f1e0ae08a676f2de7492f9227677880302327e74d159618fea86ca50abe",
30
30
  "kibi-usage/resources/ui-requirements.md": "f99c2a9a73bbb7bd92ce1f231db3056d544588be149a5b0d3f7cc6f28bc9eee9",
31
- "kibi-usage/resources/workflows.md": "9cfdcf8c21ad92ed5c72e0f350e9b1ab678ff263670e2c34d7d9277933ead1bf"
31
+ "kibi-usage/resources/workflows.md": "53c6889f375988a89a4cce8e68e79c7f621b15cc81cff915d61733642db87153"
32
32
  }
package/skills/kibi-freshness/SKILL.md CHANGED
@@ -2,7 +2,7 @@
2
2
  id: kibi-freshness
3
3
  name: kibi-freshness
4
4
  description: Check exact Git attachment, branch migration/quarantine, compiled-store freshness, source linkage, and repair state before decisions or writes.
5
- version: 2.0.0
5
+ version: 2.1.0
6
6
  kibiCompatibility: ">=1.0.0"
7
7
  tags:
8
8
  - kibi
@@ -53,7 +53,7 @@ echo '{}' | npx --no-install kibi status --input -
53
53
  `committed_with_repairs`, follow required typed `nextActions`; never retry the
54
54
  original operation.
55
55
 
56
- For every freshness, branch, or completion question, call `kb_status` first, then `kb_query` the entities and source files that status names, then `kb_check` as the last Kibi call before answering. Never skip the query step, even when status alone seems to answer the question. If another query or write follows a check, run `kb_check` again before answering. When asked whether requirements are consistent or proven, run `kb_query`, then `kb_check` with the domain-contradictions rule, then `kb_coverage`, and read whether the analysis was complete. Report any unmodeled or unknown clause as incomplete analysis, not as consistent. Only when every clause is fully modeled and compatible, state plainly that no conflict was found. For authorized knowledge changes, keep the exact supplied target and intended relationship edges, and discover and query those targets first. Validate the payload with `kb_upsert` and `dryRun: true`, then perform the authorized `kb_upsert` with that same payload and read the result back exactly before the final checks. A passing dry run is validation, not completion. Distinct authorized payloads may need several sequential writes, each validated and read back, but never retry a mutation that already committed. If a mutation returns `committed_with_repairs`, follow its typed `nextActions` instead of repeating the original operation.
56
+ For every freshness, branch, or completion question, call `kb_status` first, then `kb_query` the entities and source files that status names, then `kb_check` as the last Kibi call before answering. Never skip the query step, even when status alone seems to answer the question. If another query or write follows a check, run `kb_check` again before answering. When asked whether requirements are consistent or proven, run `kb_query`, then `kb_check` with the rules `domain-contradictions`, `kb-consistency` and `kb-consistency-unresolved`, then `kb_coverage`, and read whether the analysis was complete. `domain-contradictions` compares facts two at a time; `kb-consistency` checks every fact of a property together, so a clean pairwise result is not proof. Report a `kb-consistency` violation as a conflict, name every requirement it lists, and give superseding or changing one of them as the next step; never edit or delete facts to make the check pass. Report a context `kb-consistency-unresolved` names as unresolved, never as consistent, with the step that would make it comparable. Report any unmodeled or unknown clause as incomplete analysis, not as consistent. Only when every clause is fully modeled and compatible, state plainly that no conflict was found. For authorized knowledge changes, keep the exact supplied target and intended relationship edges, and discover and query those targets first. Validate the payload with `kb_upsert` and `dryRun: true`, then perform the authorized `kb_upsert` with that same payload and read the result back exactly before the final checks. A passing dry run is validation, not completion. Distinct authorized payloads may need several sequential writes, each validated and read back, but never retry a mutation that already committed. If a mutation returns `committed_with_repairs`, follow its typed `nextActions` instead of repeating the original operation.
57
57
 
58
58
  ## Guidance
59
59
 
package/skills/kibi-usage/SKILL.md CHANGED
@@ -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.22.0
5
+ version: 2.24.0
6
6
  kibiCompatibility: ">=1.0.0"
7
7
  tags:
8
8
  - kibi
@@ -168,7 +168,7 @@ End every task with these five independent fields:
168
168
  taskOutcome: complete | interim | blocked
169
169
  kbState: clean_fresh | stale | dirty | legacy_compat | not_evaluated
170
170
  verificationState: fresh | dirty | unavailable | not_evaluated
171
- proofState: proven | mixed | unresolved | not_evaluated
171
+ proofState: tested | mixed | unresolved | not_evaluated
172
172
  limitationDisposition: none | accepted | unaccepted | not_applicable
173
173
  ```
174
174
 
package/skills/kibi-usage/resources/proof.md CHANGED
@@ -1,6 +1,6 @@
1
1
  # Proof and Verification Workflow
2
2
 
3
- Use this resource when a requirement must be proven before handoff, when
3
+ Use this resource when a requirement must be tested end to end before handoff, when
4
4
  wiring a proof-bearing test, or when `kb_ingest_proof` or `kibi prove`
5
5
  rejected evidence.
6
6
 
@@ -97,9 +97,9 @@ Cosmetic edits (descriptions, labels) never stale proof. Execution-relevant
97
97
  edits (command, artifact, targets, options, bindings, contract) change the
98
98
  effective fingerprint and do.
99
99
 
100
- ## What counts toward proofProven
100
+ ## What counts toward proofTested
101
101
 
102
- A requirement is proven only by its scenarios' tests, and a scenario test
102
+ A requirement reaches `proofStatus: tested` only through its scenarios' tests, and a scenario test
103
103
  counts only when it is an **end-to-end** test with a valid, fresh, passing
104
104
  receipt for the current snapshot.
105
105
 
@@ -109,7 +109,7 @@ receipt for the current snapshot.
109
109
  `source` path contains `e2e`) counts as end-to-end; anything else is
110
110
  `unknown` scope.
111
111
  - A `unit` or `integration` receipt is still recorded on the test entity, but
112
- it does not move `proofProven` for a behavioural requirement: the
112
+ it does not move `proofTested` for a behavioural requirement: the
113
113
  requirement keeps the `missing_passing_e2e` gap in `proofGaps`. The one
114
114
  exception is a scenario whose specifying requirements are all grounded only
115
115
  in component-scope UI predicates (`ui_pattern`, `same_pattern`,
@@ -120,6 +120,38 @@ receipt for the current snapshot.
120
120
  receipt does not change it, and a `passing` status without a fresh receipt
121
121
  proves nothing.
122
122
 
123
+ ## Evidence levels
124
+
125
+ Every requirement row also carries `evidenceLevel`, the strength of what backs
126
+ it, and `evidence`, the entries that earned it (each with `kind`, `scope` and
127
+ `level`):
128
+
129
+ - `proved`: a re-checkable certificate covers every case. No proof kind issues
130
+ certificates yet, so nothing reaches it today.
131
+ - `tested`: `proofStatus` is `tested`; fresh E2E receipts cover every linked
132
+ scenario.
133
+ - `asserted`: a person stands behind the statement (approved, or firm by
134
+ `firmness` or a non-agent origin) but nothing current checks it.
135
+ - `unverified`: an agent wrote it, no person approved it, nothing checks it.
136
+
137
+ Report the level as it is. Never call an `asserted` or `unverified`
138
+ requirement proven or tested, and never call `tested` proved. Firmness is a
139
+ separate axis: it says how sure the person is, not how strong the evidence is.
140
+
141
+ ## Knowledge-base certificates
142
+
143
+ `kb_check` (`kibi check`) proves facts about the KB itself in its
144
+ `kb-consistency` rule and re-checks each answer with an independent checker:
145
+ property facts are consistent (a model per subject, property and scope, or an
146
+ irreducible contradiction core), predicate facts and allow/deny decisions are
147
+ consistent, and stored rules are stratified. It catches facts that contradict
148
+ only together, which the pairwise `domain-contradictions` rule misses. A
149
+ `kb-consistency` violation names the core facts and the requirements behind
150
+ them: supersede or change one of those requirements; never edit the facts so
151
+ the check passes. Quote a `kb-consistency-unresolved` diagnostic as
152
+ unresolved, never as consistent. Opposing rule pairs and scenario
153
+ feasibility are not certified yet; their own rules still decide them.
154
+
123
155
  ## Attempt semantics (factual, never optimistic)
124
156
 
125
157
  - `attempts: {status: "complete", entries: [...]}` — known history; the
package/skills/kibi-usage/resources/workflows.md CHANGED
@@ -9,7 +9,7 @@ success flag):
9
9
  taskOutcome: complete | interim | blocked
10
10
  kbState: clean_fresh | stale | dirty | legacy_compat | not_evaluated
11
11
  verificationState: fresh | dirty | unavailable | not_evaluated
12
- proofState: proven | mixed | unresolved | not_evaluated
12
+ proofState: tested | mixed | unresolved | not_evaluated
13
13
  limitationDisposition: none | accepted | unaccepted | not_applicable
14
14
  ```
15
15