ci: copy releases to npmjs from the GitHub mirror #2

jercik · 2026-10-21T12:05:03Z

jercik commented

2026-10-21 12:05:03 +00:00

Marks fta-check as an npm mirror (.npm-mirror) and adds what j4k-align 6.7.1 renders for it: .github/workflows/release-npm.yml and an npm-mirror job in the Forge release.yml. Forgejo ignores the GitHub file because .forgejo/workflows exists.

The tag of v1.5.10 has no release-npm.yml, and its Forge release records no tarball integrity, which the mirror requires. The first release the mirror can copy is the next one.

Marks fta-check as an npm mirror (`.npm-mirror`) and adds what `j4k-align` 6.7.1 renders for it: `.github/workflows/release-npm.yml` and an `npm-mirror` job in the Forge `release.yml`. Forgejo ignores the GitHub file because `.forgejo/workflows` exists. The tag of v1.5.10 has no `release-npm.yml`, and its Forge release records no tarball integrity, which the mirror requires. The first release the mirror can copy is the next one.

jercik added 1 commit

2026-10-21 12:05:03 +00:00

ci: copy releases to npmjs from the GitHub mirror

Checks / pr-flow-canary (pull_request) Has been skipped

Details

Checks / reuse (pull_request) Successful in 3s

Details

commit-msg / commitlint (pull_request) Successful in 14s

Details

Checks / quality-checks (26.5.0) (pull_request) Successful in 35s

Details

Checks / quality-checks (24.15.0) (pull_request) Successful in 36s

Details

Review / Review (pull_request_target) Successful in 6m40s

Details

3dab0c80cc

Mark the repository as an npm mirror and render the workflows j4k-align
6.7.1 generates for it.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>

forgejo-actions commented

2026-10-21 12:11:41 +00:00

Review 01M5F5KKKKM3J79C1WXWYX48ET — head 3dab0c80cc9e51c4dcc7be09636d47bd2f2e0eed

Review — j4k-oss/fta-check @ `fd15727ce9`

Scope: diff against base tree b1360802d35a
Status: dispatched — coverage complete (6/6 slots terminal)
Facts: current review-wide projection

Computed under:

{
  "abandonment": "abandonment-v1",
  "anchor_recipe": 1,
  "batch_policy": "batch-v1",
  "coverage": "coverage-v3",
  "dispatch_policy": "dispatch-v2",
  "grounder_version": 1,
  "grounding_read_rule": "grounding-read-v1",
  "promotion_policy": "promotion-v1",
  "report": "report-v4",
  "tally": "tally-v1",
  "triage_settle": "triage-settle-v2"
}

Findings (5)

high — npm-mirror job comment lists what it checks and omits the SLSA provenance check the job performs

claim: 01M5F5NJKHBQ8WKEYQ79YW6S1W
anchor: .forgejo/workflows/release.yml (snippet)

then checks the account, the publisher, the artifact and the dist-tags, so a mirror that never ran

lens: restated-sets · arm: default
verdicts: 1 valid / 0 invalid / 0 uncertain
- pass 01M5F5R7D9DXSBQD3W0N0N7WK9 · valid: The exact-grounded job comment presents account, publisher, artifact and dist-tags as the checks performed. The reviewer identifies the source workflow and describes the corresponding checks, plus the separate provenance and repository-visibility checks absent from that inventory. This supplies the required source/copy comparison and supports high severity for an already incomplete maintenance copy. The step name need not mention the artifact comparison performed by another step; that scope mismatch in the argument does not refute the job-comment defect. Retain the job's purpose and failure consequence, and point to its checks without an inventory.
duplicates: 01M5F5P8GCNHEY6QDM4S0EPE9V (writing-quality)
disposition: none

What goes wrong: the comment above the npm-mirror job presents a list as what the job checks: "checks the account, the publisher, the artifact and the dist-tags". The job also verifies SLSA provenance, so a reader trusting the comment believes the provenance/ref/commit binding is not checked, or will not update the comment when the checks change.

What the subject does: the source is the job's steps in .forgejo/workflows/release.yml. Step "Check the npm account, publisher, provenance and dist-tag" runs: npmjs collaborators and maintainers (account), _npmUser and trustedPublisher ids (publisher), the GitHub repository visibility policy, verifyProvenance on the SLSA attestation (provenance subject, repository/workflow, ref, commit, with a failure "npmjs holds no SLSA provenance"), and dist-tags.latest. Step "Compare the npm tarball with the Forge release" is the artifact check. Members in the source only: provenance (and repository visibility). Members in the comment only: none. The step name is a second copy of the list and itself omits the artifact (a separate step), so the two lists already disagree with each other. No exception applies: the comment is an orientation summary whose reader task (understand why the job exists) does not need an inventory.

Correction: state the purpose and point to the steps, e.g. "This job waits for the version on npmjs, then verifies the copy against the Forge release in the steps below, so a mirror that never ran, or published something else, turns this run red."

Examined: .forgejo/workflows/release.yml lines 279-475 (job comment, both steps, expect calls, verifyProvenance). Not run.

medium — Comment counts "three package.json fields" the mirror rewrites; the repack step is the source and every change to it must update the count

claim: 01M5F5NJ482HH0A3VBHW68VZTD
anchor: .github/workflows/release-npm.yml (snippet)

in every member except the three package.json fields the mirror rewrites.

lens: restated-sets · arm: default
verdicts: 1 valid / 0 invalid / 0 uncertain
- pass 01M5F5R7D9DXSBQD3W0N0N7WK9 · valid: The exact-grounded comment independently maintains the count 'three'. The reviewer names .github/workflows/release-npm.yml and quotes the repack commands defining name, repository.url and publishConfig; that reported comparison establishes a matching count today. The number adds no necessary information to the maintainer's task of understanding the tarball-comparison exception. Drop the count and retain the exception with a pointer to the repack step. This is the stipulated medium maintenance-copy defect.
duplicates: 01M5F5PP4KZ871BN30KF0RJXW6 (writing-quality)
disposition: none

What goes wrong: the comment above the "Compare the copy with the Forge release" step states a count of the package.json fields the mirror rewrites. Nobody is prompted to update it when the repack step gains or loses a rewrite, so the count goes stale silently and the comment then misdescribes what the comparison tolerates.

