workplan family: tracker-conform — the fix half of the contract's compliance block

[mmcky]

Part of #63 (Phase 2). Split out of #49, item 3.

The problem

The tracker contract §5 describes its compliance block as one half of a pair, and names the other half explicitly:

Every registered tracker gets a compliance object in data/latest.json, nightly. It is the check half; qe:tracker-conform (skills#49, Block D) is the fix half.

The check half runs nightly. The fix half does not exist. C2 §3.2 cites it a second time, as the thing that converts a banner stamp to the heading form. So an upstream contract, already shipped, names a skill in this repository that has never been written.

Measured upstream on 2026-08-24: 26 of 28 registered trackers are untyped. This is not a long tail of stragglers — it is nearly all of them, and fixing them one at a time by hand is exactly the kind of repetitive, rule-governed work the marketplace exists to share.

The work

Given a tracker — or the non-compliant list from the nightly output — restructure its body into the contract layout, apply the Project issue type, stamp it, and edit on approval. Structure only, never content: the skill moves a live-state paragraph under a conformant heading, it does not decide what the project's status is.

Whether this is its own skill or a mode of /qe:workplan is open. The argument for its own skill is that its subject is any tracker, including ones this family never created; the argument for a mode is that it shares the whole convention with workplan and would otherwise restate it.

Its first run is the audit of the registered trackers, and it doubles as the field test (QuantEcon/qeps#14) for the Project-tracker QEP that the interface half of QuantEcon/qeps#15 becomes.

Do the Phase 1 hand-conformance work first. Whatever proves fiddly there — deciding which prose is really the live-state table, splitting a checkbox list into sub-issues without losing its ordering — is this skill's actual specification.

Acceptance criteria

• A decision, recorded, on standalone skill versus a workplan mode
• Reads the nightly compliance output as an input, not just a single named tracker
• Changes structure only; a diff that alters a status claim is a bug
• Never runs unattended — proposes, a human approves
• Run against the registered non-compliant set, with a record under reviews/

[mmcky]

Two of this issue's open questions were settled in discussion on 2026-08-26. Recording them here so the design isn't re-derived from scratch, and because neither is visible in the issue as filed.

Where the skill lives: qe, not status-projects. The tempting argument is locality — C2 lives in status-projects, so put the skill that enforces C2 there too. It does not hold, for two reasons. First, the skill's subject is not the dashboard: it restructures tracker issues across roughly 28 repositories, and a maintainer running it is standing in meta or workspace-lectures, not in the dashboard checkout. qe already holds skills whose subject is other repos — /qe:audit-issues audits any tracker, /qe:copilot-review runs cross-repo — so this is the existing pattern rather than an exception. Second, there is a hard distribution cost: a Claude Code plugin marketplace inside a private repository is installable only by people with access, while QuantEcon/skills is public and already wired into lecture repos through .claude/settings.json. Moving one skill would mean standing up a second, private marketplace with its own install story.

The general rule this comes from, worth stating once: a skill's home follows its subject; a contract's home follows its enforcement. C2 belongs beside collector/validate.py because the regexes it publishes are the ones that actually run. This skill belongs beside the other skills that act on the org's repositories.

What the skill should cite: the QEP, not C2. The interface C2 implements — one tracker issue, direct sub-issues as the work, a status stamp, the native Project type — is planned as a one-page public QEP that C2 will cite (status-projects design.md R6, written from the collector's evidence after Block B, field-tested in Draft per QuantEcon/qeps#14). The QEP sits above C2; nothing is carved out of C2, which keeps everything it has.

That matters here because this skill needs to know what shape to write, not what regex recognises it. The shape is the QEP's; the regex is C2's. Citing C2 reaches past the layer the skill actually depends on, and today it also means citing a members-only document. #62 does the interim honestly — the example form inline, C2 named as the authority, and a note that the section re-points at the QEP when it lands. This skill should be built against the QEP if it exists by then, and re-pointed if it lands later.

Still open, unchanged: whether this is a standalone skill or a mode of /qe:workplan, and the sequencing note already in the body — #64's hand-conformance pass comes first, because doing the job manually once is this skill's real specification.