Three shipped operator verbs (engine-setup, engine-parts, engine-upgrade) have no admitting roster decision

[StarshipSuperjam]

The engine opened this item itself — you didn't create it.

What this is. Three shipped operator-typed verbs have no admitting roster decision.

• Core's manifest provides nine skills; eight are operator-typed and one (engine-recall) is model-auto.
• The verb-roster decisions on record admit five of the eight: the original locked membership (carried downstream as D-087) plus the later status and conduct-authoring admissions (D-200/D-201, D-192/D-193). engine-recall's arrival now has its own record tracked separately.
• engine-setup, engine-parts, and engine-upgrade ship as real operator verbs with no decision admitting them to the roster — engine-setup descends from the first-run/provisioning design, engine-parts and engine-upgrade from their features, but none was ever ratified as a roster addition, so the locked five-verb enumeration and the shipped eight-verb set disagree silently.
• Downstream, the operator's product repo adopted the built roster during its spec reconciliation (recorded there as part of a wave-7 adoption cluster); this issue is the upstream half: the admitting record owed to this repository's own decision surface.

What happens next. Log the admitting decision for the three verbs — what each is for and that the roster enumeration is superseded by the shipped set. A record-only change; the skills themselves need nothing.

More detail.

• The nine-skill provides list (core manifest.json)
• One unadmitted verb (engine-setup SKILL.md)
• Another (engine-parts SKILL.md)
• Another (engine-upgrade SKILL.md)
• The reconciliation policy this ruling was made under (decision 0320)