Risks first, not files

The Fremen do not leave the sietch with a to-do list - they leave with a map of what kills. The desert is predictable in its hostility: every threat has a known weight and a known frequency. A test plan brings that rigor to the project: instead of covering files one by one, it maps risks on the impact × likelihood axes and describes each risk as a user-facing failure - "the cart loses items on refresh", not "cart.ts has no tests".

A test plan starts from a map of what kills the project, not from a list of files: it maps risks on the impact × likelihood axes and describes each risk as a user-facing failure - "the cart loses items on refresh", not "cart.ts has no tests".

Input: a working product and the PRD. Output: context/foundation/test-plan.md - a risk map cut into rollout phases, from the most dangerous scenarios down. Mechanism: /10x-test-plan orchestrates the delivery of tests instead of writing them itself - it drives each phase through the chain (research → plan → implement), and a re-run resumes from the next phase instead of starting over.

In "The Three-Body Problem" disputes are settled by experiment: a theory that cannot be measured is just an opinion. A test has the same nature - it must know what is correct from an oracle built from requirements and research, not from the code it checks. A test that reads its expected value from the implementation merely duplicates it - it will rubber-stamp every bug already living there. Hence the anti-patterns to eradicate: assertions copied from code, snapshots without understanding, mocks testing mocks.

A test must know what is correct from an oracle built from requirements and research, not from the code it checks. An assertion copied from the implementation merely duplicates it - it will rubber-stamp every bug already living there; hence the anti-patterns to eradicate: assertions copied from code, snapshots without understanding, mocks testing mocks.

Input: one risk from test-plan.md. Output: a test whose assertion actually fails on broken code. Mechanism: the mutation check - break the protected behavior on purpose and confirm the red; if the instrument does not scream after sabotage, it measures nothing. /10x-tdd enforces this order from the start: a red test before the code, green as proof, refactoring on protected ground.

A cruiser does not take fire on its hull armor - that is what deflector shields are for, layer after layer, from the cheapest on the outside to the most expensive at the plating. Quality defense works the same way and is ordered by cost: per-edit (lint and typecheck seconds after a save) → pre-commit → pre-push. The farther an error flies, the more it costs to shoot down.

Quality defense is ordered by cost: per-edit (lint and typecheck seconds after a save) → pre-commit → pre-push. The later an error is detected, the more its fix costs.

Input: the project's quality rules - lint, typecheck, fast tests. Output: hooks wired to events - per-edit, pre-commit and pre-push, each with its own time budget. Mechanism: a self-checking pipeline - drift is detected seconds after it appears, in the background, with no human involved; the only things that reach the end of a phase are those no layer could have caught earlier.

The Rocinante did not prove she could fly on dock schematics - she proved it with a test flight: drive, navigation, hull and crew at once, in vacuum. An E2E test is the same maneuver: a flight through all modules at once - UI, API, data - exactly where a mock would lie. The rule of the cheapest test that gives signal applies: if a unit test is enough, E2E is a luxury; if the unit test lies, E2E is the only honest measurement. Signal is the goal, not coverage.

An E2E test is a pass through all modules at once - UI, API, data - exactly where a mock would lie. The rule of the cheapest test that gives signal applies: if a unit test is enough, E2E is a luxury; signal is the goal, not coverage.

Input: a running application and a risk from the plan that nothing cheaper can cover. Output: Playwright tests + a seed test preparing the data for the flight. Mechanism: /10x-e2e drives the risk through plan → generate → review → verify on the running application, multimodally - the agent reads the DOM and looks at screenshots at the same time, so it also sees what a selector cannot catch.

The pilgrims on their way to the Time Tombs reach the truth only because each one tells his own story - none of them explains anything on its own, all of them at once point to the same place. Debugging with an agent works exactly the same way: a synthesis of evidence from many sources - Sentry from production, wrangler logs from the backend, console and network from Playwright - instead of mastery of a single tool.

Debugging with an agent is a synthesis of evidence from many sources at once - Sentry from production, wrangler logs from the backend, console and network from Playwright - instead of mastery of a single tool. No source explains anything on its own; all of them at once point to the same place.

Input: a symptom - a user-facing error, a red test, an alert. Output: a diagnosis backed by evidence and a fix pinned with a test so the regression does not come back. Mechanism: collect readings from all the instruments at once and look for where the tales intersect; along the way, eradicate error swallowing - a try/catch returning 200 is sweeping evidence away (OWASP A10:2025), and it makes the next diagnosis start from zero.