feat: upsert act-board issues and blocker sub-issues

[WilcoFiers]

Summary

• Implements act-tools#63: generate deterministic act-board issue bodies and upsert one issue per rule by [ruleId].
• Closes deprecated/removed rule issues; skips GitHub writes when title, body, and state already match.
• Links open Community Group Blocker issues as cross-repo sub-issues (addSubIssue / removeSubIssue), attaching a shared blocker under the lowest matching rule id only while still listing it in every matching body.

Test plan

• yarn test (includes mocked act-board upsert tests)
• Optional live dry-run: yarn approval-report then GITHUB_TOKEN=... yarn upsert-act-board --input approval-report.json against act-rules/act-board

Made with Cursor

[WilcoFiers]

PR Review: #70 — feat: upsert act-board issues and blocker sub-issues

Author: WilcoFiers | Base: main ← issue-63-act-board-upsert | Changes: +964 / -1

Summary

This PR adds upsertActBoardIssues plus a CLI to create/update one act-rules/act-board issue per classifier row, keyed by [ruleId], with a generated-by-bot body, close-on-deprecated/removed, write-skipping when title/body/state already match, and cross-repo Blocker sub-issues attached only under the lowest matching rule id. That matches issue #63 (project field sync correctly left out). One Important defect: every generated body links a Community Group rule file path that does not exist in act-rules.github.io.

Findings

• Critical: 0
• Important: 1
• Suggestions: 4

Finding 1 of 5 — Important

src/approval-report/act-board.ts:109
Issue: Community Group rule file links are built as _rules/${row.ruleId}.md (for example _rules/674b10.md). Real files are slug-ruleId.md (for example _rules/role-attribute-valid-value-674b10.md), so every upserted issue will contain a 404. RuleApprovalRow does not currently carry filename, so this cannot be derived from the snapshot as written. The new test asserts the broken URL, so the gap is locked in.
Suggestion: Persist the rule filename on the classifier row (it is already available as rule.filename in buildRuleApprovalRows) and use _rules/${filename} in the body. Until that field exists, link a working CG surface such as https://act-rules.github.io/rules/${row.ruleId} or a GitHub search for path:_rules + the rule id, and update the rendering test to match a real _rules/*-{ruleId}.md path.

Finding 2 of 5 — Suggestions

src/approval-report/act-board.ts:356
Issue: Issue titles and commit subjects are interpolated raw into Markdown links/list items. generate-report.ts already escapes comparable fields. A title containing ]( (or a subject with unescaped Markdown) can break or hijack the rendered link in the generated body.
Suggestion: Collapse whitespace and escape ], [, and ) in link text (and treat html_url / commit URLs as data, not Markdown). Mirror the caution already used in the approval-report markdown renderer.

Finding 3 of 5 — Suggestions

src/approval-report/act-board.ts:215
Issue: No-op detection uses exact (issue.body ?? "") !== body. The renderer always ends with a trailing \n. If GitHub returns a trimmed body or \r\n line endings, every run will PATCH bodies even when content is unchanged, which weakens the “skip writes when nothing changed” acceptance criterion.
Suggestion: Compare a normalized form of both strings (for example unify \r\n to \n and trimEnd) before deciding to send update.body.

Finding 4 of 5 — Suggestions

src/approval-report/act-board.ts:218
Issue: skipped is incremented when title/body/state are unchanged, before sub-issue add/remove. A run that only moves blockers can report skipped: 1 together with subIssuesAdded / subIssuesRemoved, which makes the CLI summary misleading (the issue row was not a full no-op).
Suggestion: Count skip only after the sub-issue set is known to match, or use a separate counter so “issue fields unchanged” is not confused with “no GitHub writes.”

Finding 5 of 5 — Suggestions

src/approval-report/act-board.ts:177-L181
Issue: If two board issues share the same [ruleId] prefix, only the lowest issue number is managed. Extra duplicates are not updated, not closed, and not included in sub-issue sync. The bot will not create that situation, but a human-created duplicate (including a closed low-number issue plus a live high-number one) will be handled incorrectly: the closed original can be reopened while the live duplicate is ignored.
Suggestion: When the same prefix maps to multiple issues, treat extras as unmanaged duplicates to close (or log loudly), and prefer an already-open match over a closed lower number.

Recommended Action: Request Changes

Issue #63 behavior is otherwise in good shape (prefix upsert, disclaimer, close deprecated/removed, mocked skip/close/sub-issue tests, lowest-id parent with body listing on every match, no project fields). The Important 404 on every Community Group rule-file link should be fixed before merge; the rest can land as follow-ups.