ADR-0067 A failed upload ranks nothing, and section B's own example was wrong twice

#Context

ADR-0061 audited section B's five remaining rows and kept four, each on a different dimension. It also warned about the thing this record has to answer before anything else: *"a roster that only ever shrinks has stopped being an adversarial sample and become an argument the system is winning against itself."*

Two of those four have now been built. Both were kept on a dimension that distinguished them from tabs, and in both cases the layer question had not been asked. ADR-0066 found pagination was an Emitter rather than the Arbiter the table said, and built it. This record asks the same question of file-uploader and gets no answer at all.

That the same audit produced one component and one removal is the test working rather than momentum. The dimension ADR-0061 kept this row on — *per-member state with no exclusivity* — is a true statement about how it differs from tabs, and it is not a statement that anything is being arbitrated.

#The layer question has no answer

§3's Arbiter *"resolves competing requests among its children."*

Three files uploading and one fails. Nothing resolves anything. The failed one reports its own failure, on its own account, at whatever rung its own adverse variant carries — and the other two go on reporting theirs. Several may fail at once; there is no member raised above its siblings, because there is no competition and nothing to win.

That is an Emitter's behaviour per row, and the container above them is a place for rows to be.

#Every part of it is built

Carbon's anatomy has five entries. Each maps to a component this system ships:

inline-loading is the one worth dwelling on. Its subject, in its own description, is *"the compact form, sitting beside the control whose work it reports"* — and a file being uploaded is precisely a piece of work reported beside the control that started it. Its three variants are the three states a file row has, its label role is a filename, and it is already vouching, which a file transfer needs and a container could not supply.

#And Carbon states button-group's problem in prose

The page's placement guidance:

When including a button as the action to upload a file, use either a primary or tertiary button depending on your use case. If there is already a primary button present on the page, use a tertiary button for the file uploader so it does not conflict with the primary action.

That is exactly the problem ADR-0054 built an Arbiter to solve — a set of controls of which exactly one may be the local focus — and Carbon solves it by asking the designer to remember what else is on the page. button-group grants the rung instead. Nothing in Carbon's file uploader needs building here; the part that looks like it does is a problem this system already answered in a different place.

#Section B's own example sentence was wrong twice

The sentence that justifies the whole section:

Each ranks one member of a set above its siblings — a selected tab, an expanded panel, a current page, a current step, a failed upload.

A failed upload is not ranked by anything. It is the one example on that list where the distinguished member is distinguished by having gone wrong rather than by being chosen, and ADR-0061 noticed that and read it as a *difference* rather than as a *disqualification*. Being distinguished by your own state is what an Emitter does. Being distinguished by your container's choice is what an Arbiter's child does. The sentence names four of the second kind and one of the first.

It is the second of that sentence's examples to fall. ADR-0058 removed the row the section's *second* sentence was written for — tile, admitted because §3's example list names a card, on a page where Carbon says it has no card pattern. Two of section B's five examples were not Arbiter cases, which is a better account of why the section's argument kept needing patches than "the sentence did not stretch."

#Decision

**file-uploader is removed from the roster and enters *Not carried, with the reason*. Roster 52 → 51; the Carbon term 38 → 37; dropped 7 → 8; the identity holds at 8 + 35 = 43**.

Section B has one row left: tree-view, which carries ADR-0061's open conflict with §5 and is the last decision the section needs.

#Rejected options

Build it as a Scope holding the rows. The strongest option, and it nearly works: a bounded area with a heading, a count and a stack of reports is a real thing. It is region, built in ADR-0058, and a second Scope whose only difference is what its children happen to be about would be identical to it in layer, levels, interactivity and governed copy — ADR-0050's four, all four the same. What varies is the subject of the children, and the tier reads nothing about subjects.

Build the drop zone, which is the one genuinely new thing. A bounded region that accepts a gesture is not a Button and not a Region, and this is the honest counter-argument to the whole record. It lost because a drop target's attention semantics are nil: it says *you may act here*, which is ADR-0045's turned corner and already in the vocabulary, and everything else about it is an interaction affordance. Button's own disabled note draws that line — *"an interaction affordance rather than a fact this component's allocation could describe"* — and a system with no runtime cannot test the half that would be new. If a drop target earns a component it will be because something can be measured about it, and this record cannot say what.

Keep the row and build it thinly, for roster parity. ADR-0021 took Carbon as an adversarial sample and this is the sample reporting a result. A row built to keep a number is the scenery §11 warns about, and this would be scenery assembled entirely from components that already exist.

Refuse the removal on ADR-0061's own warning. The warning is right and it is why this record derives the layer rather than asserting a collapse. The answer to *is the roster only ever shrinking?* is in the same audit: of the two rows ADR-0061 kept and this session has now resolved, one became a component at a layer the roster had wrong, and one becomes nothing. A test that produced only removals would be suspect; a test that produces both is doing its job.

#Consequences

Roster 51, built 32. Nineteen rows remain to build, one of them in section B.

Section B is six rows — five built and tree-view — from fourteen. Every row it lost left for a stated reason and each is in the exclusion table or in another section.

Nothing is built, no token, scene or baseline moves. A record and a table row, which is ADR-0050's shape and the fifth time this session.

The finding that outlives the row: section B's justifying sentence has now been shown wrong about two of its five examples. A section whose argument covers three of five named cases is a section assembled by grouping, and the two layer corrections this session made — tile to Scope, pagination to Emitter — are what that looks like from the other end.

#Measured

• Carbon's file-uploader anatomy, 2026-09-05: five entries, each mapping to a built component; the placement guidance quoted above is button-group's problem in prose.
• inline-loading: variants pending, complete, failed, one governed part *"which operation this reports"*, vouches: true — *disk, this pass*.
• Section B: 14 rows at ADR-0021, 6 now; two of its justifying sentence's five examples shown not to be Arbiter cases.
• Roster 52 → 51; the roster's Carbon rows 38 → 37; dropped 7 → 8; the identity 8 + 35 = 43 holds.
• Built 32, unchanged. pnpm battery — the verdict this pass is measured by.