Design

This page designs florete-design-change, the skill that runs design work in Florete. It moves a design forward through decisions rather than through drafts of prose, and records what was decided in a form that survives the session.

Invoking it → Using the skill. Building it → How it works, which opens with a map of the whole. Changing this design, or finding out why it is shaped as it is → the Decision Log at the foot; an implementer should read its rejected clauses before concluding a rule is arbitrary, since they record what was already tried.

Using the skill

Invoke it on a scoped ask — a ticket, or a plain instruction naming what is being designed. If the scope is unsettled the skill stops and asks rather than inferring one.

What it produces is a design page in two halves. Prose is for whoever uses or implements the thing. The skeleton is for whoever will change it later, and is itself two artifacts: the shape, a compact map of the design's structure and how it runs, and the decision log, one entry per decision carrying the reasoning and the alternatives it rejected.

Every pass starts from a shape, and the mode decides where that shape comes from:

That matters because the axes — the first thing you are asked for — are what that shape leaves unsettled. They are never gathered in a vacuum. Curation is also a precondition of revision on a page with no skeleton yet, and whether it covers the whole page or only what your change touches is your call.

What follows is a pass with five sign-offs. At each, work stops until you agree:

1. Axes — what the design leaves unsettled. Write your own list first; the skill then merges its own into yours, marking anything it transformed or dropped. Yours may be as rough or as detailed as you like.
2. Options — the candidates for each axis, the criterion separating them, and any dependency between them.
3. Verdicts — one pick per axis with its reasoning, added to the same file the axes and options grew in, which you comment on or amend in place.
4. Record — the skeleton written into the page. You check the render, and prose follows.
5. Prose — the page written around the skeleton. It is iterative, and each iteration re-enters through the decisions: a question raised while reading prose is answered as an axis, not in the prose itself. You sign it off by asking for the implementation handoff.

That last sign-off is a completion signal rather than a review — judging prose is review's job, in fresh context — and it is a signal rather than a lock. Notice something afterwards and the pass carries on; the note is re-issued.

Two things about how you engage. The stance shifts: early on you are hunting for what is missing, late on you are judging picks — and the decision work has converged when there is nothing left to challenge. And the sequence is a default, not a rule: arriving with your own axes and options already written is a normal entry point, and the skill picks up wherever you are.

Working files land in design-wip/<ticket>-<topic>/ in the florete repository, which git ignores — design-wip/123-installer/ for a design tracked by issue 123. The skill reports them at the end and never deletes them unasked.

How it works

Shape

STRUCTURE

  what        a design skill, invoked on a scoped ask
              its own audience is one: whoever designs or evolves a design

  modes       greenfield   nothing exists yet
              revision     a skeleton exists; amend it
              curation     prose exists, a skeleton does not; build one

  produces    one design page, in two halves, plus one handoff note

  artifacts   skeleton  ├─ shape           structure and flow, amended as decisions land
                        └─ decision log    one entry per decision, keeping its rejections
              prose     ├─ orient          what the page is, and where each reader goes
                        ├─ surface         rendered under a domain name
                        └─ internals       one section or several

  audiences   who each half is written for; readers may overlap
              consumers     surface     varies by domain: product users, another
                                        component's developers, or architects
              implementers  internals   and the skeleton, to see what is load-bearing
              architects    skeleton    the half written for them

FLOW

  invoked on a scoped ask
      └─ scope unsettled  → stop and ask; never infer it

  read   the target page, its cross-refs, related ADRs, the ticket   silent
      ├─ greenfield  → sketch a shape, to be contested
      ├─ revision    → read the skeleton, amend it, collect findings
      └─ curation    → extract a shape, harvest decisions already made

  AXES      what the shape leaves unsettled, one line each;
            the human's list first, then the agent's merged into it
       → GATE 1  clears when the merged list is agreed
  OPTIONS   candidates, the criterion between them, dependency, per axis
       → GATE 2  clears when the candidates are agreed
  VERDICTS  pick · because · accepting · rejected, per axis
       → GATE 3  clears when every axis is ratified
  RECORD    the workspace compacted into the page's skeleton
       → GATE 4  clears when it renders and the human accepts it
  PROSE     orient · surface · internals
            each iteration re-enters through the decisions
       → GATE 5  clears when the human asks for the implementation handoff
                 a completion signal, not a review; the pass may reopen after it

