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

What ownership actually means here, and where it stops

Ownership means copying source today

People ask this as: own the CRM source my coding agent builds, without a vendor runtime underneath

Ownership here means the source is yours to keep, read and change, and today it means copying it. The project bootstrap scaffolds from a checkout of the repository and the published package is still an empty name reservation; either way the framework is vendored into the project, so upgrading means merging rather than bumping a version. What you get is MIT, Node 22 and a checkout with zero third-party runtime dependencies. What you do not get is the npm create story the roadmap describes, and that gap is L-08 on every surface rather than sold around.

Where this stops

Read this before the rest of the page. Every line below is a thing this does not do.

  • Ownership is not installation. The bootstrap scaffolds from a checkout, the reserved `npm create` name still installs nothing, and there is no versioned framework dependency — upgrading means merging changes into a copy.
  • Neither half of the ejection proof exists yet: there is no examples/ejected application and no test asserting a project still verifies green once the framework dependency is deleted.
  • Zero third-party runtime dependencies describes the framework, not your application. Everything you add, you carry.
  • The MIT confirmation covers this framework only. It decides nothing about a future managed offering and nothing about the licence of the code you generate.
  • Owning the source does not make it safe to deploy. No authentication, no tenancy, no RBAC, SQLite only, and no path to service a data-subject request.
  • A package detaches without touching the kernel, but its data stays behind and there is no export to take it with you.
  • There is no registry, marketplace or sandbox. An enabled package runs with the host process's authority.

No authentication, tenancy or RBAC. The server is local-development-only. An actor header is an assertion, not an identity. Do not expose it to a network. Every claim and every limitation is on one page.

What you are left with if this project disappears

The ownership test in GO_TO_MARKET.md §2.6 is one question: if this project disappears tomorrow, what am I left with? Here the answer is a Node application in your repository, no third-party runtime dependencies, and a SQLite file any client can open. That last part is measurable: package.json has no dependencies field, persistence is node:sqlite, and the HTTP server, the test runner and the database adapter are all Node built-ins (C-17). The comparison it is drawn against answers the same question with a runtime you must keep operating.

The licence is MIT, and ADR-023 confirmed it rather than assuming it. Nothing about the file changed; what changed is the kind of statement being made, because three distribution manifests carry a licence field and a licence in a manifest is an assertion to everyone who installs from it. scripts/distribution-check.js reads brand.json before it will let a manifest state a licence to a third party. The ADR is explicit about what it does not decide: nothing about a future managed offering, and nothing about the licence of anything a customer generates — generated code belongs to the customer under whatever terms they choose, which is the point of generating it.

The property is also bounded. Zero runtime dependencies is a property of the framework, not of whatever you add on top of it; the first library you install is yours to carry.

Where ownership stops today

L-08 states it without softening, and it is two facts rather than one. the repository's project bootstrap scaffolds a project that boots, reports valid from app inspect and exits 0 from project doctor — run from a checkout of the repository, offline, with no install. The package published under the reserved npm name is still an empty placeholder, so the `npm create` route installs nothing until a human publishes it. Either way the framework is vendored into the project: you own the result outright, a versioned framework dependency does not exist, and upgrading means merging, not bumping.

GO_TO_MARKET.md §1 calls this a mechanism problem rather than a credibility problem, and it has one consequence for language that is worth stating on the page rather than in a style guide: the sentence 'the framework is a dependency you could remove' was removed from this site because today the code arrives by copying, not by installing, and that sentence may not come back through a comparison page.

The plan records two honest endings and no third. Either an ejection proof lands — an application in its own package that depends on the framework, verifies green, and documents what survives deleting the dependency — or L-08 is accepted permanently. Neither the examples/ejected application nor the test that would prove it exists in this tree today.

The unit of ownership is a package, not a fork

The reason ownership does not have to mean forking is ADR-018: domain behaviour lives in optional packages built on the runtime's contracts, so extending the system is adding a package rather than editing a platform you then have to keep merging. A customer-authored package attaches and detaches with the kernel's fingerprint unchanged and reaches another package only through a capability it declares (C-13).

Detaching is clean for code and not for data: removing a package removes its behaviour and leaves its rows behind, which is why removing a package without losing its data is only 'partially supported' (JTBD-PK-04). There is no registry or marketplace to install a package from (JTBD-PK-06), and no sandbox — a package you enable runs with the host process's authority, so running an untrusted one safely is not supported (JTBD-PK-07).

What owning it does not buy you yet

Owning the code does not make it deployable. There is no authentication, tenancy or RBAC, and the server is local-development-only (L-01); persistence is SQLite (L-02); there is no import, export, dedupe, merge, bulk edit, saved view or global search (L-06). You cannot put real customer data in it: a CRM is a personal-data system by definition, and this one has no way to service an access or deletion request (L-09).

And there is nothing to sign up to. No hosted CRM, no free tier, no account — the output is an application in your repository that you run (L-07). Ownership today is ownership of a framework and a local application, not of a system your team logs into on Monday.

The evidence this page rests on

Claims and limitations are printed from site/claims.json word for word. Job statuses come from docs/benchmarks/jobs.json; a job with no page of its own is listed with its status rather than linked.

Claims

  • C-17 Zero third-party runtime dependencies. Node 22 and a checkout — no build step, no bundler, no framework underneath your framework.

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

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

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

Limitations

  • L-08 Ownership today means copying source, not installing a dependency. 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.
  • 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.
  • L-01 No authentication, tenancy or RBAC. The server is local-development-only. An actor header is an assertion, not an identity. Do not expose it to a network.
  • L-02 SQLite only. Persistence is Node's built-in SQLite adapter. PostgreSQL is on the Production Spine track and is not implemented.
  • L-06 No import, export, dedupe, merge, bulk edit, saved views or global search. 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.
  • L-09 You cannot put real customer data in this yet. 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.

Jobs it covers

Documented in

Proved by