Rotom Table 1.0 is a Nuxt 4, SQLite-authoritative, liveplay-only trusted-table application. Choose the path that matches your role; development hosting and archived seams are not production instructions.
Read these in order for the supported Linux x86-64 private VPS shape:
- Private VPS hosting boundary
- Deployment smoke checklist
- 1.0 campaign upgrade guide
- Backup, restore, retention, and rollback
- Private VPS live-play smoke checklist
- Security and outer access gate
Release identity and compatibility:
- Versioning, tags, and provenance
- Private VPS readiness summary
- API mutation audit
- Campaign repository/private-root layout
- Source-tree and private-data hygiene
Use npm run upgrade:campaign, backup:campaign, restore:campaign, and audit:campaign only as documented. Local Nuxt development is not a supported liveplay host.
- Complete Play Loop GM guide — sheets, inventory, encounters, settlement, continuation, and recovery.
- GM Campaign Toolkit and GM guide — campaign tables, deterministic wild/NPC packages, session preparation, Builder launch, and recovery.
- Pokémon Contests — ordinary, Trainer Participant, and Battle Contest workflows.
- Deferred mechanics closure — ranged weapons, item actions, Skill Checks, and Battle Contest integration.
- Group inventory workflow — shared custody, transfers, revisions, and realtime behavior.
- Player profiles — profile creation, character links, and token control.
- Ability recovery/manual QA and Move recovery/manual QA.
- Complete Play Loop player guide
- Player profiles and linked-character control
- Live play authority — commands, revisions, retries, and setup versus live boundaries.
- Contest documentation
The GM/Player picker is role projection for a known table, not public authentication. Player views must never rely on GM diagnostics or private evidence.
Start with:
- Contributing
- Support expectations
- Architecture
- Data model
- Liveplay authority
- Encounter presentation contract and schema/API reference
- Complete Play Loop contributor guide
- GM Campaign Toolkit contributor guide
Mechanics authorities:
- Move automation and release acceptance
- Ability automation and release acceptance
- Encounter presentation release acceptance
- Breeding contributor guide and GM/player guide
- Contests
Architecture decisions:
- ADR 009 — Server-authoritative profile play
- ADR 010 — Move automation runtime
- ADR 011 — Ability automation runtime
- ADR 012 — Encounter presentation
Release checks are machine-owned under data/release-readiness/ and scripts/release-readiness/. Canonical mechanics data comes only from the fourteen data/reference/*.json authorities and shared/ruleset/natures.ts; documentary trees and parser inputs are not runtime fallback sources.
- Screenshot workflow
- Map v2
- Render scheduler architecture
- Performance roadmap
- Benchmark scenarios, fixtures, runbook, and results
- No-quality-loss guardrails, readiness, and review guardrails
- Move animations, manual QA, and realtime action-event QA
- Token cosmetics
- Pokémon size outliers
- Fan-project notice
- Repository notice
- Security
- Support expectations
- Contributing/data hygiene
- Third-party media attribution
Never commit campaign databases, profiles, environment files, backup archives, release evidence, or screenshots containing private campaign material.
Archived legacy live-session documents describes the retired/direct-only /sessions seam and is historical maintenance material. They do not define current profile-based liveplay architecture. Any document explicitly marked roadmap, legacy, archived, or historical is context—not a supported operator procedure.