chore: note parked issues in the running-tend skill

[prql-bot]

Adds a "Parked issues" section to the repo's tend guidance, so a future CI run checks the PRs already filed against an issue — and why the closed ones were closed — before opening its own.

This is guidance only; it doesn't touch the compiler or take a position on the semantics under discussion in #6166.

Why

#6147 fixed the duplicate-module call site by merging the two blocks and was closed after review as "implicit merging of namespaces is a design smell". #6166 was then opened to track the behavior, and its first comment says explicitly that no fix PR was being opened, so a later triage pass wouldn't open a third. #6206 was opened anyway, taking the same merging approach, and was closed with:

This is @prql-bot's third repeat at this issue. #6166 specifically mentions that the open tracking issue was created to avoid opening further PRs.

Each CI session starts cold, so a note in a thread only works if the session reads the whole thread before deciding to act.

Follow-up commit: the first recipe didn't work

The section originally gated on gh pr list --state all --search "<issue-number>". Run against 6166 today, that returns #6212, #6206, #6164 and a stray chore: bump tokio — not #6147, the rejected attempt the section exists to catch. #6147 was opened 2026-08-06, two days before #6166 (2026-08-08), so it cites no issue number at all. The 2026-08-18 nightly (run 32109908394) ran that same search and got back only #6164, then concluded "No overlap" and opened #6206.

7b25396e replaces it with two checks that do fire on this case:

• Search by the symbol the fix touches. gh pr list --state all --search "fold_module_def_stmt" returns fix: merge repeated module definitions instead of replacing them #6147, fix: report duplicate import definitions as an error #6150, fix: make std.text and std.date reachable as types via _self #6151, fix: report duplicate declarations from enum definitions #6164 and fix: extend a re-opened module instead of discarding the earlier block #6206 — the whole history of that call site, issue numbers irrelevant.
• Read the issue's comment bodies, not the count. The same nightly projected COMMENTS: \(.comments|length), so the prior run's note on Duplicate module definitions silently discard the earlier declaration #6166 saying not to open another PR was never in its context — the section's own premise, defeated by a --jq field.

Both recipes were run against this repo before being written down.

Follow-up commit: reading a closed PR's own comments

Self-review pointed out that the gate turns on a classification neither check could reach: "closed on the approach rather than the code" isn't visible in gh pr list output. Running the symbol search against #6147 gives CLOSED #6147 fix: merge repeated module definitions instead of replacing them, which reads as an ordinary abandoned fix — the parking signal ("I've reviewed the code itself and it's fine; the behavior change is the part that I'm unsure about") is only in the PR's comments.

138ddee8 adds gh pr view <pr-number> --json comments,reviews to the first block, gives the parked entry a retirement criterion ("remove once #6166 closes or a maintainer asks for a fix"), and re-anchors its justification on kgutwin's direct ask rather than on "closed as premature", which was inaccurate for #6147. It also corrects the number-search claim, which omitted #6206.

[prql-bot]

Self-review, so this is a COMMENT rather than an approval. The section earns its place — it guards against a wrong outward action rather than saving compute — and both new recipes check out when run: the symbol search on fold_module_def_stmt does return #6147, #6206 and #6164, where searching 6166 misses #6147 entirely, and authorAssociation is a real field on gh issue view --json comments. The nightly claim is right too — run 32109908394's session log shows the exact projection TITLE / LABELS / COMMENTS: \(.comments|length) / BODY, so comment bodies genuinely never reached that run's context.

Three things left, all inline.

The classification the gate turns on has no recipe. "A PR closed on the approach rather than the code" is the whole decision, but neither block fetches a PR's closing comments — the first returns state/number/title, the second reads the issue thread. A session that runs both learns that #6147 exists and is closed, which is what the parked list already told it; the reason it was closed (reasoning rejected, code explicitly fine) is only in the PR's own comments.

Nothing retires a parked entry. Once #6166 is settled and closed, the bullet keeps reading as a standing instruction not to implement the decision that settled it.

"Both closed as premature" is the weaker justification, and slightly off for #6147. kgutwin asked directly on the thread that no further PRs be opened unless specifically directed (12:29Z, 2026-08-19) — a fact a cold session can act on without re-deriving it. And #6147 wasn't closed as premature: it was closed on the reasoning, with the code reviewed as fine ("I've reviewed the code itself and it's fine; the behavior change is the part that I'm unsure about").

Verification

Run against the merge ref, current head 7b25396e:

• gh pr list --state all --limit 20 --search "fold_module_def_stmt" --json number,title,state → #6212, #6164, #6206, #6150, #6147, #6151. Confirms the line 112 claim.
• gh pr list --state all --search "6166" --json number,title,state,closedAt → #6212, #6206, #6164, #3921. No #6147, as claimed — but #6206 is in the result, so line 110's list is incomplete; suggestion adds it.
• gh issue view 6166 --json comments --jq '.comments[] | "\(.author.login) (\(.authorAssociation)): \(.body)"' → runs clean, prints prql-bot (MEMBER), kgutwin (COLLABORATOR), prql-bot (MEMBER).
• gh run view 32109908394 → tend-nightly, schedule, 2026-08-18T07:06:49Z; its session-log artifact contains the COMMENTS: \(.comments|length) projection verbatim. #6206 was opened at 07:22:19Z that morning, sixteen minutes after that run started.
• All three suggestions were run through prettier@3.9.6 --prose-wrap always (matching .prettierrc.yaml) before posting, so they land pre-commit-clean.

[max-sixty]

erm, no, this is not a good design. we would not store a list of issues in the repo itself. we have access to the issues, we can search them anytime!

if there's a problem, and it's material, put an issue into tend

[max-sixty]

ok I made a note in #6166

[prql-bot]

Agreed, and filed in tend: max-sixty/tend#1013.

The diagnosis is that nightly's pre-PR dedup (gh pr list --state open --json number,title) can't see either artifact that said stop — #6147 was closed, and the "deliberately not opening a fix PR" note was in #6166's comments, not its title. It also matches on titles rather than on the code the fix touches, so searching 6166 misses #6147 entirely while searching fold_module_def_stmt returns all three PRs. That's a general fix to the dedup rather than a list anyone has to maintain.