/red-line-digital
Interactive field guide

The /page-code pipeline

Before a page is built, its code gets planned: exact files and changes, not vague intentions. Three critics read the plan at once for structure, security, and performance, a referee weighs their findings with a thumb on the security scale, and the result is locked so building it is mechanical.

Security findings get bumped a level on purpose; the rest do not. If that asymmetry feels wrong, or right, tell us. Reply on LinkedIn.

How to read this map

Each card is a stage of the pipeline, in order. Two of them stop and wait for your approval.
The colour on each card's edge tells you what kind of work it is: a gate, a draft, critique, or the lock.
Open any card for the full, plain-language walkthrough at that stage.

Pick a stage to walk, or start at the top

Get this command /plugin marketplace add fire-farmer/red-line-toolkit view source →

The walkthrough, as text

Every stage of the interactive walkthrough above, as plain readable text. Each stage has its own link.

Stage 0Start from a locked designNo design lock, no code plan

Pre-flight

The pipeline reads the locked design doc for this page. If the design isn't locked, it refuses and tells you to lock it first, because a code plan built on a moving design is wasted work.

Read the locked design doc; refuse if it isn't locked. Flag any risk surface for the security lens.

What happens

The pipeline finds the page's design doc and confirms it carries a locked marker. An unlocked design means the code plan would be planning against something still in flux, so it stops.

It also notes whether the page touches a risk surface like logins, payments, or money math, which arms the security-asymmetric rule for the referee later.

Who acts

  • Read, tool: Reads the locked design doc and the project conventions.

The rules

  • Locked design or stop. A code plan is only worth building against a settled design; an unlocked one pauses the pipeline.

In: A page name with a locked design. Out: A confirmed design and a note of any risk surface.

Stage 1Draft the code planExact files, not intentions

Draft

The pipeline writes the plan: which files get created or changed, exactly what changes in each and why, how data moves, where the security boundaries are, what could be slow, and how it will be tested. Vague is not allowed. Then it pauses for your sign-off.

A code plan specific enough to be mechanical: exact files, per-file changes, data flow, security boundaries, performance, and a test plan.

What happens

The plan names exact file paths and the change in each with a reason, not 'we'll figure out the structure later'. It maps how data flows through the state store and service modules, and marks the security boundaries: server-side checks, input validation, and injection vectors.

It flags what could be slow and how to avoid it, and it names the tests. Pure-logic changes must name a characterization test and the exact input and output to capture. This is the first hard pause.

Who acts

  • AskUserQuestion, command: The approval gate after the plan, before the critics.

The rules

  • Exact, or it's not a plan. Missing file paths or test scenarios mean the plan is incomplete; it is revised before it locks.
  • Pure logic ships with a test. Any change to pure logic names a characterization test and its input-output pair up front.

In: The locked design. Out: A code plan ready for critique.

Stage 2Three critics at onceStructure, security, performance

Critique

The plan goes to three critics at the same time, none seeing the others. One checks it against the project's conventions and structure. One reads it for security holes. One looks for what will be slow.

Three parallel critics: structure and conventions, security, and performance. Blind to each other.

What happens

The structure critic checks component patterns, file-size discipline, state organisation, and that components never reach for the network directly. The security critic verifies server-side checks, input validation on money fields, injection and export safety, and no secrets in source, escalating its own risk findings.

The performance critic looks for heavy pieces that should be lazy-loaded and memoization that quietly fails on unstable callbacks. All three run blind and in parallel.

Who acts

  • structure critic, agent: Conventions, file sizes, state and service patterns.
  • security critic, agent: Server-side checks, validation, injection, secrets.
  • performance critic, agent: Lazy-loading and silent memoization failures.

The rules

  • Blind and parallel. No critic sees another's findings, so none anchors on the others.
  • Security escalates itself. The security critic raises the severity of its own risk findings before they even reach the referee.

In: The code plan. Out: Three sets of findings, ready for the referee.

Stage 3Referee, security weightedKeep, ditch, or modify

Adjudicate

The referee marks each finding keep, ditch, or modify against the project's standards, with one thumb on the scale: a plausible security finding can be bumped up a level, and nothing else can. Then you choose what to absorb.

The Adjudicator rules on each finding with a security-asymmetric upgrade, then a checkpoint asks which to absorb.

What happens

The referee judges each finding against the project's real standards, cutting generic noise. The one asymmetry: a security finding can escalate a level even when uncertain, because the cost of missing a real one is too high. Its own guide walks the judgement.

Then your checkpoint: absorb everything kept, keep the plan as-is, or pick specific findings.

Who acts

  • the Adjudicator, agent: Marks findings KEEP/DITCH/MODIFY with a security bump. Has its own guide.
  • AskUserQuestion, command: The checkpoint: which findings to absorb.

The rules

  • Security is the only thumb on the scale. A plausible security finding escalates; no other kind does.
  • Your call on what lands. You choose which surviving findings the revision absorbs.

In: The three critics' findings. Out: A filtered, security-weighted set of findings.

Stage 4Revise and lockFreeze the plan

Lock

The pipeline folds in the findings you chose and writes the code plan to a locked doc, tied to its design. From here the plan is settled and specific enough that building it is mechanical.

Apply the absorbed findings, then write a locked code plan that /page-implement executes.

What happens

The revised plan is written to a dated code-plan doc marked locked, pointing back to the parent design.

That lock is the hand-off. The /page-implement pipeline reads this plan and writes the code from it; if implementation finds the plan wrong, it kicks back here rather than improvising.

Who acts

  • Write, tool: Writes the locked code plan to disk.

The rules

  • Locked means buildable. The plan is specific enough that /page-implement can execute it without guessing.

In: The filtered findings and the plan. Out: A locked code plan, ready for /page-implement.

Stage ✓A page's code, planned before writtenReady to build

Plan locked

What you end with is a plan detailed enough that implementation is mechanical: exact files, exact changes, security boundaries drawn, tests named. The next step writes it.

A locked code plan is the hand-off point: /page-implement executes it, critiques, and verifies.

What happens

No code was written here either. The pipeline produced a plan so specific that building it is execution, not invention.

From here, /page-implement writes the code, runs its own critique and verify passes, and ships the page. It has its own field guide.

The rules

  • Plan, then build. The locked plan is what implementation executes; guessing is designed out before a line is written.

In: An approved, filtered plan. Out: A locked code plan, ready for /page-implement.