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.mdC-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.mdC-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.mdC-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.mdWhere 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.