PLAN: qe workplan family — the tracker contract, the dashboard hooks, and first validated runs

[mmcky]

The workplan-* family shipped across qe 0.3.0–0.5.0 and has been tracked inside #3 — "PLAN: qe style skills" — ever since. That was a shortcut while the family was two days old, and it has stopped being harmless: #3 is a registered tracker on the projects dashboard under the slug qe-style-skills, so the family's work is filed under a public name that describes a different skill family. This tracker takes that half over, and #3 goes back to being about the style skills alone.

It also carries work that arrived from outside the repo. On 2026-08-24 the dashboard's collector began parsing every registered project tracker nightly and publishing a per-tracker compliance block, which made this family a producer for a machine consumer. The contract is C2, written upstream and pointed at rather than restated here. #49 was the ask; #62 landed the first third of it and #49 is closed as split into #66 and #67. A second document now rules the structure of what the skills write: QEP-6 (draft), whose field test (qeps#19) read workplan-project against it and filed six findings here; those became phase 1 work on 2026-09-02 and are done.

Where we stand (verified 2026-09-02 14:11 AEST)

Fact	Value
Skills in the family	/qe:workplan (create, read, resume, update, close), /qe:workplan-project, and — since 0.9.0 — /qe:workplan-roadmap (a project tracker drawn as mermaid flowcharts: phases, decision gates, pathways, work items with dependencies; structure only, never status)
Plugin version	qe 0.10.0, merged 2026-09-02 as 7ebf8a5 (#76); validate and docs workflows green on that SHA
Release tag	qe--v0.10.0, pushed 2026-09-02 at 7ebf8a5
Verbs with a validated run	update and resume — 2026-08-20, on #25 on 2026-08-25, on this tracker on 2026-09-02 morning, and this revision, the first update run from an installed 0.10.0 plugin
workplan-project runs	none against a real report bundle. Its step-6 filing mechanics — parent read before linking, --add-sub-issue in plan order, reprioritise with after_id, list read-back — were exercised once by hand on 2026-09-02, linking #69–#74 into this tracker; the appended-then-reprioritised sequence behaved exactly as the 0.10.0 text says
workplan-roadmap runs	none as an installed skill. Its procedure was extracted from one hand run — the Lectures monorepo roadmap drawn from project-monorepo#7 and merged as project-monorepo#30 on 2026-09-02 — and its deterministic half, scripts/workplan/tracker-snapshot.sh, was tested against that private tracker (23 children, six Decision-typed) and the public meta#358 (11 untyped)
C2 conformance of what the skills write	stamp heading and Project type landed in 0.8.0; registration hook (#66) and conform pass (#67) still unbuilt
QEP-6 conformance of what workplan-project writes	landed in 0.10.0 (#69–#74): phase table instead of a work-item roster, tracker written once, plan order stated and kept, parent read before every link, a membership gate, exemplar cited for content only, Related work and Gates for split packages. /qe:workplan itself is not yet read against QEP-6 §7 — #68 is that work, adopted into phase 1 on 2026-09-02
This repo's own registered trackers	re-measured 2026-09-02 13:08 AEST, unchanged since 2026-08-26: #3 (qe-style-skills) and #12 (audit-skills) are both untyped, unstamped, 0 native sub-issues
This tracker	registered as slug workplan-skills (status-projects#15) and conformant — Project type, 6/12 native sub-issues completed, list in plan order (phase 1 contiguous, then phase 2); the 2026-09-02 00:45Z collection read its type and 2026-08-26 stamp, and will read 50% at the next one. This revision also removes the work-item roster from its own body, per QEP-6 §7
Org Project issue type	enabled 2026-08-24, id IT_kwDOAITMVM4nCT-M
Registered trackers org-wide carrying the type	10 of 34, from the dashboard's 2026-09-02 00:45Z collection (2 of 28 on 2026-08-24)

Every row above was measured on 2026-09-02 against live state, not carried forward from an earlier plan.

Front of the plan: #64, unchanged. The six findings were adopted, fixed and linked in one session, so phase 1 is now #64, #65 and #68 with six completed items between them. #64 still leads for the reason it always did — conforming #3 and #12 by hand is what specifies #67 — and it has a second reason now: this tracker's own body carried the roster QEP-6 forbids until this revision, so the conform pass has one worked example of the body edit and needs two more. #65 has changed shape rather than order: the workplan-project run it wants is now worth doing, because the skill is in the shape a run should validate, and its filing step already has one hand-run of evidence recorded above. #68 — the same read of /qe:workplan against QEP-6 §7 that #69–#74 were for workplan-project — closes phase 1's skill-conformance half and can be taken any time. #66, #67 and #55 are unblocked and can be taken in any order. Nothing on this plan is overdue.

The gaps

#	Gap	Severity	Where
1	This repo's two registered trackers fail all three C2 checks, so the dashboard publishes their progress as null and flags them untyped	High — the dashboard is live and public, and these are ours	#3, #12
2	A conformant tracker is still invisible until a row lands in projects.yml; the skills say so but cannot do it. This tracker's own registration was done by hand in status-projects#15 — that is the gap demonstrated, not closed	Medium	#66
3	C2 §5 names qe:tracker-conform as the fix half of its compliance block. The check half ships nightly; the fix half does not exist	Medium — the contract cites a skill this repo has not written	#67
4	Milestone naming for phased plans is unruled, and workplan-project files phases with no milestone at all. QEP-6 §3 bans sequence tokens in milestone names, which bears on the wp{issue#}-stage{n} proposal	Low	#55
5	Three of five workplan verbs, all of workplan-project, and all of workplan-roadmap have never run as installed skills — the filing step of workplan-project now has one hand-run of evidence, which is not the same thing	Medium — these are procedures, and an unrun procedure is a hypothesis	#65
6	/qe:workplan has no body spec for the long-lived tracker genre and no home for the resume pointer; QEP-6 §7's Next: line is the candidate, and the verb has not been read against §7 the way workplan-project now has	Low	#68

Plan

Work items and their order are the sub-issue list: topmost open item is next, completed items keep their place, phase groups contiguous. Phases carry no milestone until #55 rules the naming; the table below says what each phase is for and when it is finished, never which items it holds.

Phase	Intent	Exit criterion
Phase 1 — Field work	Bring what already exists up to the two documents that now read it: conform this repo's own registered trackers by hand, fix what the QEP-6 field test found in workplan-project, and run every unrun skill once from an installed plugin	#3 and #12 pass all three C2 checks; workplan-project is QEP-6-conformant (done, 0.10.0); each skill and verb has a validated run recorded in reviews/ or on its issue
Phase 2 — New capability	Close the two halves of the compliance loop the contract assumes exist, and rule the milestone convention	A registration PR can be opened from the skill; tracker-conform exists and has run against #3 or #12; the milestone convention is ruled and wired in

Gates: phase 2's tracker-conform (#67) waits on phase 1's hand conformance of #3 and #12 (#64), because whatever proves fiddly by hand is what the skill has to handle, and a skill designed before that pass is designed against a guess. Nothing else in phase 2 waits on phase 1.

Sequencing rationale: phase 1 needs nothing built and front-loads the evidence. Within phase 2, the registry hook (#66) is worth landing before tracker-conform: a conform pass that fixes a tracker nobody registered has fixed something invisible. #49 asked for three things and is split across the two phases: its item 2 (one stamp form) landed in #62, and its items 1 and 3 are #66 and #67. It is closed as split rather than carried, so no sub-issue here is two-thirds done.

What does not need to change

The C2 rules themselves — they are authored upstream and this repo links to them, which is the arrangement both sides intend. Where C2 and QEP-6 disagree — a body roster of work items is C2-conformant and QEP-6-forbidden — the skills say so and cite QEP-6's Adoption clause 3, which rules QEP-6 authoritative for structure until C2's handover; the disagreement is not resolved in this repo. C2's stale skill names are status-projects#20, and the dashboard's re-sort of children by issue number, which hides plan order from the public site, is status-projects#19; both are upstream. What the skills should eventually cite is the one-page public QEP that status-projects design.md R6 plans, which sits above C2 rather than being carved out of it; QEP-6 is the structure half of that, not the whole. Two related questions were raised and closed on 2026-08-26, recorded in full on #67: the skills stay in qe rather than moving to status-projects (a skill's home follows its subject; a contract's home follows its enforcement), and no QuantEcon/specs or QuantEcon/interfaces repo is created — qeps already is that repo, public and with a lifecycle. The workplan/workplan-project split settled in 0.5.0 and is not reopened here. The period-plan genre stays untyped and unregistered: a session's working document is not a project, and that boundary is what stops every weekly plan landing on the dashboard.

Sources

The contract and its compliance block: C2, written 2026-08-24 against the structural audit of 2026-08-23. The structure standard: QEP-6 (draft), and its field test qeps#19, whose finding 9 produced #69–#74. The dashboard side of this work is Block D of QuantEcon/status-projects#1. The convention this family operates is headed for a QEP, discussed at QuantEcon/qeps#15, and the issue-type question it answers is the field report at QuantEcon/qeps#11. Release history is in qe/CHANGELOG.md.

[mmcky]

Revision 2026-08-26 13:19 AEST — the plan's first update, six hours after it was created. Recorded because a same-day revision still has to be readable by a session that was not here.

What landed. #62 merged at 03:17Z as daa27f2 — qe 0.8.0, the docs site deployed green on that SHA. The stamp heading and the Project issue type are now what the skills write, so gap 2 of #49's three asks is closed at the source rather than by hand. status-projects#15 merged at 02:38Z, registering this tracker as slug workplan-skills; collector/validate.py passed at 8 programmes and 29 projects. #49 is closed as split, into #66 (registry hook) and #67 (tracker-conform). Three merged branches were pruned from the remote, leaving main alone.

What was decided, with the full argument on #67 rather than repeated here: the skills stay in qe rather than moving to status-projects, on the rule that a skill's home follows its subject while a contract's home follows its enforcement; no QuantEcon/specs or QuantEcon/interfaces repository is created, because qeps already is that repository; status-projects stays private for now, its two go-public blockers being historical rather than working-tree; and C2 is not published, because the one-page interface QEP that status-projects design.md R6 plans supersedes the need and a Pages URL would be unversioned anyway. The QEP sits above C2 and cites it — nothing is carved out of C2.

What this revision found. Two things, neither a defect in the plan:

The 0.8.0 release was untagged — qe--v0.7.0 was still the newest tag, though tagging is the documented last step of a release (developing-skills § Tags). Fixed in this session: qe--v0.8.0 is pushed and points at daa27f2. Nothing installs from a tag, so no user was affected; it is the bookmark that makes a version's tree findable later, which matters here because the skills' text changed materially in 0.8.0.

The installed plugin is qe 0.7.0, so this update run loaded the pre-0.8.0 procedure — the one whose convention section still says plan issues stay untyped and which has no tracker-contract section. The 0.8.0 text on main was followed instead. This is the same stale-procedure hazard #25 recorded before audit run 2, hitting a second time in a different family, and the fix is the same: claude plugin update qe@quantecon plus a session restart before running a skill whose procedure changed this session. Worth knowing that neither the version bump nor CI can catch it — the cache is per-version and a running session holds whatever it loaded at startup.

Resume pointer: #64. It leads not because it is largest but because it is the sequencing constraint: conforming #3 and #12 by hand is what specifies #67, and #67 designed before that pass is designed against a guess. #65, #66 and #55 are unblocked and can be taken in any order. The release is complete — merged, tagged, deployed — so nothing on this plan is overdue.

[quantecon-services]

Six findings on workplan-project, filed unparented — proposing them for phase 1

From the QEP-6 field test (QuantEcon/qeps#19), which built two conformant trackers by hand and hit these on the way. They bear directly on gap 5 and on the "C2 conformance of what the skills write" row of your stamp table.

#	Finding	Severity
#69	The mandated Phase | Issue | Work item table is the body mirror QEP-6 §6 forbids	Blocking
#70	Plan order is never stated; the re-run path appends out of position	Blocking
#71	The extraction bar is a quality bar — nothing tests membership	High
#72	Linking a pre-existing sub-issue can silently steal it from another tracker	High
#73	The cited exemplar (QuantEcon.py#925) is stamp-unreadable under C2 §3.4	Medium
#74	Split packages have nowhere to record how they relate	Medium

I have not linked any of them. Adding six children would take this tracker from 5 to 11 and move its published percentage without any work having happened — which is itself one of the field test's findings, so it seemed a poor way to deliver it. The membership call is yours.

If you do take them, the argument for phase 1 is the one already in your body: "Phase 1 is field work on skills that already exist and needs nothing built." All six are edits to one SKILL.md. And #65 is the reason they are urgent rather than tidy — a first validated run of workplan-project in its current shape produces a tracker that violates QEP-6 in two ways and writes it into someone else's repository. Fixing #69 and #70 before that run is cheaper than conforming the output afterwards, and #65's value as evidence depends on the thing being run.

Ordering suggestion, if useful: #69 → #70 → #72 → #71 → #73 → #74. #69 first because it is a net deletion that removes step 5.3 and the second body write, which simplifies #70's territory before #70 touches it; #72 before #71 because it is a safety guard on a path that already exists.

Three notes, in fairness to the current text

#69's construct is C2-conformant. C2 rules only that checkbox progress is never read; it does not forbid a body roster. The skill followed the document it cites. The gap is between C2 and QEP-6, and it is new — which is also why the same table appears in this tracker's own body, and why that is not a criticism.

#70 cannot be verified through the dashboard yet. The collector re-sorts published children ascending by issue number, so a tracker in plan order and one in arbitrary order publish identically. Raised upstream as QuantEcon/status-projects#19 — it is QEP-6 Adoption clause 4, a one-row contract change plus a sort removal.

Two of your citations have drifted, raised as QuantEcon/status-projects#20: C2 still names qe:workplan-update, consolidated into /qe:workplan update at 0.5.0, and still describes qe:tracker-conform in the present tense — which is your #67, and which means the compliance block currently has a check half shipping nightly and no fix half at all.

One thing I did not file

The wp{issue#}-stage{n} convention in #55 is worth a look against QEP-6 §2 before it is ruled: sequence tokens in milestone names are exactly what that section bans, on the grounds that a token welds order to identity, so every re-plan either renames the work or lets the names lie. There is also a purely mechanical reason to avoid numeric milestone names — gh issue list --milestone runs strconv.ParseInt on its argument first, so a milestone titled "2026" is looked up as milestone number 2026 and fails. Left for #55 rather than filed separately, since that issue is where the decision belongs.

---

Generated by Claude Code

[mmcky]

Revision 2026-09-02 — qe 0.9.0: the family's third skill, /qe:workplan-roadmap

What landed since the 2026-08-26 stamp. #75 merged as 393d98f and is tagged qe--v0.9.0; the docs site deployed green on that SHA. It adds /qe:workplan-roadmap, which draws a project tracker as two GitHub-rendered mermaid flowcharts (the route — phases, decision gates, pathways — and every sub-issue with its dependencies) plus a gates table and node index, and keeps the drawing in step with the tracker after a plan review. It reads trackers and writes only a repository file; it never edits an issue, so it adds nothing to what the family writes under C2. The procedure was extracted from a hand run: the Lectures monorepo roadmap drawn from project-monorepo#7 and merged as project-monorepo#30 the same day. Copilot's two review comments on #75 (a marker-matching mismatch in the snapshot script, a punctuation slip) were fixed before merge.

What was re-measured. Every row of the table above, on 2026-09-02. #3 and #12 are unchanged — still untyped, unstamped, no native sub-issues — so gap 1 and the front of the plan (#64) stand. The org-wide count of registered trackers carrying the Project type moved from 2 of 28 to 10 of 34 between the 2026-08-24 audit and the dashboard's 2026-09-02 collection. No premise inverted.

What changed in the plan. Gap 5 and #65 now include workplan-roadmap among the skills with no run as an installed plugin; its natural first case is the monorepo tracker once its plan moves, which project-monorepo#29 (a review pass over that repo's plan documents) is about to cause. Nothing was re-ordered.

Surfaced, not decided. Six workplan-project findings (#69–#74) were filed unparented on 2026-08-27 and proposed for phase 1 in the comment above; they are still unparented. Whether they join this tracker is the maintainer's call, and the body now says so rather than leaving the proposal to be rediscovered.

Resume pointer. Front of the plan is still #64. The first workplan-roadmap run, when it comes, belongs on #65 as evidence.