{ "answersContract": 1, "generatedFrom": "site/answers.json and site/claims.json", "sourceVisibility": { "repository": "https://github.com/khaoss85/agent-crm", "note": "Evidence paths resolve in the public repository." }, "questions": [ { "slug": "can-an-agent-approve-a-deal-or-discount", "question": "Can a coding agent approve a deal or a discount on my behalf?", "answer": "No. Commercial policy is deterministic code rather than a model's judgement — a renewal at or above the threshold stops and waits for a named human (C-03) — and a test asserts the refusal, so the boundary is a property of the system rather than a promise in a README (C-04). The same refusal holds where the money is: an agent actor calling quote.approve is rejected with status 403 and code HUMAN_APPROVAL_REQUIRED, and only a human user actor can decide (C-21). The scope is exactly this: the actor is asserted, not authenticated — there is no auth, tenancy or RBAC, and an actor header is not identity (L-01) — so it holds a boundary against an honest agent, not against an attacker with network access, and the threshold policy is proven on the built-in renewal object with a single value threshold.", "claims": [ "C-03", "C-04", "C-21" ], "limitations": [ "L-01" ], "snippet": "No. A discount or a renewal at the threshold stops and waits for a named human. The actor is asserted, not authenticated: no auth, tenancy or RBAC.", "url": "https://accordo.dev/answers/can-an-agent-approve-a-deal-or-discount.html", "evidence": [ { "id": "C-03", "text": "Commercial policy is deterministic code, not a model's judgement: a renewal at or above the threshold stops and waits for a named human.", "limitation": "Proven for the built-in renewal object and its single value threshold. A general policy engine over arbitrary custom objects does not exist.", "evidence": { "jtbd": "JTBD-02", "tests": [ "tests/workflow.test.js", "tests/api.test.js" ], "docs": [ "ARCHITECTURE.md", "DECISIONS.md" ] } }, { "id": "C-04", "text": "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.", "limitation": "The actor is asserted, not authenticated: there is no auth, tenancy or RBAC, and an actor header is not identity. This holds a boundary against an honest agent, not against an attacker with network access.", "evidence": { "jtbd": "JTBD-02", "tests": [ "tests/workflow.test.js" ], "docs": [ "ARCHITECTURE.md" ], "testName": "approval workflow rejects an agent pretending to make the human decision" } }, { "id": "C-21", "text": "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.", "limitation": "The 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.", "evidence": { "jtbd": "JTBD-CO-03", "tests": [ "tests/commercial-e2e.test.js" ], "docs": [ "docs/COMMERCIAL_OPERATIONS.md" ], "testName": "commercial e2e: approval boundary, revise/version-2, concurrency, fault injection, provider failures, drift", "assertion": "tests/commercial-e2e.test.js — quote.approve with actor { type: 'agent' } rejects with status 403 and code HUMAN_APPROVAL_REQUIRED" } }, { "id": "L-01", "text": "The server is local-development-only. An actor header is an assertion, not an identity. Do not expose it to a network.", "limitation": null, "evidence": { "jtbd": "JTBD-15", "docs": [ "docs/PROJECT_STATUS.md", "README.md" ], "repoFacts": [ "crm app inspect reports productionPosture: local development only" ] } } ] }, { "slug": "can-i-run-this-in-production", "question": "Can I deploy this and let my team log into it?", "answer": "No. There is no authentication, tenancy or RBAC; the HTTP server is local-development-only and an actor header is an assertion rather than an identity, so it must not be exposed to a network (L-01). Persistence is Node's built-in SQLite adapter — PostgreSQL is on the Production Spine track and is not implemented (L-02). Even the fully composed starter application runs entirely locally against SQLite with no authentication (C-22), and there is no hosted CRM, free tier or account to sign up to (L-07).", "claims": [ "C-22" ], "limitations": [ "L-01", "L-02", "L-07" ], "snippet": "No. No authentication, tenancy or RBAC, the server is local-development-only and an actor header is not an identity. SQLite only, nothing to sign up to.", "url": "https://accordo.dev/answers/can-i-run-this-in-production.html", "evidence": [ { "id": "C-22", "text": "One command composes the whole thing and then inspects it: 70 modules, 6 packages, 41 resources, 56 actions, 7 policies and 5 providers, applied from manifests and driven end to end — then it prints the eleven things the inspector says it cannot see.", "limitation": "It 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.", "evidence": { "tests": [ "tests/app-inspect.test.js", "tests/contracts-activation-e2e.test.js", "tests/delivery-economics-e2e.test.js" ], "docs": [ "docs/APPLICATION_INSPECTION.md" ], "repoFacts": [ "npm run tour runs examples/starters/b2b-lead-qualification/install.mjs, which CI runs on every push, into a directory it keeps", "the counts are the app inspect report of that composed project", "scripts/tour.js exits non-zero if the composed application is ever empty" ] } }, { "id": "L-01", "text": "The server is local-development-only. An actor header is an assertion, not an identity. Do not expose it to a network.", "limitation": null, "evidence": { "jtbd": "JTBD-15", "docs": [ "docs/PROJECT_STATUS.md", "README.md" ], "repoFacts": [ "crm app inspect reports productionPosture: local development only" ] } }, { "id": "L-02", "text": "Persistence is Node's built-in SQLite adapter. PostgreSQL is on the Production Spine track and is not implemented.", "limitation": null, "evidence": { "docs": [ "docs/PROJECT_STATUS.md", "docs/strategy/PLATFORM_CAPABILITIES.md" ] } }, { "id": "L-07", "text": "There is no hosted CRM, no free tier and no account. The output is an application in your repository that you run.", "limitation": null, "evidence": { "docs": [ "PRODUCT.md", "docs/strategy/CATEGORY.md" ] } } ] }, { "slug": "can-an-agent-add-a-custom-crm-object", "question": "Can a coding agent add a custom CRM object without me writing page code?", "answer": "For CRUD, yes: a module manifest becomes a migration, a service, a REST resource, an SDK method and Admin screens with no page code (C-01), and one field declaration gives a generated object a foreign key, runtime target validation, schema metadata and an Admin selector (C-02). References are generated-to-generated many-to-one only — many-to-many, inverse collections, cascade delete and generated-to-core references do not exist. What is not generated is the interesting half: workflows and approvals for a custom object are still handwritten, and pipeline stages are proven on the built-in Opportunity module, with configurable pipelines for generated custom objects not claimed (C-05). Changing an object later goes through explicit revisions, a checked-in state file and append-only named migrations, but that view is source-only — what a particular database has actually applied is not knowable from it (C-19).", "claims": [ "C-01", "C-02", "C-05", "C-19" ], "limitations": [], "snippet": "For CRUD, yes: a manifest becomes migration, service, REST, SDK and Admin screens with no page code. Not generated: workflows and approvals for that object.", "url": "https://accordo.dev/answers/can-an-agent-add-a-custom-crm-object.html", "evidence": [ { "id": "C-01", "text": "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.", "limitation": "Generated CRUD only. The factory does not generate workflows or approvals for a custom object — that is still handwritten (JTBD-06, partially supported).", "evidence": { "jtbd": "JTBD-01", "tests": [ "tests/module-factory-e2e.test.js", "tests/generated-api-e2e.test.js", "tests/admin-modules.test.js", "tests/admin-core.test.js" ], "docs": [ "docs/MODULE_FACTORY.md", "docs/ADMIN.md" ] } }, { "id": "C-02", "text": "Generated objects reference each other: a foreign key, runtime target validation, schema metadata and an Admin selector, all from one field declaration.", "limitation": "Generated-to-generated many-to-one only. Many-to-many, inverse collections, cascade delete and generated-to-core references do not exist.", "evidence": { "jtbd": "JTBD-01b", "tests": [ "tests/reference-fields-e2e.test.js", "tests/reference-resolver.test.js", "tests/module-factory.test.js" ], "docs": [ "docs/MODULE_FACTORY.md" ] } }, { "id": "C-05", "text": "Opportunities move through code-first pipeline stages under a server-authoritative action — the client asks, the server decides.", "limitation": "Pipelines are proven on the built-in Opportunity module. Configurable pipelines for generated custom objects are not claimed.", "evidence": { "jtbd": "JTBD-03", "tests": [ "tests/opportunity-pipeline-e2e.test.js", "tests/pipeline-contract.test.js", "tests/admin-pipeline.test.js" ], "docs": [ "docs/ACTIONS.md" ] } }, { "id": "C-19", "text": "Generated modules evolve without rewriting history: explicit revisions, a checked-in state file and append-only named migrations.", "limitation": "The view is source-only: what the checked-in revisions and migrations say is knowable; what a particular database has actually applied is not.", "evidence": { "tests": [ "tests/module-evolution.test.js", "tests/module-evolution-factory.test.js", "tests/module-migrations.test.js" ], "docs": [ "docs/MODULE_EVOLUTION.md" ] } } ] }, { "slug": "what-does-app-inspect-tell-an-agent", "question": "How does a coding agent find out what an application built with this actually contains?", "answer": "One command returns packages, capabilities, resources, actions, policies and providers as a single deterministic JSON report, read from checked-in source (C-14). It is source-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. Composing the starter and inspecting it gives 70 modules, 6 packages, 41 resources, 56 actions, 7 policies and 5 providers, then prints the eleven things the inspector says it cannot see (C-22). Those counts describe that starter's composition, not yours, it runs locally against SQLite with no authentication, and wall-clock time is deliberately not claimed.", "claims": [ "C-14", "C-22" ], "limitations": [], "snippet": "One command returns packages, capabilities, resources, actions, policies and providers as deterministic JSON. It never opens the database or reads a secret.", "url": "https://accordo.dev/answers/what-does-app-inspect-tell-an-agent.html", "evidence": [ { "id": "C-14", "text": "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.", "limitation": "Source-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.", "evidence": { "jtbd": "JTBD-AX-01, JTBD-AX-02", "tests": [ "tests/app-inspect.test.js" ], "docs": [ "docs/APPLICATION_INSPECTION.md", "docs/AGENT_HARNESS_COMPATIBILITY.md" ] } }, { "id": "C-22", "text": "One command composes the whole thing and then inspects it: 70 modules, 6 packages, 41 resources, 56 actions, 7 policies and 5 providers, applied from manifests and driven end to end — then it prints the eleven things the inspector says it cannot see.", "limitation": "It 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.", "evidence": { "tests": [ "tests/app-inspect.test.js", "tests/contracts-activation-e2e.test.js", "tests/delivery-economics-e2e.test.js" ], "docs": [ "docs/APPLICATION_INSPECTION.md" ], "repoFacts": [ "npm run tour runs examples/starters/b2b-lead-qualification/install.mjs, which CI runs on every push, into a directory it keeps", "the counts are the app inspect report of that composed project", "scripts/tour.js exits non-zero if the composed application is ever empty" ] } } ] }, { "slug": "can-an-agent-change-my-project-safely", "question": "If I point a coding agent at this, can it overwrite or destroy my project?", "answer": "The MCP server exposes project context and narrow write tools to a coding agent, and anything that generates code or destroys state is dry-run unless you pass an explicit apply flag (C-18) — so you can read the generated output before anything is written. It is stdio only and local only: there is no hosted or authenticated MCP endpoint, and the server inherits the authority of the process that starts it. Planning is separate from execution: 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 (C-15). That is a document contract, not a planner and not a runtime — nothing executes a plan, and the validator refuses a plan that carries a command.", "claims": [ "C-18", "C-15" ], "limitations": [], "snippet": "Anything that generates code or destroys state is dry-run unless you pass an explicit apply flag. Nothing executes a plan; the MCP server is local stdio only.", "url": "https://accordo.dev/answers/can-an-agent-change-my-project-safely.html", "evidence": [ { "id": "C-18", "text": "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.", "limitation": "Stdio only, local only. There is no hosted or authenticated MCP endpoint, and the server inherits the local process's authority.", "evidence": { "jtbd": "JTBD-AX-02", "tests": [ "tests/mcp.test.js", "tests/scaffold.test.js" ], "docs": [ "docs/MCP.md" ] } }, { "id": "C-15", "text": "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.", "limitation": "A document contract, not a planner and not a runtime. Nothing executes a plan, and the validator refuses a plan that carries a command.", "evidence": { "jtbd": "JTBD-AX-03", "tests": [ "tests/solution-plan.test.js" ], "docs": [ "docs/SOLUTION_PLAN.md" ] } } ] }, { "slug": "is-there-a-benchmark-for-agent-built-crms", "question": "Is there a benchmark showing how often a coding agent builds a working CRM with this?", "answer": "No. The build benchmark protocol is designed and published, but it has not been run, so no Successful Agent Build Rate exists and any number quoted for this project is not ours (L-03). What exists instead is a test suite: 701 tests run on every push, covering happy paths and the policy boundaries that matter — hostile input, transaction rollback, idempotency, concurrency and immutability among them (C-20). That count measures effort, not correctness, and real-browser tests are run manually and are not in CI.", "claims": [ "C-20" ], "limitations": [ "L-03" ], "snippet": "No. The protocol is published and has never been run, so no success rate exists and any number quoted for this project came from somewhere else.", "url": "https://accordo.dev/answers/is-there-a-benchmark-for-agent-built-crms.html", "evidence": [ { "id": "C-20", "text": "701 tests, run on every push, covering happy paths and the policy boundaries that matter — hostile input, transaction rollback, idempotency, concurrency and immutability among them.", "limitation": "A 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.", "evidence": { "repoFacts": [ "npm run verify at 9958ed9: 701 passing, 0 failing", ".github/workflows/ci.yml runs verify and smoke on push and pull_request" ], "docs": [ "docs/QUALITY_GATES.md" ] } }, { "id": "L-03", "text": "The protocol is designed and published; no Successful Agent Build Rate exists yet. Any number you see quoted for this project is not ours.", "limitation": null, "evidence": { "docs": [ "docs/strategy/CRM_BUILD_BENCHMARK.md", "docs/PROJECT_STATUS.md" ] } } ] }, { "slug": "how-do-i-check-these-claims-myself", "question": "How do I check that these claims are true instead of taking them on trust?", "answer": "Every claim in site/claims.json names the evidence that holds it — a test file, a document, or a named repository fact — and the limitation that travels with it, so each sentence resolves to something you can check. Run the suite — 701 tests on every push — and read docs/QUALITY_GATES.md for the adversarial-review categories, because the count itself measures effort rather than correctness (C-20). Then run falsify: five rules are removed on purpose in one command and the suite catches every one in about two seconds, naming the test that caught it, and anything that survives is reported as a gap rather than omitted (C-23). Its scope is narrow on purpose — it falsifies six named rules, not the claims in this ledger, it proves only that a test holds each rule, and a rule that is wrong but faithfully defended survives every mutation.", "claims": [ "C-20", "C-23" ], "limitations": [], "snippet": "Every claim names the evidence that holds it and the limitation that travels with it. Falsify removes six rules on purpose; it does not falsify the ledger.", "url": "https://accordo.dev/answers/how-do-i-check-these-claims-myself.html", "evidence": [ { "id": "C-20", "text": "701 tests, run on every push, covering happy paths and the policy boundaries that matter — hostile input, transaction rollback, idempotency, concurrency and immutability among them.", "limitation": "A 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.", "evidence": { "repoFacts": [ "npm run verify at 9958ed9: 701 passing, 0 failing", ".github/workflows/ci.yml runs verify and smoke on push and pull_request" ], "docs": [ "docs/QUALITY_GATES.md" ] } }, { "id": "C-23", "text": "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.", "limitation": "It 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.", "evidence": { "tests": [ "tests/falsify.test.js", "tests/module-factory.test.js", "tests/workflow.test.js" ], "docs": [ "docs/FALSIFY.md" ], "repoFacts": [ "npm run falsify at 6489982: 5 caught, 0 survived, 0 stale, 2.2s", "npm run falsify --only delivery-cost-rounding: caught by 'cost arithmetic is exact at every boundary' in 108.3s", "the run refuses to start over uncommitted target files and verifies every restore byte-for-byte" ] } } ] }, { "slug": "does-every-change-leave-an-audit-trail", "question": "Does every change leave an audit trail and a trace?", "answer": "Yes. Every mutation goes through a module service or a named workflow, and leaves an audit event and a step-level trace behind it (C-16). That routing is also what makes the approval refusal enforceable rather than advisory: a test asserts that an agent cannot make the human's decision (C-04). What the audit is not: it records what the process did under an asserted actor, so it is not a tamper-evident or externally attestable log and it is not a compliance control — there is no authentication, tenancy or RBAC behind the actor it records (L-01).", "claims": [ "C-16", "C-04" ], "limitations": [ "L-01" ], "snippet": "Yes — every mutation leaves an audit event and a step-level trace. It is not tamper-evident, not externally attestable, and no authentication sits behind it.", "url": "https://accordo.dev/answers/does-every-change-leave-an-audit-trail.html", "evidence": [ { "id": "C-16", "text": "Every mutation goes through a module service or a named workflow, and leaves an audit event and a step-level trace behind it.", "limitation": "Audit 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.", "evidence": { "jtbd": "JTBD-02", "tests": [ "tests/workflow.test.js", "tests/action-runtime-semantics.test.js", "tests/event-bus-outbox.test.js" ], "docs": [ "ARCHITECTURE.md", "docs/ACTIONS.md" ] } }, { "id": "C-04", "text": "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.", "limitation": "The actor is asserted, not authenticated: there is no auth, tenancy or RBAC, and an actor header is not identity. This holds a boundary against an honest agent, not against an attacker with network access.", "evidence": { "jtbd": "JTBD-02", "tests": [ "tests/workflow.test.js" ], "docs": [ "ARCHITECTURE.md" ], "testName": "approval workflow rejects an agent pretending to make the human decision" } }, { "id": "L-01", "text": "The server is local-development-only. An actor header is an assertion, not an identity. Do not expose it to a network.", "limitation": null, "evidence": { "jtbd": "JTBD-15", "docs": [ "docs/PROJECT_STATUS.md", "README.md" ], "repoFacts": [ "crm app inspect reports productionPosture: local development only" ] } } ] }, { "slug": "can-i-put-real-customer-data-in-it", "question": "Can I put real customer data in it?", "answer": "No. A CRM is a personal-data system by definition, and this one has no authentication, no tenancy, no export and no erasure path, so a data-subject access or deletion request cannot be serviced with it; the data-governance track is designed and unimplemented (L-09). There is also no import, export, dedupe, merge, bulk edit, saved views or global search (L-06), and the server is local-development-only with an actor header that is an assertion rather than an identity (L-01). The one thing that does hold today: lead scoring is deterministic and versioned, every score carrying the fingerprint of the model version that produced it, rather than a model's judgement about a person (C-07).", "claims": [ "C-07" ], "limitations": [ "L-09", "L-06", "L-01" ], "snippet": "No. No authentication, no tenancy, no export and no erasure path, so a deletion request cannot be serviced. No import, dedupe, merge or search either.", "url": "https://accordo.dev/answers/can-i-put-real-customer-data-in-it.html", "evidence": [ { "id": "C-07", "text": "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.", "limitation": "Deterministic weighted rules, not a machine-learning model. Nothing trains, fits or backtests.", "evidence": { "jtbd": "JTBD-LI-02, JTBD-LI-07", "tests": [ "tests/lead-intelligence-e2e.test.js", "tests/intelligence-contract.test.js" ], "docs": [ "docs/LEAD_INTELLIGENCE.md" ] } }, { "id": "L-09", "text": "A CRM is a personal-data system by definition, and this one has no authentication, no tenancy, no export and no erasure path — so there is no way to service a data-subject access or deletion request with it. Data governance is designed and unimplemented. The one thing that does hold today: lead scoring is deterministic, versioned and explainable, not a model's judgement about a person.", "limitation": null, "evidence": { "jtbd": "JTBD-15", "tests": [ "tests/lead-intelligence-e2e.test.js" ], "docs": [ "docs/strategy/DATA_GOVERNANCE.md", "docs/benchmarks/CRM_JTBD_MATRIX.md" ], "repoFacts": [ "DATA_GOVERNANCE.md records the whole track as design only", "no import or export exists (L-06)", "scoring is a deterministic weighted model with a persisted version fingerprint (C-07)" ] } }, { "id": "L-06", "text": "Table stakes in every commercial CRM, and none of them has a milestone yet. This is recorded deliberately rather than left for you to discover.", "limitation": null, "evidence": { "docs": [ "docs/benchmarks/CRM_JTBD_MATRIX.md" ] } }, { "id": "L-01", "text": "The server is local-development-only. An actor header is an assertion, not an identity. Do not expose it to a network.", "limitation": null, "evidence": { "jtbd": "JTBD-15", "docs": [ "docs/PROJECT_STATUS.md", "README.md" ], "repoFacts": [ "crm app inspect reports productionPosture: local development only" ] } } ] }, { "slug": "how-does-quoting-and-discount-approval-work", "question": "How does it price quotes and handle discount approval?", "answer": "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 (C-08). The approval is human by policy: an agent actor asking to approve a discounted quote is refused with status 403 and code HUMAN_APPROVAL_REQUIRED, and only a human user actor can decide (C-21). Two boundaries travel with it: catalog sync runs against a fixture provider with no real external catalog (Stripe, Zuora, ERP) connected, and money is integer cents with no FX — currencies are never summed. The refusal assertion also lives inside a composite end-to-end test rather than a test named for it, so it is cited by file and line rather than by test name.", "claims": [ "C-08", "C-21" ], "limitations": [], "snippet": "Quotes price on the server and freeze into an immutable version when a discount goes for approval, which only a human can give. The catalog is a fixture.", "url": "https://accordo.dev/answers/how-does-quoting-and-discount-approval-work.html", "evidence": [ { "id": "C-08", "text": "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.", "limitation": "Catalog 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.", "evidence": { "jtbd": "JTBD-CO-01, JTBD-CO-03", "tests": [ "tests/commercial-e2e.test.js", "tests/commercial-contract.test.js", "tests/admin-quotes.test.js" ], "docs": [ "docs/COMMERCIAL_OPERATIONS.md" ] } }, { "id": "C-21", "text": "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.", "limitation": "The 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.", "evidence": { "jtbd": "JTBD-CO-03", "tests": [ "tests/commercial-e2e.test.js" ], "docs": [ "docs/COMMERCIAL_OPERATIONS.md" ], "testName": "commercial e2e: approval boundary, revise/version-2, concurrency, fault injection, provider failures, drift", "assertion": "tests/commercial-e2e.test.js — quote.approve with actor { type: 'agent' } rejects with status 403 and code HUMAN_APPROVAL_REQUIRED" } } ] }, { "slug": "what-integrations-exist", "question": "Which external services does it integrate with?", "answer": "None. Every provider is an offline fixture: enrichment runs against a fixture provider with no real external data source wired (C-06), catalog sync against a fixture provider with no Stripe, Zuora or ERP connected (C-08), and signature against a fixture provider with a test-only webhook key, where the artifact hash is provider-reported rather than independently recomputed (C-09). No DocuSign, Adobe Sign or Dropbox Sign adapter exists. There is no email, calendar or marketing integration either — an in-memory notification provider contract exists, and no adapter sends anything to anyone (L-05).", "claims": [ "C-06", "C-08", "C-09" ], "limitations": [ "L-05" ], "snippet": "None. Every provider — enrichment, catalog, signature, notification — is an offline fixture. No DocuSign, Stripe, Zuora, ERP, email or calendar adapter exists.", "url": "https://accordo.dev/answers/what-integrations-exist.html", "evidence": [ { "id": "C-06", "text": "A lead is captured, scored, routed, qualified and converted into Company, Contact and Opportunity through explicit actions, each one atomic and audited.", "limitation": "Enrichment 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.", "evidence": { "jtbd": "JTBD-04, JTBD-05, JTBD-05b, JTBD-LI-01, JTBD-LI-02, JTBD-LI-04", "tests": [ "tests/lead-qualification-e2e.test.js", "tests/lead-conversion-e2e.test.js", "tests/lead-intelligence-e2e.test.js" ], "docs": [ "docs/LEAD_INTELLIGENCE.md" ] } }, { "id": "C-08", "text": "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.", "limitation": "Catalog 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.", "evidence": { "jtbd": "JTBD-CO-01, JTBD-CO-03", "tests": [ "tests/commercial-e2e.test.js", "tests/commercial-contract.test.js", "tests/admin-quotes.test.js" ], "docs": [ "docs/COMMERCIAL_OPERATIONS.md" ] } }, { "id": "C-09", "text": "A signature envelope produces verified events and a hashed signed artifact, and exactly one immutable Order is built from the approved quote version.", "limitation": "A 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.", "evidence": { "jtbd": "JTBD-CO-07", "tests": [ "tests/signature-order-e2e.test.js", "tests/signature-contract.test.js", "tests/admin-signature.test.js" ], "docs": [ "docs/SIGNATURE_ORDER.md" ] } }, { "id": "L-05", "text": "An in-memory notification provider contract exists. No adapter sends anything to anyone.", "limitation": null, "evidence": { "jtbd": "JTBD-14", "docs": [ "docs/strategy/INTEGRATION_RUNTIME.md" ] } } ] }, { "slug": "what-happens-after-the-order-is-signed", "question": "Does it cover what happens after a deal is signed?", "answer": "Partly, and each step names where it stops. A signature envelope produces verified events and a hashed signed artifact, and exactly one immutable Order is built from the approved quote version (C-09); that Order activates into a Commercial Contract, an immutable contract version, a Subscription and explicitly pending delivery and service obligations (C-10); those obligations hand over into a Delivery Project with work packages, milestones and an optional partner, atomically and idempotently (C-11), which records append-only time and expense evidence costed server-side by a versioned fingerprinted policy (C-12). Nothing bills, renews, amends or cancels — there is no scheduler, so auto-renew and notice periods are recorded and never fire — and nothing schedules, staffs, computes percent complete or bills. Deliverables and recorded customer acceptance do exist as of M14b2 — acceptance there is evidence a user actor recorded, never an authenticated customer, a legal signature or authorization to bill. The contribution estimate is deliberately not a margin: no revenue recognition, no cost of goods sold, no ARR/MRR/TCV, no annualization, no FX, and a project carrying a recurring obligation returns no estimate at all and says why.", "claims": [ "C-09", "C-10", "C-11", "C-12" ], "limitations": [], "snippet": "Partly: signature, immutable Order, contract, subscription, pending obligations, delivery, acceptance. Nothing bills or renews, and there is no scheduler.", "url": "https://accordo.dev/answers/what-happens-after-the-order-is-signed.html", "evidence": [ { "id": "C-09", "text": "A signature envelope produces verified events and a hashed signed artifact, and exactly one immutable Order is built from the approved quote version.", "limitation": "A 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.", "evidence": { "jtbd": "JTBD-CO-07", "tests": [ "tests/signature-order-e2e.test.js", "tests/signature-contract.test.js", "tests/admin-signature.test.js" ], "docs": [ "docs/SIGNATURE_ORDER.md" ] } }, { "id": "C-10", "text": "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.", "limitation": "The term is post-signature operational metadata, not a signed contractual term. Nothing bills, renews, amends or cancels: there is no scheduler, so auto-renew and notice periods are recorded and never fire.", "evidence": { "jtbd": "JTBD-CS-01, JTBD-CS-02", "tests": [ "tests/contracts-activation-e2e.test.js", "tests/contracts-contract.test.js", "tests/admin-contracts.test.js" ], "docs": [ "docs/CONTRACT_ACTIVATION.md" ] } }, { "id": "C-11", "text": "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.", "limitation": "It 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.", "evidence": { "jtbd": "JTBD-DS-01", "tests": [ "tests/delivery-handover-e2e.test.js", "tests/delivery-execution-e2e.test.js", "tests/admin-delivery.test.js" ], "docs": [ "docs/DELIVERY_HANDOVER.md" ] } }, { "id": "C-12", "text": "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.", "limitation": "Deliberately 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.", "evidence": { "jtbd": "JTBD-DS-06, JTBD-DS-07", "tests": [ "tests/delivery-economics-e2e.test.js" ], "docs": [ "docs/DELIVERY_ECONOMICS.md" ] } } ] }, { "slug": "does-it-run-scheduled-work-or-reminders", "question": "Does it send renewal reminders or run anything on a schedule?", "answer": "No. There is no scheduler, no task engine and no reminders: one follow-up Task is created inside lead qualification, and there is no recurring work, no delayed workflow and no queue (L-04). This reaches into the contract lifecycle — auto-renew dates and notice periods are recorded on an activated contract and never fire (C-10). Lead capture, scoring, routing, qualification and conversion happen through explicit actions that something calls, each one atomic and audited (C-06), not on a timer.", "claims": [ "C-10", "C-06" ], "limitations": [ "L-04" ], "snippet": "No. There is no scheduler, no task engine and no reminders. Auto-renew dates are recorded on an activated contract and never fire — nothing runs on a timer.", "url": "https://accordo.dev/answers/does-it-run-scheduled-work-or-reminders.html", "evidence": [ { "id": "C-10", "text": "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.", "limitation": "The term is post-signature operational metadata, not a signed contractual term. Nothing bills, renews, amends or cancels: there is no scheduler, so auto-renew and notice periods are recorded and never fire.", "evidence": { "jtbd": "JTBD-CS-01, JTBD-CS-02", "tests": [ "tests/contracts-activation-e2e.test.js", "tests/contracts-contract.test.js", "tests/admin-contracts.test.js" ], "docs": [ "docs/CONTRACT_ACTIVATION.md" ] } }, { "id": "C-06", "text": "A lead is captured, scored, routed, qualified and converted into Company, Contact and Opportunity through explicit actions, each one atomic and audited.", "limitation": "Enrichment 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.", "evidence": { "jtbd": "JTBD-04, JTBD-05, JTBD-05b, JTBD-LI-01, JTBD-LI-02, JTBD-LI-04", "tests": [ "tests/lead-qualification-e2e.test.js", "tests/lead-conversion-e2e.test.js", "tests/lead-intelligence-e2e.test.js" ], "docs": [ "docs/LEAD_INTELLIGENCE.md" ] } }, { "id": "L-04", "text": "One follow-up Task is created inside lead qualification. There is no recurring work, no delayed workflow, no queue — so nothing fires on a renewal notice period either.", "limitation": null, "evidence": { "jtbd": "JTBD-07, JTBD-10", "docs": [ "docs/strategy/JOBS_AND_OUTBOX.md" ] } } ] }, { "slug": "what-do-i-own-and-how-do-i-install-it", "question": "What do I actually own, and how do I install it?", "answer": "You own the source, and today that means copying it: there is a project bootstrap that runs from a checkout of the repository and no published package: the repository's bootstrap command scaffolds a project that boots, inspects and passes the project doctor, while the reserved `npm create` name still reaches an empty placeholder and installs nothing. Either way the framework is vendored into the project, so upgrading means merging, not bumping a version (L-08). What you are left with is a Node application with zero third-party runtime dependencies — Node 22 and a checkout, no build step, no bundler (C-17) — though that property belongs to the framework, not to whatever you add on top of it. A domain package you author attaches and detaches with the kernel's fingerprint unchanged and reaches another package only through a declared capability (C-13), but there is no scaffold, registry, marketplace or sandboxing, package code runs with the host process's authority, and detaching leaves its data behind. There is nothing to sign up for: no hosted CRM, no free tier, no account (L-07).", "claims": [ "C-17", "C-13" ], "limitations": [ "L-08", "L-07" ], "snippet": "You own the source, and today that means copying it: a bootstrap that scaffolds from a checkout, no published package, and upgrading means merging rather than bumping a version.", "url": "https://accordo.dev/answers/what-do-i-own-and-how-do-i-install-it.html", "evidence": [ { "id": "C-17", "text": "Zero third-party runtime dependencies. Node 22 and a checkout — no build step, no bundler, no framework underneath your framework.", "limitation": "Development dependencies and the eventual PostgreSQL adapter are separate questions. Having no runtime dependencies is a property of the framework, not of whatever you add on top of it.", "evidence": { "repoFacts": [ "package.json has no dependencies field", "SQLite via node:sqlite", "the HTTP server, test runner and database adapter are all Node built-ins" ], "tests": [ "tests/api.test.js" ], "docs": [ "ARCHITECTURE.md", "AGENTS.md" ] } }, { "id": "C-13", "text": "A customer-authored domain package attaches and detaches with the kernel's fingerprint unchanged, and reaches another package only through a capability it declares.", "limitation": "No scaffold, no registry, no marketplace, and no sandboxing — package code runs with the host process's authority. Detaching leaves its data behind; there is no uninstall.", "evidence": { "jtbd": "JTBD-PK-01, JTBD-PK-02", "tests": [ "tests/package-contract.test.js", "tests/custom-package-e2e.test.js", "tests/contracts-registry-review.test.js" ], "docs": [ "docs/PACKAGE_AUTHORING.md" ] } }, { "id": "L-08", "text": "There is a project bootstrap and there is no published package, and the two are different facts. The repository's bootstrap command scaffolds a project that boots, reports `valid` from `app inspect` and exits 0 from `project doctor`, offline and with no install — run from a checkout of this repository. The package published under the reserved npm name is still an empty 0.0.1 placeholder, so the `npm create` route installs nothing until a human publishes it. Either way the framework is vendored into the project rather than depended on by version: you own the result outright, and upgrading means merging, not bumping.", "limitation": null, "evidence": { "tests": [ "tests/project-bootstrap.test.js" ], "docs": [ "docs/PROJECT_STATUS.md", "docs/plans/project-bootstrap-installability.md" ], "repoFacts": [ "the project bootstrap writes a project from an empty directory, dry-run unless --apply", "tests/project-bootstrap.test.js bootstraps into a temporary directory and then runs app inspect, project doctor and the generated project's own checks against the result", "site/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 tree", "the published 0.0.1 tarball is an empty name reservation and this repository publishes nothing" ] } }, { "id": "L-07", "text": "There is no hosted CRM, no free tier and no account. The output is an application in your repository that you run.", "limitation": null, "evidence": { "docs": [ "PRODUCT.md", "docs/strategy/CATEGORY.md" ] } } ] } ], "refused": [ { "question": "Is it production-ready yet, and when will authentication, tenancy or PostgreSQL land?", "why": "L-01 and L-02 record the absences, but no claim or limitation carries a date, a milestone order or a commitment. 'Production Spine' is named as a track in L-02's text, not as a schedule, so any answer to the 'when' half would be invented." }, { "question": "What is the Successful Agent Build Rate — how often does a coding agent finish a working CRM with this?", "why": "L-03 states the benchmark has not been run and that any number quoted is not ours. A page shaped around the number would exist only to host a figure that does not exist. The accepted page 'is-there-a-benchmark-for-agent-built-crms' answers the meta-question honestly; this one cannot be answered at all." }, { "question": "How does this compare to Salesforce, HubSpot, Twenty, Odoo or a low-code CRM platform?", "why": "No claim or limitation makes any statement about another product. A comparison needs verified, dated competitor facts, and I have no internet access to establish them; docs/strategy/COMPETITOR_MAP.md exists but is strategy, not ledger evidence, so nothing in claims.json licenses a comparison sentence." }, { "question": "How long does it take an agent to build a CRM with this, and how fast is the framework?", "why": "C-22 states outright that wall-clock time varies by machine and is deliberately not claimed. The only timing in the ledger is C-23's 'about two seconds' for the fast falsify set, which is scoped to that command and cannot be generalised into a time-to-first-CRM." }, { "question": "How well does it scale — how many records, what throughput, what response times?", "why": "No claim or limitation measures performance or volume, and no load test exists on disk that I could cite. L-02 (SQLite only) constrains the answer but does not supply one." }, { "question": "Is it secure? Has it had a security review or penetration test?", "why": "The ledger records the absence of authentication (L-01) and states that audit is not tamper-evident and not a compliance control (C-16), but it makes no positive security claim and cites no review. A page titled 'is it secure' would invite an affirmative sentence that no C-xx supports." }, { "question": "Is it SOC 2 / GDPR / HIPAA compliant, and how do I service a DSAR?", "why": "L-09 says data governance is designed and unimplemented and that a data-subject access or deletion request cannot be serviced. There is no compliance programme, certification or control mapping in the ledger, so a compliance-shaped page would imply a process that does not exist. The honest fragment already lives in 'can-i-put-real-customer-data-in-it'." }, { "question": "How do I connect it to DocuSign, Stripe, HubSpot or my email provider?", "why": "A how-to page requires steps. C-09 and C-08 state those adapters do not exist and L-05 states no adapter sends anything to anyone, so every step would be fabricated. The negative version — 'what-integrations-exist' — is accepted instead." }, { "question": "How do I import or migrate my existing CRM data into it?", "why": "L-06 records that import, export, dedupe, merge and bulk edit do not exist. There is no path to document, and a migration guide is the single most damaging thing to invent for a system that has no export either." }, { "question": "Does it have reporting, dashboards, forecasting or pipeline analytics?", "why": "No claim or limitation covers reporting or aggregation. The sentence 'reporting or aggregation over generated modules' is absent appears in site/assets/llms.txt prose, not in claims.json, so under the rule that a public sentence comes only from the ledger there is nothing to answer with. Worth adding as an L-xx if this question recurs." }, { "question": "Which coding agent works best with it — Claude Code or Codex? Which model should I use?", "why": "Nothing in the ledger compares harnesses or models, and the benchmark that would measure it has not been run (L-03). Any preference stated would be a guess presented as a measurement." }, { "question": "What does it cost, what licence does it ship under, and is there a free tier?", "why": "L-07 establishes there is nothing to sign up for, but licence status is not a ledger entry — README.md says 'MIT today' with a final confirmation gated on an explicit human decision, which is precisely the kind of sentence that must not be frozen into a retrievable page ahead of that decision." }, { "question": "Who uses this in production, how many teams have adopted it, how many stars or downloads?", "why": "No adoption, usage or popularity fact exists anywhere in claims.json, and L-08 records that nothing is published, so there are no download numbers to have." }, { "question": "Can I give a coding agent a business goal and have it build the whole CRM unattended?", "why": "C-01 is scoped to generated CRUD with workflows and approvals still handwritten, and C-15 states explicitly that nothing executes a plan. An unattended end-to-end build is the exact capability the unrun benchmark (L-03) was designed to measure, so claiming it would be claiming the benchmark result." }, { "question": "Does an LLM decide anything at runtime — is this an 'AI CRM'?", "why": "Tempting, and half-answerable: C-03 says commercial policy is deterministic code rather than a model's judgement and C-07 says scoring is deterministic weighted rules rather than machine learning. But no claim or limitation states that nothing calls a model at request time anywhere in the runtime — that sentence lives in PRODUCT.md, llms.txt and OBJECTIONS.md, not in the ledger — so a page under this question would answer wider than its evidence. It becomes proposable the moment a C-xx covers the runtime as a whole." } ] }