# Sysadmin Chronicles — New System Canon Packet

This packet combines the new quest-system spec with the established story/implementation context.

## Core sentence

The player is not “on a main quest.” The player is doing sysadmin work. The story leaks through systems.

## Hard canon

- Company: Axiom Works
- Products: AxiomFlow, AxiomDash, AxiomSync
- Tone: plausible B2B software company; dry corporate dysfunction; no cartoon villains
- Infrastructure naming: Greek-god hostnames
- Current machines:
  - `ares` — player workstation, Ubuntu 24.04
  - `hermes` — web/app/demo server, Debian 12, nginx
  - `vulcan` — build machine, Arch Linux, internal build/release pipeline
- Player: competent new junior sysadmin, replacing Dale, no spoken lines
- Dale: previous sysadmin; central unresolved mystery; reveal through systems, not exposition

## Character preservation rule

Character portraits already match the current bios and are on the in-game company website.

Allowed:

- Compress bios for prompt use
- Clarify contradictions
- Add operational story use
- Preserve and sharpen existing voice

Not allowed:

- Changing names already shown on the company site
- Changing role, personality, authority level, implied visual vibe, or age band
- Making characters cartoon villains
- Creating changes that would require new portraits

## Active character use

### Marcus Webb

Senior Systems Administrator. Primary technical contact and ticket voice. Dry, terse, precise. Trusts competence over credentials. Gives more rope as the player proves competence. Knows what Dale did but avoids discussing it directly. Respects root-cause fixes and dislikes symptom-patching.

Use for: quest assignments, technical follow-up, access/trust gates, quiet hints, sometimes late-night observations.

### Sarah Chen

Product Manager, AxiomFlow. Outcome-focused, direct, concerned with demos/staging/product-visible failures. Often right about symptoms and wrong about root cause. Notices proper underlying fixes.

Use for: product-facing tickets, hermes/demo pressure, stakeholder reactions.

### Priya Nair

Head of Security & Compliance. Canonical email: `p.nair@axiomworks.internal`. Replace old references to Priya Kapoor or Priya Singh. Calm, precise, consequence-focused. Assumes breach/misconfiguration professionally. No alarmism. No exclamation marks.

Use for: access audits, security consequences, end-of-shift review, risky-fix evaluation.

### Dave Okonkwo

Non-technical employee and ticket source. Reports symptoms accurately, misdiagnoses causes plausibly, helpful rather than stupid.

Use for: ordinary employee impact reports.

### Dave Kowalski

Director of IT Operations. Marcus's manager and player's skip-level. Policy pressure, bullet-point status emails, meetings as implied threat, “we should document that” energy.

Use for: boss/management pressure, access restriction, escalation, status demands.

### Derek Ashford

Financial Controller. Appears on CC lines around costs/procurement. Always replies-all. Treat “Dave from Finance” as likely continuity error unless the user decides otherwise.

Use for: budget/procurement pressure.

## Background character use

Use sparingly for flavor and pressure, not because every named character needs screen time.

- Nikhil Sharma — build/release pipeline and vulcan
- Tanya Okafor — customer pressure
- Phil Ruiz — sales/demo pressure
- Yusuf Halabi — engineering escalation
- Rachel Huang — sysadmin peer/provisioning
- Tom Malaney — DNS/routing/networking
- James Osei — audit details
- Ellen Marsh / David Park / Karen Volkov / Rachel Brandt — distant executive pressure

## Quest/story delivery model

Every quest is delivered through existing game systems:

1. Ticket/email describes a symptom.
2. Player investigates real VM state.
3. Player applies real Linux/admin fixes.
4. Validator resolves the matching solution branch.
5. Dialogue reacts to the actual branch.
6. World flags, trust, incidents, behavior variables, and access state persist.
7. Later quests read those consequences.

## Existing implementation concepts to preserve

- JSON quests under `content/quests/`
- Tickets under `content/tickets/`
- VM prep scripts under `tools/vm/quest-prep/QXXX-prep.sh`
- Observed-state validation
- Clue fingerprints
- Solution branches
- `trust_delta`
- `world_flags`
- `follow_up_ticket`
- `follow_up_incident`
- Incidents as delayed consequences
- Baseline snapshots

## New system additions

Add or strengthen:

- Narrative phases
- Behavior variables: curiosity, obedience, risk
- Suspicion as management/security attention
- Access levels: basic_user, sudo, root
- Boss/management pressure phase scaling
- Hidden hook discovery state
- Behavior-driven endings
- Debug tools for narrative state

## Design warning

Do not use the new system as an excuse to throw away the current strengths. The existing branch/world-flag/trust model is good. It needs to become the backbone of the new narrative system, not get replaced by a generic quest tracker wearing a fake mustache.