kibi-cursor 2.9.1 → 2.9.3

package/.cursor-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "kibi-cursor",
   "displayName": "Kibi",
-  "version": "2.9.1",
+  "version": "2.9.3",
   "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,87 @@
 # kibi-cursor
 
+## 2.9.3
+
+### Patch Changes
+
+- 94dc89d: A certificate now proves the requirement claims it names, and `proved` says which claims a requirement's certificates cover.
+
+  A certificate-kind proof contract (`exhaustive`, `typecheck`, `arithmetic`, `smt`) names the claim keys it proves in the new `proves` field. For each named claim Kibi derives what the certificate has to establish from the claim's grounding fact, so the author never states it:
+  - A set fact (the new `value_type: set` with `value_set`) gives a set-equality obligation. An `exhaustive` certificate meets it when its domain, read from the code, is exactly the set and the domain symbol is covered by the test; a `typecheck` certificate meets it when Kibi's own witness, which compares the domain type with the set both ways, compiles.
+  - A numeric fact gives a constraint. An `arithmetic` or `smt` certificate meets it when its assumptions are the fact's constraints; a new `value_source` field names the code constants that bound the variable, which `constraint_source` used to require.
+  - A fact with no derivation (a behavioral claim) gives an attested binding, which counts as `tested`.
+
+  `kibi prove` records one binding per claim in the receipt's `claim_bindings` (derived, attested or rejected, with the reason) and prints it. Kibi re-judges each binding against the current KB when it reports, so a binding goes stale when its fact changes. A requirement reports `proved` only when every applicable claim has a derived, code-scope binding from a fresh certificate that re-checks.
+
+  The semantic advisor now models closed lists ("must be one of red, green or blue") as set facts. KB consistency certificates support set facts.
+
+  `kibi coverage`, `kibi proof explain` and the HTML report show claim-level evidence (`claimSummary`, `claimEvidence`, "n/m claims proved"), and the `proved` floor gap lists the unproved claims. The new blocking `proof-contract-claims` check reports a certificate contract that names no claims, names a key that is no current claim, or names a claim its kind cannot express. The kibi-usage (2.27.0) and kibi-traceability (2.2.0) skills explain claim binding to agents.
+
+  **Migration (breaking):** KB schema 12. `kibi migrate` pins `proves` on every certificate contract with exactly one claim it could prove and lists the rest for review; until a contract names its claims, `proof-contract-claims` blocks and its certificate proves nothing. A requirement that reported `proved` from a certificate before reports `tested` until its claims are bound and re-proved. The requirement proof payload is now `kibi.requirement-proof.v5`. Facts with a legacy `allowed_values` list are read as sets; nothing is rewritten.
+
+- a71798f: Proof contracts can now earn `proved` evidence with certificate proof kinds that Kibi re-checks itself.
+
+  A proof contract sets `kind` to one of the runner kinds `e2e`, `example` or `property`, which support `tested`, or to a certificate kind, which supports `proved`:
+  - `exhaustive` runs a check on every member of a finite domain the code defines. The contract names the domain with `domain_source`; the proof must import that symbol, and Kibi loads the export itself and rejects a certificate that does not cover exactly its members.
+  - `typecheck` names a `witness` file that stops compiling when a domain member goes unhandled (an exhaustive switch ending in a `never` check, or a mapped type over the domain). Kibi compiles the witness itself, strict and with the workspace's TypeScript, and checks it is the workspace file and imports the domain.
+  - `arithmetic` states a claim about one integer or real variable. Its assumptions must be exactly the constraints of the typed numeric facts the contract names in `constraint_source`, and Kibi decides the claim exactly: the facts must be satisfiable and entail it for every value.
+  - `smt` carries an SMT-LIB query that asserts the `constraint_source` facts and the claim's negation. Kibi re-runs z3 or cvc5 on it and accepts only `unsat`.
+
+  `arithmetic` and `smt` prove that the knowledge base's facts entail a claim, not that code follows those facts.
+
+  Tests build certificates with the new `kibi-cli/proof-certificates` helpers and leave them in the directory `kibi prove` names in `KIBI_PROOF_CERTIFICATES`; outside `kibi prove` writing a certificate does nothing. A requirement reports `proved` when it is `tested` and every scenario has a test whose fresh receipt carries a certificate that still re-checks. `kibi coverage`, `kibi proof explain` and the report show the new certificate evidence, the report counts requirements proved by certificate, and a stored certificate that stops re-checking is listed with its reason under `certificateRejections`.
+
+  **Receipts:** `kibi prove` now writes `kibi.proof-receipt.v2`, which adds the contract kind, the evidence level, the certificate, its digest and, when a certificate is rejected, the reason. Existing `kibi.proof-receipt.v1` receipts stay valid and support `tested`. Older Kibi versions do not read v2 receipts, so upgrade every checkout that proves requirements together. The kibi-usage skill (2.26.0) explains certificate kinds to agents.
+
+- 0d68081: Requirements now state the evidence they need, and `kibi check` fails any current requirement whose evidence is below it.
+
+  A requirement can set `required_evidence` to `proved`, `tested`, `asserted` or `unverified`. Without it, a firm requirement needs `tested` evidence and any other requirement needs none. The new canonical `evidence-floor` rule of `kibi check` and `kb_check` reports every current requirement whose evidence level is below its floor, with the level, the floor, where the floor comes from and the proof gaps to fix. Requirements whose only gaps are receipts older than the code count as pending re-proof and pass; `kibi check --fresh-evidence`, meant for CI right after `kibi prove --all`, fails them and also needs a clean proof snapshot.
+
+  The floor replaces snapshot files of every requirement's proof gaps: a pull request that adds a requirement no longer edits a shared baseline, and the floor sits in the requirement a reviewer reads. `kibi proof impact`, which compared coverage with such a baseline, is removed; use `kibi check --rules evidence-floor` and `kibi proof explain <id>`.
+
+  **Migration:** the knowledge-base schema moves to version 11. `kibi migrate` writes `required_evidence: asserted` on every current firm requirement that has no scenario verified by an end-to-end test with a proof contract and a passing receipt, so an upgraded knowledge base passes; raise a floor to `tested` once the requirement has an end-to-end proof. Requirements that keep `tested` are listed, and `kibi check --rules evidence-floor` shows any whose proof still has gaps, such as a stale receipt. For the same reason, requirements `kibi bootstrap` imports from a person's documents are recorded with `required_evidence: asserted`, so a freshly bootstrapped knowledge base passes `kibi check`. A knowledge base below schema 11 is not judged by `evidence-floor` until it is upgraded. The kibi-usage skill (2.25.0) explains floors to agents.
+
+- 1fea8f6: Fixes from running the formal-proof lane on two test projects.
+
+  **Migration note:** a type-shape symbol (interface, type alias, enum) covered by a unit test now counts as covered only while that unit test has a current passing receipt; an authored `status: passing` is no longer enough. After upgrading, give those unit tests a `proof_contract` and run `kibi prove --stale`. Until then coverage lists the symbols in `uncoveredSymbols` with `structural_unit_receipt_not_current`.
+  - `kibi migrate` pins a `tested` floor only where the proof ladder would accept it (newest receipt, every gap), so a migrated project no longer starts with dozens of `evidence-floor` violations.
+  - `kibi check` prints the evidence-floor suggestion in text output without `--fix`, and the suggestion names the failing receipts, uncovered symbols and missing coordinates.
+  - `kibi coverage --status` judges receipts with the same per-contract binding as the unfiltered report.
+  - Certificate domains: `domain_source.export` names the export when it differs from the symbol title; TypeScript domains load through bun, the workspace's tsx, or node with a resolve hook for extensionless and `.js` imports; imports of compiled output map back to sources through `tsconfig.json`; Python domains (`Enum`, `dict`, list, tuple, set) load with `python3`.
+  - An exported constant matched by name is judged as a narrow symbol by the upsert granularity check, as the staged gate and `kibi check` already did.
+  - `kibi prove` no longer prints a raw `git show` error for a newly added test document, attributes a valid all-pass test report per test, and stops the producer's whole process group on Ctrl-C.
+  - New `kibi prove --stale` reruns only tests without a current passing receipt.
+  - New `success_policy: own_results_first_attempt` judges each obligation by its own native-case result when a run failed only in execution, so one unrelated failing Playwright case no longer fails every receipt of the suite. The Playwright reporter now marks global errors (`setup`), global timeouts (`timed_out`) and interruptions as run-level failures, which still refuse every obligation.
+  - `kibi prove` prints each integration it starts and ingests on stderr, records ingested integrations in `.kb/proof/runs/prove-progress.json`, and `kibi prove --resume` skips integrations an interrupted run already ingested at the same snapshot.
+  - With `--test`, `--requirement` or `--stale`, a direct `playwright test` integration runs only the selected tests' `proof_bindings[].source_file` spec files; every producer receives them as `KIBI_PROOF_SOURCE_FILES`.
+  - New `kibi proof run-steps` runs `proof/steps.json` as a `command` integration and writes the per-test report.
+  - Receipt binding ignores a test document's `links`, so adding a link no longer stales its receipts; receipts bound the earlier way stay current.
+  - The tree-sitter analyzer keeps a file with more than 64 decorated declarations decorator-only (the last diagnostic summarizes the rest), so `kibi sync --refresh-symbol-coordinates` no longer aborts on it.
+  - `kibi sync --refresh-symbol-coordinates` counts refreshed symbols against the stored coordinate artifact.
+  - New `coarse_anchor_only_review` diagnostic for requirements implemented only by whole-file anchors.
+  - `kibi proof inspect` detects `node --test` and `bun test` in root and workspace scripts.
+  - `kibi doctor` warns instead of failing when an augment-mode plugin's secret is missing, and the merge-driver setup names the project's package manager.
+  - `kibi coverage` text output groups traceability and proof counts.
+  - Claim texts that differ only in whitespace or trailing punctuation match.
+  - `pack:all -- --dev-version` stamps local packs `<version>-dev.<sha>`.
+
+- 26bfdd6: Close the remaining proof-lane issues.
+  - `kibi upsert` keeps the properties an update leaves out in the compiled store, as the authored file already did. A relationship-only upsert no longer drops `required_evidence` (or `priority`, `owner`, `tags` and the rest) from the stored requirement, so `evidence-floor` stops judging it by firmness until a `kibi sync --rebuild`.
+  - A Python certificate domain loads with `KIBI_PYTHON`, the active virtualenv, or a `.venv`/`venv` from the domain file's directory up to the workspace root before `python3` on `PATH`, so a domain that imports project dependencies is checked. A failed load quotes the traceback's exception line (`ModuleNotFoundError: ...`) instead of its header.
+  - The `kibi coverage` summary carries `linkCoverageScope: "priority_must"`, and the table titles the link counts `Links (priority: must)`, so `evaluated: 0` on a KB without must-priority requirements no longer reads as if nothing was proved.
+  - `kibi sync` counts distinct relationships in both summary blocks: an edge stated in front matter and again in a symbol manifest or shard counts once, so the imported count no longer exceeds the KB total.
+  - After an applied migration, `remainingPlan` is a `kibi.migration-plan-digest.v2`: it lists the first 20 automatic actions as `{ id, code, state, autoApplicable, dependsOn }` and counts all of them under `automaticSummary` (`total`, `ready`, `blocked`, `omitted`), instead of embedding every automatic action with its full input.
+
+- e421be0: Skills describe evidence levels and floors. kibi-decisions and kibi-bootstrap record an untested firm rule with `required_evidence: asserted` so `kibi check` passes until an end-to-end proof covers it. kibi-traceability and kibi-freshness report `evidenceLevel` and `evidenceFloor` from coverage. The kibi-commit-review staged gate reference lists `kb-consistency` and notes that `evidence-floor` runs only in a full check. The kibi-usage receipt workflow runs `kibi prove` and appends `kibi.proof-receipt.v2` receipts instead of deriving them by hand.
+
+## 2.9.2
+
+### Patch Changes
+
+- 45036a3: Signoff guidance no longer tells agents to attach `latest.html` as a file. Chat apps (the Claude apps, Slack and most others) show an attached HTML file as raw source or a download, so agents now share the page only as a rendered page, such as a Claude Artifact, and otherwise leave the message text as the whole view. Updates the kibi-decisions and kibi-commit-review skills (1.2.1), the `kibi signoff` page note and the stop-hook reminder.
+- Updated dependencies [45036a3]
+  - kibi-agent-core@0.9.1
+
 ## 2.9.1
 
 ### 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.9.1",
