# Sysadmin Chronicles — Redesign Audit

## A. Executive summary

### Is this design usable?

**Yes, but not implementation-ready.**  
The redesign mostly preserves the intended shape: sysadmin work first, story leaking through systems, behavior-driven outcomes, no melodramatic lore dump. It is a strong revision compared to the earlier failure mode it describes.

But it still has several hard problems that would bite implementation.

### Does it preserve the user's spec?

**Mostly.**  
It preserves the narrative spine, quest format, behavior variables, trust/world-flag compatibility, hidden-hook philosophy, and character tone. It does **not** fully preserve:

- the `basic_user → sudo → root` access model
- Phase 4+ difficulty scaling
- “chaos” as behavior-driven rather than one obvious trap
- quest authoring constraints around unique branch priorities and required VM declarations
- clean separation between hidden-hook discovery and clean-branch validation in a few quests

### Biggest risks

1. **Root access exists in the overview but not in the access progression.** The spec requires `basic_user → sudo → root`; the redesign only actually defines `basic_user`, `sudo`, SSH-to-vulcan, and temporary investigation access. That is not the same thing.

2. **Q039 can hard-route to chaos from one button-like decision.** The redesign says making the proxy change sets `final_config_made` and activates chaos, while its own calibration later says a single reckless action should not route to chaos. That is a logic fork eating its own tail.

3. **Hidden-hook detection is under-specified and technically fragile.** The redesign admits this. Detecting “player read a file” is not naturally compatible with state-based validation unless audit logging, shell wrappers, or deliberate breadcrumb creation are implemented.

4. **Q036 introduces an external host while claiming no additional VM.** Quest authoring requires every VM touched in clues, validation, or prep to be listed. Q036 connects to `10.0.0.47`, but `Additional VMs` is `none` and `Systems Used` only lists `build_machine`.

5. **Q034 has duplicate branch priorities.** The authoring guide explicitly says priorities must be unique; Branch 2 and Branch 3 both use priority 40.

---

## B. Spec-preservation table

| Spec item | Status | Notes |
|---|---:|---|
| Narrative spine | **Preserved** | Uses all six phases in order: Normal Work, Unease, Suspicion, Investigation, Conflict, Resolution. Matches binding spec. |
| Every quest maps to one phase | **Preserved** | All Q001–Q048 have a `Narrative Phase`. |
| Required quest structure | **Mostly preserved** | Quest entries consistently include title, phase, objective, Linux concepts, systems used, hidden hook/no hook, failure conditions, and behavior impact. Some entries have weak/partial behavior impact. |
| Behavior tracking: curiosity / obedience / risk | **Preserved** | Rules are explicit and mostly useful. |
| Suspicion | **Preserved** | Defined as management/security attention and connected to access/pressure. |
| Trust compatibility | **Preserved** | Keeps `trust_delta`, world flags, branches, follow-up tickets/incidents. |
| Access system | **Partially preserved** | Per-machine access is good. But `root` is not actually modeled beyond being named once. Spec requires `basic_user → sudo → root`. |
| Boss / management pressure | **Preserved** | Good: pressure is operational, not cutscene-driven. |
| Hidden narrative system | **Mostly preserved** | Hooks are embedded into sysadmin work. Some are too tightly coupled to “best branch” behavior, making them less optional than intended. |
| Difficulty scaling | **Partially preserved** | Phase 1–5 mostly work. Phase 6 explicitly returns to Tier 1, but spec says Phase 4+ should be problem-solving only. |
| Endings | **Partially preserved** | Behavior-driven overall, but `final_config_made` as a standalone chaos trigger is too single-choice and contradicts the stated calibration. |
| Design principles | **Mostly preserved** | Strong on systems over scripts and discovery over exposition. Weak spot: some late quests become explicit forensic tasks. |
| Non-goals | **Mostly preserved** | No cutscenes, no obvious “pick ending” button. But Q039 risks becoming the obvious “bad ending button.” |
| Character preservation | **Preserved** | No major portrait-breaking changes. Priya rename is canon cleanup, not a redesign. Kowalski becoming active pressure is supported by existing character docs. |

---

## C. Critical violations

### 1. Access progression does not actually implement `root`

**Location:** Access Progression Rules, Section 7.

**Problem:**  
The overview names `basic_user`, `sudo`, and `root`, but the actual progression never defines when root is granted, how it differs from sudo, when it is revoked, or which quests require it. The detailed rules stop at sudo and “investigation-level access.”

