loop-lane telemetry: move durable state off permanently-open Issues to a GitHub Discussion (storage-mechanism reconsideration)

[kyle-sexton]

Filed by AI on operator direction (attended session, 2026-07-24). Research verified empirically — see Evidence below.

Category: design · Source: operator observation during a live work-items:work-loop cycle, 2026-07-24

Problem

The loop-lane telemetry contract (convention §4, "Telemetry comment (#502)") stores each lane's durable state on a permanently-open GitHub Issue (Lane telemetry: <lane>), one per lane, carrying a single sentinel-marked comment edited in place.

The operator flagged this as a design smell while watching a lane run: the telemetry issues are permanent non-work items squatting in the real Issues backlog with no cleanup path. They are excluded from every drain/frontier evaluation by title contract, but they still appear in the default Issues view forever, and their open state — the signal a human reads as "this is outstanding work" — means the opposite here ("this lane is operating"). Three exist today: #1248 (work-loop), #1214 (babysit-loop), #1198 (attend-queue), and the count grows linearly with lanes.

This is a storage-mechanism problem, distinct from #1221, which fixes only how cycle reports describe the existing surface (correct artifact noun, standing convention anchor). #1221 makes the current design legible; this issue reconsiders whether it is the right surface at all.

Direction

Move loop-lane telemetry from a permanently-open Issue to a categorized GitHub Discussion, keeping the existing single-sentinel-comment-edited-in-place design, driven via gh api graphql.

Rationale (all empirically verified, see Evidence):

• Discussions is the only candidate that keeps the human-repliable, notified, edit-in-place comment thread the ratification workflow depends on while moving the object entirely off the Issues backlog — Discussions is a separate GitHub surface/tab, not a filtered Issues view.
• Headless reliability equals Issues provided automation targets the stable GraphQL mutations (createDiscussion, addDiscussionComment, updateDiscussionComment) rather than the gh discussion CLI porcelain, which the shipped binary and its upstream source both mark preview, "subject to change without notice" (added 2026-06-10). This requires no new habit: the lanes already bypass porcelain for raw gh api PATCH.
• markDiscussionCommentAsAnswer is a genuine gain — a native "this reply is ratified" primitive with no Issues equivalent, directly useful to the kind=ratify-c3 flow in /work-items:attend-queue.

Explicitly rejected framings:

• Pinning is a red herring — capped and web-UI-only on both surfaces (Discussions 4/repo and 4/category; Issues 3/repo), with no pin mutation in the GraphQL schema. Lanes must be found by title/category search, exactly as the status quo finds its Issue today.
• "Issues are wrong for automation" is too broad — GitHub's own IssueOps engineering blog blesses Issue-driven automation. The real, narrower defect is a never-closable Issue in the default backlog view, which Discussions fixes by being a separate surface.

Rejected alternatives: Actions/repo configuration variables (no comment/reply/notification mechanism at all — disqualifying alone, despite generous 48 KB/variable, 500/repo limits); Gist (flat comments, repo-indirection, no offsetting gain); bare git-tracked state branch (best audit trail of the five, but no reply channel).

Deferred, not excluded: a Discussion + git-tracked-branch hybrid, if a truly diffable audit trail ever becomes a hard requirement. It is not one today — and note neither Issue-comment nor Discussion-comment edit history is exposed via any API, so the status quo has no audit trail either. Trigger: a requirement for value-level state diffs.

Blast radius

