qe 0.11.0: workplan-project writes dependency edges; QEP-2 is Accepted

.claude-plugin/marketplace.json

@@ -9,7 +9,7 @@
     {
       "name": "qe",
       "source": "./qe",
-      "version": "0.10.0",
+      "version": "0.11.0",
       "description": "QuantEcon's shared agent skills under one namespace — working through a PR's review feedback, advising on and scoring lecture acceleration (benchmark), bulk read-only repository audits, turning audit reports into tracked work projects, creating, reading and carrying work-plan state across agent sessions, and drawing a project's roadmap (phases, decision gates, pathways and work items) from its tracker"
     }
   ]

qe/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "qe",
   "description": "QuantEcon's shared agent skills under one namespace — working through a PR's review feedback, advising on and scoring lecture acceleration (benchmark), bulk read-only repository audits, turning audit reports into tracked work projects, creating, reading and carrying work-plan state across agent sessions, and drawing a project's roadmap (phases, decision gates, pathways and work items) from its tracker",
-  "version": "0.10.0",
+  "version": "0.11.0",
   "author": {
     "name": "QuantEcon"
   }

qe/CHANGELOG.md

@@ -6,6 +6,21 @@ Versions are [semver](https://semver.org) as a user of this plugin experiences i
 
 Repository: [QuantEcon/skills](https://github.com/QuantEcon/skills) ([every commit that touched this plugin](https://github.com/QuantEcon/skills/commits/main/qe)). How a release is made: [developing-skills § Versioning and releases](https://github.com/QuantEcon/skills/blob/main/docs/developing-skills.md#versioning-and-releases).
 
+## 0.11.0 — 2026-09-08
+
+Follows the [QEP-6](https://github.com/QuantEcon/qeps/pull/18) §4 amendments ruled on 2026-09-08 ([qeps#18](https://github.com/QuantEcon/qeps/pull/18#issuecomment-5583823922)), and corrects two citations that were wrong rather than merely stale. QEP-6 is still a Draft and this plugin still tracks it by PR, as 0.10.0 did.
+
+**Changed**
+
+- **`workplan-project` writes dependency edges.** Step 6's mutating-call table gains `gh issue edit <item> --add-blocked-by <blocker>`. QEP-6 §4 has required native edges for a real sequencing constraint since it was drafted and **no skill in this family wrote one** — every edge on the org's conformant trackers was made by hand after a review found them missing. The row carries the two platform facts a producer needs: one call per edge, since `gh` takes no list; and for a blocker in another repository `gh` refuses the flag, so the REST `dependencies/blocked_by` endpoint is used instead, whose body takes the blocker's numeric **id** rather than its number.
+- **A gate between packages is carried, not just described.** The cross-package guidance previously said a gate is *stated* once in the body of the package that waits. Under the amended §4 the gate is **carried as native edges** and only its rationale is stated — "prose is the one carrier no consumer reads" — with the phase-level form spelled out: the first item of the waiting phase is blocked by every item of the phase it waits on, which is linear in the upstream phase and clears when that *phase* closes rather than when the upstream tracker does. Where a phase's exit criterion is a single `Decision`, each waiting item carries the edge to the `Decision` instead. The same guidance now states the test §4 applies before any edge is written — **output, not order**: an item is blocked only by what it cannot start without, and two items that merely touch the same file or will be worked in sequence are plan order, not an edge.
+- **The sibling back-pointer is no longer an obligation.** §4's requirement that the waited-on project point back was struck: blocked-by and blocking are two ends of one edge, so the reverse direction is read rather than written. A `Related work` entry pointing at the rationale stays available prose.
+
+**Fixed**
+
+- **Two Adoption clause citations were off by one.** QEP-6's Adoption list read `1., 2., 2., 3., 4.` in source, and Markdown renumbers an ordered list on render — so the published document showed 1–5 while every citation after the first pointed one clause short. The read-before-link obligation is **clause 3**, not clause 2; the C2-precedence ruling this skill applies is **clause 4**, not clause 3. (0.10.0's release note below cites clause 3 for the precedence ruling; that is left as written, since it records what shipped.) The source numbering is corrected upstream and is now enforced by a CI check ([qeps#30](https://github.com/QuantEcon/qeps/pull/30)).
+- **QEP-2 is Accepted, and the audit context said it was a Draft.** `references/audit/quantecon-context.md` told an agent that doctrine rule 6 applied and to mark anything beyond the already-canonical labels *post-acceptance*. QEP-2 has been Accepted since it merged, so the whole set is canonical. The same passage now names `qep-0002-labels.yml` as the authority and records how the CLI tracks it: the appendix is vendored verbatim with a pin to the `qeps` revision it came from, and a weekly job compares the vendored *blob* against upstream — content rather than commit, so it fires when the schema moves and not when another QEP is edited. Verified on 2026-09-08: vendored, upstream and at-pin blobs are all `161cd746`, so the copy is current. An earlier plugin-era gap, where four labels were omitted from a hand-kept manifest, is what that vendoring closed.
+
 ## 0.10.0 — 2026-09-02
 
 `workplan-project` is brought into line with [QEP-6](https://github.com/QuantEcon/qeps/pull/18) (draft), the standard for project-tracker structure and order, following the six findings its field test ([qeps#19](https://github.com/QuantEcon/qeps/issues/19)) filed against the skill — [#69](https://github.com/QuantEcon/skills/issues/69) to [#74](https://github.com/QuantEcon/skills/issues/74), adopted into [#63](https://github.com/QuantEcon/skills/issues/63) as phase 1. The skill has still not run against a real bundle ([#65](https://github.com/QuantEcon/skills/issues/65)); this release changes what that run will produce. Where C2 and QEP-6 disagree the skill now says so and cites QEP-6's Adoption clause 3, which rules QEP-6 authoritative for structure until the contract's handover.

qe/references/audit/quantecon-context.md

@@ -18,7 +18,9 @@ If the repo's own type is ambiguous, say so once and audit it as the closest fam
 
 ## Labels: recommend, never apply
 
-The standard set is [QEP-2 (Draft, qeps#2)](https://github.com/QuantEcon/qeps/pull/2) — 19 core labels plus 2 lecture-extension labels — re-recording the settled decision in [meta#324](https://github.com/QuantEcon/meta/issues/324). Because QEP-2 is still a draft, doctrine rule 6 applies: recommend only already-canonical labels, mark anything else *post-acceptance*.
+The standard set is [QEP-2](https://github.com/QuantEcon/qeps/blob/main/qeps/qep-0002-standard-github-labels.md) — 19 core labels plus 2 lecture-extension labels — re-recording the settled decision in [meta#324](https://github.com/QuantEcon/meta/issues/324). It is **Accepted** (qeps#2, merged), so doctrine rule 6's draft caveat no longer applies: the whole set is canonical and may be recommended without a *post-acceptance* mark.
+
+The machine-readable set is [`qep-0002-labels.yml`](https://github.com/QuantEcon/qeps/blob/main/qeps/qep-0002-labels.yml) beside the QEP, kept in lockstep with its tables by CI, and **that file is the authority**. The `qe` CLI vendors it verbatim with a pin to the `qeps` revision it came from, and a weekly job compares the vendored blob against upstream — comparing content rather than the commit, so it fires when the schema moves and not when some other QEP is edited. So `qe gh labels check` speaks for the current standard rather than a hand-kept copy, and its verdict is the one to cite. (An earlier gap, where the plugin-era manifest omitted four labels that had to be created by hand, is what that vendoring closed.)
 
 Application is owned by the `qe` CLI, not by an audit:
 

qe/skills/workplan-project/SKILL.md

@@ -31,6 +31,7 @@ Steps 1–5 write only local draft files, next to the report. Step 6 acts on a t
 | `gh issue edit <parent-number> --add-sub-issue` | 6 | links each work item as a native sub-issue, in plan order |
 | `gh api …/issues/<parent-number>/sub_issues/priority` (PATCH) | 6 | re-runs only: moves a recovered item into its plan position |
 | `gh issue edit <parent-number> --type Project` | 6 | applies the native issue type to the tracking issue |
+| `gh issue edit <item> --add-blocked-by <blocker>` | 6 | records a real sequencing constraint as a native dependency (§4). One call per edge — `gh` takes no list. For a blocker in **another repository** `gh` refuses the flag outright; use `gh api --method POST repos/<o>/<r>/issues/<n>/dependencies/blocked_by`, whose body takes the blocker's numeric **id**, not its number |
 
 A filed issue can be closed but not unfiled, so **do not run step 6 headlessly** — the approval gate after step 5 is the safety model.
 
@@ -92,12 +93,12 @@ Write drafts into `<bundle>/workplan/`: `00-tracking.md`, then `NN-<slug>.md` pe
 
 - **Tracking issue**: Background (why now, with sources) → **`## Where we stand (verified <date>)`** → a findings/gaps table with severity → a **phase table** (`Phase | Intent | Exit criterion`) → **Gates** (which phase waits on what) and a sequencing paragraph (why this order, what can land immediately) → what does *not* need to change → sources, including the report bundle this package came from and the snapshot SHA. That heading is the project tracker contract's status stamp and its form is exact — see **The tracker contract** below. The phase table carries what the sub-issue list cannot — what each phase is for and when it is finished — and **never an `Issue` or `Status` column**: membership, order and state are the sub-issue list's, and a body that repeats them is the mirror [QEP-6 §7](https://github.com/QuantEcon/qeps/pull/18) forbids, one that can visibly disagree with the live list rendered on the same page. When step 3 left genuine unknowns, phase 0 is the phase that converts them into knowns, and the dependent items say they are gated on it.
 - **Plan order**: the draft file order *is* the plan order — `NN-<slug>.md` files numbered in the order the work should happen, each phase's items contiguous — because the sub-issue list is the plan under [QEP-6 §3](https://github.com/QuantEcon/qeps/pull/18): position is sequence, and the topmost open item is next. Step 6 files and links in that order and checks the result against it. The `NN-` prefix is a draft filename and nothing else — it never reaches an issue title, since §3 bans sequence tokens in titles and milestone names outright.
-- **More than one package**: when step 4 splits the survivors, each package's draft gets a `## Related work` section naming its siblings — one line each on how they relate, **projects only, never work items**, since an entry about a work item is the sub-issue list restated or dependency prose, both of which [QEP-6 §7](https://github.com/QuantEcon/qeps/pull/18) forbids. A gate between packages is stated **once**, in the body of the package that *waits*, at the granularity that is actually true — usually one phase waiting on one phase, not one project waiting on one project, which would park the whole project in any consumer that derives parked-ness from open blockers; the sibling's `Related work` entry points at where the gate is stated and does not restate it. Both sections are in Appendix A; they are named here because a producer fills the slots that exist and invents none.
+- **More than one package**: when step 4 splits the survivors, each package's draft gets a `## Related work` section naming its siblings — one line each on how they relate, **projects only, never work items**, since an entry about a work item is the sub-issue list restated or dependency prose, both of which [QEP-6 §7](https://github.com/QuantEcon/qeps/pull/18) forbids. A gate between packages is **carried as native dependency edges**, with only its *rationale* stated once, in the body of the package that *waits* — prose is the one carrier no consumer reads. An edge is written only where the downstream item cannot start without something the upstream produces — a ruling, a field, a document, a page it draws from; that two items touch the same file, or will be worked in sequence, is plan order, which is position and not an edge, and it goes under the body's sequencing rationale rather than its gates. State it at the granularity that is actually true: usually one phase waiting on one phase, not one project waiting on one project, since a tracker-to-tracker edge asserts that nothing in the downstream may start and parks it wholesale in any consumer deriving parked-ness from open blockers. [§4](https://github.com/QuantEcon/qeps/pull/18) gives the phase-level form — the **first item of the waiting phase is blocked by every item of the phase it waits on**, which is linear in the upstream phase rather than a cross-product and clears when that *phase* closes rather than when the upstream tracker does. Where a phase's exit criterion is a single `Decision` closing, each waiting item carries the edge to that `Decision` instead. The sibling's `Related work` entry *may* point at the rationale but is not obliged to: blocked-by and blocking are two ends of one edge, so the waited-on package needs no back-pointer to stay in step. Both sections are in Appendix A; they are named here because a producer fills the slots that exist and invents none.
 - **Sub-issues**: open with `Part of #<tracking> (Phase k).`, then the problem with its evidence as SHA-pinned permalinks, the proposed fix, and an **acceptance criteria** checklist. A finding the report left as a judgement call becomes a *decision* sub-issue — the question, the options, and the report's lean — never a silently chosen fix.
 - **A work item that is an existing issue** — landing PR #n, deciding issue #m, a finding the repo had already filed — is linked, not re-created, and linking is claiming: sub-issue membership is single-parent, so adding an issue here removes it from whatever tracker holds it now. Read its parent at draft time, `gh issue view <n> --repo <o>/<r> --json parent --jq '.parent.number // empty'`, and where that is non-empty the method note says so in terms the user can act on: *item #n is currently a work item of #p; adding it here removes it from #p.* The approval that follows then covers the detachment knowingly, or the item stays where it is and the package cites it instead.
 - **Labels per [QEP-2](https://github.com/QuantEcon/qeps/blob/main/qeps/qep-0002-standard-github-labels.md)**: exactly one type label per issue (`bug`/`enhancement`/`infrastructure`/`maintenance`/`discuss`…), priority labels only for the genuine outliers — there is deliberately no `medium-priority`, unlabelled *is* the middle. Check the labels exist in the target repo (`gh label list`); if not, flag that the repo hasn't adopted the QEP-2 set and propose only labels it has.
 - **The tracker contract**: what this skill produces *is* a project tracker — one issue, its direct sub-issues the work — so it is drafted to conform with [`docs/contracts/tracker.md`](https://github.com/QuantEcon/status-projects/blob/main/docs/contracts/tracker.md) (C2), which states the rules once and is not restated here. Three bear on the draft: the stamp heading above in its exact form; the work in **native sub-issues**, never body checkboxes, since checkbox progress publishes as `null`; and the native `Project` issue type, applied at step 6.
-- **The tracker structure**: [QEP-6](https://github.com/QuantEcon/qeps/pull/18) (draft) rules what the tracker body may and may not carry, and this skill follows it wherever it goes further than C2. The two disagree in one place worth knowing: C2 forbids nothing in the body beyond the stamp and never *reads* a plan table, so a roster of work items there is C2-conformant, while QEP-6 §7 forbids it. QEP-6's Adoption clause 3 rules that QEP-6 is authoritative for tracker structure until C2's planned handover to it; this skill applies that ruling rather than choosing between the two, and says so here so that a reader who checks the draft against C2 alone is not surprised.
+- **The tracker structure**: [QEP-6](https://github.com/QuantEcon/qeps/pull/18) (draft) rules what the tracker body may and may not carry, and this skill follows it wherever it goes further than C2. The two disagree in one place worth knowing: C2 forbids nothing in the body beyond the stamp and never *reads* a plan table, so a roster of work items there is C2-conformant, while QEP-6 §7 forbids it. QEP-6's Adoption clause 4 rules that QEP-6 is authoritative for tracker structure until C2's planned handover to it; this skill applies that ruling rather than choosing between the two, and says so here so that a reader who checks the draft against C2 alone is not surprised.
 - **[QEP-1](https://github.com/QuantEcon/qeps/blob/main/qeps/qep-0001-purpose-and-process.md) check**: if the package crosses repositories or changes how the whole team works, it may warrant a QEP rather than (or before) a pile of issues — say so instead of filing.
 - Every body will be GitHub-rendered, so the [rules for writing to GitHub](https://github.com/QuantEcon/skills/blob/main/AGENTS.md#writing-to-github) apply: one unbroken line per paragraph, no prose in fenced blocks, and never a closing keyword before an `owner/repo#N` reference.
 
@@ -136,7 +137,7 @@ When everything is filed, say plainly that the tracker is **not on the projects
 ## Gotchas
 
 - **The reprioritise call mixes two kinds of integer.** The parent in the path is an issue *number*; `sub_issue_id` and `after_id` in the body are database *ids*, ten-digit and unrelated to the numbers. Both are bare integers and the API cannot tell a transposition from a request, so read the ids from the `sub_issues` listing in the same breath as the call. This is the only place the skill needs a database id; linking takes numbers.
-- **Linking is claiming, and the theft is silent.** In the QEP-6 field test ([qeps#19](https://github.com/QuantEcon/qeps/issues/19), finding 1) ten items linked into a new tracker were detached from the org's QEP-2 rollout tracker by that act alone, leaving it with one closed child and a published 100%. No error, no warning, in a repository nobody was watching. One `--json parent` read per pre-existing item is the whole cost of not doing that; QEP-6 Adoption clause 2 makes it an obligation on conform tooling, and for the create path this skill is that tooling.
+- **Linking is claiming, and the theft is silent.** In the QEP-6 field test ([qeps#19](https://github.com/QuantEcon/qeps/issues/19), finding 1) ten items linked into a new tracker were detached from the org's QEP-2 rollout tracker by that act alone, leaving it with one closed child and a published 100%. No error, no warning, in a repository nobody was watching. One `--json parent` read per pre-existing item is the whole cost of not doing that; QEP-6 Adoption clause 3 makes it an obligation on conform tooling, and for the create path this skill is that tooling.
 - **The exemplar's quality bar is the target.** #926 carries benchmarks, a rewritten implementation, and pinned permalinks because the report behind it did; a sub-issue only ever restates *the report's* evidence and your step-3 verification — it does not decorate a thin finding into looking like a thick one.
 - **A package that wants more than ~15 sub-issues is a signal**, not an achievement — go back to step 4 and ask whether the survivors answer to one definition of done. Usually they answer to two, and the phase boundary turns out to be the membership boundary: an oversized package is most often a membership problem wearing a size costume. Split by definition of done, never by count. (GitHub's hard cap is 100 sub-issues per parent, but the readable limit is far lower.)
 - **Reports disagree with each other.** When two bundles cover the same item with different verdicts, the later snapshot wins, but say in the draft that an earlier report disagreed — the divergence is itself information.