**Why this violates the spec:**  
SPEC_LOCK explicitly requires the permission ladder:

```text
basic_user → sudo → root
```

and says access must be affected by trust, suspicion, risk, and narrative phase.

**Corrected version:**

```md
### Levels

**basic_user:** Day one through early Phase 1. Player's own workstation account;
limited non-privileged access elsewhere only when a ticket explicitly grants it.

**sudo:** Task-scoped administrative access on a specific machine. Granted by trust
and operational need. Most admin quests use sudo, not root.

**root:** Rare, temporary break-glass or forensic-level access. Root is not a normal
promotion. It is granted only for quests where sudo is insufficient, such as filesystem
recovery, archival preservation, privileged audit capture, or service account repair.
Root access must be logged, justified, and revoked.

### Root grant rules

Root may be granted when all are true:
- Trust is positive.
- Risk is below elevated threshold.
- Suspicion is below high threshold, or access is explicitly approved by Priya.
- The current narrative phase is Investigation or Conflict.
- The quest has `requires_root: true`.

### Root restriction rules

Root is denied or revoked when:
- Risk crosses elevated threshold.
- Suspicion crosses high threshold without Priya approval.
- The player performs destructive changes outside ticket scope.
- Q031 or Q043 finds undocumented privileged activity.

### Phase gates

Phase 1: basic_user only, with no root.
Phase 2: workstation/hermes sudo possible, no root.
Phase 3: sudo on hermes/vulcan; root only for audited recovery tasks.
Phase 4: temporary root for investigation tasks when required.
Phase 5: root access becomes tightly controlled and reviewable.
Phase 6: root revoked unless the ending state explicitly preserves elevated trust.
```

---

### 2. Q039 turns chaos into a single obvious final trap

**Location:** Q039 Branch 3 and Ending Logic.

**Problem:**  
Q039 says making the config change sets `final_config_made` and “the chaos ending route activates.” Ending logic also treats `final_config_made` as a standalone chaos condition.

**Why this violates the spec:**  
SPEC_LOCK says endings emerge from world flags, behavior variables, access state, and hidden hooks — not one obvious final button. The redesign also contradicts itself by saying a single reckless action should not route to chaos.

**Corrected version:**

```md
Branch 3 — Make the change without review (priority 10): Player adds the proxy pass
to 10.0.0.47 without checking prior context or escalating. The change works
technically but creates a serious security/compliance exposure. `trust_delta: -3`.
Flags: `final_config_made`, `unauthorized_proxy_enabled`.
Follow-up incident: I039 — Priya opens an urgent access/config review.

Behavior Impact:
- Make the change: R+5, S+3

Ending note:
This branch strongly contributes to `chaos` but does not activate it alone unless
the player already has high risk, maximum suspicion, or prior falsification/omission
flags.
```

And update chaos ending logic:

```md
### Ending: `chaos`

Required conditions, any of:
- Risk above chaos threshold.
- Suspicion at maximum.
- Two or more serious falsification / evidence destruction flags.
- `final_config_made` AND at least one of:
  - risk above elevated threshold
  - `access_review_incomplete`
  - `kowalski_report_sanitized`
  - `backup_test_falsified`
  - `logs_selectively_omitted`
```

---

### 3. Q036 uses an external host but declares no additional system

**Location:** Q036.

**Problem:**  
Q036 connects to `10.0.0.47` for forensic inventory, but says `Additional VMs: none` and `Systems Used: build_machine`. That is false.

**Why this violates the spec:**  
Quest authoring requires all VMs used in clues, validation, or prep to be listed. The canon packet also says the current machines are `ares`, `hermes`, and `vulcan`; if a fourth machine exists, it needs explicit implementation status.

**Corrected version:**

```md
**Quest ID:** Q036
**Title:** Authorized Access
**Narrative Phase:** Conflict
**Tier:** 3
**Primary VM:** build_machine
**Additional VMs:** external_target_10_0_0_47
**Primary Objective:** Priya, with Kowalski's authorization, has provided read-only
credentials to connect to 10.0.0.47 for a forensic inventory. Document what is running,
what data is present, and whether Axiom Works data is identifiable. Do not modify
anything.
**Linux Concepts:** SSH with specific key/user, read-only service enumeration,
`systemctl`, `ps aux`, `ss -tulpn`, `find`, `ls -lah`, checksum capture, read-only
file inspection
**Systems Used:** build_machine, external_target_10_0_0_47
```

