Skip to Content
Why PDS Stack

Why PDS Stack

A dev has package.json, a lockfile, a linter, CI. A designer has a design file — Figma, Penpot, Framer — and their memory.

PDS Stack versions that memory. A design system extracted from Figma, references annotated with why they work, and every direction the designer has already validated or refused — read by every agent, on every feature, before anything is produced.

The memory is the product. The workflow is thin. The conversation is disposable.

The inversion

Conventional AI devPDS Stack
1. Prompt1. Read the memory
2. Generate2. Approve the direction
3. Ship3. Frame the scope around it
4. Design review (if there’s time)4. Two verdicts — one of them yours
Taste arrives last. Rework is the norm.Taste leads, and it accumulates.

Four constraints

Direction before scope — not after

The direction brief is approved before the scope is frozen. In V3 it was the other way round, and the two gates could contradict each other while both passed. The scope is now framed by the direction, so they cannot disagree.

Taste compounds, not trivia

memory/directions/ records every direction submitted to judgment — retained and refused, with the reason. A refused direction is worth more than a retained one: it stops the next brief reproposing what was already judged wrong on this product. Nothing is ever deleted from it.

Two verdicts, never averaged

Conformance is a /20 the system computes against what was written. Direction is binary and the designer alone renders it. A delivery can be 20/20 and refused — and the system says exactly that.

This is not theoretical. P-001 cycle 1 scored 18/20 = SHIPPED and was rejected outright by the designer. With four conformance dimensions and no aesthetic one, that was the only possible outcome. It is now a regression test for the gate itself.

Ceremony matches stakes

Three lanes, default Sketch: direction plus production, one gate, no spec file, no score. Hard budget: three human gates, about twelve steps. Any rule that does not fit is cut, not documented.

Time and cost are the same problem

In a prompt-and-pray flow, time and token spend go to the same place: the loop. Generate, look at it, realize it’s not the right direction, regenerate. That loop — not the generation itself — is where processing time and token cost actually accumulate. A wrong direction caught after a build is expensive twice: once in tokens spent producing it, once in tokens spent redoing it.

Every gate in PDS Stack exists to cut that loop short. The direction brief is approved as text, before BOB writes a line of code — correcting direction in prose is cheap; correcting it in a shipped build is not. The frozen scope means BOB never regenerates a feature from a moving target. Both ANALYZER verdicts gate the commit, so rework happens once, against a spec and a judgment, instead of in open-ended back-and-forth.

That was the bet. Then we measured it — and the gates were not where the tokens went.

The conversation is disposable

Everything that enters a conversation is paid again on every turn after it. What costs is not the prompt, it is how long the context lives. So V5 applies the founding rule one step further — the memory carries the state too: one phase, one conversation, and a fresh session picks up from the file.

On a real project, the same work went from $17.05 in one long chat to $7.26 with the stack. What a cycle costs, where the tokens go and which rules move the bill: Cost. (ADR-014 · ADR-015)

The cycle

session 0 · /pds cadrer ──▶ project_<name>.md + dispatch plan ──▶ one session per agent ↓ (recherche) DIRECTION CADRE PRODUIRE (handoff) JUGER + MÉMORISER ─────────── ───────────────── ──────────────── ───────────────── ───────── ────────────────── EVE, optional brief, 5 dimensions scope, framed HTML prototype Figma → ① conformance /20 read from memory/ BY the direction then Figma, code dev spec ② direction — binary lots of ~50 turns fresh bob-build/lot ⏸ gate ① ⏸ gate ② ⏸ gate ③ session 1 ──state──▶ session 2 ──/pds reprendre──▶ session 3 ──/pds reprendre──▶ session 4

Research and handoff never gate anything — they feed the phases that do. EVE preps interviews, synthesizes research and restitutes findings before DIRECTION exists to read them. After PRODUIRE, a handoff skill turns an approved Figma frame into a dev-ready spec when the implementation leaves this cycle for someone who wasn’t in the room.

LaneWhenPhasesHuman gates
Sketch (default)explore, iterate — the 80 %DIRECTION → PRODUIRE1
Standarda screen or component going to review or devall four2
Systemit touches the design systemall four + written decision3

A refused direction goes back to DIRECTION, never to the builder. It is not a list of bugs to fix; it is a direction to retake.

Ready? Head to Get Started.

Last updated on