decision: should madtea offer a user command to flag issue/PR references that do not resolve on the forge? #736

New issue

Open

opened 2026-10-07 16:16:02 +00:00 by hexajon · 0 comments

hexajon commented

2026-10-07 16:16:02 +00:00

Owner

Context

madtea's gate checks that its own shipped text does not carry issue or PR references that point at nothing. I am reworking that check to resolve each reference against the forge directly, which caught real stale references left over from a tracker migration. The check has two parts: a general core (given references and a forge, report the ones that do not resolve) and a madtea-specific scan of our own source strings, scripts, and generated docs.

The question

The general core has value beyond this repo. Any repo collects issue and PR references in issue bodies, pull request descriptions, comments, and docs, and some stop resolving over time. madtea already talks to the forge, so it could offer the same check to a user, pointed at their own repo.

Should madtea ship that as a user-facing capability, a CLI command plus an MCP tool, or keep the resolve-references logic internal to the gate?

Not decided

This is an open question, not a commitment. I have not decided to build it.

Scope to settle if the answer is yes

What content to scan: issue bodies, PR bodies, comments, release notes, in-repo docs.
The surface: a new command and MCP action, or an option on an existing one.
Output: a plain report naming each non-resolving reference and where it is.
The internal gate check would then reuse the shipped core instead of keeping its own copy.

The internal gate check does not depend on this; it stays dev-only regardless.

## Context madtea's gate checks that its own shipped text does not carry issue or PR references that point at nothing. I am reworking that check to resolve each reference against the forge directly, which caught real stale references left over from a tracker migration. The check has two parts: a general core (given references and a forge, report the ones that do not resolve) and a madtea-specific scan of our own source strings, scripts, and generated docs. ## The question The general core has value beyond this repo. Any repo collects issue and PR references in issue bodies, pull request descriptions, comments, and docs, and some stop resolving over time. madtea already talks to the forge, so it could offer the same check to a user, pointed at their own repo. Should madtea ship that as a user-facing capability, a CLI command plus an MCP tool, or keep the resolve-references logic internal to the gate? ## Not decided This is an open question, not a commitment. I have not decided to build it. ## Scope to settle if the answer is yes - What content to scan: issue bodies, PR bodies, comments, release notes, in-repo docs. - The surface: a new command and MCP action, or an option on an existing one. - Output: a plain report naming each non-resolving reference and where it is. - The internal gate check would then reuse the shipped core instead of keeping its own copy. The internal gate check does not depend on this; it stays dev-only regardless.

hexajon added the

enhancement

status/needs-decision

labels

2026-10-07 16:16:02 +00:00

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

sixfold-space/madtea#736

No description provided.

Rows
Columns