Planning bug: a card was sealed carrying a heading that said "split it", and criteria duplicating a still-open operator card's DNS records — where the duplicate would have BROKEN the card that owns them

Filed by motir run MOTIR-3507 (2026-08-26) as part of THE REPLAN ACTION. The corrected shape is plan cmt9bxgte005ii4phewt8aa8j; this card records the planner defect that made the replan necessary. The correction is already applied — nothing here is scheduled and nothing is blocked.

Two limbs, one authoring pass

Limb A — the card DECLARED its own split and was sealed anyway

MOTIR-3507 was authored with type: code, executor: human, 5 points / 60 minutes, carrying a webhook route + message-id persistence + a dashboard change in motir-core and two registrar DNS edits — and with a heading in its own body reading:

⚠️ Two-executor card — split it … "this should be split before it is picked up rather than executed as one card"

plan-rules/core.md gate 1 already says a card that declares its own split "has already performed this gate's analysis and stopped one edit short — the sentence IS the split instruction, so PERFORM it before sealing." Gate 6 says the same thing on the executor axis. Both were available to the authoring pass and neither ran; the card was sealed with its own remedy written into it, and motir run then hit it at guard #2 with a person and nothing for that person to do.

This limb is the mechanizable one. It is lexical and cheap: a body carrying "split it", "do not dispatch this as one card", "it decomposes into", "two-executor" is a card the author has already diagnosed. It also produces a shape advisory shape validate_work_item does not yet emit — the existing families cover the repo straddle (likely-repo-straddle) and the sizing gate (likely-over-gate-sizing), but not a card whose own prose instructs its split.

Limb B — the more expensive one: nobody asked whether an existing card already owned the deliverable

Two of MOTIR-3507's criteria — the _dmarc rua= and an apex SPF TXT on motir.co — are already owned by MOTIR-2596 (8.5.15), which is still todo. That card's constraint #4 names the rua= as "the one record in the zone this card edits rather than creates", and its acceptance criterion requires motir.co to return exactly one v=spf1 record.

Gate 8's taker's-seat clause — "does any EXISTING card already claim this deliverable?" — was not run, and the cost is not merely a duplicate:

MOTIR-3507's criterion was the bare "An SPF TXT record exists on the apex motir.co", naming no provider. Discharged on its own it publishes a SECOND apex v=spf1, which is a permanent SPF permerror that fails CLOSED on strict receivers — the exact receivers the card was filed about. A well-intentioned run of the card would have made the reported symptom worse, at a domain where the symptom was already the whole complaint.

Why the duplicate was invisible. MOTIR-3507 is a bug under the epic; MOTIR-2596 is a subtask under story 8.5. Neither is in the other's subtree, neither names the other, and validate_work_item's reference family only fires on a card that names a not-done item. A deliverable claimed by two cards that do not cite each other is currently detectable by nothing except a human reading both — and the shared object here was a DNS record name, not a file path, so even a repo-scoped check would have missed it.

What would have caught each

• Limb A: a lexical read of the card's own body at seal time, in the authoring pass or as a new shape advisory family. Cheap, deterministic, and it fires on the card in front of you.
• Limb B: harder, and worth saying honestly rather than over-claiming. The general form — "two cards own one write" — has no cheap detector. The narrow form does: a card whose criteria name a DNS record, an environment variable, a secret name, or a registry/endpoint identifier is claiming a write on a shared external namespace, and those namespaces have few enough owners that a search over open cards for the same literal is tractable. That is the version worth mechanizing; anything wider is a research card, not this one.

Acceptance criteria

• The corpus states, at the gate that owns it, that a card whose own prose instructs its split is not sealable until the split is performed — with the trigger phrases enumerated. If plan-rules/core.md gate 1's existing limb already says this (it does), the defect is that nothing READS it, so the change is to make it fire: name where in the authoring procedure the check runs, not a second copy of the rule.
• The external-namespace limb is recorded: a criterion naming a DNS record, an env var, a secret or a registry identifier is a claim on a shared namespace, and gate 8's taker's-seat question is run against open cards for that literal before sealing.
• Each change lands in both homes where the rule has two (motir-meta/prompts/plan-rules/ and motir-ai's planningRulePacks.ts), or the divergence is recorded.
• Whether a new validate_work_item shape family for limb A is worth building is decided on this card and recorded, either way — a "yes" becomes its own card in motir-core, a "no" says why.
• No product-code change is in scope here. The observability work MOTIR-3507 was really about lives in that card's own subtree.

Context refs

• MOTIR-3507 — the card this is about; its comment carries the full run report
• MOTIR-2596 — the still-open card that already owns both DNS records, and whose constraint #1 is what makes the duplicate destructive rather than merely redundant
• motir-meta/prompts/plan-rules/core.md — gate 1's self-declared-split limb, gate 6's executor-axis split signal, gate 8's taker's-seat clause. All three exist; none fired.
• Plan cmt9bxgte005ii4phewt8aa8j — the corrected shape, awaiting approval