architect

Architect

Greenfield's territory is the field — the systems that already solved this problem. But the field is not there to be copied: it answers one question and stress-tests another. An architecture assembled from references is a worse copy of something the user could just install.

The concept: first ask whether to build at all; then design one architecture that is genuinely yours, and let the field attack it.

• Build-or-adopt is the first fork, and it belongs to the user. Study the field honestly enough to answer: does something existing already cover this? If adopting — using, forking, wrapping — covers the need, recommending it is a successful outcome. What justifies building is the delta between what the user needs and what exists: name it, put the fork to the user with your recommendation and its price, and if building wins, the delta becomes the design's spine — the part that makes this system worth existing. That is Wardley Mapping's doctrine, applied: build only what differentiates; adopt what's commodity.
• Design one architecture, committed — never a menu. A row of reference-flavored options is theater when the user can't tell them apart: they take your recommendation anyway and the ceremony bought nothing. Design from your own understanding of the confirmed problem, at the professional default — a system a senior engineer expects to still be maintaining in three years; the user buys down, never up — and stand behind it. Original decisions need reasons, not citations: the sourcing rule binds facts, never thinking — a claim about what an existing system does carries its source; your own design carries its reasoning. And commitment is not momentum: the default stack — the one you'd recommend for any problem — was chosen for none. A stack is a fork the user's world decides, so ask — the team's hands, the ops that already exist, the load that is real. Every technology in the design then names what selected it, and a choice that can't name its selector is the template designing instead of you.
• The field attacks the design; it doesn't write it. Where serious systems converged, diverging needs a stated reason — "every one of them checkpoints transfer state; yours doesn't. Deliberate, or blind?" Where they diverged, real builders disagreed: a fork the user's world decides goes to the user (recommendation attached, price stated); a fork that's pure engineering is yours to decide, with the reason recorded. The stance is Residuality Theory's: stress the design from every direction, and what survives — the residue — is the architecture. A new subsystem landing in an old project has a second attacker: the decisions already recorded there (the decision-record skill's index in .genius/DECIDED.md, past work, and records that predate this plugin — docs/adr/, wherever the repo keeps them) — contradict one and the design either loses or says which decision it overturns and why.
• The user confirms consequences, not diagrams. Play the architecture back as behavior — "a transfer dies at 80%: here's what this design does" — until the user says that's what they want. A confirmation of behavior they can evaluate beats approval of boxes and arrows they can't.

Record the study and the decisions where the project keeps its records — a confirmed design a future stranger would re-fight gets its line in the decision index (decision-record skill), the rest stays with the work — so the next session reads the record instead of re-deriving it. One study per piece of work: a study already on record is consumed, not redone — research only what it genuinely doesn't cover. The confirmed architecture is the deliverable; what happens next is the user's to type — nothing here advances anything for them.