What the subject does: the set is defined by the "Repack the Forge tarball under the npm name" step in .github/workflows/release-npm.yml: npm pkg set "name=$NAME" "repository.url=$REPOSITORY_URL" and npm pkg delete publishConfig. The tolerated differences are enforced separately in .forgejo/workflows/release.yml (delete manifest.name; delete manifest.repository?.url; delete manifest.publishConfig;), whose success message also lists them. Source members: name, repository.url, publishConfig. Copy: "three fields", no names. The count matches today (3 = 3), so the copy does not yet disagree; no exception applies: it is not a dated record, and the reader of this comment (someone deciding what the comparison may ignore) can read the repack step directly.

Correction: drop the count and point at the authority, e.g. "Either must equal the Forge tarball in every member except the package.json fields the preceding repack step rewrites." The Forge verifier in release.yml keeps the exact list in its code where it is enforced.

Examined: both workflow files in full for the rewrite steps and comparison logic. Not verified: the runtime behaviour of the compare step beyond reading it.

low — Comment names an "OCI publisher" that does not exist in this repository

claim: 01M5F5PCCATGQM5SD00DCXMSFZ
anchor: .forgejo/workflows/release.yml (snippet)

# The OCI publisher gets the version from @j4k/semantic-release-github-output, which lives in the private registry that a public package cannot install from.

lens: writing-quality · arm: default
verdicts: 1 valid / 0 invalid / 0 uncertain
- pass 01M5F5R7D9DXSBQD3W0N0N7WK9 · valid: The exact-grounded sentence refers to 'The OCI publisher', while the reviewer supplies the npm release configuration, the actual consumers of the version output and a targeted search finding no OCI publisher. That concrete account supports the low clarity defect: the explanation sends maintainers to an unidentified publisher instead of explaining the version output this workflow needs. Its possible origin in another repository is unnecessary to the finding. Replace that referent with the current version-output purpose, retaining the private-registry constraint and any tag/rerun guarantees; avoid introducing a new exhaustive consumer inventory.
disposition: none

The comment in the Release step explains why the version comes from the git tag on HEAD, but it opens with "The OCI publisher gets the version from @j4k/semantic-release-github-output". This repository publishes an npm package. It has no OCI or container image publisher, and release.config.mjs lists only commit-analyzer, release-notes-generator, @semantic-release/npm and @j4k/semantic-release-forgejo. The text appears to come from a sibling repository's workflow. The step output version is consumed by the Record the Forge tarball integrity step and by the npm-mirror job through needs.release.outputs.new-release-version. A reader looking for the OCI publisher finds nothing and cannot tell what the tag lookup is a substitute for.

Correction: name the actual consumers and keep the reason. For example: "Later steps and the npm-mirror job need the released version, but @j4k/semantic-release-github-output lives in the private registry, which a public package cannot install from. semantic-release tags the released commit before it publishes, so the tag on HEAD names the version, and a rerun of an already released commit finds the same tag." This preserves the constraint (private plugin unavailable), the mechanism, and the rerun behavior.

I read the Release step, the job outputs, and release.config.mjs, and grepped the tree for OCI, ghcr and image, with no hit besides this comment.

low — Comment contrasts with "the other publishers" the reader cannot see, and repeats a rationale kept in the npm-mirror comment

claim: 01M5F5PT4HF92VGJ2WFZ6CPWPR
anchor: .forgejo/workflows/release.yml (snippet)

# Job-level, unlike the other publishers: the npm-mirror job below reads public endpoints only

lens: writing-quality · arm: default
verdicts: 1 valid / 0 invalid / 0 uncertain
- pass 01M5F5R7D9DXSBQD3W0N0N7WK9 · valid: The grounded phrase introduces an unidentified comparison with 'the other publishers', while the reviewer reports that this repository contains no such publisher jobs. The current placement and its public-endpoint rationale are already stated, so the external comparison adds a referent the maintainer cannot locate without helping apply the rule. Removing that phrase is a supported low clarity improvement, not a reason to remove the security explanation. Preserve the job-only credential boundary and the reported Forgejo version caveat. The batch does not ground the full second parenthetical or establish its complete reader task, so it does not justify endorsing that broader deletion.
disposition: none

The new comment above enable-openid-connect: true starts "Job-level, unlike the other publishers". No other publisher is defined in this repository; the contrast refers to other repositories' workflows, which a reader of this file cannot consult. It describes the file by contrast with something absent, and the skill's "State Durable Truth" guidance asks for the current rule instead. The npm-mirror job comment then says again that enable-openid-connect "is set on the release job alone", which restates the same placement fact in a second place.

Correction: state the rule here and keep the pointer in the other. For example: "Set on this job only. The npm-mirror job reads public endpoints and must not hold a credential that can mint a registry write token, and a workflow-level key would give it one. Forgejo 16.0.x resolves the job key over the workflow one." Keep the version-scoped sentence; readers on that Forgejo version need it. The parenthetical in the npm-mirror comment can then be cut, since the job comment is the authority for where the key is set.

I read both comments and the removed workflow-level comment in the diff, and searched the tree for other publisher jobs and found none.

low — Comment says the first step refuses non-tag refs, but the ref check is in the second step

claim: 01M5F5QJW0HY2S6W0DMK5TT4YT
anchor: .github/workflows/release-npm.yml (snippet)

The first step refuses any other ref.

lens: general-bug · arm: default
verdicts: 1 valid / 0 invalid / 0 uncertain
- pass 01M5F5R7D9DXSBQD3W0N0N7WK9 · valid: The exact-grounded comment says the first step rejects other refs, while the reviewer specifically identifies Setup Node.js as the first step and quotes the ref guard in the second, Resolve the version. That coherent ordering account establishes the low documentation inaccuracy without a reproduction. The guard preceding publication prevents a publish-impact claim, which this report correctly disclaims. Name the Resolve the version step in the comment; changing execution order is unnecessary to correct the documented location.
disposition: none