Implementation note:

```md
external_target_10_0_0_47 must be represented as either:
- a fourth VM fixture,
- a containerized fake host reachable only from vulcan,
- or a simulated network target exposed through the validation harness.

Do not leave it as an implied off-screen system.
```

---

### 4. Q034 duplicate branch priorities violate authoring rules

**Location:** Q034 Branches 2 and 3.

**Problem:**  
Both Branch 2 and Branch 3 use priority 40.

**Why this violates the spec:**  
The authoring guide explicitly says branch priorities must be unique; duplicate priorities require rewriting.

**Corrected version:**

```md
Branch 2 — Hermes first, rotation incomplete but safely staged (priority 70):
Player restores production, starts the key rotation, but does not complete final
deployment before 2am. Builds are delayed but the trust chain is not broken.
`trust_delta: +1`.

Branch 3 — Vulcan first, hermes later (priority 50):
Completes key rotation, then restores hermes. Rotation is correct; production was
down longer than necessary. `trust_delta: +0.5`.

Branch 4 — Hermes only, rotation missed (priority 30):
Restores production, misses the key rotation window entirely. Builds break overnight.
`trust_delta: 0`. Follow-up incident: I034.

Branch 5 — Neither, escalates without triage (priority 10):
Escalates both without preserving either service. `trust_delta: -2`.
```

---

### 5. Phase 6 difficulty scaling conflicts with SPEC_LOCK

**Location:** Phase 6 setup and Q041.

**Problem:**  
The redesign says Tier 1 returns for most Phase 6 quests and Q041 uses an explicit attached hardening checklist.

**Why this violates the spec:**  
SPEC_LOCK says Phase 4+ is “Problem-solving only,” applying to ticket wording, hints, clue obviousness, and branch tolerance. Phase 6 is still Phase 4+.

**Corrected version:**

```md
### PHASE 6 — RESOLUTION (Q041–Q048)

The pressure has lifted, but the player is still expected to operate at late-game
competence. Tickets are calmer, not easier. No new hidden hooks. No explicit
walkthroughs. The ending fires from accumulated state after Q048 resolves.
```

Corrected Q041:

```md
**Quest ID:** Q041
**Title:** Hardening Pass
**Narrative Phase:** Resolution
**Tier:** 3
**Primary VM:** web_server
**Additional VMs:** none
**Primary Objective:** Post-audit review found that hermes does not meet the current
security baseline. Identify the gaps, remediate them, and verify the application
still works.
**Linux Concepts:** SSH hardening, nginx security headers, firewall rule review,
service account audit, safe sequencing of access-control changes
**Systems Used:** web_server
**Ticket Sender:** Priya Nair
**Ticket Summary:** "Hermes does not match the current post-audit baseline. Bring it
into compliance and confirm service health after the changes."

**Clue Trail:**
- Baseline document exists but does not list exact commands.
- SSH config allows settings that are no longer acceptable.
- nginx lacks required security headers.
- Firewall rules include at least one stale exposure.
- Service account permissions are broader than needed.

**Solution Branches:**
Branch 1 — Full hardening, safe sequence (priority 100): Player identifies all gaps,
verifies key auth before disabling password auth, applies nginx headers, tightens
firewall rules, scopes service permissions, and confirms service health.
`trust_delta: +2`. Flags: `hermes_hardened`.

Branch 2 — Full hardening, unsafe sequence (priority 60): Final state is correct,
but the player temporarily breaks SSH or service access during sequencing.
`trust_delta: +0.5`.

Branch 3 — Partial hardening (priority 30): Some gaps fixed, others missed.
`trust_delta: 0`.

**Hidden Hook:** None.

**Failure Conditions:** SSH access lost without recovery path; nginx broken; admin
panel exposed after remediation.

**Behavior Impact:**
- Full hardening: O+1
- Unsafe sequence: R+1
```

---

## D. Moderate issues

### Repetition

- The INT-0194 thread appears often enough that it risks becoming “the glowing main quest breadcrumb.” The system can keep it, but not every major midgame hook should name the same ticket number.
- Several quests use the same “audit / document / archive” pattern. Realistic, yes. Varied, no. At some point the player is just doing paperwork with grep. That is accurate corporate simulation, but accuracy alone is not game design.

### Weak Linux concepts

