QEP-6 field test: follow-up actions needing a gh-equipped environment

[quantecon-services]

Follow-up actions for the QEP-6 field report (#19).

Original items 1–4 are all closed. Results are recorded on #19 (part 1, part 2, item 4 rationale). Item numbering below is preserved so those reports keep referring to the same things.

Correction, 2026-08-27: an earlier revision of this body re-listed items 1–4 as outstanding. That was wrong — they had already been executed. Restored, with the completed status recorded and only genuinely open work below.

---

Closed

1. Dependency edges — done. All four written on QuantEcon/cli and confirmed via blockedBy read-back: 3 ← 2, 4 ← 3, 10 ← 9, 6 ← 12. --add-blocked-by accepted plain issue numbers; the database-id fallback was not needed. The prose "Constraints" paragraph is deleted from the cli#20 body, leaving the edges as sole authority.

Worth recording for amendment 9: 3 ← 2 and 4 ← 3 are edges between items that the membership review later moved out of cli#20. They remain valid and useful. Dependency edges are independent of project membership — this is now demonstrated live, not merely argued.

2. Ordering cross-check — closed on all three surfaces. REST, GraphQL and the rendered UI returned identical order. List position is an unambiguous order carrier; finding 3 stays closed. (Verified against the pre-review 18-item list; the tracker is now 14 items after the membership review, which does not affect the result.)

3. Markdown template type: — works. An issue opened through the web template chooser arrived with issueType: Project and the Appendix A skeleton verbatim, ## Where we stand (verified YYYY-MM-DD) intact at H2. The recommendation of markdown templates over issue forms stands. Caveat: non-interactive gh issue create never applies a template, so scripted creation needs explicit --type plus a read-back.

4. Low-permission type: drop — closed as won't-test. Both possible outcomes lead to the same action, since the read-back is already mandated on two independent grounds.

---

Open

5. ⚠️ Verify a dependency edge between two tracker issues — gates amendment 10

Amendment 10 rests on this and it is untested. The claim: because dependencies are independent of the parent hierarchy, an edge between two tracker issues expresses "project B waits on project A" natively, in one edge — which is why a project-level gate should not be body prose the way a phase-level gate must be.

Item 1 above established that edges work between ordinary issues, and that they survive a membership change. What is not established is the tracker-to-tracker case specifically: both ends carrying the Project issue type and having sub-issues of their own.

Check that the edge is accepted, that --json blockedBy reads it back, and that the UI renders it as a blocker rather than silently ignoring it:

gh issue edit <trackerB> --repo <owner/repo> --add-blocked-by <trackerA>
gh issue view <trackerB> --repo <owner/repo> --json number,blockedBy

If it fails, the project-level half of amendment 10 collapses back to body prose and the amendment needs rewriting before it reaches the draft. Status 2026-08-27: a second tracker now exists in QuantEcon/cli (QuantEcon/cli#24, promoted from an existing strategy issue), and the natural occasion for a tracker-to-tracker edge arrived — but the real constraint between the two projects turned out to be phase-level, not project-level, so the edge was correctly not written and the real case declined to appear. This item therefore still needs a throwaway pair, and it is less urgent than when filed: it gates the project-level half of amendment 10 §1, which is now the half nothing has needed. Full analysis in the reopening comment.

6. Two amendment edits awaiting a call

Flagged in the item-4 rationale and not yet made:

• Amendment 8 gains the read-back mandate — the assertion must read the issue itself (gh issue view N --json issueType) rather than validate against GET /orgs/{org}/issue-types, which returns 403 Resource not accessible by integration for app identities even where the repo-scoped read succeeds.
• The field report's "untyped = untriaged" line is the one claim that leaned on item 4. Recommend dropping it as a load-bearing justification for type-over-label rather than testing it — that choice stands on native, structured, org-wide types versus repo-local labels.

---

Wider caveat

Most gh capability claims in #19 remain source-derived, not executed — read from cli/cli at pinned release tags and OpenAPI 1.1.4. What has been verified live: the reorder read-back, the not_planned progress inflation, the membership review's effect on the tracker, and items 1–3 above. Item 5 is the last structural claim still resting on inference.

[mmcky]

Executed 2026-08-27; results recorded on #19 (#19 (comment)). Item 1 done except deleting the tracker-body paragraph (permission-blocked in that session); item 2 settled on REST+GraphQL, one UI glance remains; item 3 fixture ready at QuantEcon/qep6-template-test, UI chooser submission remains; item 4 impractical — read-back assertion recommended for amendment 8.

[mmcky]

Status 2026-08-27, part 2 (details in #19 (comment)): items 1–3 are complete — edges written and prose paragraph deleted; ordering confirmed identical on REST, GraphQL, and the rendered UI; markdown template type: Project applied by the UI chooser with body verbatim. Item 4 is in flight as a low-permission run (quantecon-services) in a separate session; this issue stays open until that result lands on #19, after which the throwaway repo QuantEcon/qep6-template-test is deleted and this closes.

[quantecon-services]

Item 4 — closed as won't-test

Item 4 asks whether a markdown template's type: key is silently dropped for openers without push access. Closing it unrun: both possible answers lead to the same action, so the result cannot change anything downstream of it.

The read-back mandate it was meant to inform is already settled on two independent grounds, neither of which item 4 can disturb:

1. Non-interactive gh issue create never applies a template at all (part 1, finding (a)) — so scripted tracker creation must pass --type explicitly and confirm it landed, whatever the template key does for humans.
2. REST documents type as silently dropped without push access — a silent failure is exactly what a post-creation read-back catches.

Hypothetical read-back	Amendment 8 text	Read-back mandate
Project	unchanged	still required (ground 1)
null	unchanged	still required (grounds 1 + 2)

The API-only fallback in this issue's item 4 is worth less still: it probes the REST type parameter, whose low-permission behaviour GitHub already documents, not the template key, which is the undocumented part. Only the browser path carried new information, and it needed a second logged-in identity.

The one claim that depended on it

The field report justifies choosing the issue type over a label partly on "untyped = untriaged" being reliable — which blurs if outside contributors' trackers arrive untyped. Two things defuse this:

• The realistic population of project-tracker openers is maintainers and automation. An outside read-only contributor opening a programme tracker is close to an empty category.
• With the read-back mandated, a tracker that arrives untyped is caught and corrected at creation regardless of who opened it. The failing branch is already handled by the rule that holds either way.

Recommendation: drop "untyped = untriaged" as a load-bearing justification for type-over-label. That choice stands on firmer ground anyway — types are native, structured, and org-wide, where labels are repo-local and unenforceable.

Proposed text for amendment 8

Add to the template clause:

Creation is never trusted to carry the type. After creating a tracker, assert it by read-back (gh issue view N --json issueType) and set it explicitly if absent: non-interactive gh issue create does not apply templates at all, and the REST type parameter is silently dropped for callers without push access. Both fail silently, so the type is confirmed after creation rather than assumed from the template.

Implementation note. Assert against the issue itself, not against an org type enumeration. Observed under the Claude GitHub App identity: GET /repos/{owner}/{repo}/issue-types succeeds while GET /orgs/{org}/issue-types returns 403 Resource not accessible by integration. Tooling that validates a type name against the org endpoint before writing will fail for app and low-permission identities even where the repo-scoped read works.

Consequences

• Items 1–3 are complete; item 4 is closed unrun. This issue closes.
• QuantEcon/qep6-template-test has been deleted (2026-08-27). The fixture is gone, so the optional browser check is no longer available — reviving item 4 would mean rebuilding the fixture from scratch.
• For the record: the probe citations in the part 1 and part 2 comments on #19 (qep6-template-test#1 and #2) now resolve to a deleted repository. Item 3's result stands on the prose record in those comments; the primary artefacts are not recoverable.

---

Generated by Claude Code

[mmcky]

All four items disposed: 1–3 complete with results recorded on #19; item 4 closed as won't-test (both outcomes lead to the same read-back mandate, per the comment above). Throwaway repo QuantEcon/qep6-template-test deleted. Nothing pending — closing.

[quantecon-services]

Item 5 — still open, and the natural occasion did not arise

Reopening this issue. It was closed at 00:25 when items 1–4 completed; items 5 and 6 were added to the body afterwards, at 00:54 and 00:58, without reopening. A closed issue carrying open work is exactly the freshness failure QEP-6's stamp exists to prevent — recorded here as a small field observation, since it happened to the field test's own tracking.

Status change on item 5

QuantEcon/cli now has the second tracker this item said did not exist: #24, test infrastructure for production readiness, promoted from an existing strategy issue. The natural occasion to write a tracker-to-tracker edge had arrived.

It did not produce one. The constraint between the two projects is phase-level, not project-level — #20's Safe migration phase waits on #24's offline phase, while #20's One source of truth proceeds in parallel and #24's own integration phase is gated on something else entirely. Writing #20 blocked-by #24 would have asserted something false and parked #20 wholesale in any consumer deriving parked-ness from open blockers. So the edge was correctly not written, and item 5 remains untested.

Full analysis in the two-project field results. Two consequences for this item:

1. It stays open, and still needs a throwaway pair rather than a real case — the real case declined to appear.
2. It is less urgent than when filed. Item 5 gates the project-level half of amendment 10 §1, and that half is now the one nothing has needed. If the edge turns out not to work, what collapses is a rule with no known instance. The phase-level half — which is what practice actually wants — rests on body prose and needs no verification.

Item 6 is unchanged and still awaiting a call.

---

Generated by Claude Code

[mmcky]

Item 5 — verified (2026-08-27), and item 6 applied; nothing remains open

Item 5: the tracker-to-tracker dependency edge works. Tested on a throwaway pair (mmcky/qep6-edge-test): two tracker issues, each carrying a native sub-issue, edge written with gh issue edit 3 --add-blocked-by 1. Results:

• Edge accepted between two parent (sub-issue-carrying) issues; both trackers' sub_issues_summary unaffected.
• Read-back confirmed on both API surfaces: gh issue view 3 --json blockedBy returns tracker A; GraphQL blockedBy on B and blocking on A both return the edge (the GraphQL field is blockedBy, not blockedByIssues).
• UI: the server-rendered page carries the BlockedByAddedEvent timeline event, so the relationship is not silently ignored; the blocked-by panel itself is client-rendered, so one human glance at https://github.com/mmcky/qep6-edge-test/issues/3 fully closes that half.

One caveat, recorded rather than hidden: org repo creation was unavailable to the session, so the probe ran in a personal repo where org issue types do not exist — both ends carried sub-issues but not the Project type. The structural half (edges between parents) was the plausible failure surface and is confirmed; the type is org metadata with no known interaction with dependency edges. Amendment 10 §1's project-level half keeps must in the draft on this basis.

Bonus verification while the fixture existed: amendment 2 upgraded from source-derived to executed — gh issue list --milestone "2026" fails with no milestone found with number '2026' while --milestone "Phase 1 — Foundations" resolves correctly.

Item 6: both edits applied to #18 in commit 1a0f063 — amendment 8 carries the read-back mandate (assert issueType on the issue itself, not the org enumeration), and "untyped = untriaged" is dropped from §1 as a load-bearing justification.

Cleanup: the fixture repo mmcky/qep6-edge-test awaits deletion (session token lacks delete_repo) — glance at issue 3's blocked-by panel first, then delete.

Both remaining items disposed — closing.

[mmcky]

Item 5's remaining UI half is confirmed by direct inspection (2026-08-27): on the probe pair, the blocked-by edge rendered as the header chip ("Blocked by: Tracker A"), as a Relationships sidebar entry ("Blocked by 1"), and as the "marked this as blocked" timeline event. The edge is verified on all three surfaces — REST, GraphQL, and the rendered UI. The fixture repo mmcky/qep6-edge-test has been deleted, so as with the earlier template probes, the prose record here is the surviving artefact.