The workflow_dispatch comment says "dispatch the workflow on the tag itself ... The first step refuses any other ref." The first step of the publish job is "Setup Node.js" (actions/setup-node). The ref check ([[ "$REF" == "refs/tags/$TAG" && ... ]]) is in the second step, "Resolve the version". A reader auditing the gate looks at the wrong step, and the Node setup runs before the refusal on a branch dispatch. Correction: say "The Resolve the version step refuses any other ref", or reorder so the check runs first. I read release-npm.yml in full; this is a documentation inaccuracy only, with no publish impact because the check precedes every publish step.

Other claims

grounding-pending (0)
ungrounded (0)
rejected (0)
duplicate-of (2)
- 01M5F5P8GCNHEY6QDM4S0EPE9V high — npm-mirror job comment and step name list the checks differently, and both omit checks the job runs → 01M5F5NJKHBQ8WKEYQ79YW6S1W
- 01M5F5PP4KZ871BN30KF0RJXW6 medium — Comment counts the rewritten package.json fields; the fields are defined in the steps and scripts, and the same list is repeated in messages → 01M5F5NJ482HH0A3VBHW68VZTD
unadjudicated (2)
- 01M5F5PHFT57E0JYN6E66GYZP8 medium — Comment points to an "account gate" run that sets PRE_MIGRATION_BASELINE, but nothing in the repository defines or sets it
- 01M5F5QJADMW339APRNPXKQ1X7 low — PRE_MIGRATION_BASELINE bypass is read from env but nothing in the repo sets it; its comment cites a baseline run that does not exist

Coverage

Coverage pass: 01M5F5M3PKYEHQYHVJ4ZCYKSB1
Accounting: complete
Slot health: healthy

lens	part	arm	unit status	runs	loss
restated-sets	whole	default	claims-emitted	1	no
general-bug	release-workflow	default	claims-emitted	1	no
writing-quality	whole	default	claims-emitted	1	no
test-trimming	whole	default	no-claims	1	no
project-docs	whole	default	no-claims	1	no
unix-cli	whole	default	no-claims	1	no

use-effect — skipped-by-dispatch: only CI workflow YAML and shell/node scripts changed; no React Effects or Hooks
react — skipped-by-dispatch: only CI workflow YAML and an empty marker file changed; no React components, props, or state