- Q020, Q031, Q040 are documentation-heavy. They have Linux-adjacent evidence gathering, but the technical center is reporting. Keep them, but make sure validation requires real commands/artifacts, not just “player wrote report.”
- Q037 “trace where customer email got infrastructure details” needs concrete technical evidence: mail headers, CRM export logs, nginx access logs, document access logs, or ticket attachments. Otherwise it becomes story fog.

### Weak hidden hooks

- Q015’s hook is effectively part of the best branch: Branch 1 requires inspecting the binary, and the hook is set by inspecting the binary. That makes the hook less optional. It should be possible to complete the audit perfectly without recognizing the broader INT-0194 meaning.
- Some “hook discovered” C bonuses duplicate branch C bonuses. Q015 explicitly says Hook C+2 is “already in Branch 1 impact,” which is begging for a double-count bug.

### Pacing problems

- Phase 3 and Phase 4 are both audit/investigation-heavy. The difference is conceptually clear, but the activity palette may blur in play.
- Phase 6 “normal work again” is good thematically, but making it easier contradicts the locked difficulty model.

### Character conflicts

No major portrait-breaking character changes found.

- **Priya Nair cleanup is correct.** Character docs already say Priya Nair is canonical and older Kapoor/Singh references should be updated.
- **Kowalski becoming active pressure is allowed.** His existing bio supports policy pressure, meetings, and indirect escalation.
- **Sarah remains within role.** Q039’s Sarah request is plausible because she does not know the IP’s context. That works.

### Implementation ambiguity

- “Written report” branches need concrete artifacts: exact paths, expected content markers, checksum files, archive names, or validation commands.
- `suspicion_delta` is required in the implementation notes but omitted from many quest behavior-impact summaries. That is fine for prose, but JSON conversion must normalize missing values to `0`.
- Hidden-hook detection needs a single approved strategy before implementation. Mixing state detection, auditd, and hint detection ad hoc will turn validation into soup with line numbers.

---

## E. Implementation risks

| Area | Risk | Fix |
|---|---|---|
| Data model | New fields are defined, but `root` is not represented in real progression. | Add `access_level` enum values and root grant/revoke rules. |
| Quest validation | Some quests rely on reports/documentation rather than VM state. | Require generated files with expected fields, checksums, timestamps, and source evidence. |
| Save/load | New global state fields must persist: curiosity, obedience, risk, suspicion, per-machine access, hidden hooks. | Version save schema; migrate old saves with defaults. |
| Behavior tracking | C/O/R/S values are prose shorthand, not normalized data. | Convert every quest to explicit per-branch deltas, including zeroes. |
| Access progression | Temporary access, sudo, and root are conceptually blended. | Separate `access_level`, `temporary_grants`, and `access_review_flags`. |
| Hidden hook state | Detecting “read this file” is hard with pure state validation. | Use auditd or command wrappers for file-read hooks; do not fake it with impossible `command_assert` assumptions. |
| Ending evaluation | Q039 currently overrides behavior history. | Make `final_config_made` a heavy chaos contributor, not a standalone ending trigger. |
| External host | `10.0.0.47` is not declared as a system/VM. | Implement as fourth VM/container/simulated host and declare it in quest metadata. |
| Branch priority | Q034 duplicate priorities will create nondeterministic branch resolution. | Make all branch priorities unique. |
| Phase scaling | Phase 6 becomes easy mode. | Keep calmer tone, not lower complexity. |

---

## F. Corrected quest entries

Only entries that need fixing are included.

---

### Corrected Q033 — The Revocation Request

