Pre-launch. Not deployable to production. This page states what the tests prove and what is missing — nothing else.

Answer

Can a coding agent add a custom CRM object without me writing page code?

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).

What the ledger says, word for word

Each entry below is copied from site/claims.json, where it is bound to the evidence that holds it — a test file, a document, or a named repository fact — and to the limitation that travels with it. The answer above summarises these; these are the claim.

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-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-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

Where this stops

Nothing on this page implies the framework is deployable. There is no authentication, tenancy or RBAC, so it is local-development-only whatever any single answer says. Every claim and every limitation is on one page, and the questions this project refuses to answer are published beside them.