**Review** `01M5F5KKKKM3J79C1WXWYX48ET` — head `3dab0c80cc9e51c4dcc7be09636d47bd2f2e0eed` # Review — j4k-oss/fta-check @ fd15727ce931 Scope: diff against base tree `b1360802d35a` Status: dispatched — coverage complete (6/6 slots terminal) Facts: current review-wide projection Computed under: ```json { "abandonment": "abandonment-v1", "anchor_recipe": 1, "batch_policy": "batch-v1", "coverage": "coverage-v3", "dispatch_policy": "dispatch-v2", "grounder_version": 1, "grounding_read_rule": "grounding-read-v1", "promotion_policy": "promotion-v1", "report": "report-v4", "tally": "tally-v1", "triage_settle": "triage-settle-v2" } ``` ## Findings (5) ### high — npm-mirror job comment lists what it checks and omits the SLSA provenance check the job performs - claim: `01M5F5NJKHBQ8WKEYQ79YW6S1W` - anchor: `.forgejo/workflows/release.yml` (snippet) ``` then checks the account, the publisher, the artifact and the dist-tags, so a mirror that never ran ``` - lens: restated-sets · arm: default - verdicts: 1 valid / 0 invalid / 0 uncertain - pass `01M5F5R7D9DXSBQD3W0N0N7WK9` · valid: The exact-grounded job comment presents account, publisher, artifact and dist-tags as the checks performed. The reviewer identifies the source workflow and describes the corresponding checks, plus the separate provenance and repository-visibility checks absent from that inventory. This supplies the required source/copy comparison and supports high severity for an already incomplete maintenance copy. The step name need not mention the artifact comparison performed by another step; that scope mismatch in the argument does not refute the job-comment defect. Retain the job's purpose and failure consequence, and point to its checks without an inventory. - duplicates: `01M5F5P8GCNHEY6QDM4S0EPE9V` (writing-quality) - disposition: none > What goes wrong: the comment above the `npm-mirror` job presents a list as what the job checks: "checks the account, the publisher, the artifact and the dist-tags". The job also verifies SLSA provenance, so a reader trusting the comment believes the provenance/ref/commit binding is not checked, or will not update the comment when the checks change. > > What the subject does: the source is the job's steps in .forgejo/workflows/release.yml. Step "Check the npm account, publisher, provenance and dist-tag" runs: npmjs collaborators and maintainers (account), _npmUser and trustedPublisher ids (publisher), the GitHub repository visibility policy, `verifyProvenance` on the SLSA attestation (provenance subject, repository/workflow, ref, commit, with a failure "npmjs holds no SLSA provenance"), and `dist-tags.latest`. Step "Compare the npm tarball with the Forge release" is the artifact check. Members in the source only: provenance (and repository visibility). Members in the comment only: none. The step name is a second copy of the list and itself omits the artifact (a separate step), so the two lists already disagree with each other. No exception applies: the comment is an orientation summary whose reader task (understand why the job exists) does not need an inventory. > > Correction: state the purpose and point to the steps, e.g. "This job waits for the version on npmjs, then verifies the copy against the Forge release in the steps below, so a mirror that never ran, or published something else, turns this run red." > > Examined: .forgejo/workflows/release.yml lines 279-475 (job comment, both steps, `expect` calls, `verifyProvenance`). Not run. ### medium — Comment counts "three package.json fields" the mirror rewrites; the repack step is the source and every change to it must update the count - claim: `01M5F5NJ482HH0A3VBHW68VZTD` - anchor: `.github/workflows/release-npm.yml` (snippet) ``` in every member except the three package.json fields the mirror rewrites. ``` - lens: restated-sets · arm: default - verdicts: 1 valid / 0 invalid / 0 uncertain - pass `01M5F5R7D9DXSBQD3W0N0N7WK9` · valid: The exact-grounded comment independently maintains the count 'three'. The reviewer names .github/workflows/release-npm.yml and quotes the repack commands defining name, repository.url and publishConfig; that reported comparison establishes a matching count today. The number adds no necessary information to the maintainer's task of understanding the tarball-comparison exception. Drop the count and retain the exception with a pointer to the repack step. This is the stipulated medium maintenance-copy defect. - duplicates: `01M5F5PP4KZ871BN30KF0RJXW6` (writing-quality) - disposition: none > What goes wrong: the comment above the "Compare the copy with the Forge release" step states a count of the package.json fields the mirror rewrites. Nobody is prompted to update it when the repack step gains or loses a rewrite, so the count goes stale silently and the comment then misdescribes what the comparison tolerates. > > What the subject does: the set is defined by the "Repack the Forge tarball under the npm name" step in .github/workflows/release-npm.yml: `npm pkg set "name=$NAME" "repository.url=$REPOSITORY_URL"` and `npm pkg delete publishConfig`. The tolerated differences are enforced separately in .forgejo/workflows/release.yml (`delete manifest.name; delete manifest.repository?.url; delete manifest.publishConfig;`), whose success message also lists them. Source members: name, repository.url, publishConfig. Copy: "three fields", no names. The count matches today (3 = 3), so the copy does not yet disagree; no exception applies: it is not a dated record, and the reader of this comment (someone deciding what the comparison may ignore) can read the repack step directly. > > Correction: drop the count and point at the authority, e.g. "Either must equal the Forge tarball in every member except the package.json fields the preceding repack step rewrites." The Forge verifier in release.yml keeps the exact list in its code where it is enforced. > > Examined: both workflow files in full for the rewrite steps and comparison logic. Not verified: the runtime behaviour of the compare step beyond reading it. ### low — Comment names an "OCI publisher" that does not exist in this repository - claim: `01M5F5PCCATGQM5SD00DCXMSFZ` - anchor: `.forgejo/workflows/release.yml` (snippet) ``` # The OCI publisher gets the version from @j4k/semantic-release-github-output, which lives in the private registry that a public package cannot install from. ``` - lens: writing-quality · arm: default - verdicts: 1 valid / 0 invalid / 0 uncertain - pass `01M5F5R7D9DXSBQD3W0N0N7WK9` · valid: The exact-grounded sentence refers to 'The OCI publisher', while the reviewer supplies the npm release configuration, the actual consumers of the version output and a targeted search finding no OCI publisher. That concrete account supports the low clarity defect: the explanation sends maintainers to an unidentified publisher instead of explaining the version output this workflow needs. Its possible origin in another repository is unnecessary to the finding. Replace that referent with the current version-output purpose, retaining the private-registry constraint and any tag/rerun guarantees; avoid introducing a new exhaustive consumer inventory. - disposition: none > The comment in the `Release` step explains why the version comes from the git tag on HEAD, but it opens with "The OCI publisher gets the version from @j4k/semantic-release-github-output". This repository publishes an npm package. It has no OCI or container image publisher, and `release.config.mjs` lists only commit-analyzer, release-notes-generator, `@semantic-release/npm` and `@j4k/semantic-release-forgejo`. The text appears to come from a sibling repository's workflow. The step output `version` is consumed by the `Record the Forge tarball integrity` step and by the `npm-mirror` job through `needs.release.outputs.new-release-version`. A reader looking for the OCI publisher finds nothing and cannot tell what the tag lookup is a substitute for. > > Correction: name the actual consumers and keep the reason. For example: "Later steps and the `npm-mirror` job need the released version, but `@j4k/semantic-release-github-output` lives in the private registry, which a public package cannot install from. semantic-release tags the released commit before it publishes, so the tag on HEAD names the version, and a rerun of an already released commit finds the same tag." This preserves the constraint (private plugin unavailable), the mechanism, and the rerun behavior. > > I read the `Release` step, the job `outputs`, and `release.config.mjs`, and grepped the tree for `OCI`, `ghcr` and `image`, with no hit besides this comment. ### low — Comment contrasts with "the other publishers" the reader cannot see, and repeats a rationale kept in the npm-mirror comment - claim: `01M5F5PT4HF92VGJ2WFZ6CPWPR` - anchor: `.forgejo/workflows/release.yml` (snippet) ``` # Job-level, unlike the other publishers: the npm-mirror job below reads public endpoints only ``` - lens: writing-quality · arm: default - verdicts: 1 valid / 0 invalid / 0 uncertain - pass `01M5F5R7D9DXSBQD3W0N0N7WK9` · valid: The grounded phrase introduces an unidentified comparison with 'the other publishers', while the reviewer reports that this repository contains no such publisher jobs. The current placement and its public-endpoint rationale are already stated, so the external comparison adds a referent the maintainer cannot locate without helping apply the rule. Removing that phrase is a supported low clarity improvement, not a reason to remove the security explanation. Preserve the job-only credential boundary and the reported Forgejo version caveat. The batch does not ground the full second parenthetical or establish its complete reader task, so it does not justify endorsing that broader deletion. - disposition: none > The new comment above `enable-openid-connect: true` starts "Job-level, unlike the other publishers". No other publisher is defined in this repository; the contrast refers to other repositories' workflows, which a reader of this file cannot consult. It describes the file by contrast with something absent, and the skill's "State Durable Truth" guidance asks for the current rule instead. The npm-mirror job comment then says again that `enable-openid-connect` "is set on the release job alone", which restates the same placement fact in a second place. > > Correction: state the rule here and keep the pointer in the other. For example: "Set on this job only. The `npm-mirror` job reads public endpoints and must not hold a credential that can mint a registry write token, and a workflow-level key would give it one. Forgejo 16.0.x resolves the job key over the workflow one." Keep the version-scoped sentence; readers on that Forgejo version need it. The parenthetical in the `npm-mirror` comment can then be cut, since the job comment is the authority for where the key is set. > > I read both comments and the removed workflow-level comment in the diff, and searched the tree for other publisher jobs and found none. ### low — Comment says the first step refuses non-tag refs, but the ref check is in the second step - claim: `01M5F5QJW0HY2S6W0DMK5TT4YT` - anchor: `.github/workflows/release-npm.yml` (snippet) ``` The first step refuses any other ref. ``` - lens: general-bug · arm: default - verdicts: 1 valid / 0 invalid / 0 uncertain - pass `01M5F5R7D9DXSBQD3W0N0N7WK9` · valid: The exact-grounded comment says the first step rejects other refs, while the reviewer specifically identifies Setup Node.js as the first step and quotes the ref guard in the second, Resolve the version. That coherent ordering account establishes the low documentation inaccuracy without a reproduction. The guard preceding publication prevents a publish-impact claim, which this report correctly disclaims. Name the Resolve the version step in the comment; changing execution order is unnecessary to correct the documented location. - disposition: none > The `workflow_dispatch` comment says "dispatch the workflow on the tag itself ... The first step refuses any other ref." The first step of the `publish` job is "Setup Node.js" (actions/setup-node). The ref check (`[[ "$REF" == "refs/tags/$TAG" && ... ]]`) is in the second step, "Resolve the version". A reader auditing the gate looks at the wrong step, and the Node setup runs before the refusal on a branch dispatch. Correction: say "The Resolve the version step refuses any other ref", or reorder so the check runs first. I read release-npm.yml in full; this is a documentation inaccuracy only, with no publish impact because the check precedes every publish step. ## Other claims - grounding-pending (0) - ungrounded (0) - rejected (0) - duplicate-of (2) - `01M5F5P8GCNHEY6QDM4S0EPE9V` high — npm-mirror job comment and step name list the checks differently, and both omit checks the job runs → `01M5F5NJKHBQ8WKEYQ79YW6S1W` - `01M5F5PP4KZ871BN30KF0RJXW6` medium — Comment counts the rewritten package.json fields; the fields are defined in the steps and scripts, and the same list is repeated in messages → `01M5F5NJ482HH0A3VBHW68VZTD` - unadjudicated (2) - `01M5F5PHFT57E0JYN6E66GYZP8` medium — Comment points to an "account gate" run that sets PRE_MIGRATION_BASELINE, but nothing in the repository defines or sets it - `01M5F5QJADMW339APRNPXKQ1X7` low — PRE_MIGRATION_BASELINE bypass is read from env but nothing in the repo sets it; its comment cites a baseline run that does not exist ## Coverage Coverage pass: 01M5F5M3PKYEHQYHVJ4ZCYKSB1 Accounting: complete Slot health: healthy | lens | part | arm | unit status | runs | loss | | --- | --- | --- | --- | --- | --- | | restated-sets | whole | default | claims-emitted | 1 | no | | general-bug | release-workflow | default | claims-emitted | 1 | no | | writing-quality | whole | default | claims-emitted | 1 | no | | test-trimming | whole | default | no-claims | 1 | no | | project-docs | whole | default | no-claims | 1 | no | | unix-cli | whole | default | no-claims | 1 | no | - use-effect — skipped-by-dispatch: only CI workflow YAML and shell/node scripts changed; no React Effects or Hooks - react — skipped-by-dispatch: only CI workflow YAML and an empty marker file changed; no React components, props, or state

