Onboarding
A guided path, not a dashboard of links. Pearl Prime turns a brand and a plan into books, manga, audiobooks, video, social, and podcasts — each with its own production chain, all held to one shared standard of proof.
The system in one diagram
Intent → shared platform → content systems → production areas → quality and acceptance → publishing and distribution. That's the whole shape.
For depth: Systems Architecture.
Pick where you fit
Roles with a built onboarding page link directly. The rest route to their Production Area page for now — owner, status, and pipeline are real; a dedicated onboarding walkthrough isn't built yet for every role.
Content intelligence
Control
Delivery
Designed → Code-wired → Executed-real → Operator-accepted → Production-repeating
Every status badge in this portal maps to exactly one of these five stages. A gate PASS is at most code-wired — never production-repeating. This distinction is why past closeout reports overstated what had actually landed.
Full definitions: Quality and Evidence Model.
Where truth actually lives
| Question | Source |
|---|---|
| Where does canonical code live? | pearlstar_gitea/offline-main — the Gitea remote, not GitHub (suspended) |
| Which subsystem does an area belong to, and who owns it? | artifacts/coordination/SUBSYSTEM_AUTHORITY_MAP.tsv |
| What work is active right now? | artifacts/coordination/ACTIVE_WORKSTREAMS.tsv |
| What decisions are open, and what's the recommended default? | docs/PEARL_ARCHITECT_STATE.md |
| What's the current program status? | Generated by scripts/dashboards/build_status_json.py into brand-wizard-app/public/data/status.json |
| Where's the acceptance evidence for a specific claim? | Path cited on that area's card in Status & Evidence — never take the claim without it |
Every dashboard in this portal is a view of these sources, not the source itself. If a dashboard and a registry ever disagree, the registry wins.
What you'll need — ask your lead for specifics
- Repository access to the canonical Gitea remote
- Branch and merge permissions appropriate to your role (most roles: branch + PR, not direct merge)
- Read access to the dashboards relevant to your area
- Compute/service access if your area touches Pearl Star GPU jobs or model providers
- Storage access if your area writes large artifacts (R2, not git)
- Credentials — provisioned through your lead's own channel, never listed on this page
- Communication channel for your team
- Local tooling your area requires (see that area's runbook once linked)
Need → canonical truth
In this repo that means: branch from pearlstar_gitea/offline-main, run push-guard and the merge guard before any push, and never merge a PR that deletes more than 50 files without explicit operator approval. A PR governance check posts pass/warn/block on every PR; BLOCKED cannot merge.
- Operator approval is required for: mass deletions, force-pushes, branch protection changes, and anything the merge guard flags
status: blocked - Blockers get raised in Work & Decisions, not buried in a PR comment
- Evidence gets recorded as a file path, not a claim in a closeout message
- "Done" means the specific truth-model stage it reached — say which one
- Never report a merge, a fix, or an acceptance without a commit SHA or the evidence path
One small verified dry run
A real milestone structure
You're onboarded when you can demonstrate
- Where your area begins and ends
- What inputs and outputs you own
- Which quality gates apply to your work
- Where the evidence for your area's claims actually lives
- How to tell current truth from a stale dashboard
- How to escalate a blocker
- How to make a safe canonical change
