Capabilities
The commercial domains that are merged, and where each one stops.
Each page below states the boundary before the capability, cites the entry in the claims ledger that carries it, and names the test file that proves it. None of it is deployable. There is no authentication, tenancy or RBAC, every provider is an offline fixture, persistence is local SQLite and there is no scheduler — so a domain that works here works on one developer's machine.
-
Lead scoring and routing you can explain a year later
Lead scoring, routing and assignment
Enrichment, scoring and routing over a Lead record — all of it deterministic, none of it wired to a real data vendor.
-
CPQ quotes, price books and a discount approval that waits for a human
Quotes, price books, discount approval
A catalog, price books, composite quotes priced entirely on the server, immutable quote versions, and a versioned discount policy whose only two outcomes at the boundary are auto-approve…
-
From e-signature to exactly one immutable order
E-signature and signed orders
An approved quote version becomes one signature envelope — one, ever — whose provider events are cryptographically verified before any state changes, and whose completion produces one…
-
Turning a signed order into a contract and a subscription
Contract and subscription activation
A signed immutable Order activates, through a versioned policy and one human decision, into a Commercial Contract, an immutable contract version, one contract line per order component, a…
-
Delivery projects: hours, costs, change requests and sign-off
Delivery projects, costs and sign-off
The pending delivery obligations of an activated contract hand over into a planned project with work packages, milestones and an optional partner, then run through human-driven transitions…
-
Support entitlements and SLA tracking, activated from a contract
Support coverage, cases and SLAs
The pending service obligations of an activated contract become an operational Service Coverage with immutable entitlements, under a versioned policy that refuses to guess a support tier…
What none of the 6 pages above means
These pages describe this repository at this commit. None of them implies the framework is deployable, and none of them is a roadmap: nothing that is not merged appears on this site, in any tense.
- 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.
- SQLite only. Persistence is Node's built-in SQLite adapter. PostgreSQL is on the Production Spine track and is not implemented.
- No scheduler, no task engine, no reminders. 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.
- No email, calendar or marketing integrations. An in-memory notification provider contract exists. No adapter sends anything to anyone.
- The build benchmark has not been run. The protocol is designed and published; no Successful Agent Build Rate exists yet. Any number you see quoted for this project is not ours.
- 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.
Every claim and every limitation is on one page, and the questions this project refuses to answer are published beside them.