Motir

Type · planning defect (the correction is already applied — this is telemetry, and it holds nothing up) Discovered in · MOTIR-4071, during the run that implemented it.

What the card said, and what was true

MOTIR-4071 cut modify_node's key set into a BODY half and a PLACEMENT half, and stated the body half's delta twice:

BODY → author. … author has five already and gains four.

author's schema gains exactly the four body keys it lacks — explanationMd, priority, targetRepo, targetRepoRole — and no structure key.

priority was already on author's schema (motir-ai src/llm/treeGeneration.ts:2352 on origin/main at b9f0007), and already reached the sink on both of author's arms. The true split is six already, gains three.

Measured by BUILDING the surface rather than reading the file:

author schema props : id, kind, title, parentRef, blockedByRefs, type,
                      descriptionMd, priority, storyPoints, estimateMinutes, note
BODY keys author HAS  : title, descriptionMd, priority, type, storyPoints, estimateMinutes   (6)
BODY keys author LACKS: explanationMd, targetRepo, targetRepoRole                            (3)

Why it is worth a card even though it cost nothing

It cost nothing THIS time, and that is a property of the criterion rather than of the card. The criterion's operative half is an EXACT PROPERTY SET, and the required end state is the same under either count — so a run that reads it carefully arrives at the right code and notices the arithmetic on the way. Change one word and it does not: an acceptance criterion phrased as "gains exactly four keys", asserted as expect(added).toHaveLength(4), is a criterion no correct implementation can satisfy, and the run that met it would have added priority a second time or found something else to count.

The rule that would have caught it already exists and is the ENUMERATION limb: a card COUNTING a population owes the ref the count was taken on, and find / ls / a bare grep -r cannot supply one. This is that rule at one remove — the population is a SCHEMA's property set rather than a file tree, and the instrument is reading a source file rather than a command. The card named neither the ref nor the command, so the number could only be checked by re-deriving it.

The sharper half — the instrument, not the ref

The ref would not have saved this one, and that is the finding worth keeping. A tool schema's property set is assembled at runtime — buildAllGenerationTools spreads conditional blocks (opts.generateExplanations, a repository set, planningTurn), so the properties present depend on the OPTIONS, not only on the file. Reading the literal answers "is this key written in the source?"; the claim is about "what does the model receive?" — the same claim-vs-command mismatch as the re-measure the PREDICATE rule, with the two sets one construction apart rather than one directory apart.

So the check is one line and it is not a grep:

buildGenerationTools({ planningTurn: true })
  .find((t) => t.function.name === '<tool>')!.function.parameters.properties

Acceptance criteria

• The ENUMERATION limb gains a TOOL-SCHEMA clause, in motir-meta prompts/plan-rules/phase-deepen.md beside the existing limb: a card counting the fields a TOOL SURFACE carries or lacks states the CALL that produced the list, not the file it read, because the surface is assembled from options and the literal is a different set.
• It is added, not re-worded — the ADD-never-re-word convention for this corpus; the existing limb's text is untouched.
• The clause names the discriminator, so it is applicable rather than merely true: the claim is about what the model RECEIVES; the file says what is WRITTEN, and a conditional spread is where the two come apart.

Context refs

• MOTIR-4071 — the card, and its amendment comment carrying the measurement.
• motir-ai src/llm/treeGeneration.ts — buildAllGenerationTools' conditional property spreads, and author's schema.
• motir-meta prompts/plan-rules/phase-deepen.md — the ENUMERATION limb this extends.