01 / RUN AND CHANGE A RULE
Who owns the score?
Play the real client/server game, repair a proximity guard and prove that remote pickup fails while a legal delivery succeeds.
Runnable opening availableStudy authority and range →Anti-cheat engineering / software core
Build the rule.
Test the claim.
Start with a tiny game you own. Implement server-side rules, write independent tests, check owned code, reproduce decisions and learn what the evidence cannot tell you.
Beta local teaching project, not production anti-cheat · guided decisions work in a mobile browser · source editing needs Node 22+ on a workstation · all navigation stays open · human learning, time estimates and native accessibility remain unvalidated
Start the guided course → Work through a solved sibling, a partly solved case and a fresh checked decision in each section. Each unit has a separate three-item mastery set. Browser decisions prepare you for source work; they do not replace the code and HTTP projects below.
This route assumes basic JavaScript functions, objects and arrays, plus command-line file editing. M3 introduces asynchronous HTTP and assertions through a worked example and a completion exercise; later labs name the additional system concepts they introduce. Your work is source code plus preserved tests and reasoning. Reading a page or passing a supplied example does not establish transfer.
A small systems starting point
A program is stored code; a process is one running instance. Here the browser and Node server run separately and exchange HTTP messages. The server keeps the authoritative score. A browser button can request an action, but changing browser memory cannot by itself change the server’s saved state. Trace that boundary before adding a guard.
The book context is System Programming in Linux, chapter 1, “Processes”; the networking reading and source limits are in the reading map. Node supplies the OS interfaces for this course, so native system-call programming is not a prerequisite.
02 / VALIDATE TRANSITIONS
Old input, new consequences
Implement admission, expiry and interaction coalescing without giving the client authority over position or score.
Runnable policy exercise availableStudy admission policy →03 / AUTHOR ADVERSARIAL TESTS
Make your test discriminate
Write HTTP scenarios that accept two correct implementations and expose seven plausible defects.
Independent scenario grading availableStudy test design →04 / TIME AND RECOVERY
Retries are ordinary
Investigate clumping, reorder, loss, expiry and reconnect. Distinguish a transport retry from a cheating inference.
Runnable timing prediction exercise availableStudy the timing contract →05 / OWNED INTEGRITY AND VERSION
Which bytes are approved?
Build an inventory/digest policy. Stop changed runtime bytes, admit an approved update and state the reference's trust limit.
Runnable source exercise availableStudy package integrity →06 / TELEMETRY AND REPLAY
Can you reproduce the decision?
Replay a complete causal window, preserve the state a screenshot misses and refuse incomplete or incompatible records.
Runnable source exercise availableStudy causal replay →07 / DETECTOR EVALUATION
Measure catches and mistakes
Evaluate labelled cases, false positives, misses and a threshold frozen before the final run.
Runnable source exercise availableStudy evaluation →09 / COST AND PRIVACY
Keep only useful evidence
Measure the actual workload, bound retained data, test deletion and state the limits of a local benchmark.
Runnable source exercise availableStudy bounded retention →10 / LOCAL ROLLBACK
Recover a compatible system
Detect a bad update, restore an approved runtime/configuration and demonstrate legal behavior again.
Runnable recovery selection and real-engine trialStudy compatible recovery →11 / NEW MECHANIC CAPSTONE
A fresh rule with a real cost
Construct and independently test a new server-owned resource rule, including retries and invalid state.
Two source files and real HTTP assessmentStudy the repair station →What is outside this core?
Module 8 is an optional owned-native investigation with a separate platform bridge. It is not needed for this route. No third-party game tampering, kernel installation, OS-security change or production-security claim is part of these labs. Plan several sittings. The previous source-only estimate was 9–17 active hours for an experienced JavaScript engineer. The new guided work adds practice, so that range is a historical baseline, not an estimate for this version. Actual human duration and learning outcomes remain unmeasured.