RULES

  gates       a gate is a state, not a message — questions and redraws happen inside it
              a stage gates what may be started, never what may still be changed

  stance      shared by both parties, and it shifts across the pass:
              Challenger early, Decider late; the decision work has
              converged when there is nothing left to challenge

  media       form       the human writes, a file
              report     the agent writes, read once — chat, or a file when it
                         must cross a session
              workspace  the agent writes and keeps amending; a file the
                         human comments on

  invariants  no prose before RECORD clears
              prose may not contradict the decision log
              nothing renders except at RECORD, or on an explicit throwaway request

Modes

Three, differing in where the shape comes from and in what else the pass must handle.

Greenfield sketches a shape whose job is to be contested — it asserts things it has not earned, so their silences become visible. Revision reads the existing skeleton and amends it; there is no sketch, because the shape already exists and has a stricter quality bar. Curation builds a skeleton where prose exists but none does, harvesting decisions the prose already made implicitly rather than making new ones — as axes, which close immediately where a reason can be recovered and wait for review before they do.

Findings — contradictions and gaps in existing prose — therefore arise in revision and curation only: a greenfield shape can be silent but cannot contradict itself. They are reported when found, held across the whole pass, and acted on at the prose stage with a suggested action each: fix inline, file a ticket, or ignore.

Stages and gates

A gate is a state, not a message. It clears on a condition, and questions, redraws and amendments happen inside it — a gate is not one exchange. The conditions are: the merged axis list is agreed; the candidates are agreed; every axis is ratified; the page renders and the human accepts it; the human asks for the implementation handoff.

A stage gates what may be started, never what may still be changed. Entering verdicts adds the verdict artifact without freezing axes or options; both stay editable to the end. There are no re-entry paths, because nothing was ever closed.

With no human present no condition can clear, so a non-interactive run emits the shape and halts at the first gate.

Axes

An axis is one thing the design leaves unsettled: a label, and a clause saying what must be settled. In revision it may also carry a defect clause naming a contradiction in the existing prose; greenfield has silences rather than contradictions, so a tension phrasing there is manufactured weight.

B6. Decision ID scheme. The ID's shape, and whether it is scoped to a page
    or to a topic spanning milestones.

Axes are grouped into lettered topics with a sequence inside each — A1, A2, B1 — so an item can be inserted, split or closed without renumbering the rest. The human's own list needs no such scheme: plain numbering is the suggested form, since nobody can categorise upfront, but any is accepted. The one requirement is that its items be referenceable, because the merge points back at them — (yours 2) means the second item of that list.

Three rules govern the list:

• Derivation — an axis exists where the shape asserts something without warrant, or is silent where something must be settled.
• Admission — it survives if a competent person could reasonably choose otherwise and the choice changes the artifact.
• Widening — a human item the rule would have rejected means the rule is too narrow. The rule widens; the item is not argued down.

The human's list comes first, unread by the agent's. The agent then returns one merged canonical list — not a diff — with provenance where it transformed something: (yours 2) for an item taken as it stood, (from your 2, split) where it was reshaped, plus an explicit line naming anything dropped and why. Marking every item would be noise; what needs verifying is distortion, and distortion only happens at a transform.

Options

Every axis gets candidates, a criterion separating them, and any dependency on another axis.

Options:
- (i)   CTRL-07      topic mnemonic, one sequence across all milestones
- (ii)  CTRL-C0-01   topic mnemonic, milestone segment, sequence per milestone
- (iii) C0CTRL-01    page-scoped mnemonic, no cross-page identity

Criterion: an ID cited from another page or a ticket must not rot, and the
scheme must need no register anyone maintains.
Depends on B20, where the mnemonic is declared — which only bites under (i).

The criterion is the test that separates the candidates, and it is usually the expensive part: once it is right the pick is often obvious. Dependency names an axis that must be settled first, because its verdict changes what candidates the others even have.

