/red-line-digital
Interactive field guide

The /page-implement pipeline

This is the one that writes code. It executes a locked plan exactly, then turns critics on the diff, filters them through a referee, simplifies, and does not call the page done until the build passes and a fresh full review comes back clean.

The final review can send the work back once, but only once; a second wave means something deeper is wrong. If that cap feels tight, 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: writing, critique, verifying, or the final pass.
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 planNo plan lock, no build

Pre-flight

The pipeline reads the locked code plan for this page. If it isn't locked, it refuses and tells you to lock it first. This is the stage that writes real code, so it will not start from a moving target.

Read the locked code plan; refuse if it isn't locked. Note the risk surface for the security passes.

What happens

The pipeline finds the page's code plan and confirms the locked marker. Building against an unlocked plan would mean writing code that the plan might still contradict, so it stops.

It notes any risk surface from the plan, which arms the security-asymmetric rule for both adjudications later.

Who acts

  • Read, tool: Reads the locked code plan.

The rules

  • Locked plan or stop. This is the only pipeline that writes code; it refuses to start from an unlocked plan.

In: A page name with a locked code plan. Out: A confirmed plan, cleared to execute.

Stage 1Write the codeFollow the plan, nothing extra

Execute

The pipeline writes the code, following the locked plan exactly: the files it named, the changes it named. Anything you notice that isn't in the plan goes to the backlog, not silently into the diff. If the plan turns out too thin to follow, it kicks back rather than guessing.

Execute the locked plan exactly. Scope creep goes to the backlog; a thin plan kicks back to /page-code.

What happens

The files are created and changed exactly as the plan specified. The hard rule is no scope creep: a good idea that the plan did not call for becomes a follow-up in the backlog, so the diff stays honest to the plan.

If the plan is missing a detail it needed, the pipeline kicks back to /page-code to firm it up rather than improvising a decision the plan should have made.

Who acts

  • Write / Edit, tool: Writes the code exactly as the locked plan specifies.

The rules

  • The plan, nothing extra. Work beyond the locked plan is a backlog follow-up, never a silent addition to the diff.
  • Kick back, don't guess. A plan too thin to follow returns to /page-code instead of being improvised.

In: The locked code plan. Out: A working diff that matches the plan.

Stage 2Three critics on the diffBugs, security, simplicity

Critique

Now that real code exists, three critics read the actual diff at once. One hunts bugs and quality issues. One runs a focused security review. One looks for dead code and needless complexity.

Three parallel critics on the written diff: a code reviewer, a security review, and a simplifier. Blind to each other.

What happens

The code reviewer reports the high-confidence bugs and convention slips. The security review runs a focused pass over the changes. The simplifier looks for dead code, redundant checks, defensive code for impossible states, and abstractions built before they had two callers.

All three read the same diff in parallel and blind, and their findings are collected for the referee.

Who acts

  • code reviewer, agent: High-confidence bugs, logic errors, convention slips.
  • security review, agent: A focused security pass over the diff.
  • simplifier, agent: Dead code, redundancy, premature abstraction.

The rules

  • Critique the code, not the plan. These critics read the actual written diff, so they catch what only shows up once it exists.
  • Confidence-filtered. The reviewer reports only high-confidence issues, so the referee is not buried in maybes.

In: The written diff. Out: Three sets of findings, ready for the referee.

Stage 3Referee, then your callKeep, ditch, or modify

Adjudicate

The referee marks each finding keep, ditch, or modify against the project's standards, security weighted. Then you choose which to absorb before the revise pass.

The Adjudicator rules on the diff findings with a security-asymmetric upgrade, then a checkpoint asks which to absorb.

What happens

The referee judges the three critics' findings against the project's real standards, with the security bump in force. Its own field guide walks the judgement.

Then your checkpoint: absorb everything kept and revise, proceed to verify with no changes, 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

  • Your call on what lands. You choose which surviving findings the revision absorbs, or send it straight to verify.

In: The three critics' findings. Out: A filtered set of findings to fix.

Stage 4Revise and simplifyFix, then clean

Simplify

The pipeline makes the fixes you approved, then runs a dedicated simplify pass over the changed files, taking cuts that have a concrete reason and rejecting generic best-practice appeals. It also flags any sibling copies of a pattern it fixed.

Apply the verdicts, then a simplify pass; flag any sibling patterns caught that the plan did not name.

What happens

The approved fixes are applied, then a simplify pass looks for anything that can be smaller: dead code, needless indirection, comments that restate the code. It takes suggestions with a real failure mode behind them and rejects the generic ones.

