Status: ✅ Resolved 2026-07-21 — reuse the shipped Portal + Control
Plane; no custom page · Decider: TF engineering lead
The MVP needs an admin flow (create user, issue key) and a user flow (see/copy
my key). The scope doc proposed the gateway's built-in admin UI plus one thin
custom "My Keys" page. The open question was whether to build that throwaway
page (Option A) or package a slim profile of the Control Plane (Option B).
Neither option's custom surface gets built: the "My Keys" experience already
exists, shipped and production-hardened, as the Portal's key self-service
(built in MOAD — reveal/copy keys, per-key spend, usage charts). The MVP
umbrella chart therefore ships the real management stack:
- The single custom MVP surface the scope doc allowed for is already
delivered — building a thin page would duplicate shipped code.
- The demo story strengthens: "this is the same management stack that runs a
production AI cloud today," not a mock-up.
- It eliminates the fork risk this ADR existed to manage: both tracks now run
one management stack from day one.
- The chart is heavier than the scope doc's four components: + Portal,
Control Plane, Keycloak, MariaDB, Redis. Accepted — all of it is shipped
software; the work is packaging, not building.
- The Control Plane's AWS dependencies (SES OTP email, DynamoDB codes) move
onto the MVP critical path — a single-server install can't assume AWS.
Tracked: tokenfactory-controlplane#7.
- tokenfactory-portal#1
(the thin page) closed as completed-by-reuse; no tokenfactory-keys repo
will exist.
- Fallback if packaging slips before the demo date: run the demo against the
hosted portal pointed at the demo gateway, and keep the self-contained
install as fast-follow.