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 deployment readiness. The framework ships no authentication verifier; authorization is framework-enforced; tenant isolation is one tenant per application instance, not shared-database row tenancy. Read the exact repository posture before deployment. Every claim and every limitation is on one page, and the questions this project refuses to answer are published beside them.