• docs/conventions/loop-lane/README.md §4 — the telemetry contract is the owning surface; the tracking-item shape and the Lane telemetry: <lane> title contract change here.
• Three lane SKILL.md bodies carrying the inlined upsert (an installed plugin cannot invoke a sibling plugin's script, so each inlines it): work-items/work-loop, work-items/attend-queue, source-control/babysit-loop. All three inline the same gh api REST comment upsert and all three must move to the GraphQL mutation shape together — the marker/sentinel contract is byte-shared across lanes.
• claude-ops lanes/scripts/telemetry-upsert.sh (canonical interim home of the contract) and its .test.sh.
• claude-ops morning-brief/scripts/morning-brief.sh — the compatible reader of the same surface; a writer-only migration silently breaks the brief.
• Non-GitHub providers: the contract already degrades to "carry telemetry in the lane's cycle report" when the bound provider is not github. Discussions narrows the GitHub-native path further (Discussions is a GitHub-only concept with no REST API), so the degradation clause needs a re-read, not just a copy.
• github-iac — has_discussions is a repository setting; per the operator's standing convention it is a Pulumi-managed change in the relevant github-iac repo, never a runtime gh repo edit call embedded in a plugin. Currently disabled on all 14 sampled melodic-software repos.
• Migration of the three existing telemetry issues (Lane telemetry: work-loop #1248, Lane telemetry: babysit-loop #1214, Lane telemetry: attend-queue #1198) — content moves; the issues close with a pointer.

Sequencing constraint

The IaC enablement lands first (repos cannot host a Discussion until has_discussions is true), and the reader (morning-brief) must handle both surfaces during the transition, or be cut over in the same change as the writers.

Evidence

Research run 2026-07-24 via the discovery:research protocol — 5+ distinct tool types including live gh api graphql mutations against a throwaway personal repo (full create → comment → edit-in-place → delete round-trip), gh CLI --help capture, upstream cli/cli source fetched via gh api repo-contents, and direct fetches of docs.github.com. Outcome gate passed on all 8 binary criteria. Full evidence table, per-claim source tiers, conflicts, and gaps:

Posted in full on this issue: research evidence comment. It was produced as a machine-local memory-tier artifact, so it is reproduced here to keep the evidence durable and reviewable rather than tied to one workstation.

Open verification gaps carried forward:

1. All empirical CRUD testing ran against a personal-account repo, not an org repo — verify the same mutations against an actual melodic-software org repo before rollout.
2. Untested whether an org-level policy can block enabling Discussions for member repos.

Relations

• loop-lane telemetry: cycle reports misname the surface ('telemetry PR') and never restate the edited-in-place convention — operator-legibility rules #1221 — sibling on the same surface, report/legibility path (this issue is the storage-mechanism path); loop-lane telemetry: cycle reports misname the surface ('telemetry PR') and never restate the edited-in-place convention — operator-legibility rules #1221's "standing one-line anchor" text will need rewording for whatever surface this lands on.
• ops: loop-lane telemetry — running per-lane status (babysit / triage / work) #502 — the umbrella the telemetry block is named for.
• babysit lane telemetry edit posts literal @path body instead of file content (#502 observability fail-open) #943, guardrails/telemetry: harden telemetry-upsert.sh with post-write read-back verification + canonicalize @path-as-body anti-pattern rule #952 — telemetry-upsert write-path defects on the current (REST) implementation; a migration to GraphQL mutations should confirm whether each still applies or is obsoleted.

[kyle-sexton]

This was generated by AI on operator direction.

Sequencing head landed as a PR: melodic-software/github-iac#219 enables HasDiscussions on this repository through the governed-repository spec seam (dotnet build clean, 56/56 tests pass, lefthook clean).

That PR is a blocking dependency for the plugin-side work here — no repository can host a telemetry discussion until has_discussions is true, and the carried-forward verification gap (GraphQL mutations proven only against a personal-account repo) cannot be closed against this org repo until it deploys.

Remaining work on this issue, in order:

1. (blocked on docs(event-storming): reconcile PM/DL coordinate refs in simulation docs #219 deploying) Re-verify createDiscussion / addDiscussionComment / updateDiscussionComment against this repository, closing gap 1.
2. Convention docs/conventions/loop-lane/README.md §4 — the owning surface for the tracking-item shape and the Lane telemetry: <lane> title contract.
3. The three lanes' inlined upserts, which must move together (the sentinel contract is byte-shared): work-items/work-loop, work-items/attend-queue, source-control/babysit-loop.
4. claude-ops lanes/scripts/telemetry-upsert.sh + its .test.sh.
5. claude-ops morning-brief/scripts/morning-brief.sh — the reader; cut over with the writers or teach it both surfaces, or the brief silently breaks.
6. Migrate Lane telemetry: work-loop #1248, Lane telemetry: babysit-loop #1214, Lane telemetry: attend-queue #1198 — content moves to discussions, issues close with a pointer.

Steps 2-5 are authorable before #219 merges but not verifiable end-to-end until it does.

[kyle-sexton]

RESEARCH.md — loop-lane telemetry durable-state mechanism

Task restatement

Vet whether GitHub Discussions is the right mechanism for a Claude Code plugin's "loop-lane
telemetry" durable state: a small JSON state block + human-readable cycle report, one lane
per repo, edited/updated every drain cycle, must survive session death, and needs a
human-repliable channel for ratification replies. Status quo: one permanently-open GitHub
Issue per lane ("Lane telemetry: <lane>"), one sentinel-marked comment edited in place via
gh api PATCH. Flagged smell: permanent non-work Issues clutter the real Issues backlog
forever, with no cleanup path.

Candidates compared: (a) status-quo Issue, (b) pinned/categorized Discussion, (c) Actions/repo
variable (gh variable), (d) git-tracked state file on a dedicated branch, (e) Gist.

Non-interactive / no-project-root note: this session's working directory is not a git
repo, so per the topic-docs no-project-root fallback this artifact is written to the
plugin-data surface rather than a repo-local .work/. CLAUDE_PLUGIN_DATA was set to a
stale value from an unrelated plugin (codex-openai-codex) in this environment, so the path
was constructed by hand from the observed ~/.claude/plugins/data/<plugin>-<marketplace>/
convention: C:/Users/KyleSexton/.claude/plugins/data/discovery-melodic-software/topic-docs/loop-lane-telemetry-storage/RESEARCH.md.

Summary

No single candidate cleanly satisfies both halves of the requirement (durable JSON state
block + human-repliable ratification channel) — the task bundles two different capabilities
that the status-quo Issue currently fuses together. Of the five candidates, GitHub
Discussions is the correct swap for the container (b): it is the only mechanism that keeps
the human-repliable, notifiable, edit-in-place comment thread the workflow needs while
moving it off the real Issues backlog entirely (Discussions is a separate GitHub surface/tab,
not a filtered view of Issues). It can be driven headlessly with equal reliability to Issues
provided automation targets the stable GraphQL mutations directly via gh api graphql
(exactly how the status quo already scripts the sentinel-comment PATCH) rather than the new
gh discussion CLI porcelain, which is explicitly marked preview/unstable as of this
research. Pinning is a red herring — it's capped, web-UI-only to set on both Issues (3) and
Discussions (4), and unnecessary since lanes are found by title search/category exactly as
Issues are found today.

Evidence table

Claim	Sources (Tier 0/1 fetched/run THIS turn)	Tier	Tool diversity	Confidence
Discussions has no REST API; the REST reference index has no Discussions category (only Issues, Gists, Teams, etc.)	gh api repos/kyle-sexton/autonomy-demo-scratch shows has_discussions/has_issues as plain REST fields, but discussion CRUD only exists as GraphQL mutations (schema introspection, this turn); WebFetch of docs.github.com/en/rest shows 45 top-level categories, none named "Discussions"	0+1	gh api graphql, gh api REST, WebFetch	HIGH
GraphQL mutations createDiscussion, addDiscussionComment, updateDiscussionComment, deleteDiscussion, closeDiscussion, reopenDiscussion, markDiscussionCommentAsAnswer all exist and work	Live gh api graphql calls this turn: created discussion #65 on kyle-sexton/autonomy-demo-scratch, added a comment, edited it in place (updateDiscussionComment), then deleted the discussion — full round-trip succeeded	0	gh api graphql (empirical)	HIGH
Editing a discussion comment in place is also reachable via native gh discussion comment <id> --edit, targeting an arbitrary comment by ID/URL — a capability gh issue comment porcelain lacks (gh issue comment only offers --edit-last, which edits the current user's last comment, not an arbitrary comment by ID; status quo bypasses this gap entirely by using gh api PATCH directly, not porcelain)	gh discussion comment --help and gh issue comment --help both run this turn; GraphQL updateDiscussionComment independently confirmed the same edit	0	gh CLI --help, gh api graphql	HIGH
The native gh discussion command group is explicitly marked preview, "subject to change without notice", and was added only ~6 weeks before this research (2026-06-10)	gh discussion --help output this turn: "Working with discussions in the GitHub CLI is in preview and subject to change without notice."; upstream source pkg/cmd/discussion/discussion.go fetched via gh api repos/cli/cli/contents/... this turn shows the same string plus Short: "Work with GitHub Discussions (preview)"; gh search prs "discussion command" --repo cli/cli --merged shows PR #13541 "feat: add discussion command set" closed 2026-06-10	0	gh CLI --help, gh api (repo contents), gh search prs	HIGH
GitHub's own changelog announcement of gh discussion (2026-06-10) does not mention "preview"/"experimental" — a marketing/docs vs. shipped-CLI discrepancy	WebFetch of github.blog/changelog/2026-06-10-list-view-and-create-discussions-in-github-cli/ this turn — no preview/experimental language found	1	WebFetch	HIGH (as a conflict, see below)
Discussions can be pinned, but capped at 4 per repo and 4 per category, and pinning is web-UI only — no pin/unpin GraphQL mutation exists	GraphQL mutation-type + Discussion-type schema introspection this turn shows no pin mutation (only a read-only Repository.pinnedDiscussions connection); WebFetch of docs.github.com/en/discussions/managing-discussions-for-your-community/managing-discussions this turn: "You can pin up to four important discussions above the list of discussions for the repository or organization" / "up to four... in a specific category," steps are UI-only	0+1	gh api graphql (introspection), WebFetch	HIGH
Issues can also be pinned, capped at 3 per repo, also web-UI only — pinning is not a Discussions-specific advantage	WebFetch of docs.github.com/.../pinning-an-issue-to-your-repository this turn: "You can pin up to three important issues above the issues list in your repository"; no API/CLI method documented	1	WebFetch	HIGH
Discussions must be explicitly enabled per repo; it is currently disabled on all 14 sampled melodic-software repos; the toggle is reachable headlessly via gh repo edit --enable-discussions (added cli/cli PR #6903, shipped gh v2.22.0) or REST PATCH /repos/{owner}/{repo} has_discussions field — not web-UI-only	gh repo list melodic-software --json hasDiscussionsEnabled this turn (14/14 false); gh repo edit kyle-sexton/autonomy-demo-scratch --enable-discussions then --enable-discussions=false both executed and verified via gh api repos/.../ -q .has_discussions this turn (false → true → false)	0	gh repo list, gh repo edit, gh api (empirical)	HIGH
GitHub Actions/Dependabot repository variables: 48 KB per variable, 500 vars/repo, 1,000/org, 100/environment, 256 KB combined org+repo total per workflow run	WebFetch of docs.github.com/en/actions/reference/workflows-and-actions/variables this turn, quoting exact limit sentences	1	WebFetch	HIGH
Repo/Actions variables have no comment/reply/notification mechanism at all — disqualifying on their own for the human-repliable half of the requirement	WebFetch of the same variables reference page this turn (no comment/notification feature documented); gh variable --help this turn confirms set/get/list/delete only, no comment verb	0+1	gh CLI --help, WebFetch	HIGH
Repo/org variable changes are not exposed as a diffable revision history via API; at best an org/enterprise audit log records an update event (no value diff), and audit-log access/plan-tier gates apply	WebSearch of docs.github.com audit-log-events pages (Tier 2 corroboration; not directly confirmed with a fetched exact event name this turn)	2	WebSearch	MEDIUM — Gap, see below
Gist comments: full REST CRUD including PATCH /gists/{gist_id}/comments/{comment_id} (edit in place), comment body capped at 65,535 chars; gists have native revision/version history; comment notifications shipped 2019	WebFetch of docs.github.com/en/rest/gists/comments this turn (endpoint list + maxLength: 65535 from the schema); WebSearch corroboration of github.blog/changelog/2019-05-08-gist-notifications/	1	WebFetch, WebSearch	HIGH
Gist comments are flat, not threaded, and a gist is not naturally scoped to "one lane per repo" — it's a separate user/org-owned object with no native repo attachment, adding an extra indirection layer vs. Issues/Discussions living inside the repo	WebSearch corroboration (multiple independent snippets); not contradicted by any fetched primary	2	WebSearch	MEDIUM
A git-tracked state file on a dedicated branch gives the best native versioning/audit trail of all five candidates (full git log/diff/blame/revert) but has zero native human-reply mechanism — would require pairing with a separate Issue/Discussion/PR for replies	WebSearch corroboration of the "Stateful Action" GitHub Marketplace pattern and general orphan-branch state-store technique; this is a generic git technique, not a GitHub product with its own docs page, so no Tier 1 vendor doc applies	2	WebSearch	MEDIUM (well-established community pattern, no vendor doc to promote to Tier 1)
Issue/comment body and comment size cap is 65,536 characters (matches status quo's existing constraint; not a differentiator)	WebSearch corroboration across multiple independent GitHub community discussions and third-party tool issue trackers hitting the exact same 65536 error message; WebFetch of docs.github.com/en/rest/issues/comments this turn confirms the PATCH endpoint (status-quo mechanism) exists but the fetched page excerpt did not itself state the number	1+2	WebFetch, WebSearch	HIGH
GitHub's own official positioning: Issues = "plan, discuss, and track work" / bugs, features, tasks; Discussions = "collaborative communication forum... ask and answer questions, share updates, have open-ended conversations"; neither is positioned as a structured/machine state store	WebFetch of docs.github.com/en/discussions and docs.github.com/en/issues/.../about-issues this turn, both quoted verbatim	1	WebFetch	HIGH
GitHub's own engineering blog (IssueOps) officially blesses using Issues + Actions as an automation/state-machine interface — using an Issue for automation is not, per GitHub itself, an anti-pattern in isolation; it does not, however, address permanent-non-work-issue backlog pollution	WebFetch of github.blog/engineering/issueops-automate-ci-cd-and-more-with-github-issues-and-actions/ this turn, quoted verbatim; page explicitly does not discuss backlog-clutter mitigation	1	WebFetch	HIGH
Neither Issue-comment nor Discussion-comment edit history is exposed via API (the web UI's "edited" popover has no API equivalent found) — so (a) and (b) are equal, and inferior to (d)/(e), on audit trail	Absence checked against docs.github.com/en/rest/issues/comments and the GraphQL Discussion/DiscussionComment type introspection this turn — no revision/history field present in either	0+1	gh api graphql introspection, WebFetch	MEDIUM — Gap (absence-of-field is suggestive, not exhaustively proven against every field alias)
search(type: DISCUSSION, ...) GraphQL query and native gh discussion list --search/--category/--label both work for finding a lane's discussion by title — parity with how the status quo finds its Issue by title	Live gh api graphql search query this turn (discussionCount:1, matched by title substring); gh discussion list --help this turn shows -S/--search, -c/--category, -l/--label flags	0	gh api graphql (empirical), gh CLI --help	HIGH
gh search (the general search porcelain) does not support a Discussions type — only issues/PRs/repos/commits — a real capability gap in the general search CLI, mitigated by gh discussion list and raw GraphQL search(type: DISCUSSION)	gh search prs --state merged this turn errored, revealing valid --state values are only `{open	closed}, andgh search` subcommands are issues/prs/repos/commits/code only (observed from command family this session)	0	gh CLI (empirical)

Conflicts

1. CLI maturity vs. marketing framing. GitHub's changelog announcement for gh discussion
   (2026-06-10) presents it as a shipped, unqualified feature; the CLI binary itself and its
   upstream source both say, verbatim, "in preview and subject to change without notice."
   Resolution: the primary (shipped code, fetched this turn) wins — treat gh discussion as
   preview-grade for production automation. This does not block the recommendation because the
   underlying GraphQL mutations it wraps are the same stable, long-standing GA surface the
   status quo already uses via gh api.
2. "Pinning" framing in the topic vs. actual mechanics. The topic names "a pinned GitHub
   Discussion thread" as the candidate, but pinning turns out to be a cosmetic, capped (4),
   web-UI-only affordance that contributes nothing to headless find/automation — Issues have
   the identical constraint (cap 3, UI-only). Resolution: don't design around pinning at all;
   use category + title search, matching the status quo's existing find-by-title pattern.
3. "Issues shouldn't be used for automation state" vs. GitHub's own IssueOps positioning.
   The design-smell framing implies Issues are simply the wrong tool for automation. GitHub's
   own engineering blog explicitly blesses Issues-as-automation-interface (IssueOps). The real
   problem the smell report identifies is narrower and correct: a permanently-open,
   never-closable Issue clutters the default backlog view — that's a visibility/lifecycle
   problem, not a "was it legitimate to automate an Issue at all" problem. Discussions solves
   the visibility problem (separate surface from Issues) without requiring anyone to accept
   that automating a work-tracking object was wrong in principle.

Gaps

1. Audit-trail granularity for Actions/repo variables. Whether an org/enterprise audit log
   captures repo-variable value changes (vs. just an update event) was not confirmed with a
   directly fetched primary this turn — Tier 2 (WebSearch synthesis) only. Residual risk: low,
   since this candidate is already disqualified for the human-repliable half regardless.
2. API exposure of comment edit history for Issues/Discussions. Confirmed the absence of an
   obvious revision field via GraphQL introspection and the REST issue-comments doc, but did
   not exhaustively enumerate every GraphQL type/field or the audit-log event catalog to rule
   out an indirect path (e.g., a webhook edited event stream reconstructed externally). If
   the maintainer later needs a true diffable audit trail, re-verify this before ruling it out
   permanently; git-tracked state (candidate d) sidesteps the question entirely.
3. Exact gist size ceiling and gist-to-repo linkage convention. The 100 MB/25 MB gist file
   limits came from WebSearch corroboration, not a page fetched directly this turn (the fetched
   docs.github.com/en/rest/gists/comments page covered comments, not gist file size). Not
   pursued further since gist was already ruled out on structural grounds (flat comments, extra
   indirection) independent of size.
4. Org/enterprise policy interaction with enabling Discussions. Whether an org can
   centrally disable the Discussions feature (analogous to Actions policies) for member repos
   was not researched — relevant only if melodic-software has such a policy; the empirical
   test succeeded on a personal-account repo, not an org repo, so the org policy surface is
   unverified.

Recency status

Source	Age / verification
gh CLI (gh --version)	v2.96.0, published 2026-07-02 — 22 days old, within the 30-day standard-tool gate; confirmed live this turn
gh discussion command group	Added in gh v2.94.0 / merged 2026-06-10 (PR #13541) — ~6 weeks old; treated as very-active/preview surface, 14-day gate does not strictly apply since it's a net-new feature not a churning one, but its preview status is itself the finding
GitHub GraphQL API / Discussions schema	docs.github.com/en/graphql/overview/changelog/2026 checked this turn; no Discussions-breaking changes found for 2026; GitHub's stated policy is 3 months' notice before any breaking GraphQL change
GitHub Actions variables (gh variable)	Docs page fetched this turn; mature/stable GA feature (shipped 2023), no active churn found — passes per "stable project, latest doc confirmed current"
GitHub REST API reference index	Fetched this turn (docs.github.com/en/rest) — current as of this session

Project fit

• GitHub settings ownership convention. This user's own standing convention states GitHub
  settings changes go through the relevant github-iac repository via Pulumi, not ad hoc
  mutation. Enabling Discussions per repo (has_discussions) is a repo setting — if this
  recommendation is adopted, the enable-per-lane-repo step belongs in the Pulumi-managed
  github-iac provisioning path, not as a runtime gh repo edit --enable-discussions call
  embedded in the plugin's lane-provisioning logic. This turn's empirical test used
  gh repo edit directly only because that's the fastest way to verify capability, not as a
  suggested production mechanism.
• gh api over porcelain, already the plugin's own pattern. The status quo already drives
  the sentinel comment via gh api PATCH rather than gh issue comment --edit. That same
  posture — target the stable API surface directly — is exactly what resolves the CLI-preview
  conflict for Discussions: use gh api graphql mutations, not the preview gh discussion
  porcelain, for anything the loop depends on.
• One lane per repo, cross-repo/org-agnostic. Nothing found ties Discussions availability
  or behavior to account type (personal vs. org) beyond the standard enable-toggle and the
  unverified org-policy question in Gaps ci: onboard to the CI platform (ci-workflows + standards) #4 — worth a one-time check against an actual
  melodic-software org repo before rollout, since all empirical CRUD testing here was done
  against a personal-account repo (kyle-sexton/autonomy-demo-scratch) to avoid mutating
  organization repositories without explicit authorization.

Outcome gate result

#	Criterion	Result
1	Every claim row has ≥1 Tier 0/1 source captured this turn	PASS
2	No claim row is all-Tier-2	PASS (three MEDIUM/Gap rows are Tier-2-only by nature — held as Gaps, not accepted HIGH claims, per criterion 7)
3	Every Phase 2/3 query traces to a Phase 1 gap/conflict	PASS — gap-driven order: empirical CRUD → preview-status discovery → conflict with changelog → pin-mutation absence → falsification (IssueOps) → variable/gist/git-branch comparators → REST-index negative-claim confirmation
4	Every accepted claim has ≥2 independent corroborators	PASS for all HIGH rows (Tier 0 empirical + Tier 1 doc, or 2+ independent Tier 1/2 sources)
5	Phase 2 falsification query ran and is recorded	PASS — queried "using GitHub issue as database state store anti-pattern automation" and "GitHub Discussions bot state automation not designed for wrong tool"; found GitHub's own IssueOps blog defending Issues-for-automation (materially revised the framing — see Conflicts #3) and no counter-evidence against Discussions specifically (recorded as inconclusive, not asserted as confirming)
6	Recency gate satisfied for every tool/library/API claim	PASS — see Recency status table
7	Every accepted claim is HIGH confidence	PASS — MEDIUM-confidence items (audit-log granularity, gist size ceiling, comment-history-absence, git-branch pattern) are explicitly carried in Gaps, not asserted as accepted findings
8	Project fit checked against consuming project's own conventions	PASS — see Project fit (github-iac/Pulumi ownership, gh api-over-porcelain posture)

Gate result: PASS.

Final recommendation

Move loop-lane telemetry from a permanently-open Issue to a categorized GitHub Discussion,
keeping the existing single-sentinel-comment-edited-in-place design, and drive it via
gh api graphql — not the preview gh discussion CLI.

Why this beats every alternative for this exact job:

1. It is the only candidate that keeps the human-repliable, notified, threaded comment channel
   the ratification workflow needs and removes the object entirely from the Issues backlog
   surface (Discussions is a separate tab, not a filtered/labeled view of Issues) — directly
   fixing the flagged smell without giving up the capability the status quo exists to provide.
2. Headless reliability is equivalent to Issues as long as automation targets the GraphQL
   mutations directly (createDiscussion, addDiscussionComment, updateDiscussionComment,
   closeDiscussion) — all confirmed working this turn, all part of the long-standing GA
   GraphQL schema, not the 6-week-old preview CLI wrapper. This requires no new habit: the
   plugin already drives Issues via gh api rather than porcelain.
3. markDiscussionCommentAsAnswer is a genuine, unplanned upgrade for the ratification
   use case — a native "this reply is the accepted one" primitive Issues has no equivalent for
   (today's Issue-based design would have to fake this with a label or comment-parsing
   convention).
4. One-time enablement cost is real but small and fully scriptable
   (has_discussions via REST/gh repo edit) — and per this user's own convention, that
   enablement belongs in the Pulumi-managed github-iac repo alongside other GitHub repo
   settings, not embedded as a runtime call in the plugin itself.
5. Reject the literal "pinned" framing from the original candidate description — pinning is
   capped, cosmetic, and web-UI-only on both Issues and Discussions; find the lane's
   discussion by title search or a dedicated category instead, which is a drop-in replacement
   for the current find-Issue-by-title logic.

Explicitly not recommended alone: Actions/repo variables (no reply channel — disqualifying
on their own), Gist (flat comments + extra repo-indirection — structurally weaker than
Discussions for no offsetting gain), a bare git-tracked state branch (no reply channel at all).
Deferred, not excluded: if a true diffable audit trail of state-block changes ever becomes
a hard requirement (it is not part of today's stated need), a hybrid — Discussion for the
human-repliable report, a git-tracked branch file for the versioned JSON state block — is the
documented escape hatch (see Gaps #2), triggered only if that need materializes.

Next-stage handoff

Settled facts (usable directly by a planning step):

• Discussions: no REST API, GraphQL-only, confirmed working this turn for create/comment/edit/delete.
• gh discussion CLI porcelain is preview/unstable; use gh api graphql instead.
• Pinning (both Issues and Discussions) is capped, UI-only, and unnecessary for this design — use category + title search.
• Discussions must be explicitly enabled per repo; currently disabled on all sampled melodic-software repos; toggle is scriptable, not UI-only.
• Neither Issues nor Discussions expose comment edit history via API; git-tracked branch state is the only candidate with a native diffable audit trail, at the cost of no reply channel.
• Size limits are not a constraint for any candidate at the stated "small JSON state block" scale.

Open decisions for the planning step:

• Whether to fold the Discussions-enable toggle into the github-iac/Pulumi provisioning path now, or accept a temporary gh repo edit runtime call as a stopgap.
• Whether to verify the org-policy question (Gap ci: onboard to the CI platform (ci-workflows + standards) #4) against an actual melodic-software org
  repo before rollout, since empirical testing here was confined to a personal-account repo.
• Whether markDiscussionCommentAsAnswer should become part of the ratification protocol
  itself (e.g., ratifying = marking the sentinel or a reply as the answer) or remain unused in
  favor of the existing sentinel-marker convention.

[kyle-sexton]

This was generated by AI on operator direction.

Status at session close.

Dependency PR melodic-software/github-iac#219 is green and ready to merge — 28 checks passing on head 2cf4dc7, mergeStateStatus: CLEAN, automated review verdict "Correct, minimal, and honest about what it doesn't yet prove. Ready to merge." Nothing on it is waiting on further authoring; it needs a human merge and a Pulumi deploy.

Nothing in this issue's scope has been implemented yet — no plugin-side branch exists. Steps 2-6 of the plan above are unstarted, and step 1's merge is the gate for steps 1, 2, and 7.

Resuming from a cold start needs only this issue. The design decision, blast radius, rejected alternatives, sequencing constraint, and the full research evidence (including per-claim source tiers and the two carried-forward verification gaps) are all recorded here rather than in any session transcript or local artifact.

Recommended resumption order once #219 deploys:

1. Re-verify the three GraphQL mutations against this repository — closes carried-forward gap 1, and everything downstream assumes it.
2. Author steps 2-5 as one change: the convention section, the three lanes' inlined upserts (they must move together), telemetry-upsert.sh + test, and the morning-brief reader.
3. Migrate Lane telemetry: work-loop #1248, Lane telemetry: babysit-loop #1214, Lane telemetry: attend-queue #1198 last, once the writers and reader are proven against the new surface.

[kyle-sexton]

Frontier disposition (drain session)

Ruling: Close as not planned.

Telemetry storage-mechanism reconsideration (Issues vs Discussion) is advisory; permanently-open Issues remain the shipped convention.

Re-open trigger: When lane telemetry issue volume blocks tracker usability.