```md
**Quest ID:** Q033
**Title:** The Revocation Request
**Narrative Phase:** Conflict
**Tier:** 3
**Primary VM:** build_machine
**Additional VMs:** none
**Primary Objective:** Kowalski has asked the player to remove the `pipeline-svc`
account from vulcan before an external audit. The request is operationally legitimate.
The account is also central to the investigation.
**Linux Concepts:** `userdel`, account archival, sudo log preservation, crontab
preservation, change documentation, evidence-safe account removal
**Systems Used:** build_machine

**Solution Branches:**

Branch 1 — Archive then remove (priority 100): Player archives sudo logs, auth log
entries, crontab entries, relevant home/service files, and documents the account's
investigation relevance before removing the account. `trust_delta: +3`.
Flags: `pipeline_svc_removed_with_trail`.

Branch 2 — Remove as instructed (priority 60): Player removes the account without
additional archival. The request is completed, but investigation continuity is
damaged. `trust_delta: 0`. Flags: `pipeline_svc_removed_clean`.

Branch 3 — Ask Marcus/Priya before acting (priority 50): Player asks before removal.
They are told to archive first, then remove. `trust_delta: +1`. May resolve into
Branch 1 if archival is completed.

Branch 4 — Refuse outright without operational explanation (priority 10): Player
does not remove the account and does not provide a usable reason. `trust_delta: -2`.
Flags: `revocation_refused_without_basis`.

**Hidden Hook:** None.

**Failure Conditions:** Player leaves the account active without escalation; player
creates replacement privileged accounts; player removes logs or home data destructively.

**Behavior Impact:**
- Archive then remove: O+1, C+1
- Remove as instructed: O+2
- Refuse outright: S+3, R+1
```

---

### Corrected Q034 — Two Tickets

```md
**Quest ID:** Q034
**Title:** Two Tickets
**Narrative Phase:** Conflict
**Tier:** 3
**Primary VM:** web_server
**Additional VMs:** build_machine
**Primary Objective:** Two tickets arrive simultaneously — one from Marcus for signing
key rotation on vulcan, one from Sarah for a production outage on hermes. Triage and
complete both if possible.
**Linux Concepts:** GPG signing key rotation, nginx/application troubleshooting,
service restoration, sequencing time-sensitive administrative work
**Systems Used:** web_server, build_machine

**Solution Branches:**

Branch 1 — Both completed, hermes first (priority 100): Player restores hermes,
then completes the key rotation in the correct sequence before the deadline.
`trust_delta: +3`. Flags: `conflict_both_resolved`.

Branch 2 — Hermes first, rotation safely staged but late (priority 70): Production
is restored; key rotation is partially staged but misses final deployment. Builds are
delayed but trust chain is not broken. `trust_delta: +1`. Follow-up incident: I034.

Branch 3 — Vulcan first, hermes later (priority 50): Rotation is correct, but
production outage lasts longer than necessary. `trust_delta: +0.5`.

Branch 4 — Hermes only, rotation missed (priority 30): Production is restored;
builds break overnight due to expired signing key. `trust_delta: 0`.
Follow-up incident: I034.

Branch 5 — Neither, escalates without triage (priority 10): Player escalates both
without stabilizing either service. `trust_delta: -2`.

**Hidden Hook:** None.

**Failure Conditions:** Key rotation done out of sequence breaks package verification;
player makes hermes worse while fixing it.

**Behavior Impact:**
- Both completed: O+2
- Safe partial triage: O+1
- Out-of-sequence key rotation: R+2
- Neither stabilized: R+2, S+1
```

---

### Corrected Q036 — Authorized Access

```md
**Quest ID:** Q036
**Title:** Authorized Access
**Narrative Phase:** Conflict
**Tier:** 3
**Primary VM:** build_machine
**Additional VMs:** external_target_10_0_0_47
**Primary Objective:** Priya, with Kowalski's authorization, has provided read-only
credentials to connect to 10.0.0.47 for a forensic inventory. Document what is
running, what data is present, and whether Axiom Works data is identifiable. Do not
modify anything.
**Linux Concepts:** `ssh` with specific key/user, read-only service enumeration,
`systemctl`, `ps aux`, `ss -tulpn`, directory inspection, checksum capture, read-only
file review
**Systems Used:** build_machine, external_target_10_0_0_47

**Solution Branches:**

Branch 1 — Document only (priority 100): Player inventories services, open ports,
processes, data-store layout, timestamps, and identifiable Axiom Works data without
modifying anything. `trust_delta: +3`. Flags: `unknown_host_documented`.

Branch 2 — Minimal engagement (priority 50): Player confirms host is running and
data is present but does not fully inventory. `trust_delta: +1`.

Branch 3 — Modifies or deletes (priority 10): Player stops services, deletes files,
changes permissions, or otherwise alters the target. `trust_delta: -3`.
Flags: `forensic_target_modified`.

**Hidden Hook:** The data store contains `axiomworks-internal/employees`, suggesting
employee activity profiles rather than only session logs. Sets
`hook_employee_profile_data`.

**Failure Conditions:** Player modifies target state; player exceeds authorized
scope; player cannot provide evidence-backed inventory.

**Behavior Impact:**
- Full documentation: O+2, C+2
- Minimal engagement: O+0
- Modify/delete: R+5, S+3
- Hook discovered: C+2
```