Every axis is covered, including trivial and single-option ones, which get a line each. Skipping is how an invisible omission enters, and "only one candidate, and here is why" is exactly what a later reader would otherwise wonder about. Dependency is stated in prose where it exists, which is rarely.

Verdicts

A verdict is a judgement workspace, not a draft of a log entry. It carries the axis, its question, the options weighed, the pick and its reasoning — everything needed to weigh it. A log entry carries only what a reader needs to accept it.

→ (ii).
Because the maintenance burden exists only under (i): with a milestone segment
the sequence restarts, so nothing must be kept unique across milestones, and a
late addition is CTRL-C0-08 rather than CTRL-13 sitting oddly among 01–07.
Accepting eleven characters instead of six.
Rejected (i), which needs a cross-milestone register; (iii), which loses the
topic identity that makes CTRL mean something.

Amending a verdict has two forms: change the pick, or send the axis back for different options.

Recording

At record, both halves of the skeleton are compacted from what the pass grew — the shape from its workspace, the decision log from the verdicts:

• Compaction — drop, merge, absorb. Two decisions belong in one entry when they would be revisited together, which is looser than requiring that reversing one forces reversing the other.
• Compression — down to pick, because, accepting, rejected.

Rejections survive compression, each with its reason. The option space is regenerable — reconstructing options around a local change is exactly what the options stage does — but a rejection reason is not: lose it and the option is proposed again. Admission test: would anyone propose this again?

The skeleton records what the design is — never how it is currently built, nor the plan for getting there. Those are real decisions of the pass, so they are not discarded: they go to the implementation handoff below.

An entry's ID is a topic mnemonic, a milestone segment, and a sequence restarting per milestone — CTRL-C0-01. Pages outside the milestone structure omit the segment. Nothing declares the mnemonic; each entry states its full ID. Entries are amended in place when refined. When a pick flips, the entry's body is removed and its ID stays behind as a pointer — **DESIGN-08.** *Superseded by DESIGN-19.* — so a citation lands and is redirected while git keeps what it said; the superseding entry carries the dead pick as a rejection and absorbs whatever clauses did not flip. IDs freeze at first commit; before that the log is still a draft and may be renumbered.

A *Revisit* field marks a decision as provisional and names the condition or occasion that would settle it. Its presence is the marker, so the set of provisional decisions is a view over the log rather than a register.

Decisions whose reach extends past the page are flagged as ADR candidates at the verdict stage — the reach is known when the verdict is written and not before. The human decides; the ADR is written elsewhere.

Handoffs

One note leaves a pass. The implementation handoff always ends it, carrying the plan-shaped material the skeleton refuses: migration steps, current-state facts, ordering, anything answering how do we get from here to there.

Nothing else is filed on a schedule. A note of where the pass currently stands can be asked for at any point, to continue in a fresh session — a way of managing context rather than a stage artifact.

Review consumes neither. It takes the finished page — skeleton and prose together — in fresh context, which is the whole reason prose has no gate inside the pass.

Working files

Each artifact is classified by who writes it and how long it lives:

The distinction is load-bearing, and the two file media are files for different reasons. A form is a file because the human writes at length into it, and a long reply typed into a chat box is at risk in a way the same text in a file is not — chat history is durable, but an unsent message is not. A workspace is a file because it evolves: a posted message cannot be amended, and this one is rewritten at every turn.

The agent creates a form — its heading, its structure, and one worked example of the shape being asked for — and then never touches what the human writes into it. A workspace the human amends in place is the agent's still, with one obligation: it is edited, never rewritten wholesale, since a wholesale rewrite drops a human edit without leaving a diff.

Five files, in design-wip/<ticket>-<topic>/ in the repository holding the target page, which git ignores. The directory carries the pass's identity, so the files need no prefix. A ticket number is written bare when it belongs to that repository and prefixed with the repository name when it does not — flor-81-design-change — the form topic branches already use.

The decision artifacts are one file, not three. An axis is a block that grows — question, then candidates, then verdict — and a closed one keeps its full option list with the pick marked. A rejection reason read apart from the option it rejects cannot be reviewed, and reviewing is the file's entire purpose, so nothing is compacted before record. decisions.md shows a counter and three groups: open, inferred and closed. Inferred holds what curation harvested and nobody has reviewed yet, and it empties as the pass proceeds — anything left in it at record is an unratified axis.

