The claims ledger
Every claim, and where it stops.
This page is generated from site/claims.json, the same file the landing page renders from. A claim cannot be written directly into a page: it is pulled from this ledger, where it is bound to the tests that prove it and to the boundary that travels with it. A claim that loses its evidence, or its limitation, fails the build.
Measured against bffb1c2 on 2026-09-19 — 2196 tests passing, 0 failing.
Why a page like this exists
The repository already worked this way; the marketing had to catch up.
“Every claim in the docs, the ADR, the PR body and the JTBD matrix traces to a merged test — a capability and its limitation are stated in the same breath.”
— AGENTS.md, definition of done. A landing page is the surface where that rule is easiest to break and most expensive to break, so it is enforced there by the same script that builds the page.
Capabilities
Chips name the jobs-to-be-done row, the test files and the repository facts behind each claim. Every path is real and checked to exist before the site will build.
| ID | Claim, and its limit | Evidence |
|---|---|---|
| C-01 | Write a module manifest; the agent turns it into a migration, a service, a REST resource, an SDK method and Admin screens — with no page code. LimitGenerated CRUD only. The factory does not generate workflows or approvals for a custom object — that is still handwritten (JTBD-06, partially supported). |
JTBD-01tests/module-factory-e2e.test.jstests/generated-api-e2e.test.jstests/admin-modules.test.jstests/admin-core.test.jsdocs/MODULE_FACTORY.mddocs/ADMIN.md |
| C-02 | Generated objects reference each other: a foreign key, runtime target validation, schema metadata and an Admin selector, all from one field declaration. LimitGenerated-to-generated many-to-one only. Many-to-many, inverse collections, cascade delete and generated-to-core references do not exist. |
JTBD-01btests/reference-fields-e2e.test.jstests/reference-resolver.test.jstests/module-factory.test.jsdocs/MODULE_FACTORY.md |
| C-03 | Commercial policy is deterministic code, not a model's judgement: a renewal at or above the threshold stops and waits for a named human. LimitProven for the built-in renewal object and its single value threshold. A general policy engine over arbitrary custom objects does not exist. |
JTBD-02tests/workflow.test.jstests/api.test.jsARCHITECTURE.mdDECISIONS.md |
| C-04 | The agent cannot approve on the human's behalf. A test asserts the refusal, so the boundary is a property of the system rather than a promise in a README. LimitIn local-development mode the actor is asserted, not authenticated: no authentication ships, so an actor header there is not an identity. This holds a boundary against an honest agent, not against an attacker with network access. |
JTBD-02tests/workflow.test.jsARCHITECTURE.md |
| C-05 | Opportunities move through code-first pipeline stages under a server-authoritative action — the client asks, the server decides. LimitPipelines are proven on the built-in Opportunity module. Configurable pipelines for generated custom objects are not claimed. |
JTBD-03tests/opportunity-pipeline-e2e.test.jstests/pipeline-contract.test.jstests/admin-pipeline.test.jsdocs/ACTIONS.md |
| C-06 | A lead is captured, scored, routed, qualified and converted into Company, Contact and Opportunity through explicit actions, each one atomic and audited. LimitEnrichment runs against a fixture provider — no real external data source is wired. The Lead model is the starter's, not a built-in core module. |
JTBD-04, JTBD-05, JTBD-05b, JTBD-LI-01, JTBD-LI-02, JTBD-LI-04tests/lead-qualification-e2e.test.jstests/lead-conversion-e2e.test.jstests/lead-intelligence-e2e.test.jsdocs/LEAD_INTELLIGENCE.md |
| C-07 | Scoring is explainable and versioned: every score carries the fingerprint of the model version that produced it, so a number from last quarter can still be accounted for. LimitDeterministic weighted rules, not a machine-learning model. Nothing trains, fits or backtests. |
JTBD-LI-02, JTBD-LI-07tests/lead-intelligence-e2e.test.jstests/intelligence-contract.test.jsdocs/LEAD_INTELLIGENCE.md |
| C-08 | Quotes price on the server from a catalog — one-time and recurring, flat, per-unit, volume and graduated tiers — and freeze into an immutable version when a discount goes for approval. LimitCatalog sync runs against a fixture provider; no real external catalog (Stripe, Zuora, ERP) is connected. Money is integer cents with no FX — currencies are never summed. |
JTBD-CO-01, JTBD-CO-03tests/commercial-e2e.test.jstests/commercial-contract.test.jstests/admin-quotes.test.jsdocs/COMMERCIAL_OPERATIONS.md |
| C-09 | A signature envelope produces verified events and a hashed signed artifact, and exactly one immutable Order is built from the approved quote version. LimitA fixture signature provider with a test-only webhook key. No DocuSign, Adobe Sign or Dropbox Sign adapter exists, and the artifact hash is provider-reported rather than independently recomputed. |
JTBD-CO-07tests/signature-order-e2e.test.jstests/signature-contract.test.jstests/admin-signature.test.jsdocs/SIGNATURE_ORDER.md |
| C-10 | A signed Order activates into a Commercial Contract, an immutable contract version, a Subscription and explicitly pending delivery and service obligations — every component classified, never guessed. LimitTerms frozen into the signed quote document retain signed-order provenance; legacy orders without signed terms can use explicitly labelled post-signature operational metadata. Operational dates are never promoted to signed terms. Governed renewal and amendment execution creates a successor agreement from its own signed Order, with immutable lineage and a derived line delta. Historical contracts and subscriptions are not edited. There is no automatic renewal, cancellation execution, billing or customer notification. |
JTBD-CS-01, JTBD-CS-02tests/contracts-activation-e2e.test.jstests/contracts-contract.test.jstests/admin-contracts.test.jstests/lifecycle-amendment-execution-e2e.test.jstests/lifecycle-amendment-execution.test.jstests/signed-terms-e2e.test.jsdocs/CONTRACT_ACTIVATION.mddocs/RENEWAL_AMENDMENT.md |
| C-11 | Pending obligations hand over into a Delivery Project with work packages, milestones and an optional partner — atomically, idempotently, and across a package boundary the kernel never learns about. LimitIt hands work over and runs it through human-driven transitions. Nothing schedules, staffs, computes percent complete or bills. Deliverables and recorded customer acceptance exist as of M14b2, and acceptance there is evidence a user actor recorded — never an authenticated customer, a legal signature or authorization to bill. |
JTBD-DS-01tests/delivery-handover-e2e.test.jstests/delivery-execution-e2e.test.jstests/admin-delivery.test.jsdocs/DELIVERY_HANDOVER.md |
| C-12 | Delivery records what it consumed: append-only time and expense evidence, costed server-side by a versioned fingerprinted policy, with a reproducible contribution estimate grouped by currency. LimitDeliberately not a margin: no revenue recognition, no cost of goods sold, no ARR/MRR/TCV, no annualization, no FX. A project carrying a recurring obligation returns no estimate at all and says why. |
JTBD-DS-06, JTBD-DS-07tests/delivery-economics-e2e.test.jsdocs/DELIVERY_ECONOMICS.md |
| C-24 | A pending service obligation activates into operational coverage and an immutable entitlement; support cases then move through a declared transition table with elapsed-time SLA evidence and human-recorded escalation. LimitNo authenticated customer portal, notification delivery, business-hours calendar or automatic escalation ships. SLA evidence records elapsed-time observations; it is not a contractual breach determination, and a recorded escalation routes to nobody. |
JTBD-SV-01, JTBD-SV-03, JTBD-SV-07tests/service-operations-e2e.test.jstests/service-operations-evidence.test.jstests/service-operations-integration.test.jsdocs/SERVICE_OPERATIONS.mdexamples/scenarios/service-sla-escalation.scenario.json |
| C-13 | A customer-authored domain package attaches and detaches with the kernel's fingerprint unchanged, and reaches another package only through a capability it declares. LimitThe scaffold that starts one writes an empty package and nothing else: no business logic, no composition, no global identity-uniqueness check. There is no registry, no marketplace, no publication and no sandboxing — package code runs with the host process's authority. Detaching leaves its data behind; there is no uninstall. |
JTBD-PK-01, JTBD-PK-02tests/package-contract.test.jstests/custom-package-e2e.test.jstests/contracts-registry-review.test.jsdocs/PACKAGE_AUTHORING.md |
| C-14 | One command tells an agent what an application actually is — packages, capabilities, resources, actions, policies, providers — read from checked-in source, in a single deterministic JSON report. LimitSource-only and read-only. It never opens the database, contacts a provider, reads a secret, or reports runtime, CI or authorization state — and it lists those blind spots as machine-readable limitations in its own output. |
JTBD-AX-01, JTBD-AX-02tests/app-inspect.test.jsdocs/APPLICATION_INSPECTION.mddocs/AGENT_HARNESS_COMPATIBILITY.md |
| C-22 | One command composes the whole thing and then inspects it: 76 modules, 9 packages, 71 resources, 64 actions, 7 policies and 1 providers, applied from manifests and driven end to end — then it prints the eleven things the inspector says it cannot see. LimitIt composes the starter's application, not yours, and it runs entirely locally against SQLite with no authentication. The counts describe what that starter applies; a different composition gives different numbers. Wall-clock time varies by machine and is deliberately not claimed. |
tests/app-inspect.test.jstests/contracts-activation-e2e.test.jstests/delivery-economics-e2e.test.jsdocs/APPLICATION_INSPECTION.mdnpm run tour runs examples/starters/b2b-lead-qualification/install.mjs, which CI runs on every push, into a directory it keepsthe counts are the app inspect report of that composed projectscripts/tour.js exits non-zero if the composed application is ever empty |
| C-21 | The same refusal holds where the money is: an agent actor asking to approve a discounted quote is refused with a 403, and only a human user actor can decide. LimitThe assertion lives inside a composite end-to-end test rather than a test named for it, so the citation is a file and a line rather than a test name. Extracting it into a named test is tracked in docs/strategy/GO_TO_MARKET.md; until then, cite the line. |
JTBD-CO-03tests/commercial-e2e.test.jsdocs/COMMERCIAL_OPERATIONS.md |
| C-15 | A Solution Plan is a checked-in file with a contract and a canonical fingerprint, validated against a real inspection — so a plan written against a composition that has since moved reports itself stale. LimitA document contract, not a planner and not a runtime. Nothing executes a plan, and the validator refuses a plan that carries a command. |
JTBD-AX-03tests/solution-plan.test.jsdocs/SOLUTION_PLAN.md |
| C-16 | Every mutation goes through a module service or a named workflow, and leaves an audit event and a step-level trace behind it. LimitAudit records what the process did under an asserted actor. It is not a tamper-evident or externally attestable log, and it is not a compliance control. |
JTBD-02tests/workflow.test.jstests/action-runtime-semantics.test.jstests/event-bus-outbox.test.jsARCHITECTURE.mddocs/ACTIONS.md |
| C-17 | SQLite is Node's built-in node:sqlite. PostgreSQL requires one pinned runtime driver, pg@8.23.0. There is no ORM, no query builder, no build step and no framework underneath your framework. LimitApplications that select PostgreSQL carry pg@8.23.0. The SQLite path still needs no third-party driver. This is not a production-readiness claim and not shared-database tenancy; composition is dedicated-database, not row tenancy. |
tests/spine-v2-m3b-postgresql-adapter.test.jstests/api.test.jsARCHITECTURE.mdAGENTS.mdpackage.json.dependencies is exactly { pg: "8.23.0" }SQLite via node:sqlitethe HTTP server and test runner are Node built-insPostgreSQL uses the pinned pg@8.23.0 driver; there is no ORM |
| C-18 | The MCP server exposes project context and narrow write tools to a coding agent; anything that generates code or destroys state is dry-run unless you pass an explicit apply flag. LimitStdio only, local only. There is no hosted or authenticated MCP endpoint, and the server inherits the local process's authority. |
JTBD-AX-02tests/mcp.test.jstests/scaffold.test.jsdocs/MCP.md |
| C-19 | Generated modules evolve without rewriting history: explicit revisions, a checked-in state file and append-only named migrations. LimitThe view is source-only: what the checked-in revisions and migrations say is knowable; what a particular database has actually applied is not. |
tests/module-evolution.test.jstests/module-evolution-factory.test.jstests/module-migrations.test.jsdocs/MODULE_EVOLUTION.md |
| C-20 | The verification gate runs on every push — source checks and then the whole test suite — covering happy paths and the policy boundaries that matter: hostile input, transaction rollback, idempotency, concurrency and immutability among them. LimitA test count measures effort, not correctness — read the adversarial-review categories in docs/QUALITY_GATES.md to see what is actually attacked. Real-browser tests are run manually and are not in CI. |
docs/QUALITY_GATES.mdmeasuredAgainst in this file records the run: npm run verify, green, at the commit named there, with a fingerprint of the tests/ tree it was taken over.github/workflows/ci.yml runs verify and smoke on push and pull_request, and runs the public-claims gate over full history so the measurement can be traced |
| C-23 | Five rules can be removed on purpose in one command, and the suite catches every one in about two seconds — naming the test that caught it. Anything that survives is reported as a gap, not omitted. LimitIt falsifies six named rules, not the claims in this ledger, and it proves only that a test holds each one — a rule that is wrong but faithfully defended passes every mutation. It is not mutation testing: nothing is generated or sampled, and no score is derived. |
tests/falsify.test.jstests/module-factory.test.jstests/workflow.test.jsdocs/FALSIFY.mdnpm run falsify at 6489982: 5 caught, 0 survived, 0 stale, 2.2snpm run falsify --only delivery-cost-rounding: caught by 'cost arithmetic is exact at every boundary' in 108.3sthe run refuses to start over uncommitted target files and verifies every restore byte-for-byte |
Standing limitations
These are not per-feature caveats but properties of the project as a whole. They are the first thing to read, not the last.
L-01 · No authentication ships: the framework authenticates nobody.
Production Spine v1 (ADR-038) gives the framework verified identity, organizations and memberships, server-authoritative authorization and one tenant per application instance — so tenancy and authorization now exist and are enforced. What does not exist is authentication: no login, password, session or OIDC implementation ships, and a deployment must supply the adapter that verifies the request. Production mode refuses to start without one. In local-development mode an actor header is accepted as an assertion and is not an identity, which is the default developer posture. This is not shared-database multi-tenancy and it is not a readiness claim.
JTBD-15tests/production-spine.test.jstests/actor-fails-closed.test.jsdocs/PROJECT_STATUS.mdREADME.mdDECISIONS.mdcrm app inspect reports a productionPosture that refuses to be read as a readiness claimL-02 · Not shared-database tenancy.
createAccordoAppAsync can boot one tenant onto dedicated PostgreSQL databases. Shared-database row-level tenancy is not implemented, and this is not a production-readiness claim.
docs/PROJECT_STATUS.mddocs/strategy/PLATFORM_CAPABILITIES.mdL-03 · The build benchmark has not been run.
The protocol is designed and published; no Successful Agent Build Rate exists yet. Any number you see quoted for this project is not ours.
docs/strategy/CRM_BUILD_BENCHMARK.mddocs/PROJECT_STATUS.mdL-04 · Timers exist; a service that runs them for you does not.
Durable jobs, a transactional outbox and scheduled asks exist for self-hosted applications that explicitly start a worker. Nothing autostarts; a timer opens an ask, never makes a decision, and no managed worker service or recurrence is included.
JTBD-07, JTBD-10docs/strategy/JOBS_AND_OUTBOX.mdL-05 · No email, calendar or marketing integrations.
An in-memory notification provider contract exists. MK1 marketing records supplied funnel observations and human-reviewed proposals only; it has no sending, publishing or spending path.
JTBD-14tests/marketing-no-external-effect.test.jstests/marketing-e2e.test.jsdocs/strategy/INTEGRATION_RUNTIME.mdL-06 · Bounded customer imports and logical identity; incomplete data operations.
Customer Data Foundation supports bounded JSON imports with preview/apply, per-row receipts and idempotency, deterministic duplicate candidates, and human-governed canonical identity as logical links. It does not provide CSV ingestion, physical merge, complete export/erasure, bulk editing, saved views or global search.
tests/customer-data-foundation.test.jsdocs/benchmarks/CRM_JTBD_MATRIX.mdL-08 · Ownership means vendored source: there is no framework dependency to bump.
The published create-accordo@0.1.0 scaffolds vendored source; it is the August 19 snapshot, not the current repository feature set. Use a current source checkout for the capabilities described here; upgrades require merging source (L-08). The framework is copied into the project, not installed as a framework library dependency. The accordo npm name is an empty reservation; the @accordo scope is claimed and deliberately empty.
tests/project-bootstrap.test.jsdocs/PROJECT_STATUS.mddocs/plans/project-bootstrap-installability.mdthe project bootstrap writes a project from an empty directory, dry-run unless --applytests/create-accordo-package.test.js packs the publication twice, byte-identically, installs it offline and runs the generated project's own checkssite/brand.json records the registry status and the source status as two separate fields, and scripts/distribution-check.js fails if either disagrees with the treepublication is staged from CI through OIDC trusted publishing and goes live only after a human approves the staged version with 2FAL-09 · Personal-data readiness requires deployment work beyond the foundation.
Customer Data Foundation supplies bounded import and identity governance, not complete personal-data operations. Authentication must be supplied by the deployment, and complete subject export and erasure remain absent; the framework alone does not establish compliance or suitability for real customer data. Lead scoring remains deterministic, versioned and explainable.
JTBD-15tests/lead-intelligence-e2e.test.jstests/customer-data-foundation.test.jsdocs/strategy/DATA_GOVERNANCE.mddocs/benchmarks/CRM_JTBD_MATRIX.mdCustomer Data Foundation records bounded imports and human-governed logical canonical identity without deleting or rewriting source recordsComplete subject export and erasure are not supplied by Customer Data Foundationscoring is a deterministic weighted model with a persisted version fingerprint (C-07)L-07 · This is a framework, not a product you sign up for.
There is no hosted CRM, no free tier and no account. The output is an application in your repository that you run.
PRODUCT.mddocs/strategy/CATEGORY.mdL-10 · Nothing bills.
No invoice, payment, tax, usage rating, proration or revenue recognition exists, and MRR, ARR and TCV are not derived from contract data.
JTBD-DS-10, JTBD-CS-05docs/strategy/EXECUTION_ROADMAP.mddocs/benchmarks/CRM_JTBD_MATRIX.mdEXECUTION_ROADMAP.md lists invoicing, billing, payment, usage rating, proration, tax and FX as explicitly deferredpackages/contracts/modules/subscription.module.json describes itself as a commercial activation record, not a billing engine, with no invoice schedule, usage rating, proration, payment, renewal or cancellation stateJTBD-DS-10 (activate billing on accepted milestones) and JTBD-CS-05 (calculate MRR, ARR and TCV from real contract data) both read 'not supported'L-11 · Marketing proposals are local evidence; campaign execution is absent.
The optional MK1 package records supplied funnel counts, derives a drop insight and prepares a complete-or-refused proposal for human approval. It performs no audience execution, consent enforcement, sending, publishing, spending, scheduling or attribution. JTBD row promotion remains a separate review.
JTBD-MK-01tests/marketing-e2e.test.jstests/marketing-no-external-effect.test.jsdocs/strategy/MARKETING_GROWTH_OPERATIONS.mddocs/benchmarks/CRM_JTBD_MATRIX.mdpackages/marketing is optional and the default generated domain registry is emptyMK1 approval creates local immutable evidence and declares no provider or external operationHow to check us
Don't take the ledger's word for it.
# clone, install nothing, run everything git clone https://github.com/khaoss85/agent-crm.git my-crm && cd my-crm npm run verify # 2196 tests npm run smoke # the approval demo, asserted # ask the framework what it thinks it is npm run crm -- app inspect --json | jq '.limitations' # rebuild this site and re-check every claim on it npm run site:check
The third command is the one worth running. app inspect reports its own blind spots as machine-readable limitation codes — that it never opened the database, never contacted a provider, never read a secret, and can report no runtime or authorization state. A tool that lists what it cannot see is a tool you can reason about.
What has actually been measured
Two instruments, two different answers.
The build benchmark — can an agent turn a CRM brief into a working application — is designed, published and has not been run. No success rate exists, and any number you see quoted for this project was invented somewhere else.
A narrower instrument has run: a tool-selection panel asking whether a coding agent, given a plain business goal, picks the right framework command instead of assembling an answer by hand. Its protocol was frozen and fingerprinted before the first cell ran, every expected outcome was pre-registered in a commit that precedes every run, and the receipts are all committed — including the 52 planned cells that could not run because two of the three agent products were not installed, and one run that hit its turn cap. It contains no success rate by design: one measured arm is a pilot, not a comparison, and the record says so about itself. It measures agent behaviour on this repository, never framework capability, and it licenses no ranking of any product.
That is the discipline the rest of this page rests on: the scoreboard is built and published before the first result, the parts that hurt are committed next to the parts that flatter, and a figure this project has not measured does not appear here.