status-projects: registry hook in the workplan skills, one stamp form for the tracker contract (C2), and a tracker-conform skill

[mmcky]

Three asks from the projects dashboard (QuantEcon/status-projects — private repo, public site at https://quantecon.github.io/status-projects/), ruled at its architecture review on 2026-08-23 (status-projects#9). The dashboard's collector reads every registered project tracker nightly, so the qe workplan family is now a producer for a machine consumer; the pieces below keep the two ends pointing at one contract. Block D of status-projects#1 owns them on the dashboard side.

1. Registry hook in workplan-project / workplan-issue / workplan-update

After creating a project tracker, offer to register it: open a PR adding a row to projects.yml in QuantEcon/status-projects (slug, name, programme, one public sentence, stage, priority, owner, the tracker ref, links). The dashboard's validator is the gate; the skills stay thin — one documented YAML snippet, no second edit path. At close-out (workplan-update), offer to set stage: done / parked / dropped with the date and point links.ledger at the closing ledger.

2. The tracker contract (C2) — one pointer, one stamp form

The collector parses exactly four things from a tracker: its state, its direct sub-issues (progress is measured one level down, never deeper), its native issue type, and a status stamp in the body. The stamp is where the convention and the parser can drift: the structural audit of 2026-08-23 found three forms in the wild — ## Where we stand (verified YYYY-MM-DD), ## Where we stand with no date, and a > **Updated YYYY-MM-DD.** banner — plus free-text "verified YYYY-MM-DD" inside checklists that a naive regex mis-reads. workplan-update now also recommends a time and timezone on the stamp.

Ask: the convention section in workplan-issue SKILL.md links to the consumer-side contract (docs/contracts/tracker.md in status-projects, written at the start of its Block B) and fixes one stamp form — the heading with a mandatory date and an optional HH:MM TZ suffix — which the parser accepts, with the banner as a fallback and free text never.

3. A tracker-conform skill (or a mode of workplan-update)

The collector publishes a per-tracker compliance block nightly (sub-issues present · stamp present and its age · Project issue type · tracker open). This skill is the fix: given a tracker (or the non-compliant list), restructure its body into the contract layout, apply the Project issue type, stamp it, and edit with approval — structure only, never the content. Its first run is the audit of the registered trackers, and it doubles as the field test (qeps#14) for the Project-tracker QEP that the interface half of qeps#15 becomes; the practice half of that discussion stays here.

Context

• The Project native issue type (org-level; no label, so QEP-2 is untouched and qeps#11 is answered) is being added by the org admin; type:Project then works in any issue list and org-wide, and the collector reads issueType.
• Programme-level trackers (programme → project → items) are deliberately not part of the contract; whether they are structure or a venue is deferred (status-projects#10).
• Structural baseline the spec is drawn from: of 99 tracker-shaped open issues org-wide, 92% carry no issue type, 60% have no sub-issues (work tracked by checkboxes or prose), 14 of 34 parents are nested, 24 parent→child links cross repos, and 0 trackers use dependencies.