Live files stay current for the whole pass, prose included: a decision that changes while prose is being written changes there and then. Sealed files are left where their stage ended, and the agent suggests deleting them at record, where nothing reads them any more.

The shape file emerges when the target is read and is amended as decisions land; it is never regenerated from the verdicts. Alone among the artifacts it carries no identifier scheme — a finding or an axis is cited for days, while a pointer into the shape lives for one exchange, so a block is addressed by its caption and label instead.

Handoffs are reports, but filed rather than posted, since they exist to cross a session boundary.

Where the skill lives

The skill is tool-agnostic guidance in the flor repository, at .agents/florete/skills/florete-design-change/, with discovery shims under .codex/skills/ and .claude/skills/. This page, being documentation, lives in florete — the same split the code-review workflow already uses.

Two references carry the depth, since SKILL.md stays thin: process/decision-log.md for entry format, the admission filters and ID rules, and process/design-sketch.md for shape form, its size bound and worked examples.

The skill does not read this page to run. It defines its own vocabulary and states its own rules, so a pass never depends on the design being at hand; this page is cited once, and for the opposite purpose — to argue with a rule rather than to apply one. The two are kept in step by amending the log whenever the skill outgrows it, which is how this section's own rules arrived.

Decision Log

DESIGN-01. The review surface is decisions, not prose. A human reviews a decision log; prose never enters the review loop. Everything else here follows from that. Because prose is cheap to generate and expensive to read, so review attention — the scarce resource — belongs on the decisions, which are the part that cannot be regenerated.

DESIGN-02. Three modes, differing in source and in artifact. Greenfield sketches a shape to be contested. Revision reads the existing skeleton and amends it. Curation builds a skeleton where prose exists but none does. Curation is a precondition of revision on an un-curated page and is independently invocable; whether it covers the whole page or only what changed is the human's call. Findings arise in revision and curation only, are held across the pass, and are acted on at prose with a suggested action each: fix inline, file a ticket, ignore. Because a greenfield shape can be silent but cannot contradict itself, so findings do not arise there; and a skeleton that does not exist cannot be amended. Accepting revision on an un-curated page is two passes. Revisit whether curation-then-revision ever runs as a single pass, making the split ceremony.

DESIGN-03. A design page serves three audiences at three altitudes. Consumers want the surface; implementers want the internals; architects want the structure, because they are the ones who will change it. Who counts as a consumer is domain-specific — product users for a product, other components' developers for a component, architects for a skill — so the skill fixes the audience map and never the placement. The map names who an artifact is written for, not who may read it: implementers gain from the skeleton's rejections, which is where a rule that looks arbitrary turns out to have been paid for already. Because an artifact that names no audience ends up serving none, which is exactly what happened to the summary this design first proposed. Rejected one audience per page — the assumption that produced that summary; a separate document for architects — a second thing to keep in step, when co-location is the skeleton's whole value.

DESIGN-04. The decision log sits at the foot; the shape opens the internals. Where a page has no surface, the head of the internals is the top of the page. Both sections carry fixed names — Shape and Decision Log — since neither is domain-specific and a citation has to land; the shape's level follows the internals, while the log is always top-level and always last. The skeleton is the two together, but they are placed where each does the most work. The log ends the page: it is dense, addressed to architects, and close to unreadable cold — a property, not a defect. The shape leads the internals, because it is the compact map of the whole and the sections that follow hang in the air without it. Both stay visible rather than collapsed, with orient routing whoever needs them. Because what mattered was that the skeleton must not compete for attention at the top of the page, where consumers land — and the head of the internals is not the top of the page. Anyone who reaches it is already an implementer. Accepting the skeleton is split across the page, so "skeleton" is a concept rather than a section. Rejected per-page names for the skeleton's sections, which trade a citation that lands for a freedom nobody has asked for; top-of-page placement, premised on "read this first", false once the audience is named; a collapsed block, since a designer would rather jump to a section than uncover one, and a cut can break in-page search; duplicating the shape in both places, which is a sync burden for a formatting gain.

