# Journey: Persona release evidence cycle `/personas` is a real persona-governance cockpit, but it is not one end-to-end release orchestrator. The page combines a read-only registry, editable governance, tone-calibration decisions, rehearsal controls, premium-cast approvals, and voice/avatar review queues. A separate BFF lifecycle state machine controls canonical release status, and a separate customer API controls catalog eligibility and active selection. No current test joins all three lanes into one automatic promotion. | Evidence lane | Proven responsibility | Boundary | | ----------------------- | ---------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- | | Admin `/personas` | Registry evidence, governance edits, calibration, rehearsal, premium-cast approval | Does not expose persona creation or release-channel promotion | | Persona lifecycle BFF | Validated status transitions, sign-offs, rollback plan, audit | Not driven by the Admin page panels | | Customer persona picker | Consent-gated catalog, select, active, clear | Reads released eligibility; does not prove how Admin evidence caused release | ## Personas - **Persona governance operator** — has the persona workspace scope and edits publication governance. - **Calibration reviewer** — approves or rejects scored tone runs. - **Rehearsal operator** — starts or completes pre-production dry runs. - **Premium-cast approver** — confirms license, talent, compliance, and rollback attestations before release approval. - **Customer member** — separately grants high-risk voice consent and selects an eligible released persona. ## Pre-conditions - An admin session exists and can enter `/personas`. - `loadWorkspaceDetail('personas', session)` returns the seeded registry, governance, release, voice, and avatar snapshots. - The BFF persona lifecycle store is available for the separate canonical transition path. - Customer picker tests create their own authenticated member and consent state; they do not reuse the Admin browser session. ## Steps ```mermaid flowchart LR A[Inspect registry] --> B[Complete governance] B --> C[Decide calibration] C --> D[Run rehearsal] D --> E[Attest premium cast] F[Separate lifecycle BFF] --> G[Released persona] G --> H[Consent-gated customer picker] E -. no proved automatic join .-> F ``` ### 1. Read the persona registry - [x] The page renders `PersonaRegistryPanel` with status, channel, approval-gate, evaluation, published-version, disclosure, and release-blocked counts. - [x] Entries expose boundaries, versions, disclosure text, rejected or pending gates, and failing or warning evaluations. - [x] Release-blocked entries sort ahead of in-review/draft, certified, and retired entries. - [ ] The registry is read-only. There is no **Add persona** form and no release-channel selector on this page. ### 2. Complete publication governance - [x] `PersonaGovernanceEditor` exposes the seeded governance record for each persona and names incomplete publication blockers. - [x] Saving a complete governance patch calls the Admin API and clears the draft persona's blockers after refresh. - [x] An inconsistent patch against a published persona returns the publication invariant instead of silently accepting contradictory state. - [ ] This editor does not verify a cross-workspace `/rights` consent record or submit a package to `/review`. ### 3. Decide a tone-calibration run - [x] `ToneCalibrationReviewPanel` summarizes pending, approved, rejected, and superseded runs. - [x] The focused browser flow approves a scored pending run through its real Admin mutation route and removes its action card after refresh. - [ ] A calibration decision does not itself advance the separate persona lifecycle status. ### 4. Inspect and operate rehearsals - [x] `RehearsalOutcomesPanel` renders scheduled, in-progress, completed, rolled-back, and cancelled states with scenario results, deviations, sign-off, and rollback readiness. - [x] Scheduled records expose **Start rehearsal**; in-progress records expose completion inputs and outcome controls. - [ ] The current persona release Playwright spec verifies the seeded states and control anatomy, not a complete start → finish mutation round trip. ### 5. Complete premium-cast approval - [x] A pending approval requires four named attestations: license terms, talent consent, production compliance, and rollback plan. - [x] The browser flow toggles all four through real endpoints, approves the record, refreshes, and observes `approved`. - [x] Rejection requires a rationale of at least ten characters. - [ ] The premium-cast decision is a release-evidence record; it is not proof that the registry channel changed. ### 6. Use the separate canonical lifecycle BFF - [x] The lifecycle route enforces: `drafted → in-review → rehearsal → approved-for-test → approved-for-release → released`. - [x] Auth and persona-admin scope are required. - [x] Release approval without a rollback plan returns `409 lifecycle_transition_invalid`. - [x] Invalid sign-off envelopes, illegal events, and rollback MTTR above 24 hours fail without status or audit mutation. - [x] Successful transitions append lifecycle audit evidence and use optimistic current-status conflict checking. - [ ] The `/personas` governance, calibration, rehearsal, and premium-cast controls do not call this transition route automatically. ### 7. Verify the separate customer picker - [x] The customer BFF withholds high-risk voice personas until consent is granted. - [x] After a real consent grant, the member can browse, select, read the active persona, and clear it. - [x] Authentication and not-in-catalog failures are explicit. - [ ] This proves released-catalog eligibility, not that an Admin premium-cast approval published that persona. ### 8. Keep adjacent panels in scope - [x] Voice-profile and avatar-pack review rows render their seeded status and approval evidence on `/personas`. - [x] Tara sponsor, sequence-script, and nameplate panels are composed on the same page and have their own focused coverage. - [ ] No tested chain joins those panels to lifecycle release or customer selection. ## Post-conditions - Admin evidence can be inspected and the proven governance, calibration, and premium-cast mutations are reflected after refresh. - The canonical lifecycle can reach `released` only through its own validated transition route and rollback gate. - A customer with the required consent can select an eligible released persona. - Persona creation, automatic evidence-to-lifecycle promotion, review-package submission, channel promotion, staging dwell, and one unbroken audit chain remain unproved. ## Failure modes - **Missing persona scope** — the entry point denies access and persona panels are absent. - **Incomplete governance** — named publication blockers remain. - **Published-governance contradiction** — the API returns the publication invariant and does not accept the patch. - **Unscored calibration** — it cannot be treated as an approvable scored run. - **Incomplete premium-cast attestations** — approval is refused. - **Stale lifecycle status** — optimistic concurrency returns a conflict. - **Missing or defective lifecycle sign-off** — the transition returns 409 without mutation. - **Rollback plan missing or too slow** — live-exposure approval is blocked. - **Consent absent** — the customer catalog reports the blocked persona rather than making it selectable. - **Lane conflation** — matching persona ids across snapshots are not proof of automatic orchestration. ## E2E coverage - [apps/oshun/admin/e2e/persona-approval-flows.spec.ts](../../apps/oshun/admin/e2e/persona-approval-flows.spec.ts) covers registry ordering, gates, evaluations, versions, disclosure, voice/avatar rows, and access denial. - [apps/oshun/admin/e2e/persona-governance-editor.spec.ts](../../apps/oshun/admin/e2e/persona-governance-editor.spec.ts) covers blockers, a real complete governance save, publication invariants, and scope denial. - [apps/oshun/admin/e2e/persona-release-flows.spec.ts](../../apps/oshun/admin/e2e/persona-release-flows.spec.ts) covers tone-calibration decisions, rehearsal presentation, premium-cast attestations/approval, and scope denial. - [apps/oshun/web/e2e/persona-lifecycle-bff.spec.ts](../../apps/oshun/web/e2e/persona-lifecycle-bff.spec.ts) drives the separate lifecycle BFF and its rollback, sign-off, concurrency, and authorization gates. - [apps/oshun/web/e2e/persona-session-picker.spec.ts](../../apps/oshun/web/e2e/persona-session-picker.spec.ts) proves the separate consent-gated customer picker. Coverage is **deep within the three evidence lanes but partial end to end**. No current browser test proves automatic Admin evidence → lifecycle release → customer publication. ## Per-view files touched by this journey - [workspaces/content/personas.md](../workspaces/content/personas.md) — registry, governance, release evidence, and voice/avatar reviews. - [workspaces/safety/rights.md](../workspaces/safety/rights.md) — adjacent consent workspace; no automatic join is claimed. - [workspaces/governance/review.md](../workspaces/governance/review.md) and [workspaces/governance/review-id.md](../workspaces/governance/review-id.md) — adjacent generic review surfaces, not a proved persona submission. - [../../WALKTHROUGH/customer/03-tara/tara.md](../../WALKTHROUGH/customer/03-tara/tara.md) — customer Tara context. ## Cross-references - [review-cycle-admin.md](./review-cycle-admin.md) — real generic review decision flow and its own boundaries. - [isis-lora-training-admin.md](./isis-lora-training-admin.md) — separate voice model training evidence. - [trust-safety-voice-abuse-response.md](./trust-safety-voice-abuse-response.md) — read-only voice-abuse monitoring boundary. - `apps/oshun/admin/src/app/personas/page.tsx` — Admin composition. - `apps/oshun/bff/src/admin/persona-lifecycle-store.ts` — separate lifecycle store. - `apps/oshun/bff/src/routes/admin-personas-lifecycle.ts` — lifecycle HTTP and audit boundary. ## Open questions - [ ] Which service creates a persona and joins its registry and lifecycle identities? - [ ] Which evidence gates should automatically authorize each lifecycle transition? - [ ] Should Admin `/personas` expose the canonical lifecycle controls directly? - [ ] How should voice/avatar consent records be joined and freshness-checked? - [ ] What owns staging dwell, incident-free observation, and rollback execution? - [ ] Which durable projection publishes a newly released persona into the customer catalog?