The watcher reads WATCHER_STATE_FILE / upstream-version.txt but never updates either after dispatching. As a result, once upstream advances past LAST_SEEN, this cron job will keep dispatching the analyzer every 15 minutes (and repeatedly attempt to open duplicate issues/PRs), potentially burning the model budget. Persist the new LATEST value (e.g., write it to ${WATCHER_STATE_FILE} and commit/push it, or store it in a repo/environment variable) after a successful dispatch so subsequent runs can short-circuit.

This workflow always attempts to open draft PRs, even when push_branches is false (dry-run). In that case the batch branches won't exist on origin, so PR creation will fail noisily. Consider guarding the PR-opening step with an if: on steps.inputs.outputs.push_branches == 'true' (and optionally steps.analyze.outputs.has_commits == 'true') to keep dry-runs clean.

buildIssueLabels only replaces the first underscore in the recommendation string. For HOLD_FOR_HUMAN this produces upstream:hold-for_human (still contains an underscore) instead of upstream:hold-for-human, which will prevent expected label matching/creation. Use a global replacement (e.g., replaceAll / regex) so all underscores become dashes.

🔴 replace("_", "-") only replaces the first underscore, producing malformed label for HOLD_FOR_HUMAN

String.replace with a string (non-regex) argument only replaces the first occurrence. For the HOLD_FOR_HUMAN recommendation, "hold_for_human".replace("_", "-") produces "hold-for_human" instead of the intended "hold-for-human". This creates an inconsistent GitHub label upstream:hold-for_human.

Confirmed by running: node -e "console.log('HOLD_FOR_HUMAN'.toLowerCase().replace('_', '-'))" → hold-for_human.

Was this helpful? React with 👍 or 👎 to provide feedback.

🔴 Upstream tag watcher never persists seen-tag state, causing infinite repeated analyzer dispatches

The watcher reads LAST_SEEN from .upstream-watcher-seen-tag or upstream-version.txt (line 62-70), but after dispatching the analyzer it never writes the newly-detected tag back to either file. The old sync-upstream.yml (now disabled) was the only workflow that updated upstream-version.txt. Since the new analyzer pipeline also doesn't update it, every 15-minute cron run will re-detect the same upstream tag ($LATEST != $LAST_SEEN remains true) and fire another upstream-tag-detected dispatch. The analyzer's concurrency group limits parallel runs per to_tag, but completed runs will be followed by queued duplicates indefinitely — creating duplicate issues and draft PRs.

The upstream-tag-watcher.yml workflow detects new upstream tags and dispatches the analyzer, but it never persists the detected tag. After dispatching at line 121, the workflow should write the new tag to a state file so subsequent cron runs see that this tag was already dispatched.

Two possible approaches:
1. Commit the tag to upstream-version.txt or .upstream-watcher-seen-tag and push (requires contents: write permission, already only has contents: read).
2. Use GitHub Actions cache to persist the last-seen tag between runs (avoids needing write access to the repo).

The simplest fix would be to add a step after 'Fire repository_dispatch' that writes the LATEST tag to .upstream-watcher-seen-tag, commits it, and pushes to dev. This would also require changing permissions.contents from 'read' to 'write'.

Was this helpful? React with 👍 or 👎 to provide feedback.

🔴 Em dash (U+2014) in generated content violates AGENTS.md anti-pattern rule

AGENTS.md explicitly states: "Never use em dashes, en dashes, or AI filler phrases in generated content". The renderCommitLines function uses an em dash (—, U+2014) as a separator in generated issue body content. Should use -- or - instead.

Was this helpful? React with 👍 or 👎 to provide feedback.

🔴 Em dash (U+2014) in generated verification content violates AGENTS.md anti-pattern rule

AGENTS.md explicitly states: "Never use em dashes, en dashes, or AI filler phrases in generated content". The renderVerifications function uses an em dash (—, U+2014) as a separator in generated issue body content.

Was this helpful? React with 👍 or 👎 to provide feedback.