+  "version": "2.9.3",
   "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.16.0
+version: 3.17.0
 kibiCompatibility: ">=1.0.0"
 tags:
   - kibi
@@ -43,7 +43,7 @@ Seed branch-local Kibi knowledge from cited product intent, without creating a p
 9. **Read back** with `kb_query` and `kb_search` to confirm writes and citations.
 10. **Close out** with `kb_check`, then `kb_status`.
 11. **Deepen.** Bootstrap is complete; the KB is now half-way, holding cited `req` entries and review facts but no scenarios, tests or predicates. Load `kibi-usage` and continue in the normal Kibi workflow, one area at a time, telling the human what you author:
-    - **Unplanned claims.** For every claim suppressed as `invalid_write` and every `sourceOnlySignals` entry ("Author requirement …"), restate the claim's statement and citation (`sourceId:reference`), model it with `kb_model` (`mode: "requirement"`, or `mode: "predicates"` for domain claims), and write the result with `kb_upsert` (`dryRun: true` first) with `origin: {kind: "import", ref: "<sourceId:reference>"}` and `firmness: "firm"`, as the plan does for the claims it writes. Without an explicit origin `kb_upsert` records the requirement as the agent's own `default` choice, which a later agent may supersede without asking.
+    - **Unplanned claims.** For every claim suppressed as `invalid_write` and every `sourceOnlySignals` entry ("Author requirement …"), restate the claim's statement and citation (`sourceId:reference`), model it with `kb_model` (`mode: "requirement"`, or `mode: "predicates"` for domain claims), and write the result with `kb_upsert` (`dryRun: true` first) with `origin: {kind: "import", ref: "<sourceId:reference>"}` and `firmness: "firm"` and `required_evidence: "asserted"`, as the plan does for the claims it writes; raise the floor (drop `required_evidence`) only once an end-to-end proof covers the requirement. Without an explicit origin `kb_upsert` records the requirement as the agent's own `default` choice, which a later agent may supersede without asking.
     - **Scenarios.** Write scenarios from the cited ticket's acceptance criteria, one scenario per criterion, not bulk drafts from the requirement title; ask the human when the source states none. Give each a plain title, the scenario prose in `document.body` (never in `properties`), and `assumes` links to the `property_value` facts whose values the scenario relies on. Set `expects` only when the scenario links `assumes` facts (or its criterion names concrete values that become them); `expects` without `assumes` only yields a feasibility-unknown warning, so a draft tagged `needs-human-review` omits `expects`. Then link the requirement with `specified_by` (upsert the `req` with its stored `title`, a `status` and that relationship only). Example: criterion "Given an annotation in draft state, when the user deletes it, the draft is cleared" becomes `{"type":"scenario","id":"SCEN-annotation-delete-clears-draft","properties":{"title":"Deleting a draft annotation clears the draft","status":"active","expects":"success"},"document":{"body":"Given an annotation in draft state, when the user deletes it, then the draft is cleared and nothing is published.\n\nThe acceptance criterion comes from the cited ticket; reviewers asked for it so a deleted draft never reappears after reload.\n"},"relationships":[{"type":"assumes","from":"SCEN-annotation-delete-clears-draft","to":"FACT-annotation-state-draft"}]}`, where the assumed fact is a `property_value` (`annotation.state` `eq` `draft`). Link existing tests that exercise it; never invent test evidence.
     - **Predicates.** Run `kb_model` with `mode: "predicates"` and `requirementId` on each persisted requirement and apply a returned plan with `requires_predicate` to its `relationshipTarget` (the planned `FACT-PRED-…` id, never a `SUGGEST-…` candidate id), or record the `review:ontology-gap` observation it returns, with its prose in `document.body`. A non-empty `existingGrounding` means the bootstrap already grounded that claim: on `replace_grounding` leave it unless the human wants the `replacementPlan` swap; on `provide_argument_bindings` retry with the listed arguments bound; on `record_ontology_gap` still write the returned gap observation, which is not a grounding link. Count what `kb_query` shows afterwards, not the calls you made.
     - **Unrecorded ambiguity.** Record any conflict or open question you found but did not declare in step 3 as a cited `fact_kind: observation` tagged `review:conflict` or `review:open-question`.

package/agent-plugin/skills/kibi-commit-review/SKILL.md

@@ -2,7 +2,7 @@
 id: kibi-commit-review
 name: kibi-commit-review
 description: "Use when kibi check --staged or the Kibi pre-commit hook blocks a commit (kibi_impact_evidence_missing, symbols_manifest_stale, symbol_granularity_violation, symbol-coverage, kibi check-generated drift, Staged impact review failed), or when preparing a commit or pull-request impact review. Covers reading the per-file Detail lines, authoring .kb/symbols.yaml symbol entries through kb_upsert, kibi sync --refresh-symbol-coordinates, staging the tracked Kibi evidence with git add, kb_prepare_impact_review for a staged or diff scope, the kibi signoff requirements summary to show before a commit, and how merge commits and migration renames are judged."
-version: 1.2.0
+version: 1.2.2
 kibiCompatibility: ">=1.0.0"
 tags:
   - kibi
@@ -85,8 +85,9 @@ requirement with its statement (before and after for a rewrite), firmness,
 origin, scenarios and proof state. Put it in your reply unchanged (in the
 messaging tool's message when replies go through one), then add one or two
 sentences on why the requirements changed. Offer the full page with
-`kibi signoff --format html --open`, or attach or publish
-`.kb/briefs/signoff/latest.html` when your host can carry a file or a page;
+`kibi signoff --format html --open`, or publish `.kb/briefs/signoff/latest.html`
+as a rendered page when your host has a page tool (the Artifact tool in Claude
+apps); never attach the `.html` as a file, which chat apps show as raw source;
 past 15 requirements the Markdown stops and only the page lists them all.
 Host details: `kibi-decisions`, `resources/signoff-views.md`. `--no-proof` skips the proof lookup, which reads coverage and is slow
 on a large knowledge base. The summary is not an approval: never set

package/agent-plugin/skills/kibi-commit-review/resources/staged-gate.md

@@ -30,11 +30,16 @@ symbols_manifest_stale: .kb/symbol-coordinates.yaml is stale or missing for stag
 | `symbol-coverage` | A changed symbol, or a symbol whose staged manifest entry changed, fails the full-check rule on the staged knowledge. | The symbol `implements` the requirement and is `covered_by` a test that verifies it: through the requirement's scenario (`verified_by` scenario -> test) when it has one, else `verified_by` requirement -> test. A direct requirement -> test link does not count while a scenario exists. The finding's suggestion names the missing link (see `kibi-traceability`). |
 | `kibi_impact_override_missing_rationale` | A `Kibi-Impact: none` declaration has no `Rationale:` line. | Add the rationale, or drop the declaration and stage real evidence. |
 | `entity-context-missing` (staged entity) | A staged requirement, scenario, test, ADR or observation fact has fewer than 12 words of context. | Upsert a sectioned `document.body` (see `kibi-usage`, Entity body contract). |
-| `domain-contradictions`, `scenario-feasibility`, `exception-claim-keys` (staged `.kb/` change) | The staged knowledge introduces a violation the last commit did not have. | Fix the knowledge; a contradiction with a recorded rule goes to the person (`kibi-decisions`). |
+| `domain-contradictions`, `kb-consistency`, `scenario-feasibility`, `exception-claim-keys` (staged `.kb/` change) | The staged knowledge introduces a violation the last commit did not have. `kb-consistency` also catches facts that contradict only together and names their requirements. | Fix the knowledge; a contradiction with a recorded rule goes to the person (`kibi-decisions`). |
 | Proposition-complete ingestion | A staged requirement's semantic inventory is missing or no longer matches its prose. | Re-derive it (`kb_model` analyze with the complete prose) or run `kibi migrate` for drift. |
 | `kibi check-generated --staged` drift | The staged `.kb/symbols.yaml` or `.kb/symbol-coordinates.yaml` differs from a refresh computed from the index. | `kibi sync --refresh-symbol-coordinates`, review the diff, stage only the intended hunks (`git add -p`). |
 | `Staged impact review failed: impact_review_invalid: ...` | The base commit has `.kibi/impact-policy.json` and the staged `.kibi/impact-review.json` is missing, stale or incomplete. The message names the cause (missing review path, stale fingerprint, ...). | Prepare a fresh record (below). Any later staged change makes the fingerprints stale again, so prepare it last. |
 
+The staged gate does not judge evidence levels: the `evidence-floor` rule
+runs only in a full `kibi check`. A firm requirement staged without an
+end-to-end proof passes the commit and fails that check later (see
+`kibi-decisions` for `required_evidence`).
+
 ## Advisory findings
 
 These warn but do not block. Read them; they are often the real review.

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

@@ -2,7 +2,7 @@
 id: kibi-decisions
 name: kibi-decisions
 description: "Use when the person states a rule or decision (must, never, always, from now on, we decided), when a Kibi hook asks to confirm or warns about an edit to code that implements a firm requirement, when the Stop hook says source files changed but nothing was recorded, when kb_check quotes requirement_statement_unverified, or when a request conflicts with a recorded requirement or ADR. Covers reading firmness and origin, recording a person's rule as firm with origin.ref, superseding with a Why this changed section, the kb_compile_intent unresolved/reviewCandidates/conflictReviews loop, asking before overriding a firm rule, and putting decisions to the person as one numbered kibi signoff --questions view."
-version: 1.2.0
+version: 1.3.0
 kibiCompatibility: ">=1.0.0"
 tags:
   - kibi
@@ -74,6 +74,13 @@ name the missing capability. Never read or edit `.kb/` files directly.
   quoting their words and where they said them, a sectioned `document.body`,
   a scenario, and an `implements` link from the code that enforces it. Use
   `kb_compile_intent` first when the rule may touch several requirements.
+  A firm rule needs `tested` evidence by default, so `kb_check`'s
+  `evidence-floor` rule fails on it until an end-to-end test proves its
+  scenario. When the change includes that test, give it a proof contract and
+  run `kibi prove`. Otherwise set `required_evidence: asserted`, say in the
+  body that no end-to-end test proves the rule yet, and report it as
+  asserted, not tested. Kibi's bootstrap and migration give an untested firm
+  rule the same floor.
 - **The person changes a rule:** supersede it (new requirement linked
   `supersedes` new -> old, `firmness: firm` when the old one was firm, a
   `## Why this changed` section of at least 12 words naming their instruction
@@ -124,7 +131,8 @@ Validation is not completion. When a request conflicts with a recorded rule and
 
 End with `kb_check` (and `kb_status` when freshness matters) and say:
 
-- which rules you followed, asked about, recorded or changed (ids, firmness);
+- which rules you followed, asked about, recorded or changed (ids, firmness,
+  evidence level);
 - under "Decisions I changed", each supersede and its evidence;
 - the open question, if a conflict is waiting on the person;
 - or, when the session made no decision, one line saying so.

package/agent-plugin/skills/kibi-decisions/resources/decision-records.md

@@ -43,7 +43,7 @@ says it, link to it instead of restating it. Otherwise write the scenario
 first, then the requirement (the requirement's write sends `specified_by`):
 
 ```json
-{"type":"req","id":"REQ-billing-refund-approval","properties":{"title":"Refunds above 500 EUR need a finance approval","status":"open","priority":"must","firmness":"firm","origin":{"kind":"agent","ref":"session request: \"from now on refunds above 500 EUR must be approved by finance\""}},"relationships":[{"type":"specified_by","from":"REQ-billing-refund-approval","to":"SCEN-billing-refund-approval"}],"document":{"body":"Refunds above 500 EUR need a finance approval.\n\n## Context\n\nThe person asked for this rule while changing the refund flow; reason not stated.\n\n## Source\n\n> from now on refunds above 500 EUR must be approved by finance\n\nSession request."}}
+{"type":"req","id":"REQ-billing-refund-approval","properties":{"title":"Refunds above 500 EUR need a finance approval","status":"open","priority":"must","firmness":"firm","required_evidence":"asserted","origin":{"kind":"agent","ref":"session request: \"from now on refunds above 500 EUR must be approved by finance\""}},"relationships":[{"type":"specified_by","from":"REQ-billing-refund-approval","to":"SCEN-billing-refund-approval"}],"document":{"body":"Refunds above 500 EUR need a finance approval.\n\n## Context\n\nThe person asked for this rule while changing the refund flow; reason not stated. No end-to-end test proves it yet.\n\n## Source\n\n> from now on refunds above 500 EUR must be approved by finance\n\nSession request."}}
 ```
 
 Then link the enforcing symbol with `implements` (and its test with
@@ -58,6 +58,11 @@ validation, not the write.
   `origin.approved_by` to the person.
 - A rule from a document, test or ticket a person wrote is `firm` too, with
   `origin.ref` to that source.
+- `required_evidence: asserted` keeps an untested firm rule from failing
+  the `evidence-floor` check while it is recorded. Drop it (the floor goes
+  back to `tested`) once an end-to-end test with a proof contract and a
+  passing `kibi prove` receipt covers the rule's scenario; never set it below
+  `asserted` on a firm rule.
 - Your own choice is `default`; a guess is `exploratory`. Write the value
   explicitly whenever you record a decision.
 - For strict modeling (claim keys, predicate facts) follow `kibi-usage`,

package/agent-plugin/skills/kibi-decisions/resources/signoff-views.md

@@ -13,7 +13,8 @@ statements and lists that render in any chat or messaging surface. Put it in
 your reply unchanged: never wrap it in a code block, summarize it or retell a
 requirement in your own words. Every run also writes
 `.kb/briefs/signoff/latest.json`, `latest.md` and `latest.html` (git-ignored);
-`latest.html` is a self-contained page with the full view.
+`latest.html` is a self-contained page with the full view, meant to be opened
+in a browser or published as a page, not attached as a file.
 
 ## Showing it on your host
 
@@ -21,7 +22,7 @@ requirement in your own words. Every run also writes
 | --- | --- |
 | Claude Code, Codex, Cursor, ZCode, VS Code chat | Paste the default output; `/kibi-signoff` (Claude Code, Cursor, ZCode) runs it. Offer `kibi signoff --format html --open` for the page |
 | OpenCode terminal | `kibi signoff --format md` and paste the fenced block unchanged: kibi-opencode draws it as a card, and `/kibi-signoff` reopens it |
-| Replies sent through a messaging tool (cloud or project threads, chat bots) | Pass the default output as the message text, and attach or publish `.kb/briefs/signoff/latest.html` next to it when the tool can carry a file or a page |
+| Replies sent through a messaging tool (cloud or project threads, chat bots) | Pass the default output as the message text. Share `latest.html` only as a rendered page: in Claude apps (claude.ai, the mobile and desktop apps, Claude Code on the web) publish it with the Artifact tool and give its link. Never attach the `.html` as a file: the Claude apps, Slack and most chat apps show it as raw source or a download. With no page tool, the message text is the whole view |
 | VS Code or Cursor with the kibi-vscode extension | The **Kibi: Show Requirements Signoff** panel follows every run |
 | Remote machine, no browser | Give the person the path of `latest.html` |
 

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

@@ -2,7 +2,7 @@
 id: kibi-freshness
 name: kibi-freshness
 description: Check exact Git attachment, branch migration/quarantine, compiled-store freshness, source linkage, and repair state before decisions or writes.
-version: 2.1.0
+version: 2.2.0
 kibiCompatibility: ">=1.0.0"
 tags:
   - kibi
@@ -66,6 +66,10 @@ For every freshness, branch, or completion question, call `kb_status` first, the
   evidence-dependent closeout. Name the exact paths/symbol IDs and whether the
   result is fixed, accepted, or deferred.
 - If entities look stale, refresh context through an approved Kibi capability and then re-query.
+- When asked whether a requirement is proven, quote its `evidenceLevel` and
+  `evidenceFloor` from `kb_coverage`. `pending_reproof` (receipts older than
+  the code) is stale evidence, not proof; `kibi prove` refreshes it, and
+  `kibi check --fresh-evidence` is the check that fails on it.
 - Preserve source-file traceability by carrying `sourceFile`, text references, and validation evidence through discovery, mutation, and completion.
 - Do not read or edit files inside `.kb` directly; use the selected Kibi interface instead.
 - Kibi authors tracked files but never Git-stages or commits them; ordinary Git workflows remain responsible for review and commit.

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

@@ -2,7 +2,7 @@
 id: kibi-traceability
 name: kibi-traceability
 description: Maintain source-first requirement, scenario, test, symbol, and proof traceability through Kibi's peer interfaces.
-version: 2.0.0
+version: 2.2.0
 kibiCompatibility: ">=1.0.0"
 tags:
   - kibi
@@ -64,3 +64,13 @@ stale snapshots, unavailable receipts, and incomplete grounding explicit.
 Fresh proof requires a current verification snapshot, the exact contracted E2E
 command, an append-only receipt, and current symbol coordinates. Structural
 coverage and a green check are not proof by themselves.
+
+Report each requirement's `evidenceLevel` from `kb_coverage` as it is:
+`proved` only when certificate proofs (exhaustive, typecheck, arithmetic,
+smt) derive every applicable claim, named in each contract's `proves`
+(`claimSummary` and `unprovedClaims` say which are missing), `tested` for fresh passing E2E receipts,
+`asserted` when only a person stands behind it, `unverified` otherwise. Its
+`evidenceFloor` says what `kb_check`'s `evidence-floor` rule requires:
+`below` is a traceability gap to close with links, tests and `kibi prove`;
+`pending_reproof` means the receipts are older than the code and need
+`kibi prove`. Never lower `required_evidence` to clear either.

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.24.0
+version: 2.27.0
 kibiCompatibility: ">=1.0.0"
 tags:
   - kibi
@@ -434,9 +434,11 @@ safe normative claims; use `observation` or `meta` for bug/workaround notes and
 tests, symbol ownership, and fresh proof-bearing receipts before claiming proof.
 For an existing product KB that needs semantic backfill, read
 `resources/kb-improvement.md`, and `resources/proof.md` for the proof workflow.
-When a proof ratchet fails, follow Debugging proof regressions in
-`resources/proof.md`: use `kibi proof explain` and compare current proof state
-to committed `proof/baseline.json` with `kibi proof impact`.
+Each current requirement has an evidence floor (`required_evidence`, else
+`tested` when firm); certificate proof kinds (exhaustive, typecheck,
+arithmetic, smt) reach `proved` for the claims their contract names in
+`proves`, and a requirement is proved only when every claim is. When the `evidence-floor` rule fails, follow Debugging
+proof regressions in `resources/proof.md` and use `kibi proof explain`.
 
 ## Predicate Ontology Decision Tree
 

package/agent-plugin/skills/kibi-usage/resources/proof.md

@@ -17,12 +17,18 @@ reports what happened as `kibi.proof-run.v1`; Kibi evaluates proof.
    ```bash
    kibi prove --test TEST-<id>
    # or: kibi prove --requirement REQ-<id> | --integration <id> | --all
+   # add --stale to rerun only tests without a current passing receipt
+   # add --resume to continue an interrupted run (same selector)
    ```
 
+   With `--test`, `--requirement` or `--stale`, a direct `playwright test`
+   integration runs only the selected tests' `proof_bindings[].source_file`
+   specs; wrappers get them as `KIBI_PROOF_SOURCE_FILES`.
+
    `kibi prove` captures the workspace snapshot, runs each integration's
    producer once (`shell: false`), revalidates the snapshot, evaluates the
    artifact against every selected contract, and appends idempotent
-   `kibi.proof-receipt.v1` receipts.
+   `kibi.proof-receipt.v2` receipts (v1 receipts stay valid).
 3. Confirm with `kb_status` (fresh, current snapshot) and `kb_coverage`.
 
 Never hand-write receipts. Kibi derives them from validated
@@ -51,6 +57,13 @@ proof_bindings:                 # optional provenance metadata
 
 Provenance lives in `proof_bindings`; the contract stays semantic.
 
+`success_policy: own_results_first_attempt` judges each obligation by its own
+`native_case` result when the run failed only in execution (other cases
+failed), so one unrelated failing case does not fail every receipt of a
+Playwright suite. Aggregate-run obligations, run-level errors, timeouts,
+interruptions and setup failures still refuse every obligation. Keep
+`all_required_first_attempt` unless the user wants per-case judgement.
+
 - Every `required_proofs[].symbol_id` must name an existing `symbol` entity,
   or `kb_check` reports `proof-contract-symbols`. Create the symbols first
   (`kb_upsert`, narrow method-level granularity, never a `type-shape`
@@ -85,7 +98,10 @@ replacing one named integration.
   `--command` the proposal is the `package.json` `test` script or the
   detected runner again), or make the run attributable per test: have the
   command write a `kibi.proof-test-report.v1` to the path in
-  `KIBI_PROOF_TEST_REPORT` so each test is judged by its own steps.
+  `KIBI_PROOF_TEST_REPORT` so each test is judged by its own steps. The
+  shipped `kibi proof run-steps` does that from `proof/steps.json`
+  (`[{test_id, steps: [[argv...]]}]`); use it as the integration command
+  instead of writing a producer script.
 - `producer: playwright` (or custom) — the child emits `kibi.proof-run.v1`
   itself (bundled reporter: `kibi-cli/playwright-reporter`).
 - `producer: junit` / `tap` — Kibi converts the native report at `artifact`
@@ -126,8 +142,11 @@ Every requirement row also carries `evidenceLevel`, the strength of what backs
 it, and `evidence`, the entries that earned it (each with `kind`, `scope` and
 `level`):
 
-- `proved`: a re-checkable certificate covers every case. No proof kind issues
-  certificates yet, so nothing reaches it today.
+- `proved`: the requirement is `tested` and every applicable claim has a
+  derived, code-scope binding from a fresh certificate that still re-checks
+  (see Certificate proof kinds). The entry has `kind: certificate` and lists
+  the tests. `claimSummary` counts claims per level and `unprovedClaims`
+  lists the claims below proved.
 - `tested`: `proofStatus` is `tested`; fresh E2E receipts cover every linked
   scenario.
 - `asserted`: a person stands behind the statement (approved, or firm by
@@ -138,6 +157,94 @@ Report the level as it is. Never call an `asserted` or `unverified`
 requirement proven or tested, and never call `tested` proved. Firmness is a
 separate axis: it says how sure the person is, not how strong the evidence is.
 
+## Certificate proof kinds
+
+A contract's `kind` says what its evidence can reach. The runner kinds `e2e`
+(the default), `example` and `property` support `tested`. The certificate
+kinds support `proved`, and only when Kibi re-checks the certificate the test
+left:
+
+- `exhaustive`: the test runs a check on every member of a finite domain.
+  Set `domain_source: { symbol_id: SYM-<domain> }` to the symbol that defines
+  the domain (add `export: <name>` when the export is not named like the
+  symbol's title), and import that symbol in the proof file. Kibi loads the
+  export itself (bun, the workspace's tsx, or node; for a `.py` domain
+  `KIBI_PYTHON`, the active or project `.venv`/`venv`, then `python3`:
+  Enum values, dict keys, list/tuple/set items) and rejects a
+  certificate that does not cover exactly its members, so a hand-listed or
+  partial domain stays `tested`. An import from build output is mapped back
+  to its source through `tsconfig.json` `outDir`/`rootDir`.
+- `typecheck`: a witness file that stops compiling when a domain member
+  goes unhandled (a switch ending in a `never` assignment, or a
+  `satisfies Record<Domain, ...>` map). Set `witness.path` and
+  `domain_source`; the witness must import the domain. Kibi compiles the
+  witness itself (strict, with the workspace's TypeScript), so `typescript`
+  must be installed in the workspace.
+- `arithmetic`: a claim on one `int` or `real` variable decided exactly from
+  typed facts. Set `constraint_source: { fact_ids: [FACT-...] }` to the
+  numeric `property_value` facts (one subject and property); the
+  certificate's variable is their `property_key` and its assumptions are
+  exactly their constraints. To read the value from the code instead, set
+  `value_source: [{ symbol_id: SYM-<constant>, export: <name> }]`; Kibi
+  evaluates the number export itself and adds `variable eq value` as an
+  assumption.
+- `smt`: an SMT-LIB query that declares the facts' property as a constant,
+  asserts each `constraint_source` fact constraint and then the claim's
+  negation. Kibi re-runs z3 or cvc5 on it and accepts only `unsat`.
+
+`arithmetic` and `smt` from `constraint_source` alone prove that the
+knowledge base's facts entail the claim, not that code follows the facts:
+their claim bindings have scope `intent` and the claim stays `tested`. Use
+`value_source` (its symbols `covered_by` the test) for scope `code`. A test
+whose numbers are not in typed facts or code constants stays `tested`.
+
+Every certificate contract names the claims it proves in `proves:
+[CLAIM-...]` (blocking `proof-contract-claims` from schema 12). Kibi derives
+each claim's obligation from its grounding fact: a set fact (`value_type:
+set`, `value_set: [...]`) needs the `exhaustive` domain or the `typecheck`
+domain type to be exactly the set; a numeric fact needs the `arithmetic`
+claim or the negated `smt` assertion to be its constraint. The receipt
+records one binding per claim: `derived` (checked, the only kind that
+proves), `attested` (the fact has no derivation; counts as tested) or
+`rejected` with the reason. Model an enumerated claim as a set fact and a
+bound as a numeric fact before writing its certificate. `kibi proof explain
+REQ-...` shows each claim with its bindings.
+
+Build the certificate with `kibi-cli/proof-certificates`
+(`exhaustiveCertificate`, `typecheckCertificate`, `arithmeticCertificate`,
+`smtCertificate`), fail the test when it records a failure
+(`failedMembers`), and call `writeCodeCertificate`; it writes to the
+directory `kibi prove` sets in `KIBI_PROOF_CERTIFICATES` and does nothing
+elsewhere. A Python test writes the same `kibi.code-certificate.v1` JSON
+to that directory itself. Wire the KB: the proof file symbol is
+`executable_for` the test and named in `required_proofs`; the domain symbol
+`implements` the requirement and is `covered_by` the test; the test
+`validates` one of the requirement's scenarios. `proved` is per claim: a
+multi-claim requirement is proved only when certificates derive every
+applicable claim, and reads `tested` with `n/m claims proved` otherwise. A
+rejected certificate leaves the receipt at `tested` with
+`certificate_rejection` naming why; fix the proof, never the receipt. If a
+stored certificate stops re-checking later, coverage and `kibi proof
+explain` list it under `certificateRejections`. Use a
+certificate kind only when the domain or claim is genuinely finite or
+decidable; an e2e test that samples cases stays `tested`.
+
+## Evidence floors
+
+Each current requirement accepts a weakest level, its floor: the
+`required_evidence` field (`proved`, `tested`, `asserted` or `unverified`),
+or, when absent, `tested` for a firm requirement and no floor otherwise.
+`kb_check`'s `evidence-floor` rule fails while the level is below the floor;
+coverage rows show it as `evidenceFloor` (`required`, `source`, `status`).
+A requirement whose receipts are only older than the code is
+`pending_reproof` and passes a plain check; `kibi check --fresh-evidence`
+fails it, and is what CI runs after `kibi prove`.
+
+Fix a finding by raising the level: add the scenario, the end-to-end
+test with a proof contract and the receipts, or have a person approve the
+requirement. Lower `required_evidence` only when a person decides the
+requirement does not need that evidence, and say why in the requirement.
+
 ## Knowledge-base certificates
 
 `kb_check` (`kibi check`) proves facts about the KB itself in its
@@ -182,19 +289,22 @@ feasibility are not certified yet; their own rules still decide them.
 
 ## After code changes
 
-Receipts bind to the snapshot, contract hash, and execution fingerprint at
-run time. Any code or source change moves the snapshot and stales receipts:
-re-run `kibi prove` for the affected selection, then confirm `kb_status` and
-`kb_coverage` before handoff.
+Receipts bind to the contract, the test document (its links excluded) and
+the code of the symbols they cover. A change to that code stales them:
+re-run `kibi prove --stale` (or the affected selection), then confirm
+`kb_status` and `kb_coverage` before handoff. Type-shape symbols covered by a
+unit test count only while that unit test has a current passing receipt, so
+prove unit tests that cover type-shape symbols too.
 
 Full reference: `docs/proving-requirements.md`.
 
 ## Debugging proof regressions
 
-When a proof ratchet fails, diagnose first. Do not treat
-`proof/baseline.json` as the thing to edit.
+When the `evidence-floor` rule fails, diagnose first. Do not lower
+`required_evidence` to make it pass.
 
-1. Do not refresh `proof/baseline.json` as the first fix.
+1. Read the finding: it names the requirement, its level, its floor and where
+   the floor comes from (`explicit` or `firmness`).
 2. Identify the exact requirement and symbol responsible for the regression.
 3. Use Kibi proof diagnostics rather than reverse-engineering
    `requirement_proof.pl`:
@@ -202,14 +312,9 @@ When a proof ratchet fails, diagnose first. Do not treat
    ```bash
    kibi proof explain REQ-<id>
    kibi proof explain SYM-<id>
-   kibi proof impact
+   kibi check --rules evidence-floor
    ```
 
-   `kibi proof impact` compares the current Proof projection to
-   `HEAD:proof/baseline.json` (the committed ratchet snapshot, not the
-   working-tree file). It is diagnostic: fingerprint differences are reported
-   and the command exits 0 on successful evaluation. The strict ratchet remains
-   `scripts/check-proof-baseline.mjs`.
 4. For `missing_production_symbol_coverage`, inspect symbol role, owning
    requirement, `covered_by`, candidate test scope, the requirement scenario
    chain, and the current proof receipt. `kibi proof explain` prints those as
@@ -231,5 +336,5 @@ When a proof ratchet fails, diagnose first. Do not treat
    `covered_by` relationship semantically correct.
 10. Prefer one meaningful E2E scenario covering multiple internal functions
     plus focused unit tests for edge cases, rather than an E2E test per helper.
-11. Refresh the baseline only after a genuine intentional proof-state
-    improvement requires the ratchet snapshot to be updated.
+11. A `pending_reproof` finding under `--fresh-evidence` needs `kibi prove`
+    for the tests behind the requirement, not a KB change.

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

@@ -116,7 +116,7 @@ The canonical workflow for any KB operation follows this pattern:
 7. **Create endpoints**: validated `kb_upsert` for new entities, sequentially
 8. **Link**: validated `kb_upsert` with `requires_rule`, `requires_predicate`, `constrains`, or `requires_property`, sequentially
 9. **Validate coverage and consistency**: targeted `rule-safety`, `rule-verifiability`, `semantic-completeness`, `logic-coverage`, `predicate-verifiability`, and `domain-contradictions`, then final full `kb_check`
-10. **Prove execution**: read `kb_status.proofSnapshot`, run `kibi prove` so each configured integration executes once and its `kibi.proof-run.v1` artifact is evaluated against every selected test's `kibi.proof-contract.v1` obligations, appending idempotent `kibi.proof-receipt.v1` receipts; then re-run `kb_coverage`. Never promote durable test status into fresh evidence.
+10. **Prove execution**: read `kb_status.proofSnapshot`, run `kibi prove` so each configured integration executes once and its `kibi.proof-run.v1` artifact is evaluated against every selected test's `kibi.proof-contract.v1` obligations, appending idempotent `kibi.proof-receipt.v2` receipts; then re-run `kb_coverage` and read each requirement's `evidenceLevel` and `evidenceFloor`. Never promote durable test status into fresh evidence.
 11. **Repair incrementally**: require `kb_coverage.repairPlan.scope.complete`, apply only one `ready` dependency batch per requirement, validate before every sequential write, and rerun coverage before selecting the next batch
 12. **Gate workflow evidence**: when `.kb/usage.log` exists, run `kibi usage-metrics --format json --require-acceptance`; repair ranked telemetry diagnostics and never treat stale or insufficient evidence as a pass
 
@@ -144,7 +144,7 @@ choose package managers, ground semantic claims, resolve contradictions, rerun
 E2E tests, rewrite receipt history, remap authored symbols, or accept
 limitations. Those actions remain explicit review/operator/execution steps.
 
-For `e2e_receipt_freshness_low`, query each listed requirement/test gap and run `kibi prove --requirement <id>` (or the covering integration); this appends proof receipts idempotently and preserves history. If `coverage_depth_review` conflicts with a coverage row whose `proofStages.passingE2e.status` is `passed`, report the diagnostic as a stale heuristic and keep any independent proof gaps unresolved.
+For `e2e_receipt_freshness_low`, query each listed requirement/test gap and run `kibi prove --requirement <id>` (or the covering integration); this appends proof receipts idempotently and preserves history. If `coverage_depth_review` conflicts with a coverage row whose `proofStages.passingE2e.status` is `passed`, report the diagnostic as a stale heuristic and keep any independent proof gaps unresolved. For `coarse_anchor_only_review`, the requirement is implemented only by whole-file anchors: link the functions, methods or types that implement it (with `covered_by` to their tests) so its `tested` evidence is tied to that code.
 
 ## Creating a New Feature
 ```
@@ -172,8 +172,8 @@ Do not create a test-fact pair. Facts describe invariants; requirements or scena
 
 1. Confirm the exact `REQ -> SCEN -> TEST` path and require typed `verification_scope: end_to_end`; direct requirement-to-test links do not satisfy the conservative scenario stage.
 2. Read `kb_status` and retain its available `proofSnapshot`. Stop if the runtime reports `unknown`; proof must fail closed when the code identity cannot be computed.
-3. Run the exact E2E command against that snapshot. Record runner, command, start/finish timestamps, outcome, an environment SHA-256, and an artifact/output SHA-256. Do not mint a passed receipt from an authored test status or from an unexecuted assertion.
-4. Preserve every existing receipt byte-for-byte and append the derived `kibi.proof-receipt.v1` object with strictly later `finished_at`. Earlier receipts may bind older contracts or fingerprints; they remain audit history but cannot prove the current contract. Mutation and incremental sync reject history removal, rewriting, and reordering.
+3. Run `kibi prove --test TEST-<id>` (or `--requirement`, `--integration`, `--all`). It runs the configured producer once against that snapshot and appends a `kibi.proof-receipt.v2` receipt per evaluated contract. Never hand-write a receipt, and never mint a passed receipt from an authored test status or from an unexecuted assertion.
+4. Receipts are append-only. Earlier receipts, including `kibi.proof-receipt.v1` ones, may bind older contracts or fingerprints; they remain audit history but cannot prove the current contract. Mutation and incremental sync reject history removal, rewriting, and reordering.
 5. Re-read `kb_status`; if the snapshot changed during the run, discard the candidate as proof and rerun against the new snapshot. Then run `kb_coverage` and inspect `proofStages.passingE2e.receiptEvidence` plus gap codes.
 
 Only the newest receipt matching the live snapshot, current contract hash, and current execution fingerprint qualifies, and it must be passed, no more than seven days old, and no more than five minutes in the future. Wrong-snapshot and older-contract history is retained but cannot prove the current test. `missing_proof_receipt`, `stale_proof_receipt`, `failed_proof_receipt`, `invalid_proof_receipt`, `proof_contract_mismatch`, and `proof_snapshot_unavailable` are repair states, not warnings to waive.

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

@@ -1,7 +1,7 @@
 {
   "name": "kibi-cursor",
   "displayName": "Kibi",
-  "version": "2.9.1",
+  "version": "2.9.3",
   "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": {