Epic: Build Studio and an admin API with management parity

Normative authority:

• _docs/PROCESS.md
• 01 — Platform architecture
• 06 — Studio and admin API
• 07 — Security, privacy, accessibility, and operations
• 10 — Verification strategy

Outcome

Provide /studio/ and /api/v1/admin/ as two safe adapters over the same application services, capability registry, function/object/field authorization, validation, concurrency and idempotency controls, long-running operation resources, and redacted append-only audit trail. Studio is presentation-only; business mutations belong in owning application services shared by public views, jobs, Studio, and the admin API.

Django admin is never the normal management interface. It is disabled in production or reserved as the separately protected break-glass surface defined by the accepted identity/recovery policy. The resolved #20 direction removes a dedicated break-glass credential process: management-API parity is the recovery direction, with direct database access only as the last-resort operational fallback if that API is unreachable.

Current disposition

OPEN / P0 / epic / not complete / not engineering-ready.

This audit reconciles the epic against origin/main at face8e4808d65afbf0374d1ced7a88079950d663 on 2026-08-31.

• The latest push run 33295699282 is cancelled at the aggregate gate; its management/test jobs are not a green release identity and no deployment followed.
• The scheduled run 33294786109 tested the superseded 9a491cd snapshot and failed 21 known browser assertions, including the prior public overflow and stale copy expectations. It is not evidence for current main and must not be rerun as a release verdict.
• The approved public headings Events and Community knowledgebase are correct. No #7 work may roll them back.
• No local candidate, issue comment, focused test, screenshot, provider state, protected data, or old SHA substitutes for a current-main engineer → independent tester/screenshots → PM acceptance → focused commit → no-ff merge/push → on-call CI lifecycle.

Authority and exact boundaries

• #20 is closed by owner direction: use the existing shared Cognito pool for staff OIDC, keep Django groups/permissions authoritative, never authorize from generic is_staff, and do not create a dedicated break-glass credential process. The exact OIDC/session implementation and the external federated-MFA evidence remain in #61 and DataTalksClub/aws-infra#24.
• #23 is closed by owner direction and supplies the privacy/retention/minors defaults. It does not itself implement management behavior.
• #28 is closed by owner direction: the named high-risk action classes require reauthentication plus action-specific explicit confirmation; dual approval is deferred unless later operational evidence warrants it. Exact freshness, API-proof, binding, replay, and reason-vocabulary values remain implementation/control inputs on #32.
• Closed #31, #86, and #87 are accepted code foundations only. They do not establish full domain management parity or production identity.
• Source/provenance facts, inventories, parsers, matrices, and traceability reports may be produced only from immutable, caller-supplied inputs and synthetic fixtures. They cannot activate a source, change a public reader, write a protected database, create credentials, contact a provider, or authorize deployment.
• Runtime management changes require the owning issue’s explicit service/registry/permission/policy contract and the full independent lifecycle. Production provider, AWS, protected-data, sender, migration, cutover, and rollback actions remain separately owned HUMAN/operations gates.

Epic completion gate

Every checkbox below remains unchecked until the exact current-main candidate and all applicable lifecycle evidence are accepted.