🚀 1

forgejo-actions reviewed

2026-10-21 12:11:42 +00:00

.forgejo/workflows/release.yml

					
				@ -78,6 +70,11 @@ jobs:

				    needs: quality-checks

				    runs-on: ubuntu-latest

				    timeout-minutes: 15

				    # Job-level, unlike the other publishers: the npm-mirror job below reads public endpoints only and must not hold a credential that can mint a registry write token, and a workflow-level key would hand it one. Forgejo 16.0.x resolves the job key over the workflow one.

low — Comment contrasts with "the other publishers" the reader cannot see, and repeats a rationale kept in the npm-mirror comment

The new comment above enable-openid-connect: true starts "Job-level, unlike the other publishers". No other publisher is defined in this repository; the contrast refers to other repositories' workflows, which a reader of this file cannot consult. It describes the file by contrast with something absent, and the skill's "State Durable Truth" guidance asks for the current rule instead. The npm-mirror job comment then says again that enable-openid-connect "is set on the release job alone", which restates the same placement fact in a second place.

Correction: state the rule here and keep the pointer in the other. For example: "Set on this job only. The npm-mirror job reads public endpoints and must not hold a credential that can mint a registry write token, and a workflow-level key would give it one. Forgejo 16.0.x resolves the job key over the workflow one." Keep the version-scoped sentence; readers on that Forgejo version need it. The parenthetical in the npm-mirror comment can then be cut, since the job comment is the authority for where the key is set.

I read both comments and the removed workflow-level comment in the diff, and searched the tree for other publisher jobs and found none.

lens writing-quality · arm default · tally 1 valid / 0 invalid / 0 uncertain
claim 01M5F5PT4HF92VGJ2WFZ6CPWPR of review 01M5F5KKKKM3J79C1WXWYX48ET

**low** — Comment contrasts with "the other publishers" the reader cannot see, and repeats a rationale kept in the npm-mirror comment > The new comment above `enable-openid-connect: true` starts "Job-level, unlike the other publishers". No other publisher is defined in this repository; the contrast refers to other repositories' workflows, which a reader of this file cannot consult. It describes the file by contrast with something absent, and the skill's "State Durable Truth" guidance asks for the current rule instead. The npm-mirror job comment then says again that `enable-openid-connect` "is set on the release job alone", which restates the same placement fact in a second place. > > Correction: state the rule here and keep the pointer in the other. For example: "Set on this job only. The `npm-mirror` job reads public endpoints and must not hold a credential that can mint a registry write token, and a workflow-level key would give it one. Forgejo 16.0.x resolves the job key over the workflow one." Keep the version-scoped sentence; readers on that Forgejo version need it. The parenthetical in the `npm-mirror` comment can then be cut, since the job comment is the authority for where the key is set. > > I read both comments and the removed workflow-level comment in the diff, and searched the tree for other publisher jobs and found none. lens `writing-quality` · arm `default` · tally 1 valid / 0 invalid / 0 uncertain claim `01M5F5PT4HF92VGJ2WFZ6CPWPR` of review `01M5F5KKKKM3J79C1WXWYX48ET`

👍 1

jercik marked this conversation as resolved

.forgejo/workflows/release.yml

					
				@ -201,0 +199,4 @@

				        run: |

				          set -euo pipefail

				          pnpm exec semantic-release

				          # The OCI publisher gets the version from @j4k/semantic-release-github-output, which lives in the private registry that a public package cannot install from. semantic-release tags the released commit before it publishes, so the tag on HEAD names the version, and a rerun of an already released commit finds the same tag.

