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.
Order:
- #165, which derives FedWiki's site usage instead of keeping a running total.
- The defects that harm members or operators now, most harmful first: #163, #23, #141, #148, #212, #153, #285, then #269, #277, #272, #270 and #271, the subscriptions that bill while delivering nothing, then #287, #290, #291 and #293, then #178 and #282, then #245, #246, #247, #283 and #284, then #196. None of them depends on the integration contract, so they go before it.
- What the contract needs before it starts: #164, what an unlimited limit is, which #171 states explicitly; and #184, the swap stored as two requests.
- The integration contract, in order: #171, #172, #173 (after #167, the notice part it uses), and #174 (with #44 and #46).
- At any point: #36, #64, #244, and #186, which closes once #165 and #196 have written their locks into the lock order.
- Last: the custom-domain operations sign-off on the reference deployment, after #141.
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.