DESIGN-05. The shape is a workspace artifact that evolves, then compacts. It asserts a structure and shows how it runs; its form is chosen per topic, and it must cover dynamic behaviour rather than static structure alone. It emerges when the target is read and evolves in its own workspace file as decisions land — never regenerated from the verdicts. Record then compacts it for the page, exactly as the verdicts compact into the decision log: both halves of the skeleton are compactions of something the pass grew. Because a shape is complete when its silences are visible: a dimension absent from it cannot be challenged, and nobody notices what was never shown. And regeneration loses what incremental amendment keeps — rebuilding the shape wholesale was tried twice and produced something thinner than the sketch it replaced, because a one-shot rewrite has no memory of what each decision was reacting to. Rejected regenerating at record; copying the working shape verbatim, which carries working detail into a compact artifact; keeping it in chat, which worked here only because the shape was small and the session unbroken, and fails across a handoff; one mandated form for every topic; a dated snapshot allowed to lag, since a stale shape misleads worse than none.

DESIGN-06. Prose has three roles, named internally and rendered by domain. Orient states what the page is about and then routes each reader to the part addressed to them; surface and internals carry the two prose altitudes. These are the skill's vocabulary, not headings: surface renders as ## Component API or ## Using the skill, internals as ## How it works or several sections, and either may be absent where its domain has no such audience. Orient is mandatory and headless by default — naming it is a per-page call. Because "users" is domain-specific, so a fixed heading would be wrong on most pages; and a literal ## Orient would head every page's table of contents with jargon, where a lead paragraph read first anyway needs no entry. Routing alone is not enough — a reader who does not yet know the subject cannot use a map of it. Accepting orient can drift from the sections it points at; being short and written last is the only mitigation. Rejected literal headings; a pure router with no subject statement; unstructured prose, which loses the audience distinction entirely; an invariant policing orient's routing, which needed context no reviewer reliably has and guarded a pain nobody had felt.

DESIGN-07. Prose elaborates the record and may not contradict it; review is always separate. Prose follows record, in the context that made the decisions, and is not derivable from the log — the log is the compressed subset by construction. Its own gate is a completion signal, never a judgement of the writing. Review is a third thing, never inside the pass: it runs in fresh context and takes the finished page, skeleton and prose together, plus whatever the review skill supplies. It consumes no handoff. Because a reviewer at the tail of a design pass is saturated, and prose review is the one activity needing clean context. And a design is reviewed whole: a skeleton without its prose is not the artifact anyone will read. Accepting the workflow names that debt but cannot collect it. Rejected gating prose on its quality, which puts the writing in front of the one reviewer least able to judge it; feeding the handoff to review, which confused a writing aid for a reviewing input.

DESIGN-08. Superseded by DESIGN-19.

DESIGN-09. Five sign-offs, and stages add capability without removing it. Gates sit after axes, options, verdicts, record and prose. A gate is a state rather than a message: it clears on a condition, and questions, redraws and amendments happen inside it. A stage gates what may be started, never what may still be changed. The prose gate clears when the human asks for the implementation handoff — a completion signal, not a review, and one that does not lock the pass: work continues if something is noticed afterwards. Stance is a gradient shared by both parties — Challenger early, Decider late — which gives convergence a definition: the decision work is converged when there is nothing left to challenge. What ends the pass is that last ask. Because a gate belongs where the agent's output could be silently incomplete and the gap undetectable downstream, or where the human must choose what happens next. With nobody present no condition can clear, so a non-interactive run halts at the first gate. Rejected splitting the axis gate in two, since human-list-then-merge is a protocol inside one state; leaving prose ungated, which was tenable only while a prose handoff could carry an unwritten page to another session — without one, stopping at record leaves a skeleton its prose contradicts and nothing recording that; gating prose on its quality, which is review's job and belongs in fresh context; assigning a stance per party, since both challenge and both decide; naming no stance at all, which was what let a reader auto-answer a list they were asked to review.