low — Comment names an "OCI publisher" that does not exist in this repository

The comment in the Release step explains why the version comes from the git tag on HEAD, but it opens with "The OCI publisher gets the version from @j4k/semantic-release-github-output". This repository publishes an npm package. It has no OCI or container image publisher, and release.config.mjs lists only commit-analyzer, release-notes-generator, @semantic-release/npm and @j4k/semantic-release-forgejo. The text appears to come from a sibling repository's workflow. The step output version is consumed by the Record the Forge tarball integrity step and by the npm-mirror job through needs.release.outputs.new-release-version. A reader looking for the OCI publisher finds nothing and cannot tell what the tag lookup is a substitute for.

Correction: name the actual consumers and keep the reason. For example: "Later steps and the npm-mirror job need the released version, but @j4k/semantic-release-github-output lives in the private registry, which a public package cannot install from. semantic-release tags the released commit before it publishes, so the tag on HEAD names the version, and a rerun of an already released commit finds the same tag." This preserves the constraint (private plugin unavailable), the mechanism, and the rerun behavior.

I read the Release step, the job outputs, and release.config.mjs, and grepped the tree for OCI, ghcr and image, with no hit besides this comment.

lens writing-quality · arm default · tally 1 valid / 0 invalid / 0 uncertain
claim 01M5F5PCCATGQM5SD00DCXMSFZ of review 01M5F5KKKKM3J79C1WXWYX48ET

**low** — Comment names an "OCI publisher" that does not exist in this repository > The comment in the `Release` step explains why the version comes from the git tag on HEAD, but it opens with "The OCI publisher gets the version from @j4k/semantic-release-github-output". This repository publishes an npm package. It has no OCI or container image publisher, and `release.config.mjs` lists only commit-analyzer, release-notes-generator, `@semantic-release/npm` and `@j4k/semantic-release-forgejo`. The text appears to come from a sibling repository's workflow. The step output `version` is consumed by the `Record the Forge tarball integrity` step and by the `npm-mirror` job through `needs.release.outputs.new-release-version`. A reader looking for the OCI publisher finds nothing and cannot tell what the tag lookup is a substitute for. > > Correction: name the actual consumers and keep the reason. For example: "Later steps and the `npm-mirror` job need the released version, but `@j4k/semantic-release-github-output` lives in the private registry, which a public package cannot install from. semantic-release tags the released commit before it publishes, so the tag on HEAD names the version, and a rerun of an already released commit finds the same tag." This preserves the constraint (private plugin unavailable), the mechanism, and the rerun behavior. > > I read the `Release` step, the job `outputs`, and `release.config.mjs`, and grepped the tree for `OCI`, `ghcr` and `image`, with no hit besides this comment. lens `writing-quality` · arm `default` · tally 1 valid / 0 invalid / 0 uncertain claim `01M5F5PCCATGQM5SD00DCXMSFZ` of review `01M5F5KKKKM3J79C1WXWYX48ET`

👍 1

jercik marked this conversation as resolved

.forgejo/workflows/release.yml

					
				@ -207,2 +276,4 @@

				          path: ${{ steps.pnpm-store.outputs.path }}

				          key: ${{ steps.pnpm-cache.outputs.cache-primary-key }}

				  # The GitHub mirror copies this release to npmjs from the tag the push mirror delivers, and nothing on the Forge sees that run. This job waits for the version on npmjs, then checks the account, the publisher, the artifact and the dist-tags, so a mirror that never ran, or published something else, turns this run red. It is a job here and not a tag-triggered workflow because Forgejo drops events whose actor is the Actions user, and semantic-release pushes its tag as that user. It reads public endpoints only, so it holds no OIDC request credential (enable-openid-connect is set on the release job alone).

high — npm-mirror job comment lists what it checks and omits the SLSA provenance check the job performs

What goes wrong: the comment above the npm-mirror job presents a list as what the job checks: "checks the account, the publisher, the artifact and the dist-tags". The job also verifies SLSA provenance, so a reader trusting the comment believes the provenance/ref/commit binding is not checked, or will not update the comment when the checks change.

What the subject does: the source is the job's steps in .forgejo/workflows/release.yml. Step "Check the npm account, publisher, provenance and dist-tag" runs: npmjs collaborators and maintainers (account), _npmUser and trustedPublisher ids (publisher), the GitHub repository visibility policy, verifyProvenance on the SLSA attestation (provenance subject, repository/workflow, ref, commit, with a failure "npmjs holds no SLSA provenance"), and dist-tags.latest. Step "Compare the npm tarball with the Forge release" is the artifact check. Members in the source only: provenance (and repository visibility). Members in the comment only: none. The step name is a second copy of the list and itself omits the artifact (a separate step), so the two lists already disagree with each other. No exception applies: the comment is an orientation summary whose reader task (understand why the job exists) does not need an inventory.

Correction: state the purpose and point to the steps, e.g. "This job waits for the version on npmjs, then verifies the copy against the Forge release in the steps below, so a mirror that never ran, or published something else, turns this run red."

Examined: .forgejo/workflows/release.yml lines 279-475 (job comment, both steps, expect calls, verifyProvenance). Not run.

lens restated-sets · arm default · tally 1 valid / 0 invalid / 0 uncertain
claim 01M5F5NJKHBQ8WKEYQ79YW6S1W of review 01M5F5KKKKM3J79C1WXWYX48ET

