Motir

Found by motir run MOTIR-4130 (2026-09-02), at guard #4, before a worktree was written to. The correction is already applied to MOTIR-4130 — this card is the telemetry, and it holds nothing up.

Two defects in one card's authoring, both of which sealed ready: true, valid: true, openBlockers: [].

---

Defect 1 — the enumeration is a correct count of the wrong set

MOTIR-4130's premise is a claim about a POPULATION: "the shipped rail has three rows there". As authored (quoted verbatim, because update_work_item leaves no prior revision — the as-authored-body-is-lost rule):

The shipped rail's bottom section, in declaration order from app/(authed)/_components/SidebarNav.tsx:

row	icon	href	added by
Git	GitBranch	/settings/workspace/github	the connect-settings surface
Docs	BookOpen	/docs	MOTIR-2570
Legal	Scale	/legal	MOTIR-1134

Two of the three rows that ship in that section are absent from every asset that draws it, and a Settings row is drawn that the shipped bottom section does not carry in that position.

Re-measured at the card's OWN base 5fb216b21 — git show 5fb216b21:'app/(authed)/_components/SidebarNav.tsx', reading the sections.push({ id: 'bottom' … }) block — the section carries SIX entries, in declaration order:

Identical on today's origin/main cd236496d. So the count is not drift and there is nothing to date — the extra members were present at the card's own base, which puts this on the enumeration was WRONG when it was written arm of run.md's step 3, not the genuine drift arm.

Two consequences, and the second is the one that would have mis-directed the build:

1. The gap is four undrawn rows (Security, Job runs, Git, Legal), not two.
2. The Settings clause is inverted. Settings is the FIRST entry of the shipped bottom section, so the asset drawing it is the one thing about that section the asset gets RIGHT. The card asks its runner to settle "whether a Settings row belongs in that section at all" — a question whose premise is false, and whose natural resolution (delete the row the asset draws) would have made the asset worse.

The mechanism, which is why "be more careful" would not have caught it. The table has an added by column: it is an inventory of rows whose PROVENANCE the author had in hand — the two rows the design/auth planning flag named, plus the one beside them — and not a reading of the section. The claim quantifies over the section; the command enumerated the rows already under discussion. X ⊋ Y, measured at the same ref, so the ref proves nothing. This is run.md's RE-MEASURE THE PREDICATE, NOT ONLY THE REF, and the lesson A population claim is only as wide as the command that produced it (INHERITS-the-set arm) — reinforced against this occurrence.

---

Defect 2 — an edge denied on the record, to an OPEN pull request that changes the card's own subject

MOTIR-4130's ## Advisory dispositions section, as authored:

• No blocked_by is owed to MOTIR-4006 or to MOTIR-3909. This card reads nothing either produces: its subject is the shell area's own assets against the shipped SidebarNav, both of which exist on origin/main today. The relates_to carries the discovery trace, and the ordering runs the other way — MOTIR-4006's panel 14 is the interim source this card eventually supersedes.

That is false, and validate_work_item had already flagged its subject — { referenced: "MOTIR-3909", referencedStatus: "in_review", severity: "advisory" }.

MOTIR-3909 is in_review on open PR moooon-B-V/motir-core#2513, which edits app/(authed)/_components/SidebarNav.tsx and makes the Legal row conditional:

-      {
-        icon: <Scale />,
-        label: t('nav.legal'),
-        href: '/legal',
-      },
+      ...(legalIndexUrl
+        ? [{ icon: <Scale />, label: t('nav.legal'), href: legalIndexUrl }]
+        : []),

So the row the card is NAMED after changes both its render condition and its href on that PR. The disposition's own test — "its subject is … the shipped SidebarNav, which exists on origin/main today" — is the right test applied to the wrong tense: what exists on origin/main today is the row the card would draw, and it is the row being retired.

And the card's stated purpose consumes MOTIR-3909's output directly. Its Boundary reads "MOTIR-4006's panel 14 stands, and stays the source for the legal row's two arms until this card lands" — the two arms (configured / unconfigured) are exactly what #2513 introduces. A card that supersedes a two-arm drawing cannot draw the arms before the arms exist.

There was no correct arm available today, which is what makes it a blocker rather than a nuisance: drawing the row unconditional makes the asset stale within days (the defect this card exists to fix, reproduced on day one); drawing both arms means building against an unmerged branch; omitting it fails the card's headline criterion.

Disposition applied: link_work_items MOTIR-4130 blocked_by MOTIR-3909 (siblings under epic MOTIR-3875, so the edge belongs at this level — gate 7 is satisfied), card → Blocked.

---

The shape worth keeping

A disposition by DENIAL gets no check, because the two honest dispositions are written as act or explain why it does not apply — and an explanation IS the second one. The lesson An advisory a card ACKNOWLEDGES as real and declines to act on is not discharged covers the DEFERRAL variant ("real, but not this pass"). This card wrote the other variant: a reasoned, specific, evidence-shaped denial that was simply wrong on the facts. It reads as MORE finished than silence, it satisfies the letter of the disposition rule, and nothing downstream re-derives it. Reinforced against this occurrence.

Acceptance criteria

• MOTIR-4130's body no longer claims a three-row bottom section, and no longer asks whether Settings belongs there. (Applied 2026-09-02 by the finding run — this criterion records it, and a reader can check it against the card.)
• MOTIR-4130 blocked_by MOTIR-3909 exists as an edge, not as a paragraph. (Applied.)
• The two lessons named above carry an occurrence for MOTIR-4130. (Applied.)
• Open: decide whether either shape earns a RULE rather than only the two lesson reinforcements — specifically whether plan-rules/core.md gate 21 should require that a disposition which DENIES an edge name the command that settled it, the way a population claim must. That is a motir-meta change and is this card's only remaining work.

Context refs

• MOTIR-4130 — the card both defects are in; relates_to
• MOTIR-3909 — the story whose open PR #2513 the denied edge points at
• motir-core app/(authed)/_components/SidebarNav.tsx — the id: 'bottom' section, six entries
• motir-meta/prompts/run.md — RE-MEASURE THE PREDICATE, NOT ONLY THE REF; guard #4's advisory block