Three documents, written before the code.

Every page about this way of working describes the artifacts. This is one real chain from the repository behind this website — what was written, in what order, and what it caught before anyone opened an editor.

Nothing here has been tidied. Whole sections are cut for length and each one says what was removed, but no sentence has been improved for publication. A polished chain would prove nothing.

The situation

Forty-nine case-study pages were rewritten in a single session. The copy was good. The template underneath grew six per-page switches to carry it, and four of them ended up set the same way on every page — which means they were not switches, they were the template, written out forty-nine times.

01Stage 1 · Plan

intent.md

States the problem once, in a form the next stage can read without anyone re-explaining it.

Reads: A code review, and whoever raised it
Gate: Product owner

Nothing here is a solution. The point of the stage is to be specific about what is wrong before anyone is attached to a fix.

intent/work-story-template/intent.md

## Problem

The 49 work stories were rewritten in one commit, and the template grew a set of per-page switches to carry the new copy. Four of those switches are set the same way on every page, which means they are not switches — they are the template, written out 49 times. A fifth change made the structured data worse.

services: is dead data. Both places that read it are gated on practiceLinks, which is false in all 49 files, so none of it renders.
practiceLinks is declared .default(true) and set false 49 times. The default is never exercised.
metaDescription is byte-identical to summary in 47 of 49 files. Each edit has to be made twice, which is how two of them silently drifted apart and shipped truncated.
The JSON-LD BreadcrumbList name is now a full sentence ending in a period.

## Proposed outcome

The template carries what every page shares; frontmatter carries only what a page says differently. The structured data goes back to naming the page rather than quoting it.

## Constraints

The closing copy already carries the practice link. Whatever happens to services, that link stays.
Two of the six are copy decisions, not code ones. They need a person, not a refactor.
Live pages. This is not a reader-visible update, so the sitemap dates should not move.

## Open questions

Is the practice band gone from work stories for good? If so, two of the items collapse into deleting it.
Does the search title move toward the new headline, or the headline back toward the old title?

Cut for length: Two of the six numbered problems, and the affected-systems section.

02Stage 2 · Design

spec.md

Turns the problem into requirements, and applies the standards up front instead of finding them in review.

Reads: intent.md
Gate: Product owner, against the intent

The constraint table is the part that earns its keep. Every constraint from the intent has to be answered in writing, so none of them can be quietly dropped between the complaint and the build.

intent/work-story-template/spec.md

## Requirements

R1 The practice band and the hero’s second button are removed, and practiceLinks is deleted from the schema and from all 49 files.
R2 services: is deleted from all 49 work stories. The practice link survives in the closing copy, which is already true on every page.
R3 metaDescription becomes optional and falls back to summary. The 47 duplicate values are deleted; the two that genuinely differ stay.
R4 The breadcrumb schema uses a short page label, not the headline.

## Design

R3 needs a fallback, not a default, because schema defaults are evaluated per entry without access to a sibling field.

R4 has two candidates. Either reuse the group label the visible breadcrumb already ends on — making the structured data match the on-page trail — or add a short label field. The first needs no new field and removes a disagreement that predates this batch.

## Constraint mapping

The practice link stays → untouched; it lives in the closing copy, not in services.
Two are copy calls → out of scope here; they stay open in the intent.
Not a reader-visible update → R1 changes the page, so dates move honestly for those; R3 and R4 touch metadata only, which the date script already ignores.

## Areas of concern

Removing the practice band deletes the only in-page link from a work story to the service it belongs to, other than the closing call to action. If that is ever reworded away from naming a practice, those 49 pages become link-dead toward the services tree.

Cut for length: One requirement and the inherited open questions.

03Stage 3 · Build

plan.md

Says what will change, in what order, and how anyone will know it worked — before a file is touched.

Reads: spec.md
Gate: Engineer, before any file is edited

Written in plan mode, where the agent can read the codebase but cannot change it. The test is whether someone who never saw the conversation could do the work from the plan alone.

intent/work-story-template/plan.md

## Files that change

The 49 content files — two frontmatter keys removed from each.
The page template — two gated blocks deleted, one fallback added.
The collection schema — one field removed, one made optional.
Generated metadata — regenerated by the publish command.

## Order of work

01Check whether the parent lists its children by hand or pulls them from the collection. Decides whether a further file is touched.
02Delete the gated blocks, then strip the frontmatter keys.
03npm run check-copy — expected clean, since the copy is written to the standard rather than fixed afterwards.
04npm run build, then npm run audit.
05Read the rendered page, because the band and the sibling row are driven by frontmatter being used for the first time.

## Risks

The capabilities marker is load-bearing in the body. Omitting it moves the band somewhere the argument does not want it. Mitigated by step 5 reading the output rather than trusting the source.
order collides with an existing sibling and silently reorders the hub. Checked in step 1.

## Proof

Both checks clean, the page rendering at its route with the band and sibling row present, and the index listing it.

What the chain caught

Four things that would otherwise have been decided silently.

It stopped the build it was written for

Two of the six items turned out to be copy decisions that needed a person, not a refactor. The spec records them as open and the work has not started. Without the chain they would have been decided silently by whoever got there first, inside a change that looked purely technical.

It wrote down a consequence nobody would have noticed

Removing the practice band also removes the only in-page link from each story to the service it belongs to. That is in the spec as an area of concern, attached to the requirement that causes it, before the work is done — not discovered a year later when the internal linking is audited.

It made the duplication visible as duplication

Four switches set identically on 49 pages read as normal frontmatter in any one file. Stated once in an intent, they read as what they are: the template, copied out.

It survived the session that produced it

The reasoning is in version control with an author and a date, not in a conversation that has since been closed. The next person to touch the template reads why, not just what.

What this is not

One repository, and not a long one.

This is a marketing website, not a regulated platform or a system with customers depending on its uptime. The stages that matter most in a bank are the ones this chain exercises least. We have been working this way for weeks rather than years, and the chain above is one of a handful.

Four of the items in that intent are still open, which is the honest state of the work and not an oversight. The artifacts hold what is undecided instead of losing it between sessions. A chain with nothing open in it has usually had the hard questions quietly answered by whoever was closest to the keyboard.

What it does show is the shape. If your engineers are producing code faster than your organization can decide what to build, review what came back and approve its release, this is what the written stages look like when they are doing their job. What we would examine with you is the practice page.

Bring us the part of delivery that has not got faster.

We will help you work out where the time is actually going and which stage is worth changing first.

Book a briefing ↗