The loose ends of #31, found while reviewing its fix in #37.
#31 was the duplicate-PR job commenting with an empty body on every pull request, because OPENCODE_API_KEY is the upstream account's and a fork gets nothing back. The fix guarded that job with if: github.repository == 'anomalyco/opencode'. Two other jobs read the same secret with no such guard, and they fire on events forks do get.
triage.yml — job triage, OPENCODE_API_KEY at :46, triggered on issues. Every issue opened on a fork runs a checkout, bun install, the opencode install script, and then asks a reporter that cannot answer.
duplicate-issues.yml — jobs check-duplicates (:8) and recheck-compliance (:142), the key at :46 and :180, also on issues. Same cost, twice.
opencode.yml and review.yml read it too but are gated on comment keywords plus author association, so they are far less likely to fire on a fork; worth checking, not urgent.
One decision inside this, which is why it is filed rather than fixed: guarding recheck-compliance stops compliance rechecking on the fork entirely. That is honest — it cannot work without the key — but it is a behaviour change on this repository's own automation, not just a saving.
Separately, docs-update.yml:13 names sst/opencode. The other twelve guards name anomalyco/opencode. So that job is dead here and would be dead in the upstream repository too unless the owner moved back, which makes it a pre-existing bug rather than a fork artifact. Worth fixing or deleting whichever is true, and worth knowing when counting how consistent this convention is: the comment in pr-management.yml claimed more than the repository has, and has been corrected to thirteen jobs across ten workflows with these exceptions named.
The loose ends of #31, found while reviewing its fix in #37.
#31 was the duplicate-PR job commenting with an empty body on every pull request, because
OPENCODE_API_KEYis the upstream account's and a fork gets nothing back. The fix guarded that job withif: github.repository == 'anomalyco/opencode'. Two other jobs read the same secret with no such guard, and they fire on events forks do get.triage.yml— jobtriage,OPENCODE_API_KEYat :46, triggered onissues. Every issue opened on a fork runs a checkout,bun install, the opencode install script, and then asks a reporter that cannot answer.duplicate-issues.yml— jobscheck-duplicates(:8) andrecheck-compliance(:142), the key at :46 and :180, also onissues. Same cost, twice.opencode.ymlandreview.ymlread it too but are gated on comment keywords plus author association, so they are far less likely to fire on a fork; worth checking, not urgent.One decision inside this, which is why it is filed rather than fixed: guarding
recheck-compliancestops compliance rechecking on the fork entirely. That is honest — it cannot work without the key — but it is a behaviour change on this repository's own automation, not just a saving.Separately,
docs-update.yml:13namessst/opencode. The other twelve guards nameanomalyco/opencode. So that job is dead here and would be dead in the upstream repository too unless the owner moved back, which makes it a pre-existing bug rather than a fork artifact. Worth fixing or deleting whichever is true, and worth knowing when counting how consistent this convention is: the comment inpr-management.ymlclaimed more than the repository has, and has been corrected to thirteen jobs across ten workflows with these exceptions named.