DESIGN-10. At axes, the human's list comes first and the agent merges into it. The human writes their axes before seeing the agent's. The agent returns one merged canonical list, marking provenance where it transformed an item — (yours 2), (from your 2, split) — and naming anything it dropped, with why. Axes carry lettered topics with a sequence inside each — A1, B2 — so items may be inserted, split or closed without renumbering; the human's own list uses any scheme, plain numbering suggested, provided its items are referenceable, since provenance points back at them. An axis is admitted when a competent person could reasonably choose otherwise and the choice changes the artifact; a human item the rule would have rejected widens the rule rather than being argued down. Because an agent's list anchors a human's, and independent generation covers more. Human items may be fat and agent items lean — generating is cheap for one, reading expensive for the other — but both are written from the Challenger stance. Rejected returning new items alone, which hides the merge that is the actual deliverable; a mapping table, which is bad reading for the thing read most.

DESIGN-11. At options, every axis gets candidates before any verdict. Each axis gets candidates, a criterion separating them, and any dependency on an axis that must be settled first. Trivial and single-option axes get one-liners rather than being skipped. Because a wrong option set produces a right-looking verdict whose reasoning hides the omission — the failure a verdict review almost never catches. "Only one candidate, and here is why" is exactly what a reader would otherwise wonder about. Rejected covering only non-obvious axes, since skipping is how an invisible omission enters; formal dependency notation, which costs more than it carries — prose states it where it exists, which is rarely; the name "rank", which reads as priority when it means precedence.

DESIGN-12. Verdicts are a judgement workspace; the decision log is their compaction. A verdict carries what a human needs to weigh it. A log entry carries what a reader needs to accept it. Record compacts — drop, merge, absorb, where the test is whether two decisions would be revisited together — and compresses to pick, because, accepting, rejected. Rejections survive compression, each with its reason: the options are regenerable, since reconstructing them around a local change is exactly what the options stage does, but a rejection reason is not — lose it and the option gets re-proposed. Admission test for a rejection: would anyone propose this again? The skeleton records what the design is — never how it is currently built, nor the plan for getting there; both go to the implementation handoff. Because the axis filter is a fact about the process and the entry filter a fact about the design, so the second is strictly narrower. Accepting the fine-grained trace dies with the working files. Rejected one-to-one entries, which flood the log and force judgement material to be pre-compressed; keeping full verdicts, since 40-odd axes are harder to reason over than 17; keeping both forms, which drift.

DESIGN-13. Three working media, by who writes them and how long they live. These are the pass's own artifacts, not the page's. A form is created and structured by the agent, then filled by the human, who is the only one to write content into it. A report is written by the agent and read once — in chat, or in a file when it must cross a session, which is what a handoff is. A workspace is written and continually amended by the agent, lives in a file, and is discussed in chat; the human may also amend one in place, and a shared file is edited rather than rewritten. Working files live beside the design they serve, in a per-pass directory the repository ignores. Five of them: the two starting axis lists, sealed where the merge consumes them, and decisions.md, shape.md and findings.md, live until the pass ends — prose included, since a decision that changes during prose changes there. Because direction alone cannot express an agent-owned artifact that persists and evolves. The two file media are files for different reasons: a form, because the human writes at length into it and an unsent message is at risk where a file is not; a workspace, because it evolves, and a posted message cannot be amended. They sit in the docs repository because the designs do — one predictable location per pass. Accepting ignored files are exactly what git clean -xdf removes, and a worktree does not carry them. Rejected one file per stage, which left the agent's own axis list, the merged list and the findings with no home at all and split every axis across three files, so a rejection could not be read beside the option it rejected; chat throughout, which loses long-lived artifacts; files throughout, which makes ownership of a line ambiguous; a fourth medium for filed reports, when the existing one only needed its lifetime clause widened; forbidding the agent to write a form at all, which would leave the human transcribing structure the agent already knows; a location outside every repository, which made a pass's home depend on how the machine happened to be laid out.

