Skip to main content
Settings
Color Mode
Theme Skin
Background

Appearance preferences are saved in this browser only.

Environment
Current Environment Production

Built with JEKYLL_ENV=production. Changes require deployment.

Theme & Build
Jekyll v3.10.0
Last Build Jul 16, 18:44
Page Location
Page Info
Layout default
Collection quest-reports
Path _quest-reports/2026-07-16-system-engineer-0101.md
URL /quest-reports/2026-07-16-system-engineer-0101/
Date 2026-07-16

System Engineer · L0101 · 2026-07-16

Quest-perfection walkthrough of the CI/CD & DevOps slice system-engineer/0101 on 2026-07-16, engine verdict warn (avg 83.6%). An evidence-based…

Slice system-engineer/0101 · Level 0101 (CI/CD & DevOps) · Adventurer ⚔️ tier · Engine verdict ⚠️ warn (avg 83.6%) · Walked 2026-07-16

🔗 Perfection run · 🏠 Perfection dashboard · 📄 Raw report · 🕘 Change history


🎯 Session Summary

I walked the System Engineer, Level 0101 (CI/CD & DevOps, Adventurer ⚔️) slice — a windowed run covering 5 of the level’s 13 quests (window 1 of 3), in the dependency-sorted order the planner selected. The sandboxed execute engine scored the five at an 83.6% average (4 pass · 1 warn · 0 fail); I read every quest as a learner would and reason about the chain below.

Headline verdict: WARN. The technical core across all five quests is genuinely strong — flagship commands (the triage.sh isolation build, the c8 coverage gate that both passes and correctly fails below threshold, the docker build/tag and rollback idioms, the env-var/config-layering examples, and the OIDC/least-privilege content) were actually executed in the sandbox and behaved exactly as documented. Two defects keep this from a clean pass: (1) Testing Integration references test:unit/test:integration/test:e2e npm scripts it never shows how to create — a literal Missing script: "test:unit" failure a beginner hits head-on — and (2) Secrets Management ships a Jekyll {​% raw %​}{​% endraw %​} templating artifact inside its Chapter 1 workflow YAML that breaks a verbatim copy-paste. Both are concrete, evidenced, copy-paste-fatal, and cheaply fixable by a content pass.

🗺️ The Journey

Planned order (dependency-sorted by the planner; the four DevOps quests form a clean Testing → Deployment → Environment → Secrets prerequisite chain, with The Cartographer sitting apart — see Chain Continuity):

  1. The Cartographer: File Platform Bugs Upstream87 · triage.sh, both Jekyll builds, all three YAML blocks and the multi-line git commit ran for real and matched the quest; only the “find the theme <sha>” guidance is unreliable.
  2. ⚠️ Testing Integration: Tiered CI/CD Test Gates71 · pyramid, gating, and the coverage gate are verified end-to-end, but the test:* scripts the CI YAML depends on are never created, and two bonus objectives are named yet never taught.
  3. Deployment Pipelines: Production Release Automation89 · every runnable snippet (docker build/tag, gh api fallback, rollback bash, gh workflow run flags) worked; the hands-on challenges assume deploy/health/rollback scripts never scaffolded.
  4. Environment Management: Dev, Staging, and Prod Parity88 · shell, PowerShell, config.js, and YAML base/override layering all executed as described; docker/terraform examples are illustrative placeholders not flagged as such.
  5. Secrets Management: Secure CI Credentials83 · accurate OIDC/least- privilege/rotation content with valid gh/aws syntax; the standout defect is the {​% raw %​} leak in the Chapter 1 workflow YAML.

🔬 Evidence

All evidence below comes from the sealed walk-evidence.json — commands the execute engine actually ran in a disposable sandbox. Snippet coverage is quoted as ran/passed/failed/skipped/reasoned from the engine’s recorded run.