**high** — npm-mirror job comment lists what it checks and omits the SLSA provenance check the job performs > What goes wrong: the comment above the `npm-mirror` job presents a list as what the job checks: "checks the account, the publisher, the artifact and the dist-tags". The job also verifies SLSA provenance, so a reader trusting the comment believes the provenance/ref/commit binding is not checked, or will not update the comment when the checks change. > > What the subject does: the source is the job's steps in .forgejo/workflows/release.yml. Step "Check the npm account, publisher, provenance and dist-tag" runs: npmjs collaborators and maintainers (account), _npmUser and trustedPublisher ids (publisher), the GitHub repository visibility policy, `verifyProvenance` on the SLSA attestation (provenance subject, repository/workflow, ref, commit, with a failure "npmjs holds no SLSA provenance"), and `dist-tags.latest`. Step "Compare the npm tarball with the Forge release" is the artifact check. Members in the source only: provenance (and repository visibility). Members in the comment only: none. The step name is a second copy of the list and itself omits the artifact (a separate step), so the two lists already disagree with each other. No exception applies: the comment is an orientation summary whose reader task (understand why the job exists) does not need an inventory. > > Correction: state the purpose and point to the steps, e.g. "This job waits for the version on npmjs, then verifies the copy against the Forge release in the steps below, so a mirror that never ran, or published something else, turns this run red." > > Examined: .forgejo/workflows/release.yml lines 279-475 (job comment, both steps, `expect` calls, `verifyProvenance`). Not run. lens `restated-sets` · arm `default` · tally 1 valid / 0 invalid / 0 uncertain claim `01M5F5NJKHBQ8WKEYQ79YW6S1W` of review `01M5F5KKKKM3J79C1WXWYX48ET`

👍 1

jercik marked this conversation as resolved

.github/workflows/release-npm.yml

					
				@ -0,0 +13,4 @@

				    tags:

				      - "v*"

				  # Re-runs a release whose tag run failed: dispatch the workflow on the tag

				  # itself ("Use workflow from" a tag). The first step refuses any other ref.

low — Comment says the first step refuses non-tag refs, but the ref check is in the second step

The workflow_dispatch comment says "dispatch the workflow on the tag itself ... The first step refuses any other ref." The first step of the publish job is "Setup Node.js" (actions/setup-node). The ref check ([[ "$REF" == "refs/tags/$TAG" && ... ]]) is in the second step, "Resolve the version". A reader auditing the gate looks at the wrong step, and the Node setup runs before the refusal on a branch dispatch. Correction: say "The Resolve the version step refuses any other ref", or reorder so the check runs first. I read release-npm.yml in full; this is a documentation inaccuracy only, with no publish impact because the check precedes every publish step.

lens general-bug · arm default · tally 1 valid / 0 invalid / 0 uncertain
claim 01M5F5QJW0HY2S6W0DMK5TT4YT of review 01M5F5KKKKM3J79C1WXWYX48ET

**low** — Comment says the first step refuses non-tag refs, but the ref check is in the second step > The `workflow_dispatch` comment says "dispatch the workflow on the tag itself ... The first step refuses any other ref." The first step of the `publish` job is "Setup Node.js" (actions/setup-node). The ref check (`[[ "$REF" == "refs/tags/$TAG" && ... ]]`) is in the second step, "Resolve the version". A reader auditing the gate looks at the wrong step, and the Node setup runs before the refusal on a branch dispatch. Correction: say "The Resolve the version step refuses any other ref", or reorder so the check runs first. I read release-npm.yml in full; this is a documentation inaccuracy only, with no publish impact because the check precedes every publish step. lens `general-bug` · arm `default` · tally 1 valid / 0 invalid / 0 uncertain claim `01M5F5QJW0HY2S6W0DMK5TT4YT` of review `01M5F5KKKKM3J79C1WXWYX48ET`

👍 1

jercik marked this conversation as resolved

.github/workflows/release-npm.yml

					
				@ -0,0 +126,4 @@

				          npm pkg delete publishConfig

				      - name: Compare the copy with the Forge release

				        # What is compared is what gets published: the version already on npmjs, or the packed repack. Either must equal the Forge tarball in every member except the three package.json fields the mirror rewrites.

medium — Comment counts "three package.json fields" the mirror rewrites; the repack step is the source and every change to it must update the count

What goes wrong: the comment above the "Compare the copy with the Forge release" step states a count of the package.json fields the mirror rewrites. Nobody is prompted to update it when the repack step gains or loses a rewrite, so the count goes stale silently and the comment then misdescribes what the comparison tolerates.

What the subject does: the set is defined by the "Repack the Forge tarball under the npm name" step in .github/workflows/release-npm.yml: npm pkg set "name=$NAME" "repository.url=$REPOSITORY_URL" and npm pkg delete publishConfig. The tolerated differences are enforced separately in .forgejo/workflows/release.yml (delete manifest.name; delete manifest.repository?.url; delete manifest.publishConfig;), whose success message also lists them. Source members: name, repository.url, publishConfig. Copy: "three fields", no names. The count matches today (3 = 3), so the copy does not yet disagree; no exception applies: it is not a dated record, and the reader of this comment (someone deciding what the comparison may ignore) can read the repack step directly.

Correction: drop the count and point at the authority, e.g. "Either must equal the Forge tarball in every member except the package.json fields the preceding repack step rewrites." The Forge verifier in release.yml keeps the exact list in its code where it is enforced.

Examined: both workflow files in full for the rewrite steps and comparison logic. Not verified: the runtime behaviour of the compare step beyond reading it.

lens restated-sets · arm default · tally 1 valid / 0 invalid / 0 uncertain
claim 01M5F5NJ482HH0A3VBHW68VZTD of review 01M5F5KKKKM3J79C1WXWYX48ET

**medium** — Comment counts "three package.json fields" the mirror rewrites; the repack step is the source and every change to it must update the count > What goes wrong: the comment above the "Compare the copy with the Forge release" step states a count of the package.json fields the mirror rewrites. Nobody is prompted to update it when the repack step gains or loses a rewrite, so the count goes stale silently and the comment then misdescribes what the comparison tolerates. > > What the subject does: the set is defined by the "Repack the Forge tarball under the npm name" step in .github/workflows/release-npm.yml: `npm pkg set "name=$NAME" "repository.url=$REPOSITORY_URL"` and `npm pkg delete publishConfig`. The tolerated differences are enforced separately in .forgejo/workflows/release.yml (`delete manifest.name; delete manifest.repository?.url; delete manifest.publishConfig;`), whose success message also lists them. Source members: name, repository.url, publishConfig. Copy: "three fields", no names. The count matches today (3 = 3), so the copy does not yet disagree; no exception applies: it is not a dated record, and the reader of this comment (someone deciding what the comparison may ignore) can read the repack step directly. > > Correction: drop the count and point at the authority, e.g. "Either must equal the Forge tarball in every member except the package.json fields the preceding repack step rewrites." The Forge verifier in release.yml keeps the exact list in its code where it is enforced. > > Examined: both workflow files in full for the rewrite steps and comparison logic. Not verified: the runtime behaviour of the compare step beyond reading it. lens `restated-sets` · arm `default` · tally 1 valid / 0 invalid / 0 uncertain claim `01M5F5NJ482HH0A3VBHW68VZTD` of review `01M5F5KKKKM3J79C1WXWYX48ET`