---

### Corrected Q039 — The Last Normal Ticket

```md
**Quest ID:** Q039
**Title:** The Last Normal Ticket
**Narrative Phase:** Conflict
**Tier:** 3
**Primary VM:** web_server
**Additional VMs:** none
**Primary Objective:** Sarah files a configuration request: add an upstream proxy
pass to nginx for a new reporting integration. The IP in the request is 10.0.0.47.
**Linux Concepts:** nginx `proxy_pass`, upstream block configuration, config testing
with `nginx -t`, safe reload, escalation when config touches known-risk infrastructure
**Systems Used:** web_server

**Solution Branches:**

Branch 1 — Refuse and escalate (priority 100): Player does not make the change,
notifies Priya with the IP and context, and tells Sarah the request is on hold pending
review. `trust_delta: +3`. Flags: `final_config_refused`.

Branch 2 — Ask Marcus first (priority 70): Player checks with Marcus before acting.
Marcus redirects them to Priya. If the player escalates to Priya, this may resolve
as Branch 1. `trust_delta: +1`.

Branch 3 — Make the change without review (priority 10): Player adds the proxy pass
to 10.0.0.47 without checking the IP context. The config works but creates a serious
security/compliance exposure. `trust_delta: -3`. Flags: `final_config_made`,
`unauthorized_proxy_enabled`. Follow-up incident: I039.

**Hidden Hook:** None.

**Failure Conditions:** nginx config is syntactically broken; player changes unrelated
proxy routes; player hides or misreports the change.

**Behavior Impact:**
- Refuse and escalate: O+2, C+1
- Ask Marcus first: O+1
- Make the change: R+5, S+3

**Narrative Notes:** This branch must not automatically force `chaos` by itself.
It is a major risk event. Chaos requires accumulated risk/suspicion or additional
serious misconduct.
```

---

### Corrected Q041 — Hardening Pass

```md
**Quest ID:** Q041
**Title:** Hardening Pass
**Narrative Phase:** Resolution
**Tier:** 3
**Primary VM:** web_server
**Additional VMs:** none
**Primary Objective:** Post-audit review found that hermes does not match the current
security baseline. Identify the gaps, remediate them, and verify the application
still works.
**Linux Concepts:** SSH hardening, nginx security headers, firewall rule review,
service account audit, safe sequencing of access-control changes
**Systems Used:** web_server
**Ticket Sender:** Priya Nair
**Ticket Summary:** "Hermes does not match the current post-audit baseline. Bring it
into compliance and confirm service health after the changes."

**Clue Trail:**
- Baseline document exists but does not give exact commands.
- SSH configuration allows at least one setting that violates baseline.
- nginx lacks required headers.
- Firewall rules include stale exposure.
- Service account permissions are broader than required.

**Solution Branches:**

Branch 1 — Full hardening, safe sequence (priority 100): Player identifies all gaps,
applies fixes in safe order, validates access, confirms nginx health, and documents
final state. `trust_delta: +2`. Flags: `hermes_hardened`.

Branch 2 — Full hardening, unsafe sequence (priority 60): Final state is correct,
but player temporarily breaks SSH or service availability while sequencing changes.
`trust_delta: +0.5`.

Branch 3 — Partial hardening (priority 30): Some baseline gaps remain. `trust_delta: 0`.

**Hidden Hook:** None.

**Failure Conditions:** SSH access lost without recovery; nginx broken; admin panel
still exposed; service account remains overprivileged.

**Behavior Impact:**
- Full hardening: O+1
- Unsafe sequence: R+1
```

---

## G. Final recommendation

### Ready for implementation spec?

**No.**

Close, but no. The redesign is directionally right, but several issues are implementation-grade problems, not wording nits.

### Must fix first

1. **Define real root access progression.**
2. **Fix Q039 and chaos ending logic so one choice does not hard-select the ending.**
3. **Declare and implement `10.0.0.47` properly or remove direct connection to it.**
4. **Fix duplicate Q034 priorities.**
5. **Normalize Phase 6 to “calm but still problem-solving,” not Tier 1 hand-holding.**
6. **Choose one hidden-hook detection strategy before writing JSON/prep scripts.**

After those are fixed, this can become an implementation spec. Right now it is a strong story/system design draft with a few landmines buried exactly where the validator will step on them.
