Part of #63 (Phase 2). Split out of #49, item 1.
The problem
A tracker can be perfectly conformant with C2 and still be invisible. The dashboard observes only what is registered: a row in projects.yml naming the project's slug, programme, stage, priority, owner, one public sentence, the tracker in Owner/repo#N form, and its links. Nothing in the workplan-* family creates that row.
As of qe 0.8.0 both skills say so and offer to draft the row, which is the honest half. The gap is that drafting stops short of the thing that takes effort — getting the row into the upstream repository, in the right shape, past that repo's validator.
The work
After workplan creates a long-lived tracker, or workplan-project files a project, offer to open a pull request against QuantEcon/status-projects adding the row. The skills stay thin: one documented YAML shape, no second edit path, and the upstream validator is the gate rather than anything reimplemented here. Where the fields cannot be inferred — programme, stage, priority, the public sentence — ask rather than guess, since summary and note are public and for a private tracker they are the only thing published.
At close-out, the same hook in reverse: workplan's close offers to set stage: done, parked or dropped with the date, and to point links.ledger at the closing ledger.
Both directions stay gated the way every other write in the family is — drafted locally, shown, and executed only on approval. A registration PR is a write to a repository the user may not even have open.
Acceptance criteria
Part of #63 (Phase 2). Split out of #49, item 1.
The problem
A tracker can be perfectly conformant with C2 and still be invisible. The dashboard observes only what is registered: a row in
projects.ymlnaming the project's slug, programme, stage, priority, owner, one public sentence, the tracker inOwner/repo#Nform, and its links. Nothing in theworkplan-*family creates that row.As of qe 0.8.0 both skills say so and offer to draft the row, which is the honest half. The gap is that drafting stops short of the thing that takes effort — getting the row into the upstream repository, in the right shape, past that repo's validator.
The work
After
workplancreates a long-lived tracker, orworkplan-projectfiles a project, offer to open a pull request againstQuantEcon/status-projectsadding the row. The skills stay thin: one documented YAML shape, no second edit path, and the upstream validator is the gate rather than anything reimplemented here. Where the fields cannot be inferred — programme, stage, priority, the public sentence — ask rather than guess, sincesummaryandnoteare public and for a private tracker they are the only thing published.At close-out, the same hook in reverse:
workplan'scloseoffers to setstage: done,parkedordroppedwith the date, and to pointlinks.ledgerat the closing ledger.Both directions stay gated the way every other write in the family is — drafted locally, shown, and executed only on approval. A registration PR is a write to a repository the user may not even have open.
Acceptance criteria
workplan create(tracker genre) andworkplan-projectboth offer the registration PR after filingworkplan closeoffers the stage change and the ledger linkprojects.ymlrather than restating its schema