🔴 Em dash (U+2014) in generated footer content violates AGENTS.md anti-pattern rule

AGENTS.md explicitly states: "Never use em dashes, en dashes, or AI filler phrases in generated content". The buildFooter function uses an em dash (—, U+2014) in the generated issue footer text: "This issue is advisory — no merges...".

Was this helpful? React with 👍 or 👎 to provide feedback.

📝 Info: GitHub Actions heredoc delimiters could theoretically collide with content

In run.ts:60-62, the emitGithubOutputs function uses fixed heredoc delimiters (EOF_TITLE, EOF_LABELS, EOF_SPECS) for multi-line GitHub Actions outputs. If artifacts.issueTitle ever contained the literal string EOF_TITLE on its own line, the heredoc would terminate prematurely and corrupt the output. In practice, the issue title is built from tag names and recommendation enums (issue-report.ts:168), making this collision astronomically unlikely. Not a bug, but worth noting if the title format ever changes to include user-controlled content.

Was this helpful? React with 👍 or 👎 to provide feedback.

📝 Info: Commit subject parsing could break on tab characters in git log output

In git-inspector.ts:26, line.split("\t") splits on tab characters, but the %s format specifier (commit subject) could theoretically contain tabs. If it did, the destructuring would misalign author and date. In practice, git commit subjects almost never contain tab characters (and many tools strip them), so this is not a practical concern for upstream commit analysis.

Was this helpful? React with 👍 or 👎 to provide feedback.

📝 Info: Fallback chain correctly re-throws non-recoverable errors

Examined the inferJsonWithFallback logic carefully (github-models-client.ts:136-154). The fallback loop only continues to the next model when shouldFallback(err) returns true (quota or context-length errors). For all other errors (network failures, auth errors, 500s), it correctly re-throws immediately at line 149 (if (isLast || !shouldFallback(err)) throw err). The lastError variable at line 154 is technically unreachable code (the loop always either returns or throws), but the defensive fallback throw is harmless.

Was this helpful? React with 👍 or 👎 to provide feedback.

📝 Info: Pipeline uses node:fs/promises imports despite Bun-only runtime convention

AGENTS.md states the runtime is "Bun only" and types should use bun-types not @types/node. Several files import from node:fs/promises and node:path (pipeline.ts:1-2, run.ts:3-4, prompt-loader.ts:1-2). Bun fully supports node: protocol imports and these modules work correctly. The git-inspector.ts file correctly uses Bun's $ shell API. While using Bun-native file APIs (like Bun.write()) would be more idiomatic, the node:fs/promises imports are functional and this is a script rather than the core plugin code. Not flagging as a bug since the convention is about runtime/types, not import source.

Was this helpful? React with 👍 or 👎 to provide feedback.

🚩 Upstream tag watcher permissions may be insufficient for dispatch + state commit

The watcher workflow has permissions: contents: read and actions: write. The github.rest.repos.createDispatchEvent call requires write access. While actions: write may cover workflow dispatch in some configurations, if the fix for BUG-0002 involves committing a state file back to the repo, the permissions would need to be upgraded to contents: write. Worth verifying that the current permissions are sufficient even for just the dispatch event.

Was this helpful? React with 👍 or 👎 to provide feedback.

Grant contents:write for repository dispatch

The watcher calls github.rest.repos.createDispatchEvent, but this job only grants contents: read; GitHub requires write-level repository contents permission for repository dispatch, so this step will fail with a 403 and the analyzer workflow will never be triggered automatically. Update this workflow permission to contents: write (least-privilege can still be preserved by keeping other scopes minimal).

Useful? React with 👍 / 👎.

Persist watcher state after successful dispatch

This workflow reads WATCHER_STATE_FILE to suppress repeated alerts, but never writes the newly detected tag after dispatching; with upstream-version.txt unchanged, every 15-minute run will keep redispatching the same range and repeatedly create duplicate analysis issues/PR attempts. Persist LATEST (or otherwise advance state) after a successful dispatch so each upstream tag is analyzed once.

Useful? React with 👍 / 👎.