1. The Cartographer — 87 (pass) · ran 6, passed 5, failed 1, reasoned 1 (of 6 available / 2 runnable)

  • passed — Set up a real Jekyll 4.4.1 project in an isolated GEM_HOME, cloned bamr87/zer0-mistakes, and ran triage.sh verbatim: both bundle exec jekyll build --trace runs (product + minimal) succeeded, triage/min.md rendered at _site/triage/min/index.html, and the final grep -iE 'error|warning' printed “No errors in either build.”
  • passed — Independently verified the script’s own dotdir warning: a page placed in .triage2/ produced no output file on rebuild — the “Jekyll skips dotdirs” claim is technically correct.
  • passed — All 3 YAML blocks parsed cleanly (YAML.load_file); the issue-form YAML matches GitHub’s real body:-list schema. The multi-line git commit ran in a fresh repo and committed with the exact message.
  • failed / reasonedcontent_accuracy scored 3: inspecting jekyll-remote-theme 0.4.3’s theme.rb shows root = File.realpath Dir.mktmpdir(...) — a fresh temp dir per build, no persistent cache; running bundle exec gem contents jekyll-remote-theme lists only the plugin’s own source, not the fetched theme. The “find the theme <sha>” guidance (source line ~144) doesn’t work as written.
  • The anchor commit bamr87/lifehacker.dev@5853ef43b (PR #42) was verified real.

2. Testing Integration — 71 (warn) · ran 11, passed 10, failed 1, skipped 2, reasoned 2 (of 11 / 7 runnable)

  • passed — Linux setup (npm init -y, npm pkg set scripts.test="node --test") produced a working test script; total.js/total.test.js ran via npm test with both assertions passing (# pass 2, # fail 0).
  • passednpx c8 --check-coverage --lines 80 --functions 80 node --test reported 100% coverage, exit 0. The gate was proven to gate: adding an uncovered function produced ERROR: Coverage for lines (54.54%) does not meet global threshold (80%) with a real non-zero exit. Chapter 3’s flagship claim holds end-to-end.
  • failednpm run test:unit -- --test-reporter=tap (as Chapter 3’s snippet, line ~369, and the CI YAML lines ~284/299/310 imply) → npm error Missing script: "test:unit". The quest never shows how to create test:unit/test:integration/ test:e2e, yet the Chapter 2 checkpoint (line ~322) asserts the learner has them.
  • reasoned — On Ubuntu 24.04 the default apt candidate for sudo apt install -y nodejs npm is nodejs 18.19.1Node 18, contradicting the quest’s own stated “Node.js 20+” requirement (line 127).
  • reasonednpm test on the ESM examples emits [MODULE_TYPELESS_PACKAGE_JSON] because "type": "module" is never set.

3. Deployment Pipelines — 89 (pass) · ran 4, passed 4, failed 0, skipped 2, reasoned 2 (of 8 / 5 runnable)

  • passeddocker build -t myapp:$(git rev-parse --short HEAD) . built against a test Dockerfile; docker tag ... registry.example.com/myapp:staging tagged correctly.
  • passedgh api repos/:owner/:repo/environments || echo "..." behaved exactly as documented (unauth call failed, fallback echo fired). Verified with --verbose that the legacy :owner/:repo colon syntax resolves identically to {owner}/{repo}.
  • passed — The rollback idiom ./scripts/health-check.sh production || ./scripts/rollback.sh production was tested with stubs (health-check exits 1) and correctly triggered rollback; the Chapter 3 YAML parses as valid YAML (yq + Python).
  • skipped / reasonedbrew/winget install snippets unrunnable on Linux (tools absent), reasoned correct by package name. deploy.sh/smoke-test.sh/ health-check.sh/rollback.sh are referenced but never scaffolded anywhere.

4. Environment Management — 88 (pass) · ran 7, passed 6, failed 1, skipped 1, reasoned 1 (of 9 / 6 runnable)

  • passed — macOS/Linux bash and the PowerShell snippet (run via pwsh -NoProfile) all printed “Running in: development against postgres://localhost:5432/app_dev”.
  • passedconfig.js run under Node 20: with vars set it printed the config; with DATABASE_URL unset it threw Error: Missing required config: DATABASE_URL — the “fail loudly” claim is verified true.
  • passedconfig/base.yml + config/production.yml parse as valid YAML; the simulated shallow merge yields log_level: warn, request_timeout_ms: 3000 while name: my-service is inherited — the layering claim holds.
  • faileddocker run -e APP_ENV=staging ... myapp:1.4.2 run verbatim → pull access denied for myapp, repository does not exist (expected placeholder, but not flagged as one). The Terraform main.tf is valid HCL but uses a fictional app_service resource and couldn’t be terraform apply‘d (no CLI/network).

5. Secrets Management — 83 (pass) · ran 6, passed 4, failed 2, skipped 5, reasoned 2 (of 10 / 6 runnable)

  • passedgh (2.96.0) and aws (2.35.15) present; gh secret set, gh auth login, aws sts get-caller-identity, aws secretsmanager get-secret-value are all valid current syntax. Both IAM policy JSON blocks and both workflow YAML blocks parse.
  • failedBUG: the Chapter 1 workflow YAML (source line 234) contains literal, unrendered Jekyll templating: STRIPE_API_KEY: ${​% raw %​}{​{ secrets.STRIPE_API_KEY }​}{​% endraw %​}. Parsed as YAML this is the string ${​% raw %​}{​{ secrets.STRIPE_API_KEY }​}{​% endraw %​}not valid GitHub Actions expression syntax. A learner copying this block into a real workflow breaks the deploy.
  • failed / skippedgh secret set and aws calls returned only credential/context errors (no auth in sandbox), expected. gh secret set NAME also assumes a repo context the platform-path instructions never establish.

🐞 Issues Found

Grouped by severity. Every item is either tested (a command actually run in the sandbox) or reasoned (judged statically from the quoted source) — labeled inline.

High

  • [tested] · Testing Integration · Chapter 2 / CI YAML (lines ~284/299/310, checkpoint ~322, flaky reporter ~369) — Running npm run test:unit yields npm error Missing script: "test:unit". The quest sets only a generic scripts.test="node --test" yet the CI YAML and Chapter 2 checkpoint depend on three named scripts. Fix: add an explicit step, e.g. npm pkg set scripts.test:unit="node --test test/unit" scripts.test:integration=... scripts.test:e2e=..., before the CI YAML.
  • [tested] · Secrets Management · Chapter 1 workflow YAML (line 234) — The ${​% raw %​}{​{ secrets.STRIPE_API_KEY }​}{​% endraw %​} templating artifact leaks into the code block and breaks a verbatim copy. Fix: render it as clean STRIPE_API_KEY: ${​{ secrets.STRIPE_API_KEY }​} by wrapping the whole fenced block in a single {​% raw %​}…{​% endraw %​} pair (as the Cartographer quest does at lines 251/267) rather than inlining the tags inside the expression.

Medium

  • [tested] · Testing Integration · Linux Territory Path (line 182 vs requirement 127)sudo apt install -y nodejs npm installs Node 18.19 on Ubuntu 24.04, violating the quest’s own “Node.js 20+” prerequisite. Fix: use NodeSource’s setup script or nvm.
  • [reasoned] · Testing Integration · Secondary Objectives (lines 107, 109) — “Test Sharding” and “Status Checks” are listed but the strings appear nowhere else in the body. Fix: add brief subsections or remove them from the checklist.
  • [reasoned] · Testing Integration · Advanced Challenge (lines 399–405) — Learners are told to “quarantine” a flaky test but no quarantine mechanism (test.skip/{ skip: true }/tagging) is ever shown. Fix: demonstrate one concrete pattern.
  • [reasoned] · Deployment Pipelines · Chapter 3 / Mastery Challenges (lines 295–327, 348–366)deploy.sh, smoke-test.sh, health-check.sh, rollback.sh are referenced throughout but never scaffolded; for a 🔴 Hard quest this leaves the entire hands-on toolchain to the learner. Fix: provide minimal working or clearly-marked stub scripts.
  • [tested] · The Cartographer · Chapter 1 “Finding the theme <sha>” (lines 142–148)gem contents jekyll-remote-theme lists only the plugin’s own source and there is no post-build cache to inspect (ephemeral Dir.mktmpdir). Fix: replace with a reliable route, e.g. git ls-remote https://github.com/bamr87/zer0-mistakes <branch> or pin remote_theme: owner/name@<sha> explicitly.
  • [tested] · Environment Management · Cloud Realms docker snippet (line 190)docker run ... myapp:1.4.2 fails verbatim with “pull access denied”. Fix: add a one-line note that myapp:1.4.2 / $STAGING_DB are placeholders to substitute.
  • [reasoned] · Environment Management · Secondary objectives (lines 108–109) — “Drift Detection” and “Environment Naming” are objectives but never taught. Fix: add a short terraform plan/config-diff example and a tagging convention, or trim the list.
  • [reasoned] · Secrets Management · Secondary objectives (lines 108–109) & gh secret set context — “Environment Scoping” and “Leak Detection” have no hands-on snippet; gh secret set NAME never notes it needs a repo context / --repo owner/repo. Fix: add minimal snippets and a one-line repo-context note.

Low

  • [tested] · Testing Integration · Chapter 1 (lines 229–248) — ESM examples emit MODULE_TYPELESS_PACKAGE_JSON; add npm pkg set type=module or a note.
  • [reasoned] · Deployment Pipelines · Cloud Realms (lines 196–201) — Prose says “deploy the identical digest” but the snippet only tags :staging; show promotion to production (or soften “digest” → “tag/image”).
  • [reasoned] · Environment Management · Chapter 3 main.tf (lines 297–306) — Label the fictional app_service resource as a placeholder, or use a real provider.

No fabricated results are included; where the sandbox couldn’t run something (no auth, no terraform/brew/winget, network-restricted) it is marked skipped/reasoned, not passed.

🔗 Chain Continuity

The slice is two campaigns, not one. Quests 2–5 (Testing → Deployment → Environment → Secrets) belong to the “DevOps Pipeline Mastery” / “The Forge of Automation” line and form a clean, correctly-ordered dependency chain: Testing unlocks Deployment; Deployment requires Testing and unlocks Environment + Secrets; Environment unlocks Secrets. The plan order matches these edges — a learner walking 2→3→4→5 is never asked for a prerequisite an earlier quest in the window didn’t foreshadow. Continuity between quest 4 and 5 is especially good: Environment Management explicitly defers credentials (“you will inject those in the Secrets Management quest”, line 273) and Secrets Management picks up exactly there.

The Cartographer (quest 1) is an orphan in this window. It belongs to a different line (“The Self-Operating Website” / “The Autonomous Realm”), required_quests: [], and its own chain threads levels 1101 → 0101 → 1110 — it recommends Chapter VII at level 1101 (a higher binary code) and unlocks Chapter IX at 1110. It shares no dependency edge with the four DevOps quests and assumes a Ruby/Jekyll toolchain + Claude Code OAuth token, whereas the DevOps four assume Node 20+ / gh / aws. It sits in this window only because it carries the 0101 tag. As a linked journey it does not build toward or from its neighbors — a real learner would experience a hard context switch between quest 1 and quest 2. This is a planning/curation observation, not a defect in the quest itself.

Assumed base outside the window. All four DevOps quests require /quests/0101/cicd-fundamentals/, which is not in this window (it’s elsewhere in the level’s 13). That is expected for a windowed sweep — but a learner starting cold at this window is assumed to have already forged CI fundamentals.

Character-routing mismatch. The planner walked the Software Developer “main story” spine. Yet the in-quest “Character Class Recommendations” route a System Engineer differently: Testing Integration sends the System Engineer to Workflow Optimization (not Deployment), and Deployment sends them to Secrets Management (skipping Environment). So a System Engineer following the quests’ own class pointers would take a different path than this slice’s order. Not a bug, but worth flagging that the slice order reflects the Developer spine rather than the System Engineer branch.

Within-quest gaps that break “ready for the next step.” Two quests assume artifacts they never produce: Testing Integration’s missing test:* scripts and Deployment Pipelines’ never-scaffolded deploy/smoke/health/rollback scripts. A learner who completed Testing Integration is not actually left with a runnable npm run test:unit, so the hands-on continuity into Deployment’s pipeline work is weaker than the prose implies.

🧠 Reasoning & Method

  • Mode: execute. The machine evidence in walk-evidence.json / walk-evidence.md was pre-computed and sealed by the workflow (the execute engine’s child claude processes cannot authenticate from an agent’s Bash tool). Per the skill, I consumed it as-is — I did not re-run, regenerate, edit, or hand-write any evidence, and I did not modify walk-plan.json. Every passed/failed above is quoted from that sealed engine run; every reasoned item I judged statically from the quest source I read.
  • What I ran vs. reasoned: I did not execute commands myself this session — the sandbox execution was the workflow’s deterministic engine step. My contribution is the linked-journey analysis: I read all five quest sources in plan order and reasoned about prerequisites, ordering, campaign coherence, character routing, and where a real System Engineer beginner would stall.
  • Coverage & limits: This is window 1 of 35 of 13 quests in Level 0101. I make no claim about the other 8 quests or about later windows. The engine’s sandbox is Linux (Ubuntu 24.04) and network-restricted, so brew/winget/terraform/ authenticated gh/aws steps were legitimately unrunnable and are reported as skipped/reasoned, never as passed. OS-specific claims verified only against Linux.
  • Confidence: High on the two tested high-severity issues (both are reproducible command/parse failures with quoted output). Medium on the reasoned completeness gaps (they are clear from the source text but were not exercised hands-on). The overall WARN reflects one warn-tier quest plus two copy-paste-fatal defects amid otherwise strong, verified technical content.

One slice, one report. No quest content was modified; fixable issues are captured above for a content pass. The caller handles git.