Who did what and when, and how the system behaves while they do it. A generic audit log that the existing provision-transition ledger was designed as a projection of, plus the metrics and alerting to run the console in production.
Phases: the audit-log schema (generic table, typed projections or a union view; record shape, retention, PII checklist); one audit row per mutating route through middleware (actor, target, status, request id); the observability stack (latency, error rate, queue depth, dashboards); per-resource history views in the operator panel; retention, PII scrubbing and alerting.
Everything an operator can do in the panel, as a versioned JSON API over HTTP for scripts, tooling and other systems, independent of the operator pages, which stay as they are. An API is a permanent contract: the auth model, error envelope, versioning and idempotency are chosen deliberately before the surface grows. This is the contract for a programmatic caller; the integration contract is the one for a plug-in, and the two are not conflated.
Phases: API design and auth model (JSON over HTTP with an OpenAPI description; token or client-credentials; error envelope; pagination and idempotency; whether responses carry hypermedia links; a health route only, to validate); catalog endpoints (organization types, products with their payment-provider mapping, capability sets with rules, plan ladders with tier reordering); runtime endpoints (persons, organizations, grants, the per-organization composite); billing and integrations (read-only over the payment mirror; integration endpoints); OpenAPI publication with a first generated client used by the demo seeder; API audit, per-principal rate limits, cross-origin lockdown.
Everything the console needs before a stranger can read the README, run the stack from the quickstart, and trust the operator panel with real members. The engine is built; this milestone is the front door, the first-run experience, and the gaps that keep an operator's happy path from completing.
Done when a newcomer can read the README and understand what the console is in under a minute, run the stack from the documented quickstart without a boot failure that looks like a bug, land on an operator overview worth showing and find their way around it without a guide, complete the operator path from creating a product through pricing and syncing it to selling it, and attach a custom domain to a site; the repository carries the standard open-source hygiene files, and every visible affordance does what it says, with half-built features hidden rather than hinted.
Closed before the tracker moved here: the project front door, first-run friction, purchasability, the custom-domain code, hardening and polish, the operator overview, the first-contact pass, the audit remediation, the model cards, the verification-found hardening, the page anatomy and quality gate, and two security-audit runs remediated. Open: the last custom-domain operations sign-off on the reference deployment, and the issues in this milestone.
Charging for what is used rather than what is granted. Usage ingest, enforcement and billing over the namespaced resource keys, plus time-tracked services. Measurement itself (bytes on the wire, disk consumed) belongs to the provider or the infrastructure; the console ingests reported usage. Storage becomes a metered resource alongside network egress.
Phases: usage ingest and threshold alerts per site and organization; limit enforcement (block or throttle over the limit, configurable grace periods); time-tracked and hourly service billing with add-on management; usage-based billing (metered subscriptions, pending charges swept into invoice items). Open: whether a metered resource can be scoped to an arbitrary subset of providers rather than one or all, which is its own issue.