• The code-owned capability registry covers every current Studio and admin-API management action, with one shared service, permission, function/object/field policy, route/method, OpenAPI operation, idempotency/concurrency rule, audit/redaction rule, test factory, and high-risk policy reference; CI fails on route/service/OpenAPI/permission/audit/result parity drift.
• Human staff identity/session, role composition, API human/service-principal separation, credential scope/revocation, and deny-by-default authorization are complete through the accepted #61 → #32 → #33 handoffs. Unknown capabilities, principals, fields, targets, and future actions fail closed.
• OpenAPI covers every routed management operation, with bounded pagination and long-running operation resources where required; Studio and admin API expose matching safe results, denial behavior, stale-write behavior, and side effects.
• High-risk role, credential, export, content-activation, bulk email/event-cancellation, grading-repair, and certificate actions enforce the accepted #28 policy plus the exact #32 control values. Audit/export is separately permissioned, bounded, formula-safe, re-redacted, retention-aware, and free of credentials, tokens, bodies, raw URL/query/header/IP data, provider payloads, reversible identifiers, and unnecessary PII.
• Domain management contributors (#38, #47, #48, #49, #52, and #59) have their owning services and adapters accepted, with source-only, send-disabled, migration, and public-authority boundaries preserved. Site settings/navigation/sponsor work under #62 remains correctly scoped.
• One current-main candidate passes the graph-selected uv/Make quality, migration, type, Django/PostgreSQL, compatibility, security/privacy, accessibility, OpenAPI/parity, full browser, container, artifact-canary, and operational gates. An independent tester recomputes the plan, runs the selected gates, captures and inspects every required desktop/mobile screenshot, and reports no required skip or pending evidence; PM accepts before commit.
• Final traceability and release consumers have exact accepted identities. #7 is not closed by a local candidate, a cancelled/missing CI run, an elapsed observation, a source inventory, or a development-only/provider-neutral rehearsal.

Child and consumer ledger

The original list mixed decision inputs, direct management lanes, and contributors owned by other epics. The table below is the authoritative relationship ledger; a GitHub CLOSED state is not by itself current-main release evidence.

Accepted inputs and foundations

Direct #7 management lanes

Cross-epic management-parity contributors

These issues contribute required management adapters/contracts to the #7 gate but keep their domain ownership under another epic.

#63 belongs to parent epic #8. It is the final residual security/authorization traceability consumer of #61/#32/#33/#52 (and other security inputs), not a #7 child and not a substitute for their implementation gates.

Acyclic dependency DAG

The following is a dependency/coordination graph, not permission to start blocked work:

#1
 └─> #31 ──> #86 ──> #87
                 │         │
                 │         └──────────────┐
#30 ──> #100 (same durable-account boundary; HUMAN rehearsal remains)
  │                 │                     │
  └───────────────> #52 <── #32 <── #61 <── #20 + owner decisions
                         │      │          └── external aws-infra#24 MFA is a closure gate
                         │      └────────────── #23 + #28 + #86 + current green base
                         └──────────────┐
                                        v
                                     #33 <── #32 + #61 + #87 + #107 development input

#51/#40/#288 + #32/#33 ──> #52
#32/#33/#52 + #53/#55-#58/#245/#246 + #48/#49 ──> #59
#45 + #46 ──> #47 ──> #50
Relay #1 + #32/#33 ──> #48 ──> #49 ──> #50
#29 + #31/#86/#87/#114 ──> #62
#219 + #253 ──> #273 ──> #274 ──> #275 ──> #272/#276/#277 ──> #278 ──> #38
#32 + #33 ──> #277
#61 + #32 + #33 + #52 + #64 + #66 ──> #63 (parent #8; final traceability consumer)

Interpretation:

• #32 is downstream of #61 for identity/session evidence and consumes the resolved #20/#23/#28 directions, but it still needs its own exact owner-approved freshness, API-proof, and bounded-reason values.
• #33 is downstream of both #32 and #61. #52 must not become a prerequisite of #32 or #33; it consumes their cross-cutting policy.
• #59 is the final course-management completeness consumer, not a source of missing domain behavior. #60 is a later production-like rehearsal/cutover consumer and never fills #59 gaps.
• #38’s source-only/preparatory children may establish evidence before runtime direct-sync work, but neither source evidence nor #277 management parity authorizes public activation.
• #47, #48, and #49 are domain/delivery contributors. #50 is downstream and owns purpose wiring/canary/cutover; no contributor can send merely because its management adapter exists.
• #62’s accepted #114/#187/#188 slices do not close the remaining umbrella or the #7 gate; #29 controls redirects/SEO exceptions.

Source-only, runtime, and activation boundary

Source-only / non-activating

• Immutable source parsing, adoption inventories, compatibility matrices, provenance reports, and traceability artifacts may inspect only caller-supplied repository snapshots and synthetic fixtures.
• #38’s #253/#273–#278 sequence may classify, validate, observe, and prepare direct-sync/public-reader contracts, but cannot mutate upstream repositories, inspect protected production data, activate a release, or retire the staged path without its explicit owner gates.
• #59’s completeness matrix and #107’s development bootstrap are evidence/development inputs. They do not create production authority, send credentials, call Relay/SES/Datamailer, or perform migration/cutover.
• No source-only result can satisfy the tester/PM/on-call lifecycle for a runtime issue or change the public authority pointer.

Runtime management

• #61 owns human staff OIDC/session behavior and the safe accounts-owned handoff.
• #32 owns the remaining Studio identity/role/high-risk/audit controls; #33 owns production admin-API principal/credential lifecycle.
• #47, #48, #49, #52, and #59 own their domain application services and Studio/admin-API adapters. Each remains deny-by-default, private/no-store/noindex, capability-registered, redacted, idempotent, and tested through its own issue.
• Runtime code is not production-ready merely because it passes a local fixture or a development-only path. All side effects remain after-commit and durable where the specifications require them.

Activation / production

• Public content/source authority, course migration/cutover, email sender/purpose/canary, external OIDC/MFA, AWS/IAM/Secrets Manager, protected-source/database access, and legacy retirement remain separately owned gates under #29, #38/#50/#60/#64/#66/#73/#74 and external repositories as applicable.
• #7 records management parity and its evidence; it grants no provider, production, protected-data, migration, sender, deployment, rollback, or direct-database permission.

Delivery convention

Follow _docs/PROCESS.md: engineer implementation remains uncommitted; a separate tester recomputes the exact verification envelope, runs focused/graph-selected gates, and captures/inspects required screenshots; PM accepts the exact candidate; only then does the engineer create the focused commit. The orchestrator locally merges with --no-ff, pushes main, and on-call alone observes terminal CI/deployment. No pull request is created.

#7 remains OPEN until every completion checkbox and all applicable downstream/operations gates are genuinely satisfied.

Start with _docs/PROCESS.md and specs 01, 06, 07, and 10, then review the direct management lanes and their dependencies in the child ledger. This epic is not engineering-ready; completion requires accepted current-main implementations, parity and security evidence, independent testing, PM acceptance, and the specified CI and release lifecycle.