[seankoji]

The release guide still described a release PR and optional RELEASE_PAT, although the workflow now validates the package and uses the CI GitHub App to push the version commit and tag atomically. Update the README to describe that flow and the existing npm OIDC publishing path.

Validation: lint, typecheck, 91 tests with coverage, and build/package verification pass on the reviewed head. This changes only the README; no release was run.

[bot-grumpy-engineer]

Approved. No blocking findings.

Advisory (P2/P3, or P1 past the round budget). These do not block approval:

• README.md: [P3] This line claims both paths run checks + build:verify. True for CI only: the tag-push path runs build:verify in the workflow (release.yml:69-72), but if the user pushes the tag before CI has finished, nothing verifies the packed package locally as the sentence implies. More importantly, the tag-push path never bumps package.json itself — it publishes whatever version the PR merged. A trailing note on the tag path ("push the tag only after the version-bump PR is merged; CI builds/verifies the tagged commit before publishing") would remove the ambiguity.
• README.md: [P3] Hidden coupling the old text surfaced and this rewrite drops: the dispatch path pushes the version commit and tag as seankoji-com-ci[bot], and release.yml:30 skips the tag-push run for that actor (github.actor != 'seankoji-com-ci[bot]') precisely because the dispatch run does the publishing. If the App identity or actor name ever changes, the tag push silently re-triggers a second npm publish. Worth one sentence so whoever touches the workflow knows why the actor check exists.
• README.md: [P3] Missing prerequisite for reproducing this setup: the workflow needs SEANKOJI_CI_APP_ID (repo variable) and SEANKOJI_CI_PRIVATE_KEY (secret) — git push --atomic uses the App token URL at release.yml:95, so without them the job dies at token generation. Name the two configuration items alongside the RELEASE_PAT reference that was just removed.