If it catches the same pattern living elsewhere under a different name, it flags each sibling: fixed here, or logged to the backlog. That log is how the project learns whether sibling checks should move earlier.

Who acts

  • simplify, skill: A dedicated pass for dead code, redundancy, and needless complexity.

The rules

  • Concrete reasons only. A simplification needs a real failure mode or a project-doc citation; generic best-practice appeals are rejected.
  • Flag the siblings. The same pattern found elsewhere is named and either fixed or sent to the backlog, never silently left.

In: The approved fixes. Out: A revised, simplified diff with siblings flagged.

Stage 5Build and prove itNot done until green

Verify

The pipeline builds the project. If it fails, it debugs to the root cause and loops until it's green. Pure-logic changes have to ship with the test the plan named. Then it runs the manual checks the plan listed.

The build must pass; pure-logic changes ship with their characterization test; then the plan's manual checks run.

What happens

A failing build is not a stopping point; the pipeline finds the root cause, fixes it, and re-runs until the build is clean. A change to pure logic that arrived without its named test is a verify failure, so the test is written and confirmed passing before moving on.

It then runs the manual checks the code plan listed and confirms the lint count did not get worse. Only a green build and passing checks let the pipeline continue.

Who acts

  • the build + tests, tool: The gate: a clean build and passing tests, or the pipeline loops.

The rules

  • Green or loop. A failing build loops through debugging until it passes; verify is never skipped.
  • Pure logic ships tested. A logic change without its characterization test is a verify failure, not a pass.

In: The revised diff. Out: A building, tested, manually-checked page.

Stage 6A fresh full reviewSix lenses, one more time

Final pass

With the page building and tested, a comprehensive review toolkit runs a final pass over everything: a code reviewer, a silent-failure hunter, a type-design analyzer, a comment analyzer, a test analyzer, and a simplifier. It's the last wide look before done.

A comprehensive final review toolkit runs a fresh full pass across bugs, silent failures, types, comments, tests, and simplicity.

What happens

This is a separate, comprehensive review, not the same three critics again. It brings a wider set of lenses to the finished, building page: silent failures, weak types, stale comments, thin tests, and lingering complexity.

If it finds nothing, the pipeline is done. If it finds something, that goes to one more adjudication.

Who acts

  • the review toolkit, skill: A comprehensive multi-lens final review pass.

The rules

  • A wider net at the end. The final pass brings lenses the earlier critique did not, on the finished code.

In: The building, tested page. Out: A clean bill, or a last set of findings.

Stage 7Adjudicate the final passOne cycle, then stop

Last call

If the final pass found anything, the referee judges it and you choose what to absorb. The pipeline will revise and re-verify once. If a second new problem surfaces after that, it stops and surfaces it, because a page that keeps growing new findings has something deeper wrong.

If the final pass found issues, adjudicate them; revise and re-verify at most once, then stop for a human.

What happens

The referee rules on the final-pass findings, security weighted, and you choose what to absorb. Approved fixes are made and the page is re-verified.

The cap is one cycle. If a second pass surfaces genuinely new problems, the pipeline stops and hands it to you rather than looping, because that pattern means the plan or the design, not the code, is the real issue.

Who acts

  • the Adjudicator, agent: Judges the final-pass findings. Has its own guide.
  • AskUserQuestion, command: The checkpoint: which final-pass findings to absorb.

The rules

  • Max one cycle from review. The pipeline revises and re-verifies once; a second new finding stops it for a human.
  • New findings can escalate. A structural finding kicks back to /page-code; a design mismatch kicks back to /page-design.

In: The final-pass findings. Out: A finished page, or an honest kick-back.

Stage ✓A page built, reviewed, verifiedWritten, then proven

Shipped

What you end with is a page that was written to a locked plan, critiqued on its real diff, simplified, built green with tests, and passed a fresh full review. The next step is a pre-commit check, then it ships.

The one pipeline that writes code, wrapped in critique and verification so the diff is proven before it commits.

What happens

This is where the plans become real. Everything before it was on paper; this pipeline turned a locked plan into a building, reviewed, tested page.

It closes by pointing you at a pre-commit check before you commit. If the page has interactive UI, it also recommends a mobile audit, because a build check never exercises runtime accessibility.

The rules

  • Proven, then committed. The diff is critiqued, simplified, built, and reviewed before it is ever committed.

In: A locked code plan. Out: A built, reviewed, verified page, ready to commit.