DESIGN-14. Decisions carry stable IDs and their own lifecycle. An ID is a topic mnemonic, a milestone segment, and a sequence restarting per milestone — CTRL-C0-01. Pages outside the milestone structure omit the segment. Nothing declares the mnemonic; each entry states its full ID. Entries are amended in place when refined. When a pick flips, the entry is removed and replaced by a pointer — **DESIGN-08.** *Superseded by DESIGN-19.* — so a citation still lands somewhere and is redirected, while git holds what it said. The superseding entry owes two things: the dead pick recorded as a rejection, and any clause of the old entry that did not flip carried forward. IDs freeze at first commit; before that the log is a draft and may be renumbered. A cluster spanning pages is several logs joined by IDs, never a shared holder. ADR candidates are flagged at the verdict stage for the human to decide; the ADR is written outside this workflow. Because an ID cited from another page or an issue must not rot — which is what the pointer preserves, and why the log records what the design is rather than what it once was — and a milestone records when a decision was made, which never changes — unlike a path. The per-milestone restart removes cross-milestone uniqueness maintenance entirely. Accepting no enforcement of mnemonic uniqueness, and an approved ADR candidate can be forgotten if nothing tracks it. Revisit whether flagged ADR candidates actually get written. Rejected keeping a superseded entry in full behind a marker, whose cost is permanent and paid by every later reader, when a supersession written properly puts the dead pick's rejection in the live entry where it will actually be met; removing the entry with its ID and all, which breaks citations from issues and other pages; a single cross-milestone sequence, which needs a register; path-derived or page-scoped IDs, which break on a move or lose topic identity; a dot separator, which breaks the ADR-0011 house convention for a marginal gain; freezing IDs from the first draft, which would strand a late entry away from its topic for the life of the page.

DESIGN-15. A provisional decision names what would settle it. *Revisit* carries a condition or an occasion, and its presence is the marker. The set of provisional decisions is a view over the log, not a register anyone maintains. Because a provisional decision is still a decision — what it carries that others do not is a known expiry condition, and naming it is what makes the decision findable later. Accepting nothing forces a revisit. Rejected a status badge, which drifts from the text explaining it; a separate revisit section, which puts one decision in two places; an issue per provisional decision, heavier than the decision itself.

DESIGN-16. Rendering is deliberate. Nothing reaches the page except at record, or on an explicit request — and an on-request render is provisional, expected to be re-rendered or discarded after a glance. Because the value of working in decision space is that a finding costs a workspace edit rather than a page rewrite plus a re-review. This design's first rendered page was thrown away by the next finding, which is how the rule was learned.

DESIGN-17. An invariant must be a scar, not a prediction. A constraint earns the name only after something has gone wrong without it. A predicted one is admissible only carrying a *Revisit* condition, and it is expected to die. Because the record is unambiguous: the two invariants invented ahead of evidence were both removed within a day of being written, while the three that survive were each extracted from a failure that had already happened. A rule set nobody trusts is a rule set nobody reads, and speculative entries are what erode the trust. Accepting a real constraint stays unwritten until it has been paid for once. Rejected admitting predicted invariants freely — tried twice, dead twice; forbidding them outright, since the provisional marker gives a cheap exit and a marked prediction costs one line.

DESIGN-18. The page carries the why; the implementation stands alone. (ADR candidate.) A skill implementing this design defines its own vocabulary and states its own rules, and never cites this page as an operating instruction. The page is cited once, for a purpose an agent can act on: read it to contest a rule, not to apply one. When the two disagree the log is amended, so the skill is never left contradicting it. This is a constraint on any implementation, not a fact about the current one, which is why the drop criterion does not reach it. Because a rule and the argument for it have different readers and different lifetimes. Loading this page to run a pass re-imports the rejected options and the reasoning — the review surface the design exists to shrink. And read the design when the skill is silent is worse than no rule at all: an absence is not detectable, so the trigger can never fire. Accepting the vocabulary exists in two places and can drift, with nothing but the amendment rule holding them together. Rejected a compact skill delegating its terms to this page, which makes the page a runtime dependency of every pass; the mixed form, whose border was never stated and whose trigger could not be evaluated — which is what shipped first, and what this entry replaces.

DESIGN-19. One note leaves a pass, at the end. (Supersedes DESIGN-08.) The implementation handoff always ends the pass, carrying the plan-shaped material the skeleton refuses. Its trigger is the human calling the prose done — a completion signal, not a review, since judging prose is review's job, in fresh context. Nothing else is filed on a schedule; a note of the pass's current state is written whenever the human asks for one, to continue in a fresh session. Because the material the prose handoff carried now lives in files that outlast the session — findings in findings.md, decisions in decisions.md, both live until the pass ends — so the note duplicated what a resuming session already reads. Accepting the framings that never became decisions are lost when a session stops at record, since nothing files them. Rejected keeping the chain for the deferred case, which is a second artifact maintained for a path that has not been taken; a note at every gate, the same duplication on a shorter cycle.

DESIGN-20. A decision taken during prose still enters through decisions. Prose is iterative, and each iteration re-enters through the decision artifacts: name the axis, give its candidates, propose a verdict, ratify, then write. At prose those arrive in one turn rather than three stages — what the rule requires is that the decision is recorded before the prose changes, not that it walks the gates again. Prose is edited directly only when the human asks for that. Because prose is where the pressure to skip is highest: the stage is active, the question looks small, and answering it in place costs the record — a decision made in prose leaves no entry, and the log silently stops describing the page. Accepting a fast path exists, and three artifacts in one turn is thinner review than three stages would give. Rejected full stage ceremony for a prose-stage question, which nobody would follow twice; answering in prose and back-filling the log afterwards, which is this rule with a promise attached, and the promise is what never gets kept.

DESIGN-21. Curation harvests into axes, and an inferred decision is reviewed before it closes. Everything the page has already settled becomes an axis. One closes at once, as closed by initial design, where the prose gives a reason; where none can be recovered it stays open and takes candidates like any other. A closed-by-initial-design axis waits in an inferred group in the working file until the human has reviewed it, and moves to closed once they have — a state rather than a category, so the group empties as the pass proceeds and anything left in it at record is an unratified axis. Curation also reads for the seams: section-by-section reading finds what a section gets wrong, while the axes that stay hidden are between sections. Because harvesting straight into log entries makes the log's coverage depend on the agent remembering an entry exists, and the entries arrive with no options and no rejections. Routing everything through axes makes the filter structural instead of remembered: a decision whose reason cannot be recovered simply cannot close, so it surfaces on its own. Accepting the axis count on a curated page roughly doubles, most of the additions being one-line closures. Rejected an inferred marker on the page, which is permanently ambiguous — the boundary between stated and reconstructed is blurred — where an inferred entry's own thin rejections already show what it is; a tag rather than a group, which leaves an unreviewed decision sitting among ratified ones; a provenance section that outlives the review, which would be a second ordering fighting the lettered topics.

DESIGN-22. The pass knows what is built, and a verdict names the claims it rests on. The read stage establishes what is implemented and what is only designed, and carries it into the implementation handoff. A verdict whose reasoning depends on a fact about the world — that a channel exists, that a release has shipped, that a file is written where it is assumed to be — states the claim and how it was checked. Because a design page states intent, so auditing its sentences mis-locates the error; what goes wrong is a pick resting on an assumed state of the world. Reasoning quality does not separate a sound argument from a sound argument built on a false premise, so nothing but checking distinguishes them, and naming the premise is what puts it in front of whoever knows better. Accepting current state goes stale, so what the pass records is dated by the pass rather than maintained; and naming a claim is not checking it. Rejected verifying the page's factual claims, which has the agent auditing the prose it is there to curate; checking every claim a pick rests on, which is unbounded, since most rest on some claim.

DESIGN-23. A flipped pick sweeps the closed group. Changing a pick after its axis has closed carries a duty: walk the closed decisions for those that rested on it, and reopen the ones that no longer hold. It is a judgement rather than a check, since nothing enumerates the dependants. Because DESIGN-09 lets a stage gate what may be started and never what may still be changed — which is what makes amendment cheap, and the price is that a closed decision can be invalidated later with nothing looking. A flip is the only event that can do that, so it is the cheapest available trigger, and it runs while the reasoning that caused it is still in hand. Accepting a sweep can miss a dependant, because nothing enumerates them. Rejected leaving it to whoever next reads the file, which is what allowed two closed decisions to contradict each other unnoticed; one sweep before record, which defers the work to the moment the file is largest and the context most spent; relying on the shape re-check, which is real but partial — a contradiction reaches the shape only if both decisions touched it, and one can sit in the decision file before it ever gets there.