👍 1

jercik marked this conversation as resolved

jercik commented

2026-10-21 12:13:18 +00:00

Review 01M5F5KKKKM3J79C1WXWYX48ET on head 3dab0c80: five findings and two unadjudicated claims, all about comment wording in the files j4k-align 6.7.1 rendered. I'm merging as is.

Nothing here changes what the workflows do. The comments come from align's templates, and editing the rendered copies would make the next j4k-align --fix revert them and the audit flag drift. The five findings are accurate and belong in the templates in j4k/align: the npm-mirror job comment's check inventory, the "three fields" count, the "OCI publisher" reference, "unlike the other publishers", and "the first step" (the ref check is the second step). That follow-up isn't filed yet, so the tracked items stay open on this PR.

The two unadjudicated claims (01M5F5PHFT57E0JYN6E66GYZP8, 01M5F5QJADMW339APRNPXKQ1X7) are the same question: nothing in the repo sets PRE_MIGRATION_BASELINE. That is intended. The release job never sets it, so the provenance check stays strict, and only an operator's baseline run sets it. That run exists: account-gate.sh post-npm --baseline fta-check 1.5.9 passed today with the variable set and accepted npm 1.5.9's refs/heads/main provenance. The comment's pointer to that run, which lives outside the repo, can be reworded in the same template follow-up.

Review `01M5F5KKKKM3J79C1WXWYX48ET` on head `3dab0c80`: five findings and two unadjudicated claims, all about comment wording in the files `j4k-align` 6.7.1 rendered. I'm merging as is. Nothing here changes what the workflows do. The comments come from align's templates, and editing the rendered copies would make the next `j4k-align --fix` revert them and the audit flag drift. The five findings are accurate and belong in the templates in `j4k/align`: the `npm-mirror` job comment's check inventory, the "three fields" count, the "OCI publisher" reference, "unlike the other publishers", and "the first step" (the ref check is the second step). That follow-up isn't filed yet, so the tracked items stay open on this PR. The two unadjudicated claims (`01M5F5PHFT57E0JYN6E66GYZP8`, `01M5F5QJADMW339APRNPXKQ1X7`) are the same question: nothing in the repo sets `PRE_MIGRATION_BASELINE`. That is intended. The release job never sets it, so the provenance check stays strict, and only an operator's baseline run sets it. That run exists: `account-gate.sh post-npm --baseline fta-check 1.5.9` passed today with the variable set and accepted npm 1.5.9's `refs/heads/main` provenance. The comment's pointer to that run, which lives outside the repo, can be reworded in the same template follow-up.

jercik merged commit af032b8806 into main

2026-10-21 12:13:46 +00:00

jercik deleted branch ci/npm-mirror

2026-10-21 12:13:46 +00:00

jercik referenced this pull request from a commit

2026-10-21 12:13:47 +00:00

ci: copy releases to npmjs from the GitHub mirror (#2)

jercik referenced this pull request

2026-10-21 13:40:22 +00:00

ci: re-align with @j4k/align 6.7.4 #3

jercik commented

2026-10-21 13:46:18 +00:00

Review items 174499 to 174503 are all confirmed and fixed. Each is a comment in a file that @j4k/align generates, so the fixes landed in align, not here: j4k/align#735 (released as 6.7.3) and j4k/align#736 (6.7.4). The re-align PR #3 brings both into this repository.

Item	Finding	Disposition
174499	The `npm-mirror` comment listed what the job checks and left out the provenance check	Fixed: the comment now says the job verifies the npmjs copy against the Forge release in the steps below
174500	The comment hard-coded "three" `package.json` fields the mirror rewrites	Fixed: it refers to the fields the repack step rewrites
174501	The `Release` step comment named an "OCI publisher" this repository does not have	Fixed: it describes what `@j4k/semantic-release-github-output` would do and why the tag on `HEAD` is used instead
174502	"Job-level, unlike the other publishers" pointed at workflows that are not in this repository	Fixed: it now reads "Set on this job only"
174503	The `workflow_dispatch` comment said the first step refuses other refs, but the check is in the "Resolve the version" step	Fixed: it names that step

gh-feedback cannot target a merged PR, so these five items stay pending in its tracker. This comment is their record.

Review items 174499 to 174503 are all confirmed and fixed. Each is a comment in a file that `@j4k/align` generates, so the fixes landed in align, not here: https://code.j4k.dev/j4k/align/pulls/735 (released as 6.7.3) and https://code.j4k.dev/j4k/align/pulls/736 (6.7.4). The re-align PR https://code.j4k.dev/j4k-oss/fta-check/pulls/3 brings both into this repository. | Item | Finding | Disposition | | --- | --- | --- | | 174499 | The `npm-mirror` comment listed what the job checks and left out the provenance check | Fixed: the comment now says the job verifies the npmjs copy against the Forge release in the steps below | | 174500 | The comment hard-coded "three" `package.json` fields the mirror rewrites | Fixed: it refers to the fields the repack step rewrites | | 174501 | The `Release` step comment named an "OCI publisher" this repository does not have | Fixed: it describes what `@j4k/semantic-release-github-output` would do and why the tag on `HEAD` is used instead | | 174502 | "Job-level, unlike the other publishers" pointed at workflows that are not in this repository | Fixed: it now reads "Set on this job only" | | 174503 | The `workflow_dispatch` comment said the first step refuses other refs, but the check is in the "Resolve the version" step | Fixed: it names that step | `gh-feedback` cannot target a merged PR, so these five items stay pending in its tracker. This comment is their record.

jercik referenced this pull request

2026-10-21 19:34:05 +00:00

ci: publish npm copies from main through the npm environment #5

jercik commented

2026-10-21 19:34:53 +00:00

Re 174499: Confirmed. The npm-mirror comment omitted the provenance check. Now it says the job verifies the npmjs copy against the Forge release in the steps below.