Kibi’s MCP server lets an agent read, search, validate, plan, and safely mutate a branch-local requirements knowledge base with traceability and proof evidence.
Query KB entities and typed facts by ID, type, tags, source file, predicate, subject/property, or fact kind.
Search the KB in natural language and get governing requirements, ADRs, scenarios, tests, facts, and evidence.
Inspect branch status, migration plans, bundled skills, relationship gaps, coverage/proof status, and graph links.
Model requirement prose into typed claims, logic, predicate schemas, and write plans without writing first.
Plan repository bootstrap or multi-requirement change intent as deterministic, hash-bound, read-only plans.
Create/update entities and relationships, with dry-run validation before mutation.
Delete entities or relationship triples with dependency checks, supersession handling, and hash-bound deletion plans.
Run KB validation and impact diagnostics for consistency, traceability, evidence, proof contracts, and source impact.
Prepare content-bound impact-review authoring inputs from staged changes or commit ranges.
Apply approved bootstrap, compile, migration, or deletion plans transactionally.
Ingest proof-run artifacts and derive evaluated proof receipts for contracted tests.
Optional experimental kibi-plugin-ui design guard keeps Angular components aligned with agreed design patterns, while styling details remain with the linter.
Integrates with Git through hooks and branch-local knowledge-base snapshots, keeping requirement context isolated per branch and supporting worktree, staged, and working-tree impact checks.
Optional experimental kibi-plugin-ui design guard keeps React components aligned with agreed design patterns, while styling details remain with the linter.
Prompt the intent. Kibi makes the agent remember it—and prove the implementation.
Simplified from what Kibi reports in each case.
Kibi is an agent-native requirements compiler and enforcement layer. You describe product intent in natural language; the agent creates and maintains the structured requirements, scenarios, tests, semantic facts, and code links. Kibi then checks that the implementation remains coherent with that intent.
Unlike passive memory or retrieval systems, Kibi is designed to place itself in the agent's workflow. The agent does not have to remember to consult a ticket, board, or requirements folder: Kibi's hooks, tools, and validation gates continuously bring the relevant product context back into the work.
Documentation · Quick start · Kibi's own health report
Most project knowledge is scattered across prompts, tickets, code, and conversations—and most AI agents eventually forget part of it. Kibi turns that knowledge into an enforceable, branch-local model:
Humans maintain intent, not artifacts — The prompt is the primary authoring interface. Agents own the routine work of creating and evolving requirements, scenarios, tests, facts, and symbol links; humans resolve genuine ambiguity and product decisions.
Memory is enforceable — Symbols need requirement ownership, requirements need complete semantics and scenarios, scenarios need tests, and proof-bearing tests need fresh execution evidence.
Prolog guards against drift — Typed properties, predicates, and safe rules let deterministic checks expose contradictions, unsupported invention, and incomplete semantics before they become accepted project knowledge.
E2E behavior is traceable — Kibi records what an end-to-end test proves, not merely which lines it happened to execute. You can navigate from a symbol to its requirement or from a test to the scenario and intent it verifies.
Intent survives branch changes — Each Git branch has its own KB snapshot, so feature context stays isolated and is there when you return.
Works across languages — TypeScript and JavaScript symbols are built in. The optional kibi-plugin-treesitter adds offline symbol extraction for Python, Go, Rust, Java, C#, PHP, C, C++, Bash, Ruby, SWI-Prolog, and Terraform/HCL using pinned WASM grammars. Each language installs as a small kibi-lang-* grammar pack (kibi-lang-python, kibi-lang-go, kibi-lang-prolog, ...), and kibi doctor names the ones a repository needs: generated files count only when the KB uses them, and any pack can be declined in kibi.declinedLanguagePacks. Generated code (linguist-generated, a generator header, or kibi.generatedPaths globs) also needs no requirement links in the commit gate unless the KB tracks it. Code and source proofs read TypeScript, JavaScript, Python and SWI-Prolog, so a Prolog project can prove its claims against its own predicates, imports, calls and pack.pl. With the plugin active for proofs, source proofs also read what Go, Java, C#, Rust, PHP, C and Bash files import, call and read from the environment, and the property values of PHP, C and Terraform/HCL files, without compiling or running them.
Optional UI design guard (experimental) — kibi-plugin-ui keeps React and Angular components on their agreed design patterns. Pixels, colours and spacing stay with your linter.
Questions in your own words (optional) — kibi-plugin-search-hints suggests which requirements a weakly answered kb_search question probably means, by meaning rather than shared words, with a small offline model.
Keep knowledge local — KB state lives in your repository's .kb/ directory and is never sent anywhere. The Kibi packages send anonymous usage statistics, which you can turn off (see Usage telemetry); the documentation website counts visits with cookieless Umami analytics.
Related MCP server: althea-mcp
Kibi is meant to be set up and driven by your coding agent, so the recommended install is a prompt rather than a list of commands. Kibi requires Node.js 22+. SWI-Prolog is bundled: on Linux (x64 or arm64, glibc 2.28+) and macOS (Apple silicon or Intel) there is nothing else to install. On other platforms, such as Alpine/musl or native Windows (use WSL), install SWI-Prolog 9.0+ and put swipl on your PATH (details).
Recommended: let your agent set it up. Paste this into Claude Code, Cursor, Codex, OpenCode, or any coding agent that can run commands in your repository:
Set up Kibi (https://github.com/Looted/kibi) in this repository, then bootstrap its knowledge base.
1. Install: confirm Node.js 22+ is available. With the package manager this repository already uses, add kibi-core, kibi-cli and kibi-mcp as dev dependencies. Do not skip optional dependencies; the bundled SWI-Prolog runtime is one.
2. Initialize: run every `kibi` command through the package manager's local runner (npm: `npm exec -- kibi <command>`). Run `kibi init`; if it reports a problem, run `kibi doctor` and fix what it names. If this platform has no bundled SWI-Prolog, tell me what to install and stop.
3. Connect: register the project-local `kibi-mcp` server for the agent host you are running in, following https://looted.github.io/kibi/guide/connect-an-agent.html. Prefer project-scoped configuration, and ask me before installing a plugin or changing global settings. Until the kb_* tools are visible to you, use Kibi's CLI JSON routes instead.
4. Bootstrap: run `kibi skills load kibi-bootstrap --format markdown` and follow that skill exactly. It starts by asking me where product intent lives outside the code (issue trackers, wikis, specs) and which sources to trust; read them through the connectors you have and cite them. Show me the complete plan and its hash, and write nothing until I approve it.
5. Verify: run `kibi check` and `kibi status`, fix anything they report, and summarize what was added. Do not commit; I will review the changes.What happens next:
Setup. The agent installs the packages, runs kibi init, and connects itself to Kibi.
Interview. It asks where your product intent already lives (issue trackers such as Jira or YouTrack, wikis, specs) and which of those sources to trust.
Plan. It reads those sources through the connectors it has and drafts a bootstrap plan. Every requirement in the plan cites the ticket or page it came from. Open questions and conflicts it finds between sources are flagged for you rather than turned into requirements.
Your approval. It shows you the plan and its hash. Nothing is written until you approve.
Apply and check. It applies the plan, validates the result, then fills in what the plan could not write, such as scenarios from acceptance criteria and machine-checkable facts for the new requirements. It tells you what it added.
After that, work normally: prompt for features, fixes, and refactors, and the agent keeps requirements, scenarios, tests, and code links in step with the code.
In your repository:
npm install --save-dev kibi-core kibi-cli kibi-mcp
npm exec -- kibi initkibi init creates the .kb/ layout and installs the Git hooks that keep it in sync. It never overwrites a hook it did not write; with lefthook, husky or the pre-commit framework it installs none and prints the configuration to add instead. It does not infer product knowledge. So that a fresh clone (a teammate's, a cloud agent's) uses Kibi too, it also writes a Kibi section into AGENTS.md (imported from CLAUDE.md) that tells any agent the knowledge base exists, and adds a prepare step that installs the hooks when dependencies are installed; the first Kibi query in a clone compiles the branch's store from the committed knowledge. Each of these can be turned off (setup choices). Connect your coding agent, then ask it:
Bootstrap Kibi for this repository.
pnpm, Yarn, and Bun work the same way through their local runners. The installation guide has their equivalents, how Kibi finds SWI-Prolog, and package-manager caveats. npm exec -- kibi doctor tells you whether everything is in place.
Upgrading. After updating the Kibi packages, run kibi migrate (or ask your agent to). It shows what would change and applies nothing until you approve; the CLI reference covers each schema version.
Versions. Each release has one Kibi release version, such as 2026.11.0, that names its exact package set and declares the KB schema it uses. kibi --version and kibi doctor show it, and doctor warns when installed packages come from different releases. When a newer kibi-cli is out, the CLI says so in one stderr line at a terminal (checked at most daily in the background, silent in CI, JSON output and agent runs, off with KIBI_UPDATE_CHECK=0), and kibi doctor reports it for every host. See Kibi release versions.
The setup prompt above does this step for you. To do it by hand: every client starts the same project-local kibi-mcp server (npx --no-install kibi-mcp, stdio, working directory = your repository). Optional plugins add bundled skills and hooks on top.
Install the optional kibi-claude plugin from this repository's marketplace. It brings the MCP server, the bundled skills, and hooks that show the agent the linked requirements, what they must keep true, and the decision behind them before it reads or edits code, including through shell commands. The agent connection guide has the details:
claude plugin marketplace add Looted/kibiclaude plugin install kibi-claude@kibiWithout the plugin, register the server for the project:
claude mcp add --scope project kibi -- npx --no-install kibi-mcpAdd Kibi to .cursor/mcp.json:
{
"mcpServers": {
"kibi": {
"command": "npx",
"args": ["--no-install", "kibi-mcp"]
}
}
}The optional kibi-cursor plugin adds rules, bundled skills, commands, and advisory hooks that show the same requirement context as the Claude Code plugin before reads and edits of linked code. See the Cursor plugin guide.
codex mcp add kibi -- npx --no-install kibi-mcpThe optional kibi-codex plugin bundles Kibi skills, MCP configuration, and warning-only hooks that bring the linked requirement into the agent's context before it changes code. Add the Kibi repository marketplace, open Codex, then run /plugins, choose Kibi Plugins, and install kibi-codex:
codex plugin marketplace add Looted/kibiThe repository marketplace is not the official OpenAI Plugin Directory; self-serve plugin publishing is not available there yet. Manual MCP configuration remains fully supported.
Add Kibi to opencode.json. The optional kibi-opencode plugin adds prompt guidance (including what a requirement linked to the file being edited must keep true) and background maintenance:
{
"mcp": {
"kibi": {
"type": "local",
"enabled": true,
"command": ["npx", "--no-install", "kibi-mcp"]
}
},
"plugin": ["kibi-opencode"]
}Add Kibi to .vscode/mcp.json:
{
"servers": {
"kibi": {
"type": "stdio",
"command": "npx",
"args": ["--no-install", "kibi-mcp"]
}
}
}Any stdio MCP client works with command: npx, args: --no-install kibi-mcp. ZCode also has an optional plugin, installed from a local checkout, whose edit hook shows the same requirement context as the Claude Code plugin; see the ZCode plugin guide. Agents without MCP can use the same operations through the CLI's JSON routes.
Kibi's skill subsystem gives the agent seven bundled skills that teach it how to work with Kibi (including kibi-provable-code, on writing code whose rules Kibi can prove), so you do not paste a long system prompt, and a small set of MCP tools does the rest:
Plain-language answers. Ask "what governs checkout rounding?" and kb_search returns the current requirements, the tests and decisions behind them, and what Kibi's checks say about each.
A review of every change. kb_check on the files the agent touched quotes the requirements that code implements and flags new code no requirement covers.
Safe writes. Every write can be previewed first, and a plan you approve lands in full or not at all.
The MCP reference lists every tool. Generic agents can start from agent onboarding.
npm exec -- kibi report --openkibi report writes a self-contained kibi-report/index.html and kibi-report/badge.svg from one coverage snapshot. % tested is the share of current requirements with fresh end-to-end evidence on the current code; the report lists what is tested, what is missing evidence, what contradicts, and what has gone stale.
Every requirement also carries an evidence level, so no guarantee reads stronger than what backs it: proved (every claim of the requirement holds for every case, backed by fresh certificates from an exhaustive, typecheck, arithmetic, smt, rule, state_machine, regex or source proof contract that names the claim, which a separate checker re-checks; claims need not be numbers: permission rules, every-member properties, state transitions, states that can never be reached, required fields and string formats are decided exactly against the code, and a source proof checks routes, database schemas, configuration, validators and code references that Kibi reads from the project itself), tested (fresh end-to-end receipts cover every linked scenario), asserted (a person stands behind it, but nothing current checks it) and unverified (an agent wrote it and no person approved it). kibi coverage returns evidenceLevel per requirement and summary.evidenceLevels counts; the report and kibi signoff show it next to firmness. See the proof ladder, proving requirements for the certificate proof kinds, and reading the report.
The knowledge base itself is checked the same way. kibi check (and kb_check for agents) proves that the facts your requirements state are consistent (one value satisfies every fact on a property, every decision has one outcome) and that stored rules are stratified, and leaves a certificate for each answer that a small separate checker re-checks. It also catches facts that contradict only together, which pairwise checks miss. A contradiction comes back as the smallest set of facts that cannot hold at once; anything it cannot compare is reported as unresolved, never as consistent.
Before you sign off on a change, kibi signoff shows the requirements it adds, rewrites or affects, each quoted with its firmness, proof state and evidence level, and kibi signoff --questions numbers the decisions waiting for you next to the rule each one would change. Agents put the view in their reply as plain Markdown, so it renders wherever the agent writes, including chat apps and cloud sessions where replies go through a messaging tool; the same view is a self-contained page in .kb/briefs/signoff/latest.html. Claude Code, Cursor, ZCode and OpenCode add a /kibi-signoff command, OpenCode draws the view as a card, VS Code opens it in a panel, and the agent hooks ask for it once a session has written requirements.
To publish the report and a clickable badge on GitHub Pages, run npm exec -- kibi init --github, then enable Settings → Pages → Source → GitHub Actions. The GitHub integration guide covers the report workflow, badge-only publishing, and a CI step that keeps pull requests mergeable when only Kibi's own files conflict. Symbol line positions are never committed: every kibi sync derives them into a gitignored cache, so two branches that edit the same source file do not conflict over them.
For day-to-day inspection, kibi status, kibi search, kibi gaps, kibi coverage, and kibi check are in the CLI reference.
Kibi combines probabilistic interpretation with deterministic verification:
Human prompt
|
v
Agent updates code and product knowledge
|
v
Requirements + semantic facts/rules + scenarios + tests + symbol links
|
v
Prolog coherence checks + traceability gates + fresh E2E evidence
|
v
Tested result or explicit, repairable gapsThe agent never writes arbitrary Prolog as trusted truth. It works through typed facts, predicate schemas, and safe logic representations; Kibi validates those encodings before the Prolog layer uses them for inference.
Kibi maintains a canonical traceability and proof chain:
Requirement -> Scenario -> Test
^ ^
| |
Production symbol Executable test symbolFor a requirement to be tested end to end rather than merely documented:
Every production symbol must trace to the requirement it implements.
Every normative requirement clause must be modeled as typed facts or stay explicitly unresolved.
Requirements must be specified by scenarios, and tests must verify those scenarios. A success scenario that assumes something a current requirement forbids blocks proof.
Executable test symbols must identify the code that actually performs the verification.
Proof-bearing production symbols must be covered by qualifying tests, and the pre-commit hook applies the same rule as the full check.
End-to-end evidence must be fresh and bound to the current code snapshot, so CI and a local checkout of the same commit agree.
That makes questions answerable in both directions: which requirement owns this symbol, what this E2E test actually verifies, which requirements lack a scenario or current evidence, and whether two current requirements contradict each other. Code coverage alone cannot answer them: it shows that a test touched a line, not which product behavior was exercised.
Suppose the product defines exactly three user roles. Once that constraint is encoded as a strict property or predicate, an agent cannot quietly invent a fourth role and treat it as established intent: Kibi can surface the contradiction or missing authorization deterministically.
Kibi does not report "no conflict" when it could not tell. Numeric constraints are compared exactly ("greater than 0" conflicts with "equals 0"), an allow and a deny for the same action contradict, and anything Kibi cannot model is reported as unresolved for the agent to review, never as a clean pass.
Prolog does not decide whether the original human intent was correct. It verifies the knowledge that was encoded, while Kibi keeps ambiguity, missing ontology, incomplete grounding, and stale evidence explicit instead of calling them proof.
Traditional knowledge bases required specialists to design ontologies, write formal logic, and maintain every mapping by hand. LLMs change the economics of that authoring step, and Kibi and Prolog supply the discipline:
Participant | Strength and responsibility |
Human | States product intent and resolves real ambiguity or policy choices |
AI agent | Maps intent to the codebase and maintains requirements, scenarios, tests, facts, and symbol links |
Kibi + Prolog | Validates schemas, checks coherence and contradictions, enforces traceability, and evaluates proof evidence |
The result uses LLM strengths to address LLM weaknesses: limited memory, hallucination, context drift, and the loss of the product-to-code mapping traditionally spread across product owners, ticket systems, and planning boards.
Eight entity types: req, scenario, test, fact, adr, flag, event, and symbol. The entity schema has the complete model.
Every entity records who authored it, a person or an agent, and advisory checks list agent-written requirements no person has approved.
Requirements and ADRs also say how firmly they were decided. A firm rule is one a person stated: it points at their words, the agent asks before changing it, and Kibi refuses to rewrite it quietly. A default choice can be revisited on evidence, and exploratory marks a guess. Every supersede has to say why it changed. How Kibi works has the details.
Install kibi-core, kibi-cli, and kibi-mcp in the project. Everything else is optional.
Package | Role |
| Prolog-backed knowledge graph, inference, and validation |
| Human, agent, automation, and Git-hook interface |
| MCP surface exposing the public Kibi operation contracts |
| Claude Code skills, MCP, requirement context before reads/edits, and advisory hooks (plugin marketplace) |
| Cursor rules, skills, MCP, requirement context before reads/edits, and advisory hooks |
| Codex skills, MCP, requirement context before edits, and lifecycle hooks |
| OpenCode guidance (including requirement context for edits) and background maintenance |
| ZCode skills, command, MCP, requirement context before edits, and advisory hooks (local checkout) |
| VS Code knowledge explorer and traceability view |
| Protocol types and validators for capability plugins |
| Default semantic, ontology, and TypeScript symbol capabilities |
| Optional TypeSafe Jev semantic classifier |
| Optional offline multi-language symbol extraction (tree-sitter queries; each grammar is a |
| Data-only grammar packs for |
| Experimental check policy keeping UI components on their agreed design patterns |
| Optional offline meaning-based hints for weak |
| Bundled SWI-Prolog runtime; the matching platform build installs automatically |
The guide and reference are published at https://looted.github.io/kibi/. Language models can start from the documentation index.
Installation — the bundled SWI-Prolog runtime, package managers, plugins, and verification
Proving requirements — proof contracts, kibi prove, and receipts
Architecture — storage, branch isolation, and data flow
Usage telemetry — what anonymous statistics Kibi sends and how to turn them off
Kibi is in beta and ready for use in real projects. Public interfaces may still evolve before 1.0, so pin exact package versions when reproducibility matters.
Kibi sends anonymous usage statistics (operation names, durations, error categories and versions, never code, paths, queries or KB content) to help prioritize fixes. Turn them off with kibi telemetry disable, KIBI_TELEMETRY=0 or DO_NOT_TRACK=1; see Usage telemetry.
Kibi is licensed under AGPL-3.0-or-later.
Apply an explicitly approved kibi.bootstrap-plan.v1, kibi.compile-plan.v1, kibi.migration-plan.v2, or entity-deletion plan after revalidating its canonical hash and live snapshots. Compile plans apply all-or-nothing: a durable journal records every source write and store mutation before the first write, all steps commit in one store transaction, and an interrupted application is completed or rolled back by the next mutating call. Bootstrap actions are dependency-ordered, sequential, source-first, and recoverable from a typed journal.
| Name | Required | Description | Default |
|---|---|---|---|
| plan | No | The complete kibi.bootstrap-plan.v1, kibi.compile-plan.v1, kibi.migration-plan.v2, or hash-bound kibi.entity-deletion-plan.v1 object. Migration plans require approvedActionIds and reject blocked actions and review actions Kibi cannot execute. | |
| async | No | MCP only. When true, start the apply as a background job and return a kibi.job.v1 receipt immediately instead of holding the request open; poll kb_job_status with the returned jobId for the final result. Use for large bootstrap plans (hundreds of actions) that can outlast a client's request timeout. The MCP server registers kb_job_status only when KIBI_MCP_OPTIONAL_TOOLS includes it; otherwise async applies synchronously. A synchronous apply sends notifications/progress after each bootstrap action when the request carries a progressToken. The CLI ignores this field. | |
| workspaceRoot | No | Optional absolute path of the workspace this call is about when it differs from the one the server started in, for example the git worktree you are working in. The server answers from that workspace's knowledge base when it is a worktree of the same repository or lies under the client's MCP roots; otherwise it answers from its own workspace and adds a workspace_mismatch diagnostic. Host hooks fill this in automatically where available. | |
| approvedPlanHash | No | Exact SHA-256 planHash returned by kb_plan_bootstrap, kb_compile_intent, or another approved plan after human review. | |
| approvedActionIds | No | Required for migration-plan.v2. Exact action IDs explicitly approved for this application: automatic actions, or review actions with a cli invocation that Kibi executes only when approved by id (for example semantic_inventory_rederive_drop_grounding). | |
| recoveryJournalId | No | Typed recovery journal identifier returned by a committed_with_repairs result or a PLAN_APPLY_RECOVERY_REQUIRED error. Recovery replays only the immutable journal and never the original plan request; a compile-plan journal (plan-apply-*) is completed or rolled back deterministically and reports which. A bootstrap journal left `applying` by a process that died mid-action is resumed without edits: the interrupted action is re-applied and a source lock held by the dead process is reclaimed and recorded in the journal. |
| Name | Required | Description |
|---|---|---|
| data | Yes | Synchronous apply result, or a kibi.job.v1 receipt when async:true detached the apply into a background job (poll kb_job_status with the jobId). |
| error | No | |
| status | Yes | |
| effects | Yes | |
| operation | Yes | |
| diagnostics | Yes | |
| nextActions | Yes | |
| kibiProtocol | Yes | |
| resultVersion | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructive/non-idempotent/non-read-only, and the description goes well beyond them: compile plans are all-or-nothing, a durable journal records every source write and store mutation before the first write, all steps commit in one transaction, and an interrupted apply is completed or rolled back by the next mutating call. Bootstrap ordering (dependency-ordered, sequential, source-first) and typed-journal recoverability are disclosed too.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the action and the approval precondition, then the transactional guarantees. Dense and information-bearing throughout, though the stacked plan-type enumeration and journal terminology make it slightly heavy for a reader orienting quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values need not be explained, and the description supplies the missing high-stakes context for a destructive, non-idempotent tool: atomicity, journal-before-write ordering, and crash/rollback behavior. Nothing an agent needs to decide to call this is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all six parameters are already documented, including async, workspaceRoot, approvedActionIds, and recoveryJournalId. The description adds only framing (plan must be approved, deduped plan types) and no syntax, format, or default detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb (apply) and resource (an approved kibi plan) and enumerates the exact plan types accepted (bootstrap-plan.v1, compile-plan.v1, migration-plan.v2, entity-deletion). An agent can distinguish it from the plan-producing siblings (kb_plan_bootstrap, kb_compile_intent) without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly conditions use on the plan being 'explicitly approved' and on hash/live-snapshot revalidation, and the schema ties approvedPlanHash back to kb_plan_bootstrap/kb_compile_intent. However, no explicit when-not guidance or named alternative (e.g., 'use kb_plan_bootstrap first') is given for an agent that arrives without an approved plan.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run KB validation rules and return violations, quality diagnostics, and typed kibi.migration-plan.v2 actions. Use before or after mutations and after source edits; checks remain read-only and never infer or apply actions from prose suggestions.
| Name | Required | Description | Default |
|---|---|---|---|
| async | No | When true, start the check as a background job and return a kibi.job.v1 receipt immediately instead of holding the request until the tool timeout. Poll kb_job_status with the returned jobId. Use for full checks on large KBs that exceed the configured tool timeout. The MCP server registers kb_job_status only when KIBI_MCP_OPTIONAL_TOOLS includes it; otherwise async runs the check synchronously. | |
| rules | No | Optional rule subset. Allowed: must-priority-coverage, symbol-coverage, symbol-traceability, symbol-granularity, symbol-coordinates-missing, no-dangling-refs, source-relationship-parity, branch-store-not-compiled, source-path-dangling, no-cycles, required-fields, deprecated-adr-no-successor, superseded-requirement-open, scenario-feasibility, scenario-feasibility-unknown, scenario-outcome-mismatch, exception-claim-keys, numeric-string-value, rule-key-arguments-missing, domain-contradictions, logic-coverage, rule-safety, rule-verifiability, query-plan-safety, req-status-vocabulary, strict-fact-shape, strict-req-fact-pairing, predicate-verifiability, strict-readiness, semantic-completeness, related-requirement-unmodeled, proof-contract-symbols, entity-id-style, domain-redundancy, domain-implication, subject-key-identity, subject-key-shape, ontology-quality, exception-unapproved, exception-approval-self-attested, agent-requirement-unapproved, requirement-rationale-missing, symbol-owner-superseded, adr-unlinked, adr-proposed, predicate-schema-conformance, entity-context-missing, entity-context-acknowledged, decision-firm-unreferenced, decision-firm-superseded, decision-firm-edited, supersedes-reason-missing, supersedes-reason-acknowledged, policy-ownership, policy-markers, kb-consistency, kb-consistency-unresolved, evidence-floor, proof-contract-claims. If omitted, server runs canonical and advisory rules plus the full-KB qualityDiagnostics audit scan, including usage telemetry acceptance when evidence exists; migration rules run only when explicitly selected. Advisory and migration findings are non-blocking qualityDiagnostics. If supplied, server preserves scoped validation and skips the full-KB advisory scan. | |
| staged | No | When true, inspect staged source changes for impact diagnostics using the shared CLI impact analyzer without shelling out to kibi check. | |
| sourceFiles | No | Optional repo-relative source files to inspect for early impact diagnostics. Use with includeImpactDiagnostics after meaningful source edits. | |
| workspaceRoot | No | Optional absolute path of the workspace this call is about when it differs from the one the server started in, for example the git worktree you are working in. The server answers from that workspace's knowledge base when it is a worktree of the same repository or lies under the client's MCP roots; otherwise it answers from its own workspace and adds a workspace_mismatch diagnostic. Host hooks fill this in automatically where available. | |
| maxDiagnostics | No | Optional maximum number of impact diagnostics to return. Graph validation violations are not capped by this value. | |
| includeWorkingTreeDiff | No | When true, inspect current unstaged working-tree diffs for impact diagnostics. Pair with sourceFiles to scope the analysis. | |
| includeImpactDiagnostics | No | When true, include changed-file impact diagnostics such as symbol_granularity_violation, symbol_semantic_review_needed, source_file_unowned and requirement_statement_unverified (each current requirement the changed code implements, with its statement and firmness, since the check never compares code with a statement) in structured output. |
| Name | Required | Description |
|---|---|---|
| data | Yes | Synchronous check payload, or a kibi.job.v1 receipt when async:true detached the check into a background job (poll kb_job_status with the jobId). |
| error | No | |
| status | Yes | |
| effects | Yes | |
| operation | Yes | |
| diagnostics | Yes | |
| nextActions | Yes | |
| kibiProtocol | Yes | |
| resultVersion | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds real value beyond that by disclosing that checks never infer or apply actions from prose suggestions — a meaningful constraint given the tool emits migration-plan actions. It does not mention async execution or the non-blocking nature of advisory findings, which live only in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with the action and outputs front-loaded; no filler. The second sentence is dense but each clause (read-only, no inference, no auto-apply) earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter tool with a 60-value rule enum, an output schema, and rich annotations, the description covers purpose, timing, and the key non-inference guarantee. Details like async job behavior, rule subsetting semantics, and impact diagnostics are fully specified in the schema, so their absence from the description is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter (async, rules, staged, sourceFiles, workspaceRoot, maxDiagnostics, includeWorkingTreeDiff, includeImpactDiagnostics) is already documented in detail. The description adds no parameter-level meaning, which is the correct baseline when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Run KB validation rules') plus the concrete return payload (violations, quality diagnostics, typed kibi.migration-plan.v2 actions). It does not name any sibling (kb_find_gaps, kb_coverage, kb_prepare_impact_review) as a contrast, so differentiation still requires inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear timing guidance: 'Use before or after mutations and after source edits.' It does not name alternatives or exclusions, though the clause about never applying actions implicitly routes application to kb_apply_plan without saying so explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compile complete change intent into a deterministic, snapshot-bound read-only plan. Use it before editing code for a change request that may touch several requirements; use kb_model for one requirement's prose and kb_plan_bootstrap for first-time onboarding. Reuses intent-aware discovery and semantic modeling, accounts for every proposition, reports contradiction witnesses, proposes traceability links, and emits dependency-ordered kb_upsert-style steps only for resolved typed claims. contradictionAnalysis.outcome is no_conflict only when the check could decide: an unmodeled proposition or a related current requirement without logic leaves it unresolved with reasons and reviewCandidates to compare and judge through conflictReviews. No mutation side effects.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes | Create a new requirement or update an existing one. Update auto-selection is allowed only with a high-confidence, well-separated candidate. | |
| title | No | Optional requirement title; existing title is preserved for updates when omitted. | |
| intent | Yes | Complete post-change normative intent. Send the desired behavior, not a patch fragment. | |
| clauses | No | Optional complete atomic clause decomposition. Each clause must be a verbatim fragment of intent (whitespace may differ); a clause that does not occur in intent fails the call with VALIDATION_FAILED naming it. Each assertive clause receives independent proposition accounting. | |
| context | No | Why the requirement exists, who asked and anything that does not fit its checked meaning. Required when mode is create (validation error naming this field otherwise); rendered as a '## Context' section of the requirement document, never as part of the checked meaning. Never invent a reason: write 'Reason not stated' when the requester gave none. An update keeps the existing document body unless context is supplied. | |
| testDrafts | No | Optional test drafts. Tests are attached to scenarios with verified_by; direct req -> test proof links are not emitted. | |
| requirementId | No | Optional exact requirement ID. Required for an update when automatic selection is below the confidence and margin gates. | |
| sourceExcerpt | No | Optional verbatim text the intent came from (a ticket, a message, a document passage). Rendered as a blockquote in the requirement's '## Source' section; requires context. | |
| workspaceRoot | No | Optional absolute path of the workspace this call is about when it differs from the one the server started in, for example the git worktree you are working in. The server answers from that workspace's knowledge base when it is a worktree of the same repository or lies under the client's MCP roots; otherwise it answers from its own workspace and adds a workspace_mismatch diagnostic. Host hooks fill this in automatically where available. | |
| scenarioDrafts | No | Optional scenario drafts. Each is linked requirement -> scenario with specified_by. | |
| semanticFacets | No | Host-agent facets forwarded to deterministic intent-v1 discovery. | |
| conflictReviews | No | Your verdict on each contradictionAnalysis.reviewCandidates entry of a previous compile: whether the intent contradicts that current requirement, which Kibi could not compare logically. A conflict verdict blocks the plan; a no_conflict verdict clears that candidate. A verdict may also name a current requirement discovery did not rank. | |
| interpretations | No | Optional host-supplied typed kibi.logic.v1 interpretations; Kibi validates them before including rule steps. | |
| sourceLocations | No | Workspace-relative source coordinates used for discovery and before-hash binding. | |
| sourceReference | No | Optional locator of the source text (ticket id, URL, path). Rendered in the requirement's '## Source' section; requires context. | |
| proposalDecisions | No | Explicit decisions for deterministic traceability proposals. Pending proposals never enter steps. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| error | No | |
| status | Yes | |
| effects | Yes | |
| operation | Yes | |
| diagnostics | Yes | |
| nextActions | Yes | |
| kibiProtocol | Yes | |
| resultVersion | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior, but the description goes further: it discloses that steps are emitted only for resolved typed claims, that proposition accounting and traceability proposals occur, and precisely when contradictionAnalysis.outcome stays unresolved (unmodeled propositions or related requirements lacking logic), naming reviewCandidates and conflictReviews as the resolution path. That is behavioral context an agent could not infer from the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and routing are front-loaded in the first sentence. The subsequent sentences are dense, comma-chained clauses about contradiction resolution that repay the space but would read better as shorter, separated statements; nothing is outright wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 16-parameter, nested-schema, annotation-rich tool with an output schema, the description covers the decision-relevant gaps: when to use it, what it emits, and the unresolved-contradiction workflow. Return-value details are correctly left to the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds cross-call semantics the schema alone does not convey: conflictReviews is defined as verdicts on a previous compile's reviewCandidates entries, a conflict verdict blocks the plan, and pending proposals never enter steps. Remaining parameters are covered adequately by the schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource with scope: 'Compile complete change intent into a deterministic, snapshot-bound read-only plan.' It also names what it is not by contrasting with kb_model and kb_plan_bootstrap, so an agent can separate it from siblings without reading schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use it 'before editing code for a change request that may touch several requirements,' and routes the agent to kb_model for single-requirement prose and kb_plan_bootstrap for first-time onboarding. Conditions and alternatives are both stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate curated structural coverage and conservative end-to-end requirement proof reports for requirements, symbols, or grouped types. Use it to ask which requirements are tested end to end, how strong each requirement's evidence is (evidenceLevel: proved, tested, asserted or unverified), and what blocks the rest; use kb_find_gaps for a plain list of missing links and kb_check for rule violations. Reports include the compatible repair plan plus typed kibi.migration-plan.v2 actions; semantic and E2E actions remain review/execution work. Paginated plans identify incomplete scope and no mutation occurs.
| Name | Required | Description | Default |
|---|---|---|---|
| by | No | Report shape: req gives per-requirement proof status and a repair plan, symbol gives per-symbol ownership coverage, type gives counts per entity type. | |
| tags | No | Keep rows for entities carrying any of these metadata tags. | |
| limit | No | Maximum rows to return. When the repair plan reports scope.complete false, rerun with offset 0 and a larger limit. | |
| offset | No | Zero-based row offset for pagination. | |
| statuses | No | Requirement proof-status filter (req mode): include only rows whose proofStatus is listed. Selecting statuses implies include-passing; not_applicable rows carry their typed applicability reason in proofStages.applicability.reason. The summary always reflects the whole KB. | |
| workspaceRoot | No | Optional absolute path of the workspace this call is about when it differs from the one the server started in, for example the git worktree you are working in. The server answers from that workspace's knowledge base when it is a worktree of the same repository or lies under the client's MCP roots; otherwise it answers from its own workspace and adds a workspace_mismatch diagnostic. Host hooks fill this in automatically where available. | |
| includePassing | No | Also return rows that are already tested or not applicable. By default only rows that still need repair are returned. | |
| migrationLimit | No | Maximum requirement migration batches to preview. Defaults to one review batch. | |
| migrationOffset | No | Zero-based offset into ready semantic-inventory batches. | |
| includeTransitive | No | Count symbol coverage reached transitively through linked entities, not only direct links. | |
| includeMigrationPreview | No | Opt in to a deterministic, read-only kibi.legacy-migration-plan.v1 preview for ready semantic-inventory repair batches. | |
| migrationPredicateLimit | No | Maximum exact predicate-schema candidates retained per assertive proposition. | |
| migrationPredicateMinScore | No | Minimum deterministic predicate-schema rank score retained in migration previews. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| error | No | |
| status | Yes | |
| effects | Yes | |
| operation | Yes | |
| diagnostics | Yes | |
| nextActions | Yes | |
| kibiProtocol | Yes | |
| resultVersion | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description reinforces this with 'no mutation occurs' plus useful extra context on pagination incomplete scope and that semantic/E2E actions remain review/execution work. It adds value beyond the annotations, though it doesn't detail rate limits or exact return shape (output schema covers that).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the action and scope, then alternatives, then behavioral caveats. Dense but each sentence carries information; minor cost is the long compound third sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 13 optional params and an output schema (so return values needn't be explained), the description covers purpose, alternatives, and behavioral caveats adequately. It could more explicitly tie the migration/preview params to usage, but nothing critical for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 13 parameters are already documented in the schema; baseline 3 applies. The description adds meaning around the evidenceLevel return values but does not enrich parameter semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Generate) and resource (structural coverage and end-to-end requirement proof reports) and names the three report modes (requirements, symbols, grouped types). An agent can distinguish it from kb_find_gaps and kb_check without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly frames the use case ('ask which requirements are tested end to end, how strong each requirement's evidence is') and routes alternatives by name: kb_find_gaps for missing-link lists and kb_check for rule violations. Clear when-to-use vs when-not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete entities by ID, or exact relationship triples. Use only for intentional removals after dependency checks. Do not use as a bulk cleanup shortcut. An entity authored in a Markdown or YAML source is not deleted directly: the call writes nothing and returns outcome plan_returned with a hash-bound deletionPlan and a nextActions entry holding the exact kb_apply_plan input ({plan, approvedPlanHash}); apply that unmodified, or repeat this call with approvedPlanHash = deletionPlan.planHash to apply the freshly computed plan in one step (a stale or different hash fails with DELETE_PLAN_HASH_MISMATCH and writes nothing). Authored requirements are never deleted: outcome supersession_required points to kb_upsert with a supersedes relationship. dryRun:true previews any delete and writes nothing. Side effects: mutates and saves KB and authored sources; skips entities with dependents; dryRun and plan_returned write nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | No | Entity IDs to delete after dependency checks. | |
| dryRun | No | Preview without writing. Relationship and direct entity deletes run their preflight and return outcome dry_run with wouldDelete counts, the sourceWrites (paths and hashes) a commit would make, and skippedEffects. Authored ids return the same deletion plan as without dryRun. | |
| relationships | No | Exact relationship triples to retract, including legacy shard records. | |
| workspaceRoot | No | Optional absolute path of the workspace this call is about when it differs from the one the server started in, for example the git worktree you are working in. The server answers from that workspace's knowledge base when it is a worktree of the same repository or lies under the client's MCP roots; otherwise it answers from its own workspace and adds a workspace_mismatch diagnostic. Host hooks fill this in automatically where available. | |
| approvedPlanHash | No | With ids only: the deletionPlan.planHash a prior call for the same ids returned. The plan is recomputed and applied through kb_apply_plan when its hash still matches; a mismatch fails with DELETE_PLAN_HASH_MISMATCH and writes nothing. Not allowed with relationships or dryRun. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| error | No | |
| status | Yes | |
| effects | Yes | |
| operation | Yes | |
| diagnostics | Yes | |
| nextActions | Yes | |
| kibiProtocol | Yes | |
| resultVersion | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructive=true and non-idempotent, but the description goes far beyond them: it discloses that entities with dependents are skipped, that authored entities trigger a hash-bound plan instead of a direct write, the exact DELETE_PLAN_HASH_MISMATCH failure mode, and what dryRun and plan_returned write (nothing). This is unusually rich behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action, and the long plan-workflow sentence is dense but justified by genuine complexity. It reads as one unbroken paragraph, so structural breaks would improve scanability; the 'Use only for intentional removals' sentence is also somewhat redundant with the following clause.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive, multi-path tool with an output schema already present, the description covers side effects, dependency handling, the plan/hash workflow, dry-run semantics, and failure outcomes. An agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds real value on top by explaining how ids + approvedPlanHash interact (a stale hash fails; must match), and by distinguishing dryRun behavior for authored vs direct deletes. It stops short of full coverage but clearly exceeds schema-only semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a concrete verb and two distinct resources: 'Delete entities by ID, or exact relationship triples.' This distinguishes it from kb_upsert, kb_apply_plan, and the read-only siblings without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use it ('intentional removals after dependency checks'), when not to ('not as a bulk cleanup shortcut'), and names the alternative path (kb_upsert with a supersedes relationship for authored requirements, kb_apply_plan for plan application). Routing guidance is complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List KB entities by the relationships they lack or have. Use for questions like which requirements lack scenarios or tests; all filters must match, and a relationship counts in either direction. Use kb_coverage instead for proof status and repair plans, and kb_check for rule violations. No mutation side effects.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Keep entities carrying any of these metadata tags. Bootstrap provenance stubs appear in rows only when this names bootstrap:provenance-stub. | |
| type | No | Only report entities of this type. Omit for all types. | |
| limit | No | Maximum rows to return; count reports the full total. | |
| offset | No | Zero-based row offset for pagination. | |
| sourceFile | No | Keep entities whose source path contains this substring. | |
| workspaceRoot | No | Optional absolute path of the workspace this call is about when it differs from the one the server started in, for example the git worktree you are working in. The server answers from that workspace's knowledge base when it is a worktree of the same repository or lies under the client's MCP roots; otherwise it answers from its own workspace and adds a workspace_mismatch diagnostic. Host hooks fill this in automatically where available. | |
| missingRelationships | No | Relationship types the entity must have none of, in either direction, for example specified_by or verified_by. verified_by and validates satisfy each other. | |
| presentRelationships | No | Relationship types the entity must have at least one of each, in either direction. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| error | No | |
| status | Yes | |
| effects | Yes | |
| operation | Yes | |
| diagnostics | Yes | |
| nextActions | Yes | |
| kibiProtocol | Yes | |
| resultVersion | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the closing "No mutation side effects" adds little. What does add value is the matching semantics: filters are ANDed, and a relationship counts in either direction — behavior that determines result shape and is not inferable from annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, front-loaded with the core purpose and followed by routing. The only wasted clause is the trailing "No mutation side effects," which repeats what the annotations already declare.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Purpose, filter conjunction semantics, directionality, and sibling routing are all covered for an 8-parameter tool, and an output schema plus rich annotations carry the return shape and safety profile. Pagination behavior (limit/offset interaction) and workspaceRoot fallback are left entirely to the schema, which is acceptable but is the remaining gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all eight parameters are already documented in the schema, including the bidirectional rule for missingRelationships/presentRelationships. The description reinforces the either-direction rule but adds no syntax, defaults, or interaction details beyond that; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — list KB entities filtered by missing/present relationships — and immediately names the sibling alternatives (kb_coverage, kb_check) with the condition that selects each. An agent can distinguish this from the graph, coverage, and check tools without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a concrete question pattern ("which requirements lack scenarios or tests") that anchors the use case, plus explicit exclusion routing: kb_coverage for proof status and repair plans, kb_check for rule violations. Both when-to-use and when-not-to-use are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run bounded graph traversal from one or more seed IDs across curated relationship types and return the nodes and edges reached. Use it to follow links from IDs you already have, such as a requirement to its scenarios and tests or a symbol to the requirements it implements; use kb_query to find entities by filter and kb_search to ask a question. Traversal stops at depth, maxNodes or maxEdges and then sets truncated. No mutation side effects.
| Name | Required | Description | Default |
|---|---|---|---|
| depth | No | Number of hops from the seeds. | |
| seedIds | Yes | Entity IDs to start from, for example REQ-... or SCEN-.... Seeds are always returned as nodes. | |
| maxEdges | No | Stop and set truncated once this many edges are reached. | |
| maxNodes | No | Stop and set truncated once this many nodes are reached. | |
| direction | No | outgoing follows links from each node, incoming follows links pointing at it, both does either. | |
| entityTypes | No | Keep only nodes of these types (req, scenario, test, adr, flag, event, symbol, fact) in the result, and the edges between them. Traversal still passes through other types. | |
| relationships | No | Relationship types to follow, for example specified_by, verified_by or implements. Omit to follow every relationship type. | |
| workspaceRoot | No | Optional absolute path of the workspace this call is about when it differs from the one the server started in, for example the git worktree you are working in. The server answers from that workspace's knowledge base when it is a worktree of the same repository or lies under the client's MCP roots; otherwise it answers from its own workspace and adds a workspace_mismatch diagnostic. Host hooks fill this in automatically where available. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| error | No | |
| status | Yes | |
| effects | Yes | |
| operation | Yes | |
| diagnostics | Yes | |
| nextActions | Yes | |
| kibiProtocol | Yes | |
| resultVersion | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds real behavior beyond the annotations: traversal terminates at depth/maxNodes/maxEdges and flags the result with 'truncated', which tells the agent how to interpret partial results. The final sentence restates the read-only profile already covered by readOnlyHint/destructiveHint, and it says nothing about invalid seed IDs or ordering, so it stops just short of the top mark.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action, and the sibling routing is compressed into one efficient clause. The closing 'No mutation side effects' sentence duplicates what the annotations already declare, so not every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return shape need not be explained, and the description still covers the one semantic gap a schema cannot: what 'truncated' means in practice. For an 8-parameter read-only traversal with full schema coverage, nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so depth, seedIds, maxNodes, maxEdges, direction, entityTypes, relationships and workspaceRoot are all self-documented. The description only echoes the truncation semantics already in the maxNodes/maxEdges descriptions and adds no new meaning for the seed or relationship parameters, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Run bounded graph traversal from one or more seed IDs') plus the scope of what it follows and returns ('nodes and edges reached'). It also names the two siblings it is not, so an agent can separate it from kb_query and kb_search without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives the exact condition for use ('follow links from IDs you already have') with concrete examples (requirement → scenarios/tests, symbol → requirements). It explicitly routes the alternative cases: 'use kb_query to find entities by filter and kb_search to ask a question'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ingest a producer-emitted kibi.proof-run.v1 artifact and evaluate it against each selected test's kibi.proof-contract.v1 proof obligations. Revalidates the live workspace snapshot, integration command binding, run-level outcome, attempt history, success policy, and append-only proof-receipt history before deriving and appending idempotent kibi.proof-receipt.v1 receipts. Producers report what happened; Kibi evaluates proof. Prefer kibi prove so the configured producer runs automatically; direct ingestion is an integration path for custom producers and agents.
| Name | Required | Description | Default |
|---|---|---|---|
| testIds | No | Existing test entities with proof_contract.v1. Omit to evaluate every test contracted to the artifact's integration. | |
| artifact | Yes | Producer-emitted kibi.proof-run.v1 proof artifact. Producers report what happened; Kibi evaluates proof obligations and policies. Produce it via `kibi prove` or direct kb_ingest_proof calls. | |
| snapshot | Yes | Workspace snapshot captured immediately before the run. | |
| workspaceRoot | No | Optional absolute path of the workspace this call is about when it differs from the one the server started in, for example the git worktree you are working in. The server answers from that workspace's knowledge base when it is a worktree of the same repository or lies under the client's MCP roots; otherwise it answers from its own workspace and adds a workspace_mismatch diagnostic. Host hooks fill this in automatically where available. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| error | No | |
| status | Yes | |
| effects | Yes | |
| operation | Yes | |
| diagnostics | Yes | |
| nextActions | Yes | |
| kibiProtocol | Yes | |
| resultVersion | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations cover high-level hints (destructive, readOnly), the description adds critical behavioral context by explaining the internal evaluation flow: it 'Revalidates the live workspace snapshot, integration command binding, run-level outcome, attempt history, success policy, and append-only proof-receipt history' before deriving receipts. This adds value beyond the hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is relatively dense, but the information is tightly packed and logically ordered: Function -> Process Detail -> Usage Policy. The sentences are highly information-rich and avoid fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the input schema (multiple nested objects, version constraints) and the detailed process described in the text, the definition is extremely complete. An AI agent has all the necessary information for accurate selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since schema coverage is 100%, the parameters are thoroughly defined structurally. The description does not need to elaborate on parameter meanings, focusing instead on the high-level context (e.g., the artifact being 'producer-emitted'). Baseline 3 is appropriate due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool ingests a specific artifact ('kibi.proof-run.v1') and its core purpose is to evaluate it against specific proof obligations ('kibi.proof-contract.v1'). It clearly defines the operational scope of the function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides excellent usage guidance by offering a clear hierarchy of preference: 'Prefer `kibi prove` so the configured producer runs automatically.' It then specifies the niche use case for this tool ('direct ingestion is an integration path for custom producers and agents').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn requirement prose into checkable structure without writing the KB. Use it for one requirement's prose; to plan a whole change request use kb_compile_intent. mode:analyze returns the semantic advisor receipt: the clause ledger, what is grounded, what is ambiguous and suggested modeling (pass clauses for compound prose and optional typed kibi.logic.v1 interpretations). mode:requirement converts one claim (subjectKey, propertyKey, operator, value, or typed logic) into a strict-lane write set and applyPlan. mode:predicates ranks ontology predicate schemas and returns an applicable predicate-fact plan only for reviewed bindings, otherwise an ontology-gap observation. With requirementId, mode:predicates also returns a hash-bound plan (fact write plus requires_predicate link) for kb_apply_plan, whose contradictionAnalysis is the what-if over the current KB; other returned plans apply with kb_upsert, and kb_upsert dryRun with plannedFacts previews a requirement before its facts exist.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Optional requirement ID used for deterministic draft relationship guidance. | |
| mode | Yes | analyze (advisor receipt), requirement (strict claim write set) or predicates (ontology predicate plan). | |
| text | Yes | Required prose requirement text to model. Example: 'Customer data must be retained for 7 years.' | |
| type | No | Entity type context for analysis. Requirement, domain-fact, and supporting prose all receive a proposition ledger; only requirements receive deterministic modeling suggestions. | |
| logic | No | Optional typed kibi.logic.v1 IR. Kibi validates and canonicalizes it into a rule fact; raw Prolog is rejected. | |
| title | No | Optional requirement title for draft apply plans. | |
| value | No | Optional extracted semantic claim value: a string, number or boolean, or a list of strings for a set claim. Example: ['requireAuth'] with operator includes. | |
| source | No | Optional primary source path or provenance root used for stable IDs and text refs. Example: '.kb/requirements/customer-retention.md'. | |
| status | No | Optional requirement status for draft suggestions. | |
| clauses | No | Optional complete list of atomic requirement clauses supplied by the caller. Each clause must be a verbatim fragment of text (whitespace may differ); a clause that does not occur in text fails the call with VALIDATION_FAILED naming it. Use this for compound prose so every normative clause receives a stable claim key and independent grounding review. | |
| claimKey | No | Optional advisor-issued claim key for the exact proposition represented by logic. | |
| minScore | No | Minimum candidate score. Higher values make ontology-gap fallback more likely. Default: 0.35. | |
| operator | No | Optional extracted semantic claim operator. Use gt/lt for strict bounds ('greater than zero' is gt 0, not gte 0). A set claim takes a list value with eq (exactly these), includes (at least these), subset_of (only these) or excludes (none of these); matches takes a regular expression string. Example: 'eq'. | |
| schemaId | No | Optional exact reviewed predicate schema ID. When supplied, Kibi selects that schema instead of lexical rank order and fails closed if it is unavailable. | |
| claimText | No | Optional exact proposition text represented by logic; defaults to text. | |
| confidence | No | Confidence score for the extracted claim. >= 0.70 yields strict-lane output; lower confidence yields observation-only review output. | |
| provenance | No | Optional extracted text reference. Falls back to source when omitted. Example: '.kb/requirements/customer-retention.md#L1'. | |
| subjectKey | No | Optional extracted semantic claim subjectKey. Example: 'Customer.Data'. | |
| propertyKey | No | Optional extracted semantic claim propertyKey. Example: 'Retention Years'. | |
| sourceFiles | No | Optional related source files. The first value is used as the source fallback when source is omitted. | |
| subjectHint | No | Optional canonical subject key to use as the first predicate argument. Example: 'editor.annotation'. | |
| polarityHint | No | Optional reviewed polarity override for claims whose surface negation does not express predicate denial. Use only after reviewing the selected schema and full claim scope. | |
| maxCandidates | No | Maximum ranked predicate candidates to return. Default: 5. | |
| requirementId | No | Optional requirement ID. The strict write set updates this requirement instead of minting a REQ-AUTO id, and a typed logic rule attaches its requires_rule relationship to it. | |
| workspaceRoot | No | Optional absolute path of the workspace this call is about when it differs from the one the server started in, for example the git worktree you are working in. The server answers from that workspace's knowledge base when it is a worktree of the same repository or lies under the client's MCP roots; otherwise it answers from its own workspace and adds a workspace_mismatch diagnostic. Host hooks fill this in automatically where available. | |
| interpretations | No | Optional host-LLM typed kibi.logic.v1 interpretations. Kibi validates and canonicalizes them; raw Prolog is not accepted. | |
| argumentBindings | No | Optional exact predicate argument values keyed by a candidate schema's argument_names. Required before applying a candidate whose binding_status is incomplete; Kibi never substitutes guessed values for unbound arguments. | |
| existingLogicClaims | No | Existing requirement logic_claims values. The returned requirement update merges the new atomic claim key into this manifest instead of replacing prior claims. | |
| includeExistingSchemas | No | Whether to include existing KB fact_kind=predicate_schema facts alongside Kibi's built-in predicate catalog. Default: true. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| error | No | |
| status | Yes | |
| effects | Yes | |
| operation | Yes | |
| diagnostics | Yes | |
| nextActions | Yes | |
| kibiProtocol | Yes | |
| resultVersion | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent/non-destructive annotations, the description explains what each mode returns: an advisor receipt with clause ledger, a strict-lane write set and applyPlan, or an ontology predicate plan only for reviewed bindings. It also clarifies that requirementId produces a hash-bound plan for kb_apply_plan while other plans apply with kb_upsert, and that dryRun plannedFacts previews a requirement before facts exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and the sibling alternative, then walks through each mode. It is dense and long, but for a 29-parameter, multi-mode tool most sentences carry substantive routing or behavioral information rather than filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description covers the mode behaviors, write-plan semantics, external application paths, and the requirementId special case. An output schema exists, so it does not need to enumerate every return field, and the safety profile is already covered by annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already 100%, so the schema documents all 29 parameters. The description still adds meaningful cross-parameter behavior: clauses are for compound prose, interpretations are optional typed logic, confidence thresholds determine strict-lane vs observation-only output, and requirementId changes plan generation and routing to kb_apply_plan.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening states a specific verb and resource: turn requirement prose into checkable structure without writing the KB. It also distinguishes the tool from kb_compile_intent for whole change requests, so an agent can route between them without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit usage for one requirement's prose and names kb_compile_intent as the alternative for planning a whole change request. The three modes are each tied to a distinct output context, though the choice between analyze and requirement is left somewhat implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a deterministic, snapshot-bound kibi.bootstrap-plan.v1 for repository onboarding. Use it only to onboard a repository whose KB is empty or incomplete (the kibi-bootstrap skill drives it); for a change in an onboarded project use kb_compile_intent. Read-only analysis of the repository plus any declared knowledge sources and cited intent claims returns evidence, bounded context questions, exact dependency-ordered actions, a canonical plan hash, and no mutation side effects.
| Name | Required | Description | Default |
|---|---|---|---|
| entityTypes | No | Optional filter to limit candidate generation to specific entity types. | |
| maxCandidates | No | Budget for candidates Kibi discovers itself (symbols, tests, repository documents). Declared intentClaims sit outside it: they are never capped and never use its slots. Clamped to [1, 200]. Default: 50. | |
| minConfidence | No | Minimum confidence threshold for candidates. Clamped to [0.60, 0.95]. Default: 0.80. | |
| workspaceRoot | No | Optional absolute path of the workspace this call is about when it differs from the one the server started in, for example the git worktree you are working in. The server answers from that workspace's knowledge base when it is a worktree of the same repository or lies under the client's MCP roots; otherwise it answers from its own workspace and adds a workspace_mismatch diagnostic. Host hooks fill this in automatically where available. | |
| bootstrapContext | No | Optional declared bootstrap context supplied by the agent to ground the read-only synthesis output. | |
| includeGenericMarkdown | No | Whether to include generic markdown file content as candidate facts. Default: true, or false when bootstrapContext declares intentClaims (the declared sources already carry the intent); set it explicitly to override. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| error | No | |
| status | Yes | |
| effects | Yes | |
| operation | Yes | |
| diagnostics | Yes | |
| nextActions | Yes | |
| kibiProtocol | Yes | |
| resultVersion | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the description needn't restate safety. It adds real value beyond that: the output contents (evidence, bounded context questions, dependency-ordered actions, canonical plan hash), the snapshot-bound determinism, and the explicit 'no mutation side effects' reassurance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core purpose before the usage constraint and the return description. Dense but each clause earns its place; the middle sentences are somewhat long but remain readable and non-redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so returns needn't be fully explained, and the description still summarizes them. Combined with 100% schema coverage and annotations, an agent has enough to call correctly, though it doesn't detail bootstrapContext sub-structure (left to schema).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all six parameters thoroughly, including the nested bootstrapContext. The description adds only high-level mentions of 'declared knowledge sources and cited intent claims' and doesn't clarify individual parameter behavior beyond what the schema provides. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Generate a deterministic, snapshot-bound kibi.bootstrap-plan.v1 for repository onboarding.' It explicitly names the sibling kb_compile_intent and the condition that selects it, so an agent can distinguish scope without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit when-to-use ('only to onboard a repository whose KB is empty or incomplete') and a when-not/alternative ('for a change in an onboarded project use kb_compile_intent'). It also points to the driving skill (kibi-bootstrap).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prepare complete content-bound impact-review authoring inputs from the current staged snapshot or explicitly selected immutable Git commits. Use it when kb_check reports that changed files need an impact review; it does not plan KB changes. Returns strict reviewer schemas and an unauthored template; it does not decide, approve, sign, stage, or prove the review.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | Yes | What to review: {"kind":"staged"} for the staged snapshot, or {"kind":"diff","baseCommit":"<sha>","headCommit":"<sha>"} with full commit hashes. | |
| workspaceRoot | No | Optional absolute path of the workspace this call is about when it differs from the one the server started in, for example the git worktree you are working in. The server answers from that workspace's knowledge base when it is a worktree of the same repository or lies under the client's MCP roots; otherwise it answers from its own workspace and adds a workspace_mismatch diagnostic. Host hooks fill this in automatically where available. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| error | No | |
| status | Yes | |
| effects | Yes | |
| operation | Yes | |
| diagnostics | Yes | |
| nextActions | Yes | |
| kibiProtocol | Yes | |
| resultVersion | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety bar is met; the description adds real value beyond them by listing what it will NOT do (decide, approve, sign, stage, prove) and confirming output is an unauthored template. That negative-space disclosure is exactly what an agent needs before chaining this into a review workflow.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences: what it does, when to use it, and what it does not do. Front-loaded and free of filler, though the negative list in the final sentence is slightly clipped in phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and full schema coverage on both parameters, the description only needs to cover purpose, trigger, and boundaries — all of which it does. Nothing an agent needs to invoke this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description's mention of "current staged snapshot or explicitly selected immutable Git commits" loosely maps to the scope kinds but adds no format or constraint detail beyond the schema's own explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ("prepare complete content-bound impact-review authoring inputs") and immediately names the two input sources. It is clearly distinguishable from siblings like kb_plan_bootstrap or kb_check, which it references as an upstream trigger rather than a peer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use it ("when kb_check reports that changed files need an impact review") and carves out a negative case ("it does not plan KB changes"). It stops short of naming the alternative tool an agent should reach for when planning is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read entities from the KB with exact filters, or ask typed fact questions. Use for lookup by id, type, tags or sourceFile, and for precise questions about modeled facts: predicate facts by name with named arguments (predicate + where), property facts of a subject (subjectKey + propertyKey), or the catalog of facts of one kind (factKind; 'predicate_schema' lists the predicates you can ask about with their argument names and constants). Typed answers return matching fact rows plus factQuery: the schema used, distinct counts, values that do exist when nothing matched, warnings about the question and the next call to make. Read-only. Tags filter by metadata tags only, not entity IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Optional exact entity ID. Example: 'REQ-cli-gc'. If omitted, returns matching entities by other filters. | |
| args | No | Positional argument values for predicate when it has no schema; null matches any value. Example: ['admin', null, null, 'allow']. Prefer where. | |
| tags | No | Optional tag filter. Matches entities that contain any provided tag. Example: ['security','billing']. | |
| type | No | Optional entity type filter. Allowed: req, scenario, test, adr, flag, event, symbol, fact. Example: 'req'. | |
| limit | No | Optional max rows to return after filtering. Default: 100 when omitted. Example: 25. | |
| scope | No | Optional: 'current_requirements' keeps only facts a current (not superseded or retired) requirement requires. | |
| where | No | Named argument values for predicate, order-free, using the argument names from the predicate's schema. Example: {actor: 'admin', decision: 'allow'}. An unknown name returns a warning with the declared names; no match returns the values that do exist. | |
| offset | No | Optional zero-based pagination offset. Default: 0. Example: 50 to skip first 50 rows. | |
| distinct | No | Optional argument name to count distinct values of across the matching predicate facts, e.g. distinct: 'role' with predicate 'has_role' and where {user: 'alice'} answers how many roles alice has. | |
| factKind | No | Typed fact filter: list facts of one kind with their typed fields. 'predicate_schema' returns the catalog of askable predicates (argument names, constants, fact counts). Example: 'predicate_schema'. | |
| polarity | No | Optional polarity filter for predicate facts. Default: both. | |
| namespace | No | Optional predicate namespace when the same name exists in several. Default: any namespace. | |
| predicate | No | Typed fact filter: predicate name to ask about, e.g. 'has_role' or 'permission_rule'. Combine with where for named arguments. Returns every stored fact of that predicate with its arguments, polarity and allow/deny effect. | |
| sourceFile | No | Optional source-file substring filter. Example: 'src/auth/login.ts'. Uses KB source linkage, not file-system scanning. | |
| subjectKey | No | Typed fact filter: dotted subject key whose property facts to list, e.g. 'user.role_assignment'. Combine with propertyKey for one property. | |
| includeBody | No | With id only: also return the entity's authored Markdown body (the prose after its front matter) as body {id, path, text}, so a stale statement in it can be corrected; kb_upsert document.body replaces it. Default: false. | |
| propertyKey | No | Optional property key under subjectKey, e.g. 'max_roles'. Returns operator, value and unit of each fact. | |
| workspaceRoot | No | Optional absolute path of the workspace this call is about when it differs from the one the server started in, for example the git worktree you are working in. The server answers from that workspace's knowledge base when it is a worktree of the same repository or lies under the client's MCP roots; otherwise it answers from its own workspace and adds a workspace_mismatch diagnostic. Host hooks fill this in automatically where available. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| error | No | |
| status | Yes | |
| effects | Yes | |
| operation | Yes | |
| diagnostics | Yes | |
| nextActions | Yes | |
| kibiProtocol | Yes | |
| resultVersion | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/non-destructive, but the description adds substantial context beyond them: the typed-answer payload (factQuery with schema used, distinct counts, existing values when nothing matched, warnings and next call), the tag caveat ('metadata tags only, not entity IDs'), and the factKind semantics. This is rich behavioral disclosure for a read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the core purpose before the mode breakdown and the tag caveat at the end. It is dense but nearly every clause carries information; the single long paragraph is slightly run-on but not padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 18-parameter, multi-mode tool with a nested object and an output schema, the description covers modes, combination semantics, output behavior, and the notable tag limitation. Nothing an agent needs to call it correctly appears to be missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds integration-level meaning by showing how parameters combine (predicate + where for named arguments, subjectKey + propertyKey for one property, factKind 'predicate_schema' for the catalog). It clarifies relationships the per-field descriptions do not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Read entities from the KB') and enumerates distinct modes: exact-filter lookups and typed fact questions (predicate/where, subjectKey/propertyKey, factKind). An agent can distinguish it from kb_search (exact vs. search) without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete when-to-use conditions ('lookup by id, type, tags or sourceFile', 'precise questions about modeled facts', catalog listing via factKind). It implies the alternative is fuzzy search but never explicitly names kb_search or states exclusions, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask the KB a question or search it. Default intent-v1 ranking accepts questions, host-agent semantic facets and changed-code source locations, returns evidence, abstains below its confidence threshold and adds an answer layer: the current requirements that govern the topic, what must stay true (linked facts), why (ADRs) and what verifies it (scenarios, tests). A weak answer may add queryAnalysis.hints from a search-hints plugin: requirements the question may mean, to re-ask with. Use before changing behavior, then kb_query for exact follow-up. No mutation side effects.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Optional entity type filter to narrow discovery. Example: 'req'. | |
| hints | No | Intent-v1 only, first page only. When true (default) and the project activates a kibi.search-hints.v1 plugin, a weak or abstained answer adds queryAnalysis.hints: requirements the question may mean, to re-ask with. Hints never change results or the answer layer. | |
| limit | No | Optional max rows to return after ranking. Default: 10; raise it or page with offset when the answer layer is not enough. | |
| query | Yes | Free-text query for metadata and markdown body discovery. Example: 'OAuth login flow'. | |
| answer | No | Intent-v1 only, first page only. When true (default) the result includes an answer layer: current governing requirements with their linked facts, scenarios, tests and ADRs, superseded requirements listed separately, and observation facts labelled as notes. Bounded in size; discovery, not proof. | |
| fields | No | Optional result detail. 'summary' returns identifying metadata plus the match snippet for discovery. Use 'full' to include complete entity bodies, or follow up with kb_query for the exact entities you need. | |
| offset | No | Optional zero-based pagination offset. Default: 0. | |
| minScore | No | Intent-v1 acceptance threshold between 0 and 1. Low-confidence queries abstain instead of returning misleading matches. | |
| rankingMode | No | Optional deterministic ranking mode. Default intent-v1: question-aware ranking with semantic facets, source-aware evidence, graph boosts, superseded demotion and abstention. Use legacy for the older lexical ranking. | |
| workspaceRoot | No | Optional absolute path of the workspace this call is about when it differs from the one the server started in, for example the git worktree you are working in. The server answers from that workspace's knowledge base when it is a worktree of the same repository or lies under the client's MCP roots; otherwise it answers from its own workspace and adds a workspace_mismatch diagnostic. Host hooks fill this in automatically where available. | |
| semanticFacets | No | Optional host-agent semantic interpretation. Kibi uses these strings as deterministic aliases/facets; ranking never calls a model. | |
| sourceLocations | No | Optional changed-code locations. Results are matched to source-linked symbols/entities and include source evidence. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| error | No | |
| status | Yes | |
| effects | Yes | |
| operation | Yes | |
| diagnostics | Yes | |
| nextActions | Yes | |
| kibiProtocol | Yes | |
| resultVersion | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/non-destructive, and the description adds real behavioral context: abstention below a confidence threshold, an answer layer with superseded requirements and observation facts, bounded size ('discovery, not proof'), and that hints never change results. The closing 'No mutation side effects' merely restates the annotations, and much of the hints/answer prose describes output fields the output schema likely already documents.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded in sentence one, but the remainder is dense jargon ('queryAnalysis.hints', 'host-agent semantic facets', 'superseded demotion') packed into long clauses. Several phrases describe return-value mechanics rather than tool selection, which dilutes a description that could be tighter for an agent scanning candidates.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 12-parameter tool with nested objects and an output schema, the description conveys the overall model (question-answering search, abstention, answer layer, follow-up with kb_query) and leaves parameter detail to the well-covered schema. A brief note on the low-confidence abstain path's shape would close the last gap, but nothing needed to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter including semanticFacets, sourceLocations and workspaceRoot is already explained in the schema. The description only adds the framing that intent-v1 accepts questions, facets and changed-code locations, without new syntax, defaults, or constraints — baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a concrete verb+resource ('Ask the KB a question or search it') and immediately characterizes the default ranking behavior (intent-v1, question-aware, evidence-returning, abstaining). It explicitly differentiates from the sibling kb_query ('for exact follow-up'), so an agent can choose between them without reading schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use before changing behavior, then kb_query for exact follow-up' gives an explicit trigger and names the follow-up alternative, and the hints sentence explains the re-ask loop when an answer is weak. It stops short of saying when NOT to use this tool versus other siblings like kb_find_gaps or kb_graph.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read bundled Kibi agent skills (workflow guidance). action:list returns the catalog; action:load returns a skill's metadata, Markdown body, declared resources and content hash (start with id 'kibi-usage'); action:read returns one manifest-declared resource. Read-only; does not require Prolog.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Bundled skill ID. Example: 'kibi-usage'. | |
| action | Yes | list, load (needs id) or read (needs id and resource). | |
| resource | No | Manifest-declared resource path to read. Example: 'resources/workflows.md'. | |
| workspaceRoot | No | Optional absolute path of the workspace this call is about when it differs from the one the server started in, for example the git worktree you are working in. The server answers from that workspace's knowledge base when it is a worktree of the same repository or lies under the client's MCP roots; otherwise it answers from its own workspace and adds a workspace_mismatch diagnostic. Host hooks fill this in automatically where available. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| error | No | |
| status | Yes | |
| effects | Yes | |
| operation | Yes | |
| diagnostics | Yes | |
| nextActions | Yes | |
| kibiProtocol | Yes | |
| resultVersion | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/non-destructive/non-open-world, so the bar is lower; the description still adds that no Prolog engine is required (a real prerequisite for other kb tools) and roughly what each action yields. It stops short of rate limits, caching or workspace-resolution nuance, which the schema handles instead.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense, front-loaded sentence enumerating the actions plus one short constraint clause; every clause earns its place. Slightly run-on with three semicolon-joined action definitions, but no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With annotations, a 100%-covered schema and an output schema present, the description only needs to cover purpose, action routing and the Prolog-free constraint, and it does all three. Nothing an agent needs in order to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds function-level meaning to the action values beyond the schema's const list (what 'load' returns vs 'read' vs 'list') and names a concrete starting id. It adds nothing for workspaceRoot or resource beyond what the schema already explains.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Read bundled Kibi agent skills') and then disambiguates its three actions by what each returns (catalog, metadata/Markdown body/resources/hash, single manifest resource). An agent can distinguish this from kb_query/kb_search without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an in-tool sequencing hint ('start with id kibi-usage') and context ('workflow guidance', 'Read-only; does not require Prolog'), but never says when to prefer this tool over siblings like kb_search, kb_query or kb_graph, nor any when-not condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report current branch, KB snapshot, freshness metadata, schema status, and a typed kibi.migration-plan.v2 action graph. Call it first to orient on a branch or after a failed call; use kb_check for validation findings and kb_coverage for proof status. Read-only status inspection with no mutation side effects; damaged stores are diagnosed without starting the engine.
| Name | Required | Description | Default |
|---|---|---|---|
| workspaceRoot | No | Optional absolute path of the workspace this call is about when it differs from the one the server started in, for example the git worktree you are working in. The server answers from that workspace's knowledge base when it is a worktree of the same repository or lies under the client's MCP roots; otherwise it answers from its own workspace and adds a workspace_mismatch diagnostic. Host hooks fill this in automatically where available. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| error | No | |
| status | Yes | |
| effects | Yes | |
| operation | Yes | |
| diagnostics | Yes | |
| nextActions | Yes | |
| kibiProtocol | Yes | |
| resultVersion | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety restatement earns little credit. The description does add real context beyond the structured fields: damaged stores are diagnosed without starting the engine, meaning it works in a degraded state where other tools may not -- useful behavioral knowledge not encoded in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the primary purpose, then usage, then safety caveat in three dense sentences with no filler. The catalogue of reported artifacts and the 'kibi.migration-plan.v2' token are slightly jargon-heavy, but each clause carries information an agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be spelled out, and annotations already carry the safety profile. The description covers purpose, triggers, alternatives, and degraded-store behavior; the only untouched element is the workspaceRoot override, which the schema itself handles.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one optional parameter (workspaceRoot) and schema description coverage is 100%, so the schema already fully documents the worktree/mismatch fallback semantics. The description adds nothing about that parameter, so baseline 3 applies rather than a higher score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb+resource (report current branch, KB snapshot, freshness metadata, schema status) and even the payload shape (typed kibi.migration-plan.v2 action graph). It explicitly distinguishes itself from kb_check (validation findings) and kb_coverage (proof status), so an agent can separate it from siblings without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete trigger conditions -- "call it first to orient on a branch or after a failed call" -- and routes two adjacent needs to named alternatives (kb_check, kb_coverage). This is explicit when-to-use plus alternative selection, not inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create or update one entity and optional relationships. Use for KB mutations after validating intent; prefer a dryRun:true call first because it validates without writing and returns semantic advisor receipts for prose-heavy requirements. Use kb_model (mode requirement) before hand-writing strict property facts from prose, and kb_model (mode predicates) before hand-writing ontology predicate facts. Use the relationships array for batch creation of multiple links in a single call (e.g., linking a requirement to multiple tests or facts). An update keeps the properties and relationships it leaves out: send the fields that change (with title and status) and only the links to add. Prefer modeling requirements as reusable fact links (constrains, requires_property, or requires_predicate) so consistency and contradiction checks remain queryable. Relationship endpoints must already exist in KB. For requirements, the write will be rejected if it contradicts existing current requirements that constrain the same subject with incompatible properties. To replace a conflicting requirement, include a supersedes relationship from the new requirement to the old one in the same request, then upsert the old requirement with status closed (kb_check blocks a superseded requirement that is not closed). Successful writes may return non-blocking semantic advisor warnings; inspect and repair those warnings before treating prose as contradiction-checkable. Pass a sectioned document.body when creating a requirement (the statement, then ## Context stating why it exists, who asked and the source, then ## Source with the verbatim excerpt) and a prose body for scenarios, tests, ADRs and observation facts; a result warning reports an entity whose body lacks context, and kb_check blocks it under entity-context-missing. Never invent a reason the requester did not give: write 'Reason not stated'. Do not use for read-only inspection. Side effects: writes KB, may refresh symbol coordinates; dryRun:true writes nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Unique entity ID (string). Example: 'REQ-cli-gc'. Name entities by the behavior they govern (<TYPE>-<area>-<behavior>), never by the next free number. Existing ID updates the entity; new ID creates it. | |
| type | Yes | Entity type to create/update. Allowed: req, scenario, test, adr, flag, event, symbol, fact. Example: 'req'. | |
| dryRun | No | Validate the payload and return schema/modeling errors, a normalized preview and the semantic advisor receipt without writing the KB or workspace. Use it as the preflight before the real write. | |
| document | No | Optional source-first document write. Paths are workspace-relative; omit body when updating to preserve the existing body bytes (a requirement whose semantic_text changes gets the new statement in place of the old one, with its context sections kept). For a new requirement pass a sectioned body: statement, '## Context' (why, who asked, constraints), '## Source' (blockquoted excerpt and reference); context never changes the checked meaning, which stays in semantic_text. | |
| properties | Yes | Entity fields to persist. Must include title and status. If created_at, updated_at, or source are omitted, server fills defaults. | |
| plannedFacts | No | dryRun only. Fact upsert payloads (type, id, properties, optional relationships) that will be written before this payload, typically the applyPlan entries kb_model returned. They are validated in order and staged with the payload, so a requires_predicate or requires_property target that does not exist yet resolves, its claim_key is read from the plan, and the contradiction preview runs against the KB as it would be after the whole batch (result: stagedFacts, whatIf). A conflict the batch would introduce, such as an allow and a deny permission_rule on the same key, is refused as the commit would refuse it. Rejected without dryRun: write the facts first. | |
| relationships | No | Optional relationship rows to create in the same call. For requirement encoding, prefer `constrains` + `requires_property` for strict property facts or `requires_predicate` for ontology predicate facts. Side effect: asserts edges in KB. | |
| workspaceRoot | No | Optional absolute path of the workspace this call is about when it differs from the one the server started in, for example the git worktree you are working in. The server answers from that workspace's knowledge base when it is a worktree of the same repository or lies under the client's MCP roots; otherwise it answers from its own workspace and adds a workspace_mismatch diagnostic. Host hooks fill this in automatically where available. |
| Name | Required | Description |
|---|---|---|
| data | Yes | Committed upsert payload, or the validation preview when dryRun:true wrote nothing. |
| error | No | |
| status | Yes | |
| effects | Yes | |
| operation | Yes | |
| diagnostics | Yes | |
| nextActions | Yes | |
| kibiProtocol | Yes | |
| resultVersion | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as destructive, non-read-only, and non-idempotent, but the description adds important behavior: updates preserve omitted properties and relationships, dryRun writes nothing, successful writes may return semantic advisor warnings, and contradictions can cause rejection. It also discloses side effects such as writing the KB and possibly refreshing symbol coordinates. This is substantial context beyond the annotation flags.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action and alternatives, then moves into operational constraints and content rules. It is dense and useful, but several sentences are long and some content-level guidance overlaps with schema documentation. It earns most of its length, but could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a destructive mutation tool with eight parameters, nested objects, and an output schema, the description covers purpose, alternatives, dry-run preflight, update semantics, rejection conditions, supersede workflow, body structure, and side effects. Nothing essential for correct invocation appears to be missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds meaningful semantics beyond the schema, especially that an update keeps properties and relationships it leaves out and that superseding a conflicting requirement requires including a supersedes link in the same request. It also clarifies the purpose of dryRun and batch relationships. Some of this overlaps with schema descriptions, which keeps it from a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states a specific verb pair and resource: create or update one entity plus optional relationships. It also explicitly excludes read-only inspection, which separates it from siblings such as kb_query and kb_search. An agent can identify the tool's function without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit workflow guidance: validate intent, prefer dryRun:true first, use kb_model before hand-writing strict property or predicate facts, and use the relationships array for batch links. It also gives update semantics and a concrete supersede procedure, including the follow-up status change required by kb_check. These are clear when-to-use, when-not-to-use, and alternative-tool instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.7kb_check2 fields changedInput schema / properties / rules / descriptionPrevious value: -"Optional rule subset. Allowed: must-priority-coverage, symbol-coverage, symbol-traceability, symbol-granularity, no-dangling-refs, source-relationship-parity, branch-store-not-compiled, source-path-dangling, no-cycles, required-fields, deprecated-adr-no-successor, superseded-requirement-open, scenario-feasibility, scenario-feasibility-unknown, scenario-outcome-mismatch, exception-claim-keys, numeric-string-value, rule-key-arguments-missing, domain-contradictions, logic-coverage, rule-safety, rule-verifiability, query-plan-safety, req-status-vocabulary, strict-fact-shape, strict-req-fact-pairing, predicate-verifiability, strict-readiness, semantic-completeness, related-requirement-unmodeled, proof-contract-symbols, entity-id-style, domain-redundancy, domain-implication, subject-key-identity, subject-key-shape, ontology-quality, exception-unapproved, exception-approval-self-attested, agent-requirement-unapproved, requirement-rationale-missing, symbol-owner-superseded, adr-unlinked, adr-proposed, predicate-schema-conformance, entity-context-missing, entity-context-acknowledged, decision-firm-unreferenced, decision-firm-superseded, decision-firm-edited, supersedes-reason-missing, supersedes-reason-acknowledged, policy-ownership, policy-markers, kb-consistency, kb-consistency-unresolved, evidence-floor, proof-contract-claims. If omitted, server runs canonical and advisory rules plus the full-KB qualityDiagnostics audit scan, including usage telemetry acceptance when evidence exists; migration rules run only when explicitly selected. Advisory and migration findings are non-blocking qualityDiagnostics. If supplied, server preserves scoped validation and skips the full-KB advisory scan."New value: +"Optional rule subset. Allowed: must-priority-coverage, symbol-coverage, symbol-traceability, symbol-granularity, symbol-coordinates-missing, no-dangling-refs, source-relationship-parity, branch-store-not-compiled, source-path-dangling, no-cycles, required-fields, deprecated-adr-no-successor, superseded-requirement-open, scenario-feasibility, scenario-feasibility-unknown, scenario-outcome-mismatch, exception-claim-keys, numeric-string-value, rule-key-arguments-missing, domain-contradictions, logic-coverage, rule-safety, rule-verifiability, query-plan-safety, req-status-vocabulary, strict-fact-shape, strict-req-fact-pairing, predicate-verifiability, strict-readiness, semantic-completeness, related-requirement-unmodeled, proof-contract-symbols, entity-id-style, domain-redundancy, domain-implication, subject-key-identity, subject-key-shape, ontology-quality, exception-unapproved, exception-approval-self-attested, agent-requirement-unapproved, requirement-rationale-missing, symbol-owner-superseded, adr-unlinked, adr-proposed, predicate-schema-conformance, entity-context-missing, entity-context-acknowledged, decision-firm-unreferenced, decision-firm-superseded, decision-firm-edited, supersedes-reason-missing, supersedes-reason-acknowledged, policy-ownership, policy-markers, kb-consistency, kb-consistency-unresolved, evidence-floor, proof-contract-claims. If omitted, server runs canonical and advisory rules plus the full-KB qualityDiagnostics audit scan, including usage telemetry acceptance when evidence exists; migration rules run only when explicitly selected. Advisory and migration findings are non-blocking qualityDiagnostics. If supplied, server preserves scoped validation and skips the full-KB advisory scan."Input schema / properties / rules / items / anyOfPrevious value: -[
- {
- "const": "must-priority-coverage",
- "type": "string"
- },
- {
- "const": "symbol-coverage",
- "type": "string"
- },
- {
- "const": "symbol-traceability",
- "type": "string"
- },
- {
- "const": "symbol-granularity",
- "type": "string"
- },
- {
- "const": "no-dangling-refs",
- "type": "string"
- },
- {
- "const": "source-relationship-parity",
- "type": "string"
- },
- {
- "const": "branch-store-not-compiled",
- "type": "string"
- },
- {
- "const": "source-path-dangling",
- "type": "string"
- },
- {
- "const": "no-cycles",
- "type": "string"
- },
- {
- "const": "required-fields",
- "type": "string"
- },
- {
- "const": "deprecated-adr-no-successor",
- "type": "string"
- },
- {
- "const": "superseded-requirement-open",
- "type": "string"
- },
- {
- "const": "scenario-feasibility",
- "type": "string"
- },
- {
- "const": "scenario-feasibility-unknown",
- "type": "string"
- },
- {
- "const": "scenario-outcome-mismatch",
- "type": "string"
- },
- {
- "const": "exception-claim-keys",
- "type": "string"
- },
- {
- "const": "numeric-string-value",
- "type": "string"
- },
- {
- "const": "rule-key-arguments-missing",
- "type": "string"
- },
- {
- "const": "domain-contradictions",
- "type": "string"
- },
- {
- "const": "logic-coverage",
- "type": "string"
- },
- {
- "const": "rule-safety",
- "type": "string"
- },
- {
- "const": "rule-verifiability",
- "type": "string"
- },
- {
- "const": "query-plan-safety",
- "type": "string"
- },
- {
- "const": "req-status-vocabulary",
- "type": "string"
- },
- {
- "const": "strict-fact-shape",
- "type": "string"
- },
- {
- "const": "strict-req-fact-pairing",
- "type": "string"
- },
- {
- "const": "predicate-verifiability",
- "type": "string"
- },
- {
- "const": "strict-readiness",
- "type": "string"
- },
- {
- "const": "semantic-completeness",
- "type": "string"
- },
- {
- "const": "related-requirement-unmodeled",
- "type": "string"
- },
- {
- "const": "proof-contract-symbols",
- "type": "string"
- },
- {
- "const": "entity-id-style",
- "type": "string"
- },
- {
- "const": "domain-redundancy",
- "type": "string"
- },
- {
- "const": "domain-implication",
- "type": "string"
- },
- {
- "const": "subject-key-identity",
- "type": "string"
- },
- {
- "const": "subject-key-shape",
- "type": "string"
- },
- {
- "const": "ontology-quality",
- "type": "string"
- },
- {
- "const": "exception-unapproved",
- "type": "string"
- },
- {
- "const": "exception-approval-self-attested",
- "type": "string"
- },
- {
- "const": "agent-requirement-unapproved",
- "type": "string"
- },
- {
- "const": "requirement-rationale-missing",
- "type": "string"
- },
- {
- "const": "symbol-owner-superseded",
- "type": "string"
- },
- {
- "const": "adr-unlinked",
- "type": "string"
- },
- {
- "const": "adr-proposed",
- "type": "string"
- },
- {
- "const": "predicate-schema-conformance",
- "type": "string"
- },
- {
- "const": "entity-context-missing",
- "type": "string"
- },
- {
- "const": "entity-context-acknowledged",
- "type": "string"
- },
- {
- "const": "decision-firm-unreferenced",
- "type": "string"
- },
- {
- "const": "decision-firm-superseded",
- "type": "string"
- },
- {
- "const": "decision-firm-edited",
- "type": "string"
- },
- {
- "const": "supersedes-reason-missing",
- "type": "string"
- },
- {
- "const": "supersedes-reason-acknowledged",
- "type": "string"
- },
- {
- "const": "policy-ownership",
- "type": "string"
- },
- {
- "const": "policy-markers",
- "type": "string"
- },
- {
- "const": "kb-consistency",
- "type": "string"
- },
- {
- "const": "kb-consistency-unresolved",
- "type": "string"
- },
- {
- "const": "evidence-floor",
- "type": "string"
- },
- {
- "const": "proof-contract-claims",
- "type": "string"
- }
-]New value: +[
+ {
+ "const": "must-priority-coverage",
+ "type": "string"
+ },
+ {
+ "const": "symbol-coverage",
+ "type": "string"
+ },
+ {
+ "const": "symbol-traceability",
+ "type": "string"
+ },
+ {
+ "const": "symbol-granularity",
+ "type": "string"
+ },
+ {
+ "const": "symbol-coordinates-missing",
+ "type": "string"
+ },
+ {
+ "const": "no-dangling-refs",
+ "type": "string"
+ },
+ {
+ "const": "source-relationship-parity",
+ "type": "string"
+ },
+ {
+ "const": "branch-store-not-compiled",
+ "type": "string"
+ },
+ {
+ "const": "source-path-dangling",
+ "type": "string"
+ },
+ {
+ "const": "no-cycles",
+ "type": "string"
+ },
+ {
+ "const": "required-fields",
+ "type": "string"
+ },
+ {
+ "const": "deprecated-adr-no-successor",
+ "type": "string"
+ },
+ {
+ "const": "superseded-requirement-open",
+ "type": "string"
+ },
+ {
+ "const": "scenario-feasibility",
+ "type": "string"
+ },
+ {
+ "const": "scenario-feasibility-unknown",
+ "type": "string"
+ },
+ {
+ "const": "scenario-outcome-mismatch",
+ "type": "string"
+ },
+ {
+ "const": "exception-claim-keys",
+ "type": "string"
+ },
+ {
+ "const": "numeric-string-value",
+ "type": "string"
+ },
+ {
+ "const": "rule-key-arguments-missing",
+ "type": "string"
+ },
+ {
+ "const": "domain-contradictions",
+ "type": "string"
+ },
+ {
+ "const": "logic-coverage",
+ "type": "string"
+ },
+ {
+ "const": "rule-safety",
+ "type": "string"
+ },
+ {
+ "const": "rule-verifiability",
+ "type": "string"
+ },
+ {
+ "const": "query-plan-safety",
+ "type": "string"
+ },
+ {
+ "const": "req-status-vocabulary",
+ "type": "string"
+ },
+ {
+ "const": "strict-fact-shape",
+ "type": "string"
+ },
+ {
+ "const": "strict-req-fact-pairing",
+ "type": "string"
+ },
+ {
+ "const": "predicate-verifiability",
+ "type": "string"
+ },
+ {
+ "const": "strict-readiness",
+ "type": "string"
+ },
+ {
+ "const": "semantic-completeness",
+ "type": "string"
+ },
+ {
+ "const": "related-requirement-unmodeled",
+ "type": "string"
+ },
+ {
+ "const": "proof-contract-symbols",
+ "type": "string"
+ },
+ {
+ "const": "entity-id-style",
+ "type": "string"
+ },
+ {
+ "const": "domain-redundancy",
+ "type": "string"
+ },
+ {
+ "const": "domain-implication",
+ "type": "string"
+ },
+ {
+ "const": "subject-key-identity",
+ "type": "string"
+ },
+ {
+ "const": "subject-key-shape",
+ "type": "string"
+ },
+ {
+ "const": "ontology-quality",
+ "type": "string"
+ },
+ {
+ "const": "exception-unapproved",
+ "type": "string"
+ },
+ {
+ "const": "exception-approval-self-attested",
+ "type": "string"
+ },
+ {
+ "const": "agent-requirement-unapproved",
+ "type": "string"
+ },
+ {
+ "const": "requirement-rationale-missing",
+ "type": "string"
+ },
+ {
+ "const": "symbol-owner-superseded",
+ "type": "string"
+ },
+ {
+ "const": "adr-unlinked",
+ "type": "string"
+ },
+ {
+ "const": "adr-proposed",
+ "type": "string"
+ },
+ {
+ "const": "predicate-schema-conformance",
+ "type": "string"
+ },
+ {
+ "const": "entity-context-missing",
+ "type": "string"
+ },
+ {
+ "const": "entity-context-acknowledged",
+ "type": "string"
+ },
+ {
+ "const": "decision-firm-unreferenced",
+ "type": "string"
+ },
+ {
+ "const": "decision-firm-superseded",
+ "type": "string"
+ },
+ {
+ "const": "decision-firm-edited",
+ "type": "string"
+ },
+ {
+ "const": "supersedes-reason-missing",
+ "type": "string"
+ },
+ {
+ "const": "supersedes-reason-acknowledged",
+ "type": "string"
+ },
+ {
+ "const": "policy-ownership",
+ "type": "string"
+ },
+ {
+ "const": "policy-markers",
+ "type": "string"
+ },
+ {
+ "const": "kb-consistency",
+ "type": "string"
+ },
+ {
+ "const": "kb-consistency-unresolved",
+ "type": "string"
+ },
+ {
+ "const": "evidence-floor",
+ "type": "string"
+ },
+ {
+ "const": "proof-contract-claims",
+ "type": "string"
+ }
+]kb_upsert9 fields changedInput schema / properties / properties / properties / proof_contract / properties / domain_source / properties / argAdded value: +{
+ "description": "A SWI-Prolog predicate's argument (1-based) whose solutions Kibi reads, when the predicate takes more than one argument (operator/2 with arg 1 lists each operator's name).",
+ "maximum": 9007199254740991,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / properties / properties / proof_contract / properties / initial_source / properties / argAdded value: +{
+ "description": "A SWI-Prolog predicate's argument (1-based) whose solutions Kibi reads, when the predicate takes more than one argument (operator/2 with arg 1 lists each operator's name).",
+ "maximum": 9007199254740991,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / properties / properties / proof_contract / properties / pattern_source / properties / argAdded value: +{
+ "description": "A SWI-Prolog predicate's argument (1-based) whose solutions Kibi reads, when the predicate takes more than one argument (operator/2 with arg 1 lists each operator's name).",
+ "maximum": 9007199254740991,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / properties / properties / proof_contract / properties / source / descriptionPrevious value: -"source: the project source a source proof reads. A project source Kibi reads by itself. reader json or yaml: {file, path?, select?: keys|values|items}. glob: {pattern, capture?, ignore?} (capture true reads what each * matched). openapi: {file, select?: operations|unsecured_operations|security_schemes|responses}. references: {files, extract: env|imports|calls|string_args|thrown|property, callee?, key?, ignore?}. schema: {format: drizzle|prisma|sql, file (drizzle, prisma) or files (sql migrations), exports?, table?, select?: tables|columns|required_columns|nullable_columns|foreign_keys}. routes: {file, export, framework?: hono|express, path_prefix?, names_from?, select?: routes|middleware}. validator: {file, export, select?: fields|required_fields|optional_fields}. Paths are repository-relative. A member Kibi cannot read statically fails the read with its location."New value: +"source: the project source a source proof reads. A project source Kibi reads by itself. reader json or yaml: {file, path?, select?: keys|values|items}. glob: {pattern, capture?, ignore?} (capture true reads what each * matched). openapi: {file, select?: operations|unsecured_operations|security_schemes|responses}. references: {files, extract: env|imports|calls|string_args|thrown|property, callee?, key?, ignore?} over TypeScript, JavaScript, Python and SWI-Prolog files. schema: {format: drizzle|prisma|sql, file (drizzle, prisma) or files (sql migrations), exports?, table?, select?: tables|columns|required_columns|nullable_columns|foreign_keys}. routes: {file, export, framework?: hono|express, path_prefix?, names_from?, select?: routes|middleware}. validator: {file, export, select?: fields|required_fields|optional_fields}. prolog: {file, functor: Name/Arity, arg?} reads one argument of every fact with that functor in a SWI-Prolog file (requires/1 in pack.pl), without running it. Paths are repository-relative. A member Kibi cannot read statically fails the read with its location."Input schema / properties / properties / properties / proof_contract / properties / source / properties / reader / anyOfPrevious value: -[
- {
- "const": "json",
- "type": "string"
- },
- {
- "const": "yaml",
- "type": "string"
- },
- {
- "const": "glob",
- "type": "string"
- },
- {
- "const": "openapi",
- "type": "string"
- },
- {
- "const": "references",
- "type": "string"
- },
- {
- "const": "schema",
- "type": "string"
- },
- {
- "const": "routes",
- "type": "string"
- },
- {
- "const": "validator",
- "type": "string"
- }
-]New value: +[
+ {
+ "const": "json",
+ "type": "string"
+ },
+ {
+ "const": "yaml",
+ "type": "string"
+ },
+ {
+ "const": "glob",
+ "type": "string"
+ },
+ {
+ "const": "openapi",
+ "type": "string"
+ },
+ {
+ "const": "references",
+ "type": "string"
+ },
+ {
+ "const": "schema",
+ "type": "string"
+ },
+ {
+ "const": "routes",
+ "type": "string"
+ },
+ {
+ "const": "validator",
+ "type": "string"
+ },
+ {
+ "const": "prolog",
+ "type": "string"
+ }
+]Input schema / properties / properties / properties / proof_contract / properties / value_source / items / properties / argAdded value: +{
+ "description": "A SWI-Prolog predicate's argument (1-based) whose solutions Kibi reads, when the predicate takes more than one argument (operator/2 with arg 1 lists each operator's name).",
+ "maximum": 9007199254740991,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / properties / properties / proof_contract / properties / value_source / items / properties / source / descriptionPrevious value: -"A project source Kibi reads by itself. reader json or yaml: {file, path?, select?: keys|values|items}. glob: {pattern, capture?, ignore?} (capture true reads what each * matched). openapi: {file, select?: operations|unsecured_operations|security_schemes|responses}. references: {files, extract: env|imports|calls|string_args|thrown|property, callee?, key?, ignore?}. schema: {format: drizzle|prisma|sql, file (drizzle, prisma) or files (sql migrations), exports?, table?, select?: tables|columns|required_columns|nullable_columns|foreign_keys}. routes: {file, export, framework?: hono|express, path_prefix?, names_from?, select?: routes|middleware}. validator: {file, export, select?: fields|required_fields|optional_fields}. Paths are repository-relative. A member Kibi cannot read statically fails the read with its location."New value: +"A project source Kibi reads by itself. reader json or yaml: {file, path?, select?: keys|values|items}. glob: {pattern, capture?, ignore?} (capture true reads what each * matched). openapi: {file, select?: operations|unsecured_operations|security_schemes|responses}. references: {files, extract: env|imports|calls|string_args|thrown|property, callee?, key?, ignore?} over TypeScript, JavaScript, Python and SWI-Prolog files. schema: {format: drizzle|prisma|sql, file (drizzle, prisma) or files (sql migrations), exports?, table?, select?: tables|columns|required_columns|nullable_columns|foreign_keys}. routes: {file, export, framework?: hono|express, path_prefix?, names_from?, select?: routes|middleware}. validator: {file, export, select?: fields|required_fields|optional_fields}. prolog: {file, functor: Name/Arity, arg?} reads one argument of every fact with that functor in a SWI-Prolog file (requires/1 in pack.pl), without running it. Paths are repository-relative. A member Kibi cannot read statically fails the read with its location."Input schema / properties / properties / properties / proof_contract / properties / value_source / items / properties / source / properties / reader / anyOfPrevious value: -[
- {
- "const": "json",
- "type": "string"
- },
- {
- "const": "yaml",
- "type": "string"
- },
- {
- "const": "glob",
- "type": "string"
- },
- {
- "const": "openapi",
- "type": "string"
- },
- {
- "const": "references",
- "type": "string"
- },
- {
- "const": "schema",
- "type": "string"
- },
- {
- "const": "routes",
- "type": "string"
- },
- {
- "const": "validator",
- "type": "string"
- }
-]New value: +[
+ {
+ "const": "json",
+ "type": "string"
+ },
+ {
+ "const": "yaml",
+ "type": "string"
+ },
+ {
+ "const": "glob",
+ "type": "string"
+ },
+ {
+ "const": "openapi",
+ "type": "string"
+ },
+ {
+ "const": "references",
+ "type": "string"
+ },
+ {
+ "const": "schema",
+ "type": "string"
+ },
+ {
+ "const": "routes",
+ "type": "string"
+ },
+ {
+ "const": "validator",
+ "type": "string"
+ },
+ {
+ "const": "prolog",
+ "type": "string"
+ }
+]Output schema / properties / data / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "claimKey": {
- "description": "For a fact with claim_text: the stored claim_key, derived from claim_text when the payload did not supply it.",
- "type": "string"
- },
- "contradictionCheck": {
- "additionalProperties": {},
- "properties": {},
- "type": "object"
- },
- "created": {
- "maximum": 9007199254740991,
- "minimum": -9007199254740991,
- "type": "integer"
- },
- "effectFailures": {
- "items": {
- "additionalProperties": {},
- "properties": {},
- "type": "object"
- },
- "type": "array"
- },
- "nextActions": {
- "items": {
- "additionalProperties": {},
- "properties": {},
- "type": "object"
- },
- "type": "array"
- },
- "relationships_created": {
- "maximum": 9007199254740991,
- "minimum": -9007199254740991,
- "type": "integer"
- },
- "semanticAdvisor": {
- "additionalProperties": {},
- "properties": {},
- "type": "object"
- },
- "sourceWrites": {
- "items": {
- "additionalProperties": {},
- "properties": {},
- "type": "object"
- },
- "type": "array"
- },
- "status": {
- "type": "string"
- },
- "updated": {
- "maximum": 9007199254740991,
- "minimum": -9007199254740991,
- "type": "integer"
- },
- "warnings": {
- "items": {},
- "type": "array"
- }
- },
- "type": "object"
- },
- {
- "additionalProperties": false,
- "properties": {
- "dryRun": {
- "const": true,
- "type": "boolean"
- },
- "errorCode": {
- "type": "string"
- },
- "errors": {
- "items": {},
- "type": "array"
- },
- "normalizedPreview": {
- "anyOf": [
- {
- "additionalProperties": {},
- "properties": {},
- "type": "object"
- },
- {
- "type": "null"
- }
- ]
- },
- "semanticAdvisor": {
- "anyOf": [
- {
- "additionalProperties": {},
- "properties": {},
- "type": "object"
- },
- {
- "type": "null"
- }
- ]
- },
- "skippedEffects": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "stagedFacts": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "valid": {
- "type": "boolean"
- },
- "warnings": {
- "items": {},
- "type": "array"
- },
- "whatIf": {
- "additionalProperties": {},
- "properties": {},
- "type": "object"
- }
- },
- "required": [
- "valid",
- "dryRun",
- "skippedEffects"
- ],
- "type": "object"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "claimKey": {
+ "description": "For a fact with claim_text: the stored claim_key, derived from claim_text when the payload did not supply it.",
+ "type": "string"
+ },
+ "contradictionCheck": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "created": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "effectFailures": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "nextActions": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "relationships_created": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "semanticAdvisor": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "sourceWrites": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "status": {
+ "type": "string"
+ },
+ "updated": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "warnings": {
+ "items": {},
+ "type": "array"
+ }
+ },
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "dryRun": {
+ "const": true,
+ "type": "boolean"
+ },
+ "errorCode": {
+ "type": "string"
+ },
+ "errors": {
+ "items": {},
+ "type": "array"
+ },
+ "normalizedPreview": {
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "rejection": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "semanticAdvisor": {
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "skippedEffects": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "stagedFacts": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "valid": {
+ "type": "boolean"
+ },
+ "warnings": {
+ "items": {},
+ "type": "array"
+ },
+ "whatIf": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ }
+ },
+ "required": [
+ "valid",
+ "dryRun",
+ "skippedEffects"
+ ],
+ "type": "object"
+ }
+]v0.1.6kb_check2 fields changedInput schema / properties / rules / descriptionPrevious value: -"Optional rule subset. Allowed: must-priority-coverage, symbol-coverage, symbol-traceability, symbol-granularity, no-dangling-refs, source-relationship-parity, branch-store-not-compiled, source-path-dangling, no-cycles, required-fields, deprecated-adr-no-successor, superseded-requirement-open, scenario-feasibility, scenario-feasibility-unknown, exception-claim-keys, numeric-string-value, rule-key-arguments-missing, domain-contradictions, logic-coverage, rule-safety, rule-verifiability, query-plan-safety, req-status-vocabulary, strict-fact-shape, strict-req-fact-pairing, predicate-verifiability, strict-readiness, semantic-completeness, related-requirement-unmodeled, proof-contract-symbols, entity-id-style, domain-redundancy, domain-implication, subject-key-identity, subject-key-shape, ontology-quality, exception-unapproved, exception-approval-self-attested, agent-requirement-unapproved, requirement-rationale-missing, symbol-owner-superseded, adr-unlinked, adr-proposed, predicate-schema-conformance, entity-context-missing, entity-context-acknowledged, decision-firm-unreferenced, decision-firm-superseded, decision-firm-edited, supersedes-reason-missing, supersedes-reason-acknowledged, policy-ownership, policy-markers, kb-consistency, kb-consistency-unresolved, evidence-floor, proof-contract-claims. If omitted, server runs canonical and advisory rules plus the full-KB qualityDiagnostics audit scan, including usage telemetry acceptance when evidence exists; migration rules run only when explicitly selected. Advisory and migration findings are non-blocking qualityDiagnostics. If supplied, server preserves scoped validation and skips the full-KB advisory scan."New value: +"Optional rule subset. Allowed: must-priority-coverage, symbol-coverage, symbol-traceability, symbol-granularity, no-dangling-refs, source-relationship-parity, branch-store-not-compiled, source-path-dangling, no-cycles, required-fields, deprecated-adr-no-successor, superseded-requirement-open, scenario-feasibility, scenario-feasibility-unknown, scenario-outcome-mismatch, exception-claim-keys, numeric-string-value, rule-key-arguments-missing, domain-contradictions, logic-coverage, rule-safety, rule-verifiability, query-plan-safety, req-status-vocabulary, strict-fact-shape, strict-req-fact-pairing, predicate-verifiability, strict-readiness, semantic-completeness, related-requirement-unmodeled, proof-contract-symbols, entity-id-style, domain-redundancy, domain-implication, subject-key-identity, subject-key-shape, ontology-quality, exception-unapproved, exception-approval-self-attested, agent-requirement-unapproved, requirement-rationale-missing, symbol-owner-superseded, adr-unlinked, adr-proposed, predicate-schema-conformance, entity-context-missing, entity-context-acknowledged, decision-firm-unreferenced, decision-firm-superseded, decision-firm-edited, supersedes-reason-missing, supersedes-reason-acknowledged, policy-ownership, policy-markers, kb-consistency, kb-consistency-unresolved, evidence-floor, proof-contract-claims. If omitted, server runs canonical and advisory rules plus the full-KB qualityDiagnostics audit scan, including usage telemetry acceptance when evidence exists; migration rules run only when explicitly selected. Advisory and migration findings are non-blocking qualityDiagnostics. If supplied, server preserves scoped validation and skips the full-KB advisory scan."Input schema / properties / rules / items / anyOfPrevious value: -[
- {
- "const": "must-priority-coverage",
- "type": "string"
- },
- {
- "const": "symbol-coverage",
- "type": "string"
- },
- {
- "const": "symbol-traceability",
- "type": "string"
- },
- {
- "const": "symbol-granularity",
- "type": "string"
- },
- {
- "const": "no-dangling-refs",
- "type": "string"
- },
- {
- "const": "source-relationship-parity",
- "type": "string"
- },
- {
- "const": "branch-store-not-compiled",
- "type": "string"
- },
- {
- "const": "source-path-dangling",
- "type": "string"
- },
- {
- "const": "no-cycles",
- "type": "string"
- },
- {
- "const": "required-fields",
- "type": "string"
- },
- {
- "const": "deprecated-adr-no-successor",
- "type": "string"
- },
- {
- "const": "superseded-requirement-open",
- "type": "string"
- },
- {
- "const": "scenario-feasibility",
- "type": "string"
- },
- {
- "const": "scenario-feasibility-unknown",
- "type": "string"
- },
- {
- "const": "exception-claim-keys",
- "type": "string"
- },
- {
- "const": "numeric-string-value",
- "type": "string"
- },
- {
- "const": "rule-key-arguments-missing",
- "type": "string"
- },
- {
- "const": "domain-contradictions",
- "type": "string"
- },
- {
- "const": "logic-coverage",
- "type": "string"
- },
- {
- "const": "rule-safety",
- "type": "string"
- },
- {
- "const": "rule-verifiability",
- "type": "string"
- },
- {
- "const": "query-plan-safety",
- "type": "string"
- },
- {
- "const": "req-status-vocabulary",
- "type": "string"
- },
- {
- "const": "strict-fact-shape",
- "type": "string"
- },
- {
- "const": "strict-req-fact-pairing",
- "type": "string"
- },
- {
- "const": "predicate-verifiability",
- "type": "string"
- },
- {
- "const": "strict-readiness",
- "type": "string"
- },
- {
- "const": "semantic-completeness",
- "type": "string"
- },
- {
- "const": "related-requirement-unmodeled",
- "type": "string"
- },
- {
- "const": "proof-contract-symbols",
- "type": "string"
- },
- {
- "const": "entity-id-style",
- "type": "string"
- },
- {
- "const": "domain-redundancy",
- "type": "string"
- },
- {
- "const": "domain-implication",
- "type": "string"
- },
- {
- "const": "subject-key-identity",
- "type": "string"
- },
- {
- "const": "subject-key-shape",
- "type": "string"
- },
- {
- "const": "ontology-quality",
- "type": "string"
- },
- {
- "const": "exception-unapproved",
- "type": "string"
- },
- {
- "const": "exception-approval-self-attested",
- "type": "string"
- },
- {
- "const": "agent-requirement-unapproved",
- "type": "string"
- },
- {
- "const": "requirement-rationale-missing",
- "type": "string"
- },
- {
- "const": "symbol-owner-superseded",
- "type": "string"
- },
- {
- "const": "adr-unlinked",
- "type": "string"
- },
- {
- "const": "adr-proposed",
- "type": "string"
- },
- {
- "const": "predicate-schema-conformance",
- "type": "string"
- },
- {
- "const": "entity-context-missing",
- "type": "string"
- },
- {
- "const": "entity-context-acknowledged",
- "type": "string"
- },
- {
- "const": "decision-firm-unreferenced",
- "type": "string"
- },
- {
- "const": "decision-firm-superseded",
- "type": "string"
- },
- {
- "const": "decision-firm-edited",
- "type": "string"
- },
- {
- "const": "supersedes-reason-missing",
- "type": "string"
- },
- {
- "const": "supersedes-reason-acknowledged",
- "type": "string"
- },
- {
- "const": "policy-ownership",
- "type": "string"
- },
- {
- "const": "policy-markers",
- "type": "string"
- },
- {
- "const": "kb-consistency",
- "type": "string"
- },
- {
- "const": "kb-consistency-unresolved",
- "type": "string"
- },
- {
- "const": "evidence-floor",
- "type": "string"
- },
- {
- "const": "proof-contract-claims",
- "type": "string"
- }
-]New value: +[
+ {
+ "const": "must-priority-coverage",
+ "type": "string"
+ },
+ {
+ "const": "symbol-coverage",
+ "type": "string"
+ },
+ {
+ "const": "symbol-traceability",
+ "type": "string"
+ },
+ {
+ "const": "symbol-granularity",
+ "type": "string"
+ },
+ {
+ "const": "no-dangling-refs",
+ "type": "string"
+ },
+ {
+ "const": "source-relationship-parity",
+ "type": "string"
+ },
+ {
+ "const": "branch-store-not-compiled",
+ "type": "string"
+ },
+ {
+ "const": "source-path-dangling",
+ "type": "string"
+ },
+ {
+ "const": "no-cycles",
+ "type": "string"
+ },
+ {
+ "const": "required-fields",
+ "type": "string"
+ },
+ {
+ "const": "deprecated-adr-no-successor",
+ "type": "string"
+ },
+ {
+ "const": "superseded-requirement-open",
+ "type": "string"
+ },
+ {
+ "const": "scenario-feasibility",
+ "type": "string"
+ },
+ {
+ "const": "scenario-feasibility-unknown",
+ "type": "string"
+ },
+ {
+ "const": "scenario-outcome-mismatch",
+ "type": "string"
+ },
+ {
+ "const": "exception-claim-keys",
+ "type": "string"
+ },
+ {
+ "const": "numeric-string-value",
+ "type": "string"
+ },
+ {
+ "const": "rule-key-arguments-missing",
+ "type": "string"
+ },
+ {
+ "const": "domain-contradictions",
+ "type": "string"
+ },
+ {
+ "const": "logic-coverage",
+ "type": "string"
+ },
+ {
+ "const": "rule-safety",
+ "type": "string"
+ },
+ {
+ "const": "rule-verifiability",
+ "type": "string"
+ },
+ {
+ "const": "query-plan-safety",
+ "type": "string"
+ },
+ {
+ "const": "req-status-vocabulary",
+ "type": "string"
+ },
+ {
+ "const": "strict-fact-shape",
+ "type": "string"
+ },
+ {
+ "const": "strict-req-fact-pairing",
+ "type": "string"
+ },
+ {
+ "const": "predicate-verifiability",
+ "type": "string"
+ },
+ {
+ "const": "strict-readiness",
+ "type": "string"
+ },
+ {
+ "const": "semantic-completeness",
+ "type": "string"
+ },
+ {
+ "const": "related-requirement-unmodeled",
+ "type": "string"
+ },
+ {
+ "const": "proof-contract-symbols",
+ "type": "string"
+ },
+ {
+ "const": "entity-id-style",
+ "type": "string"
+ },
+ {
+ "const": "domain-redundancy",
+ "type": "string"
+ },
+ {
+ "const": "domain-implication",
+ "type": "string"
+ },
+ {
+ "const": "subject-key-identity",
+ "type": "string"
+ },
+ {
+ "const": "subject-key-shape",
+ "type": "string"
+ },
+ {
+ "const": "ontology-quality",
+ "type": "string"
+ },
+ {
+ "const": "exception-unapproved",
+ "type": "string"
+ },
+ {
+ "const": "exception-approval-self-attested",
+ "type": "string"
+ },
+ {
+ "const": "agent-requirement-unapproved",
+ "type": "string"
+ },
+ {
+ "const": "requirement-rationale-missing",
+ "type": "string"
+ },
+ {
+ "const": "symbol-owner-superseded",
+ "type": "string"
+ },
+ {
+ "const": "adr-unlinked",
+ "type": "string"
+ },
+ {
+ "const": "adr-proposed",
+ "type": "string"
+ },
+ {
+ "const": "predicate-schema-conformance",
+ "type": "string"
+ },
+ {
+ "const": "entity-context-missing",
+ "type": "string"
+ },
+ {
+ "const": "entity-context-acknowledged",
+ "type": "string"
+ },
+ {
+ "const": "decision-firm-unreferenced",
+ "type": "string"
+ },
+ {
+ "const": "decision-firm-superseded",
+ "type": "string"
+ },
+ {
+ "const": "decision-firm-edited",
+ "type": "string"
+ },
+ {
+ "const": "supersedes-reason-missing",
+ "type": "string"
+ },
+ {
+ "const": "supersedes-reason-acknowledged",
+ "type": "string"
+ },
+ {
+ "const": "policy-ownership",
+ "type": "string"
+ },
+ {
+ "const": "policy-markers",
+ "type": "string"
+ },
+ {
+ "const": "kb-consistency",
+ "type": "string"
+ },
+ {
+ "const": "kb-consistency-unresolved",
+ "type": "string"
+ },
+ {
+ "const": "evidence-floor",
+ "type": "string"
+ },
+ {
+ "const": "proof-contract-claims",
+ "type": "string"
+ }
+]kb_search2 fields changedInput schema / properties / hintsAdded value: +{
+ "description": "Intent-v1 only, first page only. When true (default) and the project activates a kibi.search-hints.v1 plugin, a weak or abstained answer adds queryAnalysis.hints: requirements the question may mean, to re-ask with. Hints never change results or the answer layer.",
+ "type": "boolean"
+}Input schema / properties / semanticFacets / descriptionPrevious value: -"Optional host-agent semantic interpretation. Kibi uses these strings as deterministic aliases/facets; it does not call a model itself."New value: +"Optional host-agent semantic interpretation. Kibi uses these strings as deterministic aliases/facets; ranking never calls a model."kb_upsert8 fields changedInput schema / properties / properties / properties / case_waiverAdded value: +{
+ "description": "Fact-only. Why the edge cases derived from this fact are covered some other way or cannot occur. Waives uncovered_case once case_waiver_approved_by is set.",
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / properties / properties / case_waiver_approved_byAdded value: +{
+ "description": "Fact-only. The person who accepted case_waiver.",
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / properties / properties / dimension_waiverAdded value: +{
+ "description": "Fact-only. Why the quantifier word in claim_text ranges over nothing, so the claim needs no count, set or rule. Waives dimension_unrepresented once dimension_waiver_approved_by is set.",
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / properties / properties / dimension_waiver_approved_byAdded value: +{
+ "description": "Fact-only. The person who accepted dimension_waiver.",
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / properties / properties / failure_side_waiverAdded value: +{
+ "description": "Requirement-only. Why the requirement has no failure side to test (its claims state a capability or output shape). Waives happy_path_only once failure_side_waiver_approved_by is set.",
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / properties / properties / failure_side_waiver_approved_byAdded value: +{
+ "description": "Requirement-only. The person who accepted failure_side_waiver.",
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / properties / properties / proof_contract / properties / domain_source / properties / fieldAdded value: +{
+ "description": "exhaustive: when the export is a list of records, the field of each record that names a domain member (a catalog's name).",
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / properties / properties / proof_contract / properties / value_source / descriptionPrevious value: -"arithmetic and smt: code constants the assumptions read. Kibi evaluates each export at ingest and requires the certificate to assume the variable equals that value, so the proof is about the code and not only the knowledge base. With measure count the value is the size of a list, set, map or object export, so a count claim reads the collection itself. An entry {source, measure: count} counts the members Kibi reads from a project source (routes, tables, environment variables)."New value: +"arithmetic and smt: code constants the assumptions read. Kibi evaluates each export at ingest and requires the certificate to assume the variable equals that value, so the proof is about the code and not only the knowledge base. With measure count the value is the size of a list, set, map or object export, so a count claim reads the collection itself. A dotted export (POLICY.eventLimit) reads one field of an object export. An entry {source, measure: count} counts the members Kibi reads from a project source (routes, tables, environment variables)."v0.1.5kb_model4 fields changedInput schema / properties / operator / anyOfPrevious value: -[
- {
- "const": "eq",
- "type": "string"
- },
- {
- "const": "gt",
- "type": "string"
- },
- {
- "const": "gte",
- "type": "string"
- },
- {
- "const": "lt",
- "type": "string"
- },
- {
- "const": "lte",
- "type": "string"
- },
- {
- "const": "neq",
- "type": "string"
- },
- {
- "const": "bool",
- "type": "string"
- },
- {
- "const": "polarity",
- "type": "string"
- }
-]New value: +[
+ {
+ "const": "eq",
+ "type": "string"
+ },
+ {
+ "const": "gt",
+ "type": "string"
+ },
+ {
+ "const": "gte",
+ "type": "string"
+ },
+ {
+ "const": "lt",
+ "type": "string"
+ },
+ {
+ "const": "lte",
+ "type": "string"
+ },
+ {
+ "const": "neq",
+ "type": "string"
+ },
+ {
+ "const": "bool",
+ "type": "string"
+ },
+ {
+ "const": "polarity",
+ "type": "string"
+ },
+ {
+ "const": "matches",
+ "type": "string"
+ },
+ {
+ "const": "includes",
+ "type": "string"
+ },
+ {
+ "const": "subset_of",
+ "type": "string"
+ },
+ {
+ "const": "excludes",
+ "type": "string"
+ }
+]Input schema / properties / operator / descriptionPrevious value: -"Optional extracted semantic claim operator. Use gt/lt for strict bounds ('greater than zero' is gt 0, not gte 0). Example: 'eq'."New value: +"Optional extracted semantic claim operator. Use gt/lt for strict bounds ('greater than zero' is gt 0, not gte 0). A set claim takes a list value with eq (exactly these), includes (at least these), subset_of (only these) or excludes (none of these); matches takes a regular expression string. Example: 'eq'."Input schema / properties / value / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "items": {
+ "type": "string"
+ },
+ "minItems": 1,
+ "type": "array"
+ }
+]Input schema / properties / value / descriptionPrevious value: -"Optional extracted semantic claim value. Accepts string, number, or boolean."New value: +"Optional extracted semantic claim value: a string, number or boolean, or a list of strings for a set claim. Example: ['requireAuth'] with operator includes."kb_upsert18 fields changedInput schema / properties / properties / properties / operator / anyOfPrevious value: -[
- {
- "const": "eq",
- "type": "string"
- },
- {
- "const": "neq",
- "type": "string"
- },
- {
- "const": "lt",
- "type": "string"
- },
- {
- "const": "lte",
- "type": "string"
- },
- {
- "const": "gt",
- "type": "string"
- },
- {
- "const": "gte",
- "type": "string"
- }
-]New value: +[
+ {
+ "const": "eq",
+ "type": "string"
+ },
+ {
+ "const": "neq",
+ "type": "string"
+ },
+ {
+ "const": "lt",
+ "type": "string"
+ },
+ {
+ "const": "lte",
+ "type": "string"
+ },
+ {
+ "const": "gt",
+ "type": "string"
+ },
+ {
+ "const": "gte",
+ "type": "string"
+ },
+ {
+ "const": "matches",
+ "type": "string"
+ },
+ {
+ "const": "includes",
+ "type": "string"
+ },
+ {
+ "const": "subset_of",
+ "type": "string"
+ },
+ {
+ "const": "excludes",
+ "type": "string"
+ }
+]Input schema / properties / properties / properties / operator / descriptionPrevious value: -"Optional comparison operator for property_value facts. Example: 'eq'."New value: +"Optional comparison operator for property_value facts. Example: 'eq'. 'matches' (string facts only): value_string is a JavaScript regular expression (u flag) every value must match as a whole. Set facts only: 'includes' means every member of value_set has the property and other members may have it too; 'subset_of' means every member that has the property is in value_set ('every env var the server reads is one of ...'); 'excludes' means no member of value_set has it ('never imports md5'); 'eq' on a set means exactly those members."Input schema / properties / properties / properties / proof_contract / properties / domain_source / descriptionPrevious value: -"exhaustive and typecheck: the symbol that defines the finite domain. The proof must import it from its source file; a hand-listed domain downgrades the receipt to example. Kibi reads the export named `export`, or the symbol's title when `export` is absent."New value: +"exhaustive and typecheck: the symbol that defines the finite domain (typecheck: also the type whose fields a required_fields fact names). state_machine: the transition table or next-state function. The proof must import it from its source file; a hand-listed domain downgrades the receipt to example. Kibi reads the export named `export`, or the symbol's title when `export` is absent."Input schema / properties / properties / properties / proof_contract / properties / domainsAdded value: +{
+ "additionalProperties": {},
+ "description": "rule: the finite domain of each argument type, keyed by type name (an array, Set, Map or object export, or a Python list, set, dict or Enum), or {source} for the members Kibi reads from a project source (every route, every table, every environment variable). state_machine with a next-state function: the `state` and `event` domains it is called on.",
+ "properties": {},
+ "type": "object"
+}Input schema / properties / properties / properties / proof_contract / properties / initial_sourceAdded value: +{
+ "description": "state_machine: the export holding the initial state (or states), needed for initial_states and reachable_states facts.",
+ "properties": {
+ "export": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "symbol_id": {
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "symbol_id"
+ ],
+ "type": "object"
+}Input schema / properties / properties / properties / proof_contract / properties / kind / anyOfPrevious value: -[
- {
- "const": "e2e",
- "type": "string"
- },
- {
- "const": "example",
- "type": "string"
- },
- {
- "const": "property",
- "type": "string"
- },
- {
- "const": "exhaustive",
- "type": "string"
- },
- {
- "const": "typecheck",
- "type": "string"
- },
- {
- "const": "arithmetic",
- "type": "string"
- },
- {
- "const": "smt",
- "type": "string"
- }
-]New value: +[
+ {
+ "const": "e2e",
+ "type": "string"
+ },
+ {
+ "const": "example",
+ "type": "string"
+ },
+ {
+ "const": "property",
+ "type": "string"
+ },
+ {
+ "const": "exhaustive",
+ "type": "string"
+ },
+ {
+ "const": "typecheck",
+ "type": "string"
+ },
+ {
+ "const": "arithmetic",
+ "type": "string"
+ },
+ {
+ "const": "smt",
+ "type": "string"
+ },
+ {
+ "const": "rule",
+ "type": "string"
+ },
+ {
+ "const": "state_machine",
+ "type": "string"
+ },
+ {
+ "const": "regex",
+ "type": "string"
+ },
+ {
+ "const": "source",
+ "type": "string"
+ }
+]Input schema / properties / properties / properties / proof_contract / properties / kind / descriptionPrevious value: -"What the checker establishes; absent means e2e. exhaustive, typecheck, arithmetic and smt must leave a kibi.code-certificate.v1 that Kibi re-checks before the receipt counts as proved."New value: +"What the checker establishes; absent means e2e. exhaustive, typecheck, arithmetic, smt, rule, state_machine and regex must leave a kibi.code-certificate.v1 that Kibi re-checks before the receipt counts as proved. source reads the contract's source itself: the run may leave {version, kind: source, test_id, source} or nothing, and Kibi stores its own read as the certificate."Input schema / properties / properties / properties / proof_contract / properties / pattern_sourceAdded value: +{
+ "description": "regex: the export holding the code's pattern (a RegExp, or a Python re.Pattern) or string constant that a string fact is about.",
+ "properties": {
+ "export": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "symbol_id": {
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "symbol_id"
+ ],
+ "type": "object"
+}Input schema / properties / properties / properties / proof_contract / properties / predicate_sourceAdded value: +{
+ "additionalProperties": {},
+ "description": "rule: the code function behind each predicate a claim's rule, predicate or set fact names, keyed by predicate name. Each export takes the predicate's arguments in order and returns a boolean; Kibi calls it on every combination of its argument domains.",
+ "properties": {},
+ "type": "object"
+}Input schema / properties / properties / properties / proof_contract / properties / proves / descriptionPrevious value: -"Certificate kinds: the requirement claim keys (CLAIM-...) this certificate proves. Each must be a modeled claim of a current requirement the test reaches through its scenarios. Kibi derives what the certificate must establish from the claim's grounding fact (a set fact for exhaustive or typecheck, a numeric fact for arithmetic or smt); a claim with no such derivation is only attested and never counts as proved."New value: +"Certificate kinds: the requirement claim keys (CLAIM-...) this certificate proves. Each must be a modeled claim of a current requirement the test reaches through its scenarios. Kibi derives what the certificate must establish from the claim's grounding fact (a set fact for exhaustive or typecheck, a numeric fact for arithmetic or smt, a rule, predicate or set fact for rule and state_machine, a string fact for regex); a claim with no such derivation is only attested and never counts as proved."Input schema / properties / properties / properties / proof_contract / properties / sourceAdded value: +{
+ "additionalProperties": {},
+ "description": "source: the project source a source proof reads. A project source Kibi reads by itself. reader json or yaml: {file, path?, select?: keys|values|items}. glob: {pattern, capture?, ignore?} (capture true reads what each * matched). openapi: {file, select?: operations|unsecured_operations|security_schemes|responses}. references: {files, extract: env|imports|calls|string_args|thrown|property, callee?, key?, ignore?}. schema: {format: drizzle|prisma|sql, file (drizzle, prisma) or files (sql migrations), exports?, table?, select?: tables|columns|required_columns|nullable_columns|foreign_keys}. routes: {file, export, framework?: hono|express, path_prefix?, names_from?, select?: routes|middleware}. validator: {file, export, select?: fields|required_fields|optional_fields}. Paths are repository-relative. A member Kibi cannot read statically fails the read with its location.",
+ "properties": {
+ "reader": {
+ "anyOf": [
+ {
+ "const": "json",
+ "type": "string"
+ },
+ {
+ "const": "yaml",
+ "type": "string"
+ },
+ {
+ "const": "glob",
+ "type": "string"
+ },
+ {
+ "const": "openapi",
+ "type": "string"
+ },
+ {
+ "const": "references",
+ "type": "string"
+ },
+ {
+ "const": "schema",
+ "type": "string"
+ },
+ {
+ "const": "routes",
+ "type": "string"
+ },
+ {
+ "const": "validator",
+ "type": "string"
+ }
+ ]
+ }
+ },
+ "required": [
+ "reader"
+ ],
+ "type": "object"
+}Input schema / properties / properties / properties / proof_contract / properties / value_source / descriptionPrevious value: -"arithmetic and smt: code constants the assumptions read. Kibi evaluates each export at ingest and requires the certificate to assume the variable equals that value, so the proof is about the code and not only the knowledge base."New value: +"arithmetic and smt: code constants the assumptions read. Kibi evaluates each export at ingest and requires the certificate to assume the variable equals that value, so the proof is about the code and not only the knowledge base. With measure count the value is the size of a list, set, map or object export, so a count claim reads the collection itself. An entry {source, measure: count} counts the members Kibi reads from a project source (routes, tables, environment variables)."Input schema / properties / properties / properties / proof_contract / properties / value_source / items / properties / measureAdded value: +{
+ "anyOf": [
+ {
+ "const": "value",
+ "type": "string"
+ },
+ {
+ "const": "count",
+ "type": "string"
+ }
+ ],
+ "description": "value (default for an export): the export is a number. count (the only measure of a source): the number of members of a list, set, map or object export, or of a source."
+}Input schema / properties / properties / properties / proof_contract / properties / value_source / items / properties / sourceAdded value: +{
+ "additionalProperties": {},
+ "description": "A project source Kibi reads by itself. reader json or yaml: {file, path?, select?: keys|values|items}. glob: {pattern, capture?, ignore?} (capture true reads what each * matched). openapi: {file, select?: operations|unsecured_operations|security_schemes|responses}. references: {files, extract: env|imports|calls|string_args|thrown|property, callee?, key?, ignore?}. schema: {format: drizzle|prisma|sql, file (drizzle, prisma) or files (sql migrations), exports?, table?, select?: tables|columns|required_columns|nullable_columns|foreign_keys}. routes: {file, export, framework?: hono|express, path_prefix?, names_from?, select?: routes|middleware}. validator: {file, export, select?: fields|required_fields|optional_fields}. Paths are repository-relative. A member Kibi cannot read statically fails the read with its location.",
+ "properties": {
+ "reader": {
+ "anyOf": [
+ {
+ "const": "json",
+ "type": "string"
+ },
+ {
+ "const": "yaml",
+ "type": "string"
+ },
+ {
+ "const": "glob",
+ "type": "string"
+ },
+ {
+ "const": "openapi",
+ "type": "string"
+ },
+ {
+ "const": "references",
+ "type": "string"
+ },
+ {
+ "const": "schema",
+ "type": "string"
+ },
+ {
+ "const": "routes",
+ "type": "string"
+ },
+ {
+ "const": "validator",
+ "type": "string"
+ }
+ ]
+ }
+ },
+ "required": [
+ "reader"
+ ],
+ "type": "object"
+}Input schema / properties / properties / properties / proof_contract / properties / value_source / items / requiredRemoved value: -[
- "symbol_id"
-]Input schema / properties / properties / properties / proof_receipts / items / properties / claim_bindings / items / properties / scope / anyOfPrevious value: -[
- {
- "const": "code",
- "type": "string"
- },
- {
- "const": "intent",
- "type": "string"
- }
-]New value: +[
+ {
+ "const": "code",
+ "type": "string"
+ },
+ {
+ "const": "source",
+ "type": "string"
+ },
+ {
+ "const": "harness",
+ "type": "string"
+ },
+ {
+ "const": "intent",
+ "type": "string"
+ }
+]Input schema / properties / properties / properties / proof_receipts / items / properties / kind / anyOfPrevious value: -[
- {
- "const": "e2e",
- "type": "string"
- },
- {
- "const": "example",
- "type": "string"
- },
- {
- "const": "property",
- "type": "string"
- },
- {
- "const": "exhaustive",
- "type": "string"
- },
- {
- "const": "typecheck",
- "type": "string"
- },
- {
- "const": "arithmetic",
- "type": "string"
- },
- {
- "const": "smt",
- "type": "string"
- }
-]New value: +[
+ {
+ "const": "e2e",
+ "type": "string"
+ },
+ {
+ "const": "example",
+ "type": "string"
+ },
+ {
+ "const": "property",
+ "type": "string"
+ },
+ {
+ "const": "exhaustive",
+ "type": "string"
+ },
+ {
+ "const": "typecheck",
+ "type": "string"
+ },
+ {
+ "const": "arithmetic",
+ "type": "string"
+ },
+ {
+ "const": "smt",
+ "type": "string"
+ },
+ {
+ "const": "rule",
+ "type": "string"
+ },
+ {
+ "const": "state_machine",
+ "type": "string"
+ },
+ {
+ "const": "regex",
+ "type": "string"
+ },
+ {
+ "const": "source",
+ "type": "string"
+ }
+]Input schema / properties / properties / properties / value_type / descriptionPrevious value: -"Optional typed value discriminator for property_value facts. Pair with exactly one value_string, value_int, value_number, value_bool, or value_set (set: an exact list of allowed values, operator eq or neq); do not use generic value."New value: +"Optional typed value discriminator for property_value facts. Pair with exactly one value_string, value_int, value_number, value_bool, or value_set (set: a list of members, with operator eq, includes, subset_of or excludes); do not use generic value."v0.1.4kb_check2 fields changedInput schema / properties / rules / descriptionPrevious value: -"Optional rule subset. Allowed: must-priority-coverage, symbol-coverage, symbol-traceability, symbol-granularity, no-dangling-refs, source-relationship-parity, branch-store-not-compiled, source-path-dangling, no-cycles, required-fields, deprecated-adr-no-successor, superseded-requirement-open, scenario-feasibility, scenario-feasibility-unknown, exception-claim-keys, numeric-string-value, rule-key-arguments-missing, domain-contradictions, logic-coverage, rule-safety, rule-verifiability, query-plan-safety, req-status-vocabulary, strict-fact-shape, strict-req-fact-pairing, predicate-verifiability, strict-readiness, semantic-completeness, related-requirement-unmodeled, proof-contract-symbols, entity-id-style, domain-redundancy, domain-implication, subject-key-identity, subject-key-shape, ontology-quality, exception-unapproved, exception-approval-self-attested, agent-requirement-unapproved, requirement-rationale-missing, symbol-owner-superseded, adr-unlinked, adr-proposed, predicate-schema-conformance, entity-context-missing, entity-context-acknowledged, decision-firm-unreferenced, decision-firm-superseded, decision-firm-edited, supersedes-reason-missing, supersedes-reason-acknowledged, policy-ownership, policy-markers, kb-consistency, kb-consistency-unresolved. If omitted, server runs canonical and advisory rules plus the full-KB qualityDiagnostics audit scan, including usage telemetry acceptance when evidence exists; migration rules run only when explicitly selected. Advisory and migration findings are non-blocking qualityDiagnostics. If supplied, server preserves scoped validation and skips the full-KB advisory scan."New value: +"Optional rule subset. Allowed: must-priority-coverage, symbol-coverage, symbol-traceability, symbol-granularity, no-dangling-refs, source-relationship-parity, branch-store-not-compiled, source-path-dangling, no-cycles, required-fields, deprecated-adr-no-successor, superseded-requirement-open, scenario-feasibility, scenario-feasibility-unknown, exception-claim-keys, numeric-string-value, rule-key-arguments-missing, domain-contradictions, logic-coverage, rule-safety, rule-verifiability, query-plan-safety, req-status-vocabulary, strict-fact-shape, strict-req-fact-pairing, predicate-verifiability, strict-readiness, semantic-completeness, related-requirement-unmodeled, proof-contract-symbols, entity-id-style, domain-redundancy, domain-implication, subject-key-identity, subject-key-shape, ontology-quality, exception-unapproved, exception-approval-self-attested, agent-requirement-unapproved, requirement-rationale-missing, symbol-owner-superseded, adr-unlinked, adr-proposed, predicate-schema-conformance, entity-context-missing, entity-context-acknowledged, decision-firm-unreferenced, decision-firm-superseded, decision-firm-edited, supersedes-reason-missing, supersedes-reason-acknowledged, policy-ownership, policy-markers, kb-consistency, kb-consistency-unresolved, evidence-floor, proof-contract-claims. If omitted, server runs canonical and advisory rules plus the full-KB qualityDiagnostics audit scan, including usage telemetry acceptance when evidence exists; migration rules run only when explicitly selected. Advisory and migration findings are non-blocking qualityDiagnostics. If supplied, server preserves scoped validation and skips the full-KB advisory scan."Input schema / properties / rules / items / anyOfPrevious value: -[
- {
- "const": "must-priority-coverage",
- "type": "string"
- },
- {
- "const": "symbol-coverage",
- "type": "string"
- },
- {
- "const": "symbol-traceability",
- "type": "string"
- },
- {
- "const": "symbol-granularity",
- "type": "string"
- },
- {
- "const": "no-dangling-refs",
- "type": "string"
- },
- {
- "const": "source-relationship-parity",
- "type": "string"
- },
- {
- "const": "branch-store-not-compiled",
- "type": "string"
- },
- {
- "const": "source-path-dangling",
- "type": "string"
- },
- {
- "const": "no-cycles",
- "type": "string"
- },
- {
- "const": "required-fields",
- "type": "string"
- },
- {
- "const": "deprecated-adr-no-successor",
- "type": "string"
- },
- {
- "const": "superseded-requirement-open",
- "type": "string"
- },
- {
- "const": "scenario-feasibility",
- "type": "string"
- },
- {
- "const": "scenario-feasibility-unknown",
- "type": "string"
- },
- {
- "const": "exception-claim-keys",
- "type": "string"
- },
- {
- "const": "numeric-string-value",
- "type": "string"
- },
- {
- "const": "rule-key-arguments-missing",
- "type": "string"
- },
- {
- "const": "domain-contradictions",
- "type": "string"
- },
- {
- "const": "logic-coverage",
- "type": "string"
- },
- {
- "const": "rule-safety",
- "type": "string"
- },
- {
- "const": "rule-verifiability",
- "type": "string"
- },
- {
- "const": "query-plan-safety",
- "type": "string"
- },
- {
- "const": "req-status-vocabulary",
- "type": "string"
- },
- {
- "const": "strict-fact-shape",
- "type": "string"
- },
- {
- "const": "strict-req-fact-pairing",
- "type": "string"
- },
- {
- "const": "predicate-verifiability",
- "type": "string"
- },
- {
- "const": "strict-readiness",
- "type": "string"
- },
- {
- "const": "semantic-completeness",
- "type": "string"
- },
- {
- "const": "related-requirement-unmodeled",
- "type": "string"
- },
- {
- "const": "proof-contract-symbols",
- "type": "string"
- },
- {
- "const": "entity-id-style",
- "type": "string"
- },
- {
- "const": "domain-redundancy",
- "type": "string"
- },
- {
- "const": "domain-implication",
- "type": "string"
- },
- {
- "const": "subject-key-identity",
- "type": "string"
- },
- {
- "const": "subject-key-shape",
- "type": "string"
- },
- {
- "const": "ontology-quality",
- "type": "string"
- },
- {
- "const": "exception-unapproved",
- "type": "string"
- },
- {
- "const": "exception-approval-self-attested",
- "type": "string"
- },
- {
- "const": "agent-requirement-unapproved",
- "type": "string"
- },
- {
- "const": "requirement-rationale-missing",
- "type": "string"
- },
- {
- "const": "symbol-owner-superseded",
- "type": "string"
- },
- {
- "const": "adr-unlinked",
- "type": "string"
- },
- {
- "const": "adr-proposed",
- "type": "string"
- },
- {
- "const": "predicate-schema-conformance",
- "type": "string"
- },
- {
- "const": "entity-context-missing",
- "type": "string"
- },
- {
- "const": "entity-context-acknowledged",
- "type": "string"
- },
- {
- "const": "decision-firm-unreferenced",
- "type": "string"
- },
- {
- "const": "decision-firm-superseded",
- "type": "string"
- },
- {
- "const": "decision-firm-edited",
- "type": "string"
- },
- {
- "const": "supersedes-reason-missing",
- "type": "string"
- },
- {
- "const": "supersedes-reason-acknowledged",
- "type": "string"
- },
- {
- "const": "policy-ownership",
- "type": "string"
- },
- {
- "const": "policy-markers",
- "type": "string"
- },
- {
- "const": "kb-consistency",
- "type": "string"
- },
- {
- "const": "kb-consistency-unresolved",
- "type": "string"
- }
-]New value: +[
+ {
+ "const": "must-priority-coverage",
+ "type": "string"
+ },
+ {
+ "const": "symbol-coverage",
+ "type": "string"
+ },
+ {
+ "const": "symbol-traceability",
+ "type": "string"
+ },
+ {
+ "const": "symbol-granularity",
+ "type": "string"
+ },
+ {
+ "const": "no-dangling-refs",
+ "type": "string"
+ },
+ {
+ "const": "source-relationship-parity",
+ "type": "string"
+ },
+ {
+ "const": "branch-store-not-compiled",
+ "type": "string"
+ },
+ {
+ "const": "source-path-dangling",
+ "type": "string"
+ },
+ {
+ "const": "no-cycles",
+ "type": "string"
+ },
+ {
+ "const": "required-fields",
+ "type": "string"
+ },
+ {
+ "const": "deprecated-adr-no-successor",
+ "type": "string"
+ },
+ {
+ "const": "superseded-requirement-open",
+ "type": "string"
+ },
+ {
+ "const": "scenario-feasibility",
+ "type": "string"
+ },
+ {
+ "const": "scenario-feasibility-unknown",
+ "type": "string"
+ },
+ {
+ "const": "exception-claim-keys",
+ "type": "string"
+ },
+ {
+ "const": "numeric-string-value",
+ "type": "string"
+ },
+ {
+ "const": "rule-key-arguments-missing",
+ "type": "string"
+ },
+ {
+ "const": "domain-contradictions",
+ "type": "string"
+ },
+ {
+ "const": "logic-coverage",
+ "type": "string"
+ },
+ {
+ "const": "rule-safety",
+ "type": "string"
+ },
+ {
+ "const": "rule-verifiability",
+ "type": "string"
+ },
+ {
+ "const": "query-plan-safety",
+ "type": "string"
+ },
+ {
+ "const": "req-status-vocabulary",
+ "type": "string"
+ },
+ {
+ "const": "strict-fact-shape",
+ "type": "string"
+ },
+ {
+ "const": "strict-req-fact-pairing",
+ "type": "string"
+ },
+ {
+ "const": "predicate-verifiability",
+ "type": "string"
+ },
+ {
+ "const": "strict-readiness",
+ "type": "string"
+ },
+ {
+ "const": "semantic-completeness",
+ "type": "string"
+ },
+ {
+ "const": "related-requirement-unmodeled",
+ "type": "string"
+ },
+ {
+ "const": "proof-contract-symbols",
+ "type": "string"
+ },
+ {
+ "const": "entity-id-style",
+ "type": "string"
+ },
+ {
+ "const": "domain-redundancy",
+ "type": "string"
+ },
+ {
+ "const": "domain-implication",
+ "type": "string"
+ },
+ {
+ "const": "subject-key-identity",
+ "type": "string"
+ },
+ {
+ "const": "subject-key-shape",
+ "type": "string"
+ },
+ {
+ "const": "ontology-quality",
+ "type": "string"
+ },
+ {
+ "const": "exception-unapproved",
+ "type": "string"
+ },
+ {
+ "const": "exception-approval-self-attested",
+ "type": "string"
+ },
+ {
+ "const": "agent-requirement-unapproved",
+ "type": "string"
+ },
+ {
+ "const": "requirement-rationale-missing",
+ "type": "string"
+ },
+ {
+ "const": "symbol-owner-superseded",
+ "type": "string"
+ },
+ {
+ "const": "adr-unlinked",
+ "type": "string"
+ },
+ {
+ "const": "adr-proposed",
+ "type": "string"
+ },
+ {
+ "const": "predicate-schema-conformance",
+ "type": "string"
+ },
+ {
+ "const": "entity-context-missing",
+ "type": "string"
+ },
+ {
+ "const": "entity-context-acknowledged",
+ "type": "string"
+ },
+ {
+ "const": "decision-firm-unreferenced",
+ "type": "string"
+ },
+ {
+ "const": "decision-firm-superseded",
+ "type": "string"
+ },
+ {
+ "const": "decision-firm-edited",
+ "type": "string"
+ },
+ {
+ "const": "supersedes-reason-missing",
+ "type": "string"
+ },
+ {
+ "const": "supersedes-reason-acknowledged",
+ "type": "string"
+ },
+ {
+ "const": "policy-ownership",
+ "type": "string"
+ },
+ {
+ "const": "policy-markers",
+ "type": "string"
+ },
+ {
+ "const": "kb-consistency",
+ "type": "string"
+ },
+ {
+ "const": "kb-consistency-unresolved",
+ "type": "string"
+ },
+ {
+ "const": "evidence-floor",
+ "type": "string"
+ },
+ {
+ "const": "proof-contract-claims",
+ "type": "string"
+ }
+]kb_ingest_proof1 field changedInput schema / properties / artifact / properties / certificatesAdded value: +{
+ "description": "kibi.code-certificate.v1 objects the run left for certificate-kind contracts, one per test. Kibi re-checks each before a receipt counts as proved.",
+ "items": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "maxItems": 1000,
+ "type": "array"
+}kb_upsert23 fields changedInput schema / properties / properties / properties / proof_contract / properties / constraint_sourceAdded value: +{
+ "description": "arithmetic and smt: the typed numeric property_value facts the certificate's assumptions come from. Kibi checks the assumptions (or the query's assertions) are exactly these facts' constraints, so the proof is about the knowledge base, not numbers the test chose.",
+ "properties": {
+ "fact_ids": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "minItems": 1,
+ "type": "array"
+ }
+ },
+ "required": [
+ "fact_ids"
+ ],
+ "type": "object"
+}Input schema / properties / properties / properties / proof_contract / properties / domain_sourceAdded value: +{
+ "description": "exhaustive and typecheck: the symbol that defines the finite domain. The proof must import it from its source file; a hand-listed domain downgrades the receipt to example. Kibi reads the export named `export`, or the symbol's title when `export` is absent.",
+ "properties": {
+ "export": {
+ "description": "The name the domain is exported under in the symbol's source file, when the symbol's title is not that name.",
+ "minLength": 1,
+ "type": "string"
+ },
+ "symbol_id": {
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "symbol_id"
+ ],
+ "type": "object"
+}Input schema / properties / properties / properties / proof_contract / properties / kindAdded value: +{
+ "anyOf": [
+ {
+ "const": "e2e",
+ "type": "string"
+ },
+ {
+ "const": "example",
+ "type": "string"
+ },
+ {
+ "const": "property",
+ "type": "string"
+ },
+ {
+ "const": "exhaustive",
+ "type": "string"
+ },
+ {
+ "const": "typecheck",
+ "type": "string"
+ },
+ {
+ "const": "arithmetic",
+ "type": "string"
+ },
+ {
+ "const": "smt",
+ "type": "string"
+ }
+ ],
+ "description": "What the checker establishes; absent means e2e. exhaustive, typecheck, arithmetic and smt must leave a kibi.code-certificate.v1 that Kibi re-checks before the receipt counts as proved."
+}Input schema / properties / properties / properties / proof_contract / properties / provesAdded value: +{
+ "description": "Certificate kinds: the requirement claim keys (CLAIM-...) this certificate proves. Each must be a modeled claim of a current requirement the test reaches through its scenarios. Kibi derives what the certificate must establish from the claim's grounding fact (a set fact for exhaustive or typecheck, a numeric fact for arithmetic or smt); a claim with no such derivation is only attested and never counts as proved.",
+ "items": {
+ "pattern": "^CLAIM-",
+ "type": "string"
+ },
+ "minItems": 1,
+ "type": "array",
+ "uniqueItems": true
+}Input schema / properties / properties / properties / proof_contract / properties / success_policy / anyOfAdded value: +[
+ {
+ "const": "all_required_first_attempt",
+ "type": "string"
+ },
+ {
+ "const": "own_results_first_attempt",
+ "type": "string"
+ }
+]Input schema / properties / properties / properties / proof_contract / properties / success_policy / constRemoved value: -"all_required_first_attempt"Input schema / properties / properties / properties / proof_contract / properties / success_policy / typeRemoved value: -"string"Input schema / properties / properties / properties / proof_contract / properties / value_sourceAdded value: +{
+ "description": "arithmetic and smt: code constants the assumptions read. Kibi evaluates each export at ingest and requires the certificate to assume the variable equals that value, so the proof is about the code and not only the knowledge base.",
+ "items": {
+ "properties": {
+ "export": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "symbol_id": {
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "symbol_id"
+ ],
+ "type": "object"
+ },
+ "minItems": 1,
+ "type": "array"
+}Input schema / properties / properties / properties / proof_contract / properties / witnessAdded value: +{
+ "description": "typecheck: the repository-relative witness file Kibi compiles (an exhaustive switch ending in never, or a mapped type over the domain).",
+ "properties": {
+ "path": {
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "path"
+ ],
+ "type": "object"
+}Input schema / properties / properties / properties / proof_receipts / items / descriptionPrevious value: -"Kibi-derived kibi.proof-receipt.v1. Receipts are never caller-authored; kb_ingest_proof derives them from kibi.proof-run.v1 artifacts."New value: +"Kibi-derived kibi.proof-receipt.v2 (kibi.proof-receipt.v1 entries are still read). Receipts are never caller-authored; kb_ingest_proof derives them from kibi.proof-run.v1 artifacts."Input schema / properties / properties / properties / proof_receipts / items / properties / certificateAdded value: +{
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+}Input schema / properties / properties / properties / proof_receipts / items / properties / certificate_digestAdded value: +{
+ "pattern": "^[a-f0-9]{64}$",
+ "type": "string"
+}Input schema / properties / properties / properties / proof_receipts / items / properties / certificate_rejectionAdded value: +{
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / properties / properties / proof_receipts / items / properties / claim_bindingsAdded value: +{
+ "description": "Certificate kinds: how the certificate binds to each claim its contract names in proves, judged at ingest. derived means Kibi derived the certificate's obligation from the claim's grounding fact and the certificate satisfies it; attested means no derivation exists and the author vouches for it (never proved); rejected names why.",
+ "items": {
+ "properties": {
+ "binding": {
+ "anyOf": [
+ {
+ "const": "derived",
+ "type": "string"
+ },
+ {
+ "const": "attested",
+ "type": "string"
+ },
+ {
+ "const": "rejected",
+ "type": "string"
+ }
+ ]
+ },
+ "claim_key": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "fact_id": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "obligation": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "reason": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "requirement_id": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "scope": {
+ "anyOf": [
+ {
+ "const": "code",
+ "type": "string"
+ },
+ {
+ "const": "intent",
+ "type": "string"
+ }
+ ]
+ }
+ },
+ "required": [
+ "claim_key",
+ "binding"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Input schema / properties / properties / properties / proof_receipts / items / properties / evidence_levelAdded value: +{
+ "anyOf": [
+ {
+ "const": "proved",
+ "type": "string"
+ },
+ {
+ "const": "tested",
+ "type": "string"
+ }
+ ]
+}Input schema / properties / properties / properties / proof_receipts / items / properties / kindAdded value: +{
+ "anyOf": [
+ {
+ "const": "e2e",
+ "type": "string"
+ },
+ {
+ "const": "example",
+ "type": "string"
+ },
+ {
+ "const": "property",
+ "type": "string"
+ },
+ {
+ "const": "exhaustive",
+ "type": "string"
+ },
+ {
+ "const": "typecheck",
+ "type": "string"
+ },
+ {
+ "const": "arithmetic",
+ "type": "string"
+ },
+ {
+ "const": "smt",
+ "type": "string"
+ }
+ ]
+}Input schema / properties / properties / properties / proof_receipts / items / properties / version / anyOfAdded value: +[
+ {
+ "const": "kibi.proof-receipt.v1",
+ "type": "string"
+ },
+ {
+ "const": "kibi.proof-receipt.v2",
+ "type": "string"
+ }
+]Input schema / properties / properties / properties / proof_receipts / items / properties / version / constRemoved value: -"kibi.proof-receipt.v1"Input schema / properties / properties / properties / proof_receipts / items / properties / version / typeRemoved value: -"string"Input schema / properties / properties / properties / required_evidenceAdded value: +{
+ "anyOf": [
+ {
+ "const": "proved",
+ "type": "string"
+ },
+ {
+ "const": "tested",
+ "type": "string"
+ },
+ {
+ "const": "asserted",
+ "type": "string"
+ },
+ {
+ "const": "unverified",
+ "type": "string"
+ }
+ ],
+ "description": "Requirement-only. Weakest evidence level it accepts; the evidence-floor rule fails below it. Absent = tested if firm, else unverified."
+}Input schema / properties / properties / properties / value_setAdded value: +{
+ "description": "Optional exact set of values for property_value facts with value_type set, such as the members a domain must have.",
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "minItems": 1,
+ "type": "array",
+ "uniqueItems": true
+}Input schema / properties / properties / properties / value_type / anyOfPrevious value: -[
- {
- "const": "string",
- "type": "string"
- },
- {
- "const": "int",
- "type": "string"
- },
- {
- "const": "number",
- "type": "string"
- },
- {
- "const": "bool",
- "type": "string"
- }
-]New value: +[
+ {
+ "const": "string",
+ "type": "string"
+ },
+ {
+ "const": "int",
+ "type": "string"
+ },
+ {
+ "const": "number",
+ "type": "string"
+ },
+ {
+ "const": "bool",
+ "type": "string"
+ },
+ {
+ "const": "set",
+ "type": "string"
+ }
+]Input schema / properties / properties / properties / value_type / descriptionPrevious value: -"Optional typed value discriminator for property_value facts. Pair with exactly one value_string, value_int, value_number, or value_bool; do not use generic value."New value: +"Optional typed value discriminator for property_value facts. Pair with exactly one value_string, value_int, value_number, value_bool, or value_set (set: an exact list of allowed values, operator eq or neq); do not use generic value."v0.1.3kb_check2 fields changedInput schema / properties / rules / descriptionPrevious value: -"Optional rule subset. Allowed: must-priority-coverage, symbol-coverage, symbol-traceability, symbol-granularity, no-dangling-refs, source-relationship-parity, branch-store-not-compiled, source-path-dangling, no-cycles, required-fields, deprecated-adr-no-successor, superseded-requirement-open, scenario-feasibility, scenario-feasibility-unknown, exception-claim-keys, numeric-string-value, rule-key-arguments-missing, domain-contradictions, logic-coverage, rule-safety, rule-verifiability, query-plan-safety, req-status-vocabulary, strict-fact-shape, strict-req-fact-pairing, predicate-verifiability, strict-readiness, semantic-completeness, related-requirement-unmodeled, proof-contract-symbols, entity-id-style, domain-redundancy, domain-implication, subject-key-identity, subject-key-shape, ontology-quality, exception-unapproved, exception-approval-self-attested, agent-requirement-unapproved, requirement-rationale-missing, symbol-owner-superseded, adr-unlinked, adr-proposed, predicate-schema-conformance, entity-context-missing, entity-context-acknowledged, decision-firm-unreferenced, decision-firm-superseded, decision-firm-edited, supersedes-reason-missing, supersedes-reason-acknowledged, policy-ownership, policy-markers. If omitted, server runs canonical and advisory rules plus the full-KB qualityDiagnostics audit scan, including usage telemetry acceptance when evidence exists; migration rules run only when explicitly selected. Advisory and migration findings are non-blocking qualityDiagnostics. If supplied, server preserves scoped validation and skips the full-KB advisory scan."New value: +"Optional rule subset. Allowed: must-priority-coverage, symbol-coverage, symbol-traceability, symbol-granularity, no-dangling-refs, source-relationship-parity, branch-store-not-compiled, source-path-dangling, no-cycles, required-fields, deprecated-adr-no-successor, superseded-requirement-open, scenario-feasibility, scenario-feasibility-unknown, exception-claim-keys, numeric-string-value, rule-key-arguments-missing, domain-contradictions, logic-coverage, rule-safety, rule-verifiability, query-plan-safety, req-status-vocabulary, strict-fact-shape, strict-req-fact-pairing, predicate-verifiability, strict-readiness, semantic-completeness, related-requirement-unmodeled, proof-contract-symbols, entity-id-style, domain-redundancy, domain-implication, subject-key-identity, subject-key-shape, ontology-quality, exception-unapproved, exception-approval-self-attested, agent-requirement-unapproved, requirement-rationale-missing, symbol-owner-superseded, adr-unlinked, adr-proposed, predicate-schema-conformance, entity-context-missing, entity-context-acknowledged, decision-firm-unreferenced, decision-firm-superseded, decision-firm-edited, supersedes-reason-missing, supersedes-reason-acknowledged, policy-ownership, policy-markers, kb-consistency, kb-consistency-unresolved. If omitted, server runs canonical and advisory rules plus the full-KB qualityDiagnostics audit scan, including usage telemetry acceptance when evidence exists; migration rules run only when explicitly selected. Advisory and migration findings are non-blocking qualityDiagnostics. If supplied, server preserves scoped validation and skips the full-KB advisory scan."Input schema / properties / rules / items / anyOfPrevious value: -[
- {
- "const": "must-priority-coverage",
- "type": "string"
- },
- {
- "const": "symbol-coverage",
- "type": "string"
- },
- {
- "const": "symbol-traceability",
- "type": "string"
- },
- {
- "const": "symbol-granularity",
- "type": "string"
- },
- {
- "const": "no-dangling-refs",
- "type": "string"
- },
- {
- "const": "source-relationship-parity",
- "type": "string"
- },
- {
- "const": "branch-store-not-compiled",
- "type": "string"
- },
- {
- "const": "source-path-dangling",
- "type": "string"
- },
- {
- "const": "no-cycles",
- "type": "string"
- },
- {
- "const": "required-fields",
- "type": "string"
- },
- {
- "const": "deprecated-adr-no-successor",
- "type": "string"
- },
- {
- "const": "superseded-requirement-open",
- "type": "string"
- },
- {
- "const": "scenario-feasibility",
- "type": "string"
- },
- {
- "const": "scenario-feasibility-unknown",
- "type": "string"
- },
- {
- "const": "exception-claim-keys",
- "type": "string"
- },
- {
- "const": "numeric-string-value",
- "type": "string"
- },
- {
- "const": "rule-key-arguments-missing",
- "type": "string"
- },
- {
- "const": "domain-contradictions",
- "type": "string"
- },
- {
- "const": "logic-coverage",
- "type": "string"
- },
- {
- "const": "rule-safety",
- "type": "string"
- },
- {
- "const": "rule-verifiability",
- "type": "string"
- },
- {
- "const": "query-plan-safety",
- "type": "string"
- },
- {
- "const": "req-status-vocabulary",
- "type": "string"
- },
- {
- "const": "strict-fact-shape",
- "type": "string"
- },
- {
- "const": "strict-req-fact-pairing",
- "type": "string"
- },
- {
- "const": "predicate-verifiability",
- "type": "string"
- },
- {
- "const": "strict-readiness",
- "type": "string"
- },
- {
- "const": "semantic-completeness",
- "type": "string"
- },
- {
- "const": "related-requirement-unmodeled",
- "type": "string"
- },
- {
- "const": "proof-contract-symbols",
- "type": "string"
- },
- {
- "const": "entity-id-style",
- "type": "string"
- },
- {
- "const": "domain-redundancy",
- "type": "string"
- },
- {
- "const": "domain-implication",
- "type": "string"
- },
- {
- "const": "subject-key-identity",
- "type": "string"
- },
- {
- "const": "subject-key-shape",
- "type": "string"
- },
- {
- "const": "ontology-quality",
- "type": "string"
- },
- {
- "const": "exception-unapproved",
- "type": "string"
- },
- {
- "const": "exception-approval-self-attested",
- "type": "string"
- },
- {
- "const": "agent-requirement-unapproved",
- "type": "string"
- },
- {
- "const": "requirement-rationale-missing",
- "type": "string"
- },
- {
- "const": "symbol-owner-superseded",
- "type": "string"
- },
- {
- "const": "adr-unlinked",
- "type": "string"
- },
- {
- "const": "adr-proposed",
- "type": "string"
- },
- {
- "const": "predicate-schema-conformance",
- "type": "string"
- },
- {
- "const": "entity-context-missing",
- "type": "string"
- },
- {
- "const": "entity-context-acknowledged",
- "type": "string"
- },
- {
- "const": "decision-firm-unreferenced",
- "type": "string"
- },
- {
- "const": "decision-firm-superseded",
- "type": "string"
- },
- {
- "const": "decision-firm-edited",
- "type": "string"
- },
- {
- "const": "supersedes-reason-missing",
- "type": "string"
- },
- {
- "const": "supersedes-reason-acknowledged",
- "type": "string"
- },
- {
- "const": "policy-ownership",
- "type": "string"
- },
- {
- "const": "policy-markers",
- "type": "string"
- }
-]New value: +[
+ {
+ "const": "must-priority-coverage",
+ "type": "string"
+ },
+ {
+ "const": "symbol-coverage",
+ "type": "string"
+ },
+ {
+ "const": "symbol-traceability",
+ "type": "string"
+ },
+ {
+ "const": "symbol-granularity",
+ "type": "string"
+ },
+ {
+ "const": "no-dangling-refs",
+ "type": "string"
+ },
+ {
+ "const": "source-relationship-parity",
+ "type": "string"
+ },
+ {
+ "const": "branch-store-not-compiled",
+ "type": "string"
+ },
+ {
+ "const": "source-path-dangling",
+ "type": "string"
+ },
+ {
+ "const": "no-cycles",
+ "type": "string"
+ },
+ {
+ "const": "required-fields",
+ "type": "string"
+ },
+ {
+ "const": "deprecated-adr-no-successor",
+ "type": "string"
+ },
+ {
+ "const": "superseded-requirement-open",
+ "type": "string"
+ },
+ {
+ "const": "scenario-feasibility",
+ "type": "string"
+ },
+ {
+ "const": "scenario-feasibility-unknown",
+ "type": "string"
+ },
+ {
+ "const": "exception-claim-keys",
+ "type": "string"
+ },
+ {
+ "const": "numeric-string-value",
+ "type": "string"
+ },
+ {
+ "const": "rule-key-arguments-missing",
+ "type": "string"
+ },
+ {
+ "const": "domain-contradictions",
+ "type": "string"
+ },
+ {
+ "const": "logic-coverage",
+ "type": "string"
+ },
+ {
+ "const": "rule-safety",
+ "type": "string"
+ },
+ {
+ "const": "rule-verifiability",
+ "type": "string"
+ },
+ {
+ "const": "query-plan-safety",
+ "type": "string"
+ },
+ {
+ "const": "req-status-vocabulary",
+ "type": "string"
+ },
+ {
+ "const": "strict-fact-shape",
+ "type": "string"
+ },
+ {
+ "const": "strict-req-fact-pairing",
+ "type": "string"
+ },
+ {
+ "const": "predicate-verifiability",
+ "type": "string"
+ },
+ {
+ "const": "strict-readiness",
+ "type": "string"
+ },
+ {
+ "const": "semantic-completeness",
+ "type": "string"
+ },
+ {
+ "const": "related-requirement-unmodeled",
+ "type": "string"
+ },
+ {
+ "const": "proof-contract-symbols",
+ "type": "string"
+ },
+ {
+ "const": "entity-id-style",
+ "type": "string"
+ },
+ {
+ "const": "domain-redundancy",
+ "type": "string"
+ },
+ {
+ "const": "domain-implication",
+ "type": "string"
+ },
+ {
+ "const": "subject-key-identity",
+ "type": "string"
+ },
+ {
+ "const": "subject-key-shape",
+ "type": "string"
+ },
+ {
+ "const": "ontology-quality",
+ "type": "string"
+ },
+ {
+ "const": "exception-unapproved",
+ "type": "string"
+ },
+ {
+ "const": "exception-approval-self-attested",
+ "type": "string"
+ },
+ {
+ "const": "agent-requirement-unapproved",
+ "type": "string"
+ },
+ {
+ "const": "requirement-rationale-missing",
+ "type": "string"
+ },
+ {
+ "const": "symbol-owner-superseded",
+ "type": "string"
+ },
+ {
+ "const": "adr-unlinked",
+ "type": "string"
+ },
+ {
+ "const": "adr-proposed",
+ "type": "string"
+ },
+ {
+ "const": "predicate-schema-conformance",
+ "type": "string"
+ },
+ {
+ "const": "entity-context-missing",
+ "type": "string"
+ },
+ {
+ "const": "entity-context-acknowledged",
+ "type": "string"
+ },
+ {
+ "const": "decision-firm-unreferenced",
+ "type": "string"
+ },
+ {
+ "const": "decision-firm-superseded",
+ "type": "string"
+ },
+ {
+ "const": "decision-firm-edited",
+ "type": "string"
+ },
+ {
+ "const": "supersedes-reason-missing",
+ "type": "string"
+ },
+ {
+ "const": "supersedes-reason-acknowledged",
+ "type": "string"
+ },
+ {
+ "const": "policy-ownership",
+ "type": "string"
+ },
+ {
+ "const": "policy-markers",
+ "type": "string"
+ },
+ {
+ "const": "kb-consistency",
+ "type": "string"
+ },
+ {
+ "const": "kb-consistency-unresolved",
+ "type": "string"
+ }
+]kb_coverage7 fields changedInput schema / properties / by / descriptionAdded value: +"Report shape: req gives per-requirement proof status and a repair plan, symbol gives per-symbol ownership coverage, type gives counts per entity type."Input schema / properties / includePassing / descriptionAdded value: +"Also return rows that are already tested or not applicable. By default only rows that still need repair are returned."Input schema / properties / includeTransitive / descriptionAdded value: +"Count symbol coverage reached transitively through linked entities, not only direct links."Input schema / properties / limit / descriptionAdded value: +"Maximum rows to return. When the repair plan reports scope.complete false, rerun with offset 0 and a larger limit."Input schema / properties / offset / descriptionAdded value: +"Zero-based row offset for pagination."Input schema / properties / statuses / items / anyOfPrevious value: -[
- {
- "const": "proven",
- "type": "string"
- },
- {
- "const": "missing",
- "type": "string"
- },
- {
- "const": "unresolved",
- "type": "string"
- },
- {
- "const": "not_applicable",
- "type": "string"
- }
-]New value: +[
+ {
+ "const": "tested",
+ "type": "string"
+ },
+ {
+ "const": "missing",
+ "type": "string"
+ },
+ {
+ "const": "unresolved",
+ "type": "string"
+ },
+ {
+ "const": "not_applicable",
+ "type": "string"
+ }
+]Input schema / properties / tags / descriptionAdded value: +"Keep rows for entities carrying any of these metadata tags."kb_find_gaps7 fields changedInput schema / properties / limit / descriptionAdded value: +"Maximum rows to return; count reports the full total."Input schema / properties / missingRelationships / descriptionAdded value: +"Relationship types the entity must have none of, in either direction, for example specified_by or verified_by. verified_by and validates satisfy each other."Input schema / properties / offset / descriptionAdded value: +"Zero-based row offset for pagination."Input schema / properties / presentRelationships / descriptionAdded value: +"Relationship types the entity must have at least one of each, in either direction."Input schema / properties / sourceFile / descriptionAdded value: +"Keep entities whose source path contains this substring."Input schema / properties / tags / descriptionAdded value: +"Keep entities carrying any of these metadata tags. Bootstrap provenance stubs appear in rows only when this names bootstrap:provenance-stub."Input schema / properties / type / descriptionAdded value: +"Only report entities of this type. Omit for all types."kb_graph7 fields changedInput schema / properties / depth / descriptionAdded value: +"Number of hops from the seeds."Input schema / properties / direction / descriptionAdded value: +"outgoing follows links from each node, incoming follows links pointing at it, both does either."Input schema / properties / entityTypes / descriptionAdded value: +"Keep only nodes of these types (req, scenario, test, adr, flag, event, symbol, fact) in the result, and the edges between them. Traversal still passes through other types."Input schema / properties / maxEdges / descriptionAdded value: +"Stop and set truncated once this many edges are reached."Input schema / properties / maxNodes / descriptionAdded value: +"Stop and set truncated once this many nodes are reached."Input schema / properties / relationships / descriptionAdded value: +"Relationship types to follow, for example specified_by, verified_by or implements. Omit to follow every relationship type."Input schema / properties / seedIds / descriptionAdded value: +"Entity IDs to start from, for example REQ-... or SCEN-.... Seeds are always returned as nodes."kb_prepare_impact_review1 field changedInput schema / properties / scope / descriptionAdded value: +"What to review: {\"kind\":\"staged\"} for the staged snapshot, or {\"kind\":\"diff\",\"baseCommit\":\"<sha>\",\"headCommit\":\"<sha>\"} with full commit hashes."kb_upsert1 field changedOutput schema / properties / data / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "claimKey": {
- "description": "For a fact with claim_text: the stored claim_key, derived from claim_text when the payload did not supply it.",
- "type": "string"
- },
- "contradictionCheck": {
- "additionalProperties": {},
- "properties": {},
- "type": "object"
- },
- "created": {
- "maximum": 9007199254740991,
- "minimum": -9007199254740991,
- "type": "integer"
- },
- "effectFailures": {
- "items": {
- "additionalProperties": {},
- "properties": {},
- "type": "object"
- },
- "type": "array"
- },
- "nextActions": {
- "items": {
- "additionalProperties": {},
- "properties": {},
- "type": "object"
- },
- "type": "array"
- },
- "relationships_created": {
- "maximum": 9007199254740991,
- "minimum": -9007199254740991,
- "type": "integer"
- },
- "semanticAdvisor": {
- "additionalProperties": {},
- "properties": {},
- "type": "object"
- },
- "sourceWrites": {
- "items": {
- "additionalProperties": {},
- "properties": {},
- "type": "object"
- },
- "type": "array"
- },
- "status": {
- "type": "string"
- },
- "updated": {
- "maximum": 9007199254740991,
- "minimum": -9007199254740991,
- "type": "integer"
- },
- "warnings": {
- "items": {},
- "type": "array"
- }
- },
- "type": "object"
- },
- {
- "additionalProperties": false,
- "properties": {
- "dryRun": {
- "const": true,
- "type": "boolean"
- },
- "errors": {
- "items": {},
- "type": "array"
- },
- "normalizedPreview": {
- "anyOf": [
- {
- "additionalProperties": {},
- "properties": {},
- "type": "object"
- },
- {
- "type": "null"
- }
- ]
- },
- "semanticAdvisor": {
- "anyOf": [
- {
- "additionalProperties": {},
- "properties": {},
- "type": "object"
- },
- {
- "type": "null"
- }
- ]
- },
- "skippedEffects": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "stagedFacts": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "valid": {
- "type": "boolean"
- },
- "warnings": {
- "items": {},
- "type": "array"
- },
- "whatIf": {
- "additionalProperties": {},
- "properties": {},
- "type": "object"
- }
- },
- "required": [
- "valid",
- "dryRun",
- "skippedEffects"
- ],
- "type": "object"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "claimKey": {
+ "description": "For a fact with claim_text: the stored claim_key, derived from claim_text when the payload did not supply it.",
+ "type": "string"
+ },
+ "contradictionCheck": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "created": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "effectFailures": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "nextActions": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "relationships_created": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "semanticAdvisor": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "sourceWrites": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "status": {
+ "type": "string"
+ },
+ "updated": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "warnings": {
+ "items": {},
+ "type": "array"
+ }
+ },
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "dryRun": {
+ "const": true,
+ "type": "boolean"
+ },
+ "errorCode": {
+ "type": "string"
+ },
+ "errors": {
+ "items": {},
+ "type": "array"
+ },
+ "normalizedPreview": {
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "semanticAdvisor": {
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "skippedEffects": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "stagedFacts": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "valid": {
+ "type": "boolean"
+ },
+ "warnings": {
+ "items": {},
+ "type": "array"
+ },
+ "whatIf": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ }
+ },
+ "required": [
+ "valid",
+ "dryRun",
+ "skippedEffects"
+ ],
+ "type": "object"
+ }
+]v0.1.0kb_apply_plankb_checkkb_compile_intentkb_coveragekb_deletekb_find_gapskb_graphkb_ingest_proofkb_modelkb_plan_bootstrapkb_prepare_impact_reviewkb_querykb_searchkb_skillskb_statuskb_upsertScored across 16 tools
The surface has several clusters that could be confused (kb_query vs kb_search vs kb_graph; kb_check vs kb_coverage vs kb_find_gaps vs kb_status; kb_model vs kb_compile_intent vs kb_plan_bootstrap). However, the descriptions explicitly cross-reference each other with 'use X instead of Y' guidance, making the boundaries clear to an attentive agent. Minor overlap remains but is well managed.
All names share a consistent kb_ prefix and snake_case formatting, which is predictable. The only deviation is a mix of verb-style names (kb_query, kb_delete, kb_upsert) and noun-style names (kb_graph, kb_status, kb_skills), but each is readable and purposeful.
Sixteen tools is slightly above the ideal range but justified by a genuinely broad domain spanning query, traversal, mutation, planning, validation, coverage, proof ingestion, and review preparation. No tool appears redundant enough to clearly warrant removal, though the set is on the heavy side.
The surface covers the full KB lifecycle: read (query/search/graph/status), write (upsert/delete), plan-and-apply (bootstrap/compile/apply), validation and coverage (check/find_gaps/coverage/model), plus proof ingestion, impact review, and skills. Few obvious gaps remain beyond possible bulk import/export or direct schema management, which are minor.
Requirements authority for AI coding agents: binding requirements and acceptance criteria.
Provenance-first database for teams and agents: every value carries sources, rules and coverage.
Project memory for coding agents: requirements, decisions, code graph and delivery telemetry.
Spec-driven development for AI coding agents: live requirements, stories and traceability over MCP
