# RobCo U.O.S. — Engineering Playbook (INDEX) > A thin, navigable MAP of how this project is engineered. It is **not** a manual that duplicates the rules — > it POINTS AT the authoritative sources (protocols, architecture, memory, prompt library) so there is one source > of truth per topic and nothing drifts (drift is exactly what Protocol 2a exists to prevent). > Living doc. Gitignored / local. Built 2026-07-04. **Why an index, not a rewrite:** ~80% of a "RobCo Engineering Playbook" already exists — the 40+ protocols in `CLAUDE.md`, plus `ARCHITECTURE.md` and the agent memory. Copying those into a new manual would create a second source of truth. So this file is a table-of-contents that ties the existing, authoritative pieces together and adds only the few genuinely-missing reusable templates. --- ## Sections → authoritative source | Playbook section | Where it actually lives (source of truth) | |---|---| | **Philosophy** | Design direction memory (incl. the *"2281 RobCo engineers with modern UX research — fast, accessible, discoverable, information-dense, beautiful, never breaking the illusion"* north star + player-control principle + RobCo-OS architecture) | | **Campaigns / Audit Templates** | `RobCo_Prompt_Library.md` (this folder) + the parked audit chain (diegetic, code-quality, performance, a11y, content, mobile, test-strength, UI-consistency, cloud) | | **Design Reviews** | Protocol 8 (Opus plan → Sonnet build → Opus audit) + the Design-Unit workflow (mockup → approve → audit → build → audit) | | **Red-Team Reviews** | Protocol 8 + the Red-Team pass in `RobCo_Prompt_Library.md` (Opus argues against a plan before build) | | **Performance Reviews** | parked performance audit | | **Parallel Execution** | Protocol 12 (no concurrent pushes) + the parallelization plan (robco-audit-program) | | **Feature Expansion** | Protocol 4 (new state field, 4-file minimum) + Protocol 22 (extend before create) + capability survey | | **Documentation Standards** | Protocols 2 / 2a (docs + count sync) + 21 (plain-English changelog) | | **Roadmap Reviews** | roadmap memory + parked-roadmap-rebaseline → template below | | **Release Reviews** | Protocols 11 (deploy verify) + 43 (dev→main release gating) → template below | | **Emergency Recovery** | Protocols 16 (hotfix/rollback) + 35 (auto-flip kill-switch) → template below | --- ## The few genuinely-missing reusable templates ### Roadmap Review ``` Re-validate the roadmap against what's actually shipped. Read the shipped state, the planning docs, and history. For each planned item: is it still needed / correctly ordered / correctly scoped given what's now built? Recommend re-ordering, merging, splitting, deferring (to a later round), or dropping. Output a revised, dependency-ordered backlog. Analysis only. ``` ### Release Review (run before every dev→main promotion) ``` Pre-release audit for the dev→main promotion. Confirm: the full gate is green on dev (both runners at parity + browser checks); CHANGELOG [Unreleased] is consolidated into the dated version block; APP_VERSION + CACHE_NAME + manifest are consistent; docs (README/ARCHITECTURE) reflect the shipped state holistically (Protocol 2 README-currency); no [Unreleased]-only feature leaks to prod; deploy path (GitHub Pages + SW/CDN cache) verified. Report go/no-go with the exact reboot-to-see-it steps. ``` ### Emergency Recovery (live-site regression) ``` Live site is broken. RESTORE FIRST, diagnose second (Protocol 16). If a flaggable feature: flip its /config/flags flag off (Protocol 35) and confirm the fail-safe fallback is active. Else git revert the offending commit + bump CACHE_NAME + push. Confirm users are restored. THEN root-cause, add a regression test (Protocol 13), record in CHANGELOG, and re-attempt the fix. ``` ### Red-Team Review (also in the prompt library) ``` Before building <plan>, argue the strongest case AGAINST it (senior engineer / Fallout purist / mobile user lenses), cheaper alternatives, future debt it bakes in. Then reconcile: what survives, what changes, what's rejected. ``` ### Assumption-Challenge campaign ✅ ADOPTED (owner 2026-07-04) ``` Read the repo, architecture, planning docs, feature philosophy, roadmap, audits, and history. Do NOT look for bugs or missing features. Identify ASSUMPTIONS accepted without re-evaluation — naming, architectural boundaries, UX patterns, feature ownership, implementation order, abstractions, roadmap sequencing. For each: does it still serve the project's CURRENT goals, or does it persist from historical momentum (institutional inertia)? Recommend changes only where there's a clear long-term benefit. Analysis only. ``` > Distinct from "surprise me" (which finds improvements): this finds *inherited decisions nobody re-examined*. > A useful periodic check for a maturing project. Overlaps a little with the diegetic drift + open-ended campaigns, > but the inertia angle is sharp enough to stand alone. ✅ First-class campaign (owner adopted 2026-07-04). Run periodically (~once per round or major milestone). ### Cross-System Interaction audit ✅ ADOPTED (owner 2026-07-04) — highest-value for emergent gameplay ``` Find systems that never communicate but SHOULD. Map every subsystem (timeline/GPS/inventory/quests/companions/ faction reputation/vendors/weather/time/audio/AI/hardcore) and ask why each pair doesn't talk: e.g. GPS using discovered quest locations, companions reacting to faction changes, reputation feeding AI context, hardcore affecting travel planning. For each candidate link: describe the emergent feature, the systems it connects, and whether it can be done deterministically/opt-in (player-control principle — AI is never the sole authority). Prioritize links that reuse existing architecture. Analysis only → feeds the 2.9 gameplay ideation. ``` > ⚠ Filter every proposed link through the player-control principle + RobCo-OS architecture: pure data-reuse links > (GPS↔quest locations) are free wins; AI-context links (reputation→AI) must stay opt-in/deterministic where possible. --- ## Operating principles baked into every campaign - The full 2000+-test gate is law; never `--no-verify`; both runners at exact parity. - Analysis before code; reports feed synthesis; challenge assumptions by default. - Modernize WITH immersion (never strip modern features) — the 2281-with-modern-UX north star. - Player-control principle: AI never the sole authority; opt-in, deterministic where possible. - Keep the build-to-plan ratio healthy — run the highest-value campaigns, implement, re-baseline (Protocol 28).