Finding
import-architectures.yml and refresh-radar-reports.yml both run npm run test:unit, but they run it before the step that rewrites the data. The unit suite therefore asserts against the checkout as it was, not against what the workflow is about to propose.
.github/workflows/import-architectures.yml:
- run: npm ci
- run: npm run test:unit # <-- runs against the pre-import checkout
- run: npm run collect:metrics
- run: npm run validate:metrics
- run: npm run import:architectures
- run: npm run validate:architectures
.github/workflows/refresh-radar-reports.yml:
- run: npm ci
- run: npm run test:unit # <-- runs against the pre-refresh checkout
- run: npm run collect:radar-reports
- run: npm run validate:radar-reports
This matters because a large part of the unit suite is data-contract tests that read the generated files directly:
data/architectures/catalog.json is read by tests/architecture-catalog-contract.test.mjs, tests/reference-architectures.test.mjs and tests/members-data.test.mjs
data/radar-reports.json is read by tests/radar-reports.test.mjs and tests/radar-reports-fallbacks.test.mjs
The narrow validate:* scripts that do run after the generation step are not equivalent to those suites — validate:architectures does not assert the rendering contracts that reference-architectures.test.mjs does, and nothing at all re-checks data/members.json, which import:architectures also regenerates (it chains npm run generate:members).
As with the sibling issue, ci.yml is not a backstop: these PRs are opened by peter-evans/create-pull-request with the default GITHUB_TOKEN, and GitHub does not start workflow runs for GITHUB_TOKEN events. PR #681, produced by import-architectures.yml, carries exactly one check — DCO, a GitHub App rather than a workflow.
Recommendation
Move the test:unit step so it runs after the data is regenerated, in both workflows.
In .github/workflows/import-architectures.yml, replace:
- run: npm ci
- run: npm run test:unit
- run: npm run collect:metrics
env:
GH_TOKEN: ${{ github.token }}
- run: npm run validate:metrics
- run: npm run import:architectures
- run: npm run validate:architectures
with:
- run: npm ci
- run: npm run collect:metrics
env:
GH_TOKEN: ${{ github.token }}
- run: npm run validate:metrics
- run: npm run import:architectures
- run: npm run test:unit
- run: npm run validate:architectures
In .github/workflows/refresh-radar-reports.yml, replace:
- run: npm ci
- run: npm run test:unit
- run: npm run collect:radar-reports
- run: npm run validate:radar-reports
with:
- run: npm ci
- run: npm run collect:radar-reports
- run: npm run test:unit
- run: npm run validate:radar-reports
No file outside .github/workflows/ changes.
Completion criterion
Needs a human
The fix is entirely inside .github/workflows/. The agent that found this holds a contributor-tier App token, which does not carry the workflows permission, so any push touching .github/workflows/** is rejected by GitHub server-side. This issue therefore has no accompanying PR — a hard credential ceiling, not a judgement that the change is unready. The replacement text above is exact and applying it is mechanical; it needs a human maintainer or an agent with the workflows permission to land.
Priority
- Impact: medium-high — the suites that guard the generated data are run, but always one revision too early
- Effort: low — moving one step in each of two workflows
🐝 Hive Agent: quality | Instance: hosted-available-lke648397-260827-5n31 | SHA: b54cf81
— hive: agent=quality backend=copilot model=claude-opus-5 copilot=1.0.88
Finding
import-architectures.ymlandrefresh-radar-reports.ymlboth runnpm run test:unit, but they run it before the step that rewrites the data. The unit suite therefore asserts against the checkout as it was, not against what the workflow is about to propose..github/workflows/import-architectures.yml:.github/workflows/refresh-radar-reports.yml:This matters because a large part of the unit suite is data-contract tests that read the generated files directly:
data/architectures/catalog.jsonis read bytests/architecture-catalog-contract.test.mjs,tests/reference-architectures.test.mjsandtests/members-data.test.mjsdata/radar-reports.jsonis read bytests/radar-reports.test.mjsandtests/radar-reports-fallbacks.test.mjsThe narrow
validate:*scripts that do run after the generation step are not equivalent to those suites —validate:architecturesdoes not assert the rendering contracts thatreference-architectures.test.mjsdoes, and nothing at all re-checksdata/members.json, whichimport:architecturesalso regenerates (it chainsnpm run generate:members).As with the sibling issue,
ci.ymlis not a backstop: these PRs are opened bypeter-evans/create-pull-requestwith the defaultGITHUB_TOKEN, and GitHub does not start workflow runs forGITHUB_TOKENevents. PR #681, produced byimport-architectures.yml, carries exactly one check —DCO, a GitHub App rather than a workflow.Recommendation
Move the
test:unitstep so it runs after the data is regenerated, in both workflows.In
.github/workflows/import-architectures.yml, replace:with:
In
.github/workflows/refresh-radar-reports.yml, replace:with:
No file outside
.github/workflows/changes.Completion criterion
import-architectures.ymlrunsnpm run test:unitafternpm run import:architecturesrefresh-radar-reports.ymlrunsnpm run test:unitafternpm run collect:radar-reportsNeeds a human
The fix is entirely inside
.github/workflows/. The agent that found this holds acontributor-tier App token, which does not carry theworkflowspermission, so any push touching.github/workflows/**is rejected by GitHub server-side. This issue therefore has no accompanying PR — a hard credential ceiling, not a judgement that the change is unready. The replacement text above is exact and applying it is mechanical; it needs a human maintainer or an agent with theworkflowspermission to land.Priority
🐝 Hive Agent:
quality| Instance:hosted-available-lke648397-260827-5n31| SHA:b54cf81— hive: agent=quality backend=copilot model=claude-opus-5 copilot=1.0.88