Summary

Describe the problem and fix in 2–5 bullets:

• Problem: PR CI skipped both release-check and the separate config docs drift workflow, so config baseline drift could merge unnoticed.
• Why it matters: schema or metadata changes can break pnpm release:check later on main even when the PR looked green.
• What changed: I added pnpm config:docs:check to the existing check-additional PR lane and wired it into the aggregated failure step.
• What did NOT change (scope boundary): I did not move full pnpm release:check into PR CI or change packaging/release gates.

Change Type (select all)

• Chore/infra

Scope (select all touched areas)

• CI/CD / infra

Linked Issue/PR

• Closes #
• Related fix(config): use static channel metadata in docs baseline #51161

User-visible / Behavior Changes

None.

Security Impact (required)

• New permissions/capabilities? (No)
• Secrets/tokens handling changed? (No)
• New/changed network calls? (No)
• Command/tool execution surface changed? (No)
• Data access scope changed? (No)
• If any Yes, explain risk + mitigation:

Repro + Verification

Environment

• OS: macOS
• Runtime/container: Node 24 / pnpm in the repo worktree
• Model/provider: N/A
• Integration/channel (if any): GitHub Actions CI workflow YAML
• Relevant config (redacted): N/A

Steps

1. Reproduced the current pnpm release:check failure locally and confirmed it was caused by pnpm config:docs:check.
2. Inspected the PR CI and workflow-sanity workflow definitions plus the historical PR run for fix(config): use static channel metadata in docs baseline #51161.
3. Added pnpm config:docs:check to check-additional and included it in the final failure aggregation.

Expected

• PR CI fails when config docs baseline drift is introduced.

Actual

• PR CI previously skipped that drift check, so the offending PR merged green.

Evidence

Attach at least one:

• Trace/log snippets
• Failing test/log before + passing after
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

What you personally verified (not just CI), and how:

• Verified scenarios: I verified the workflow diff, confirmed the new step is part of check-additional, and ran scripts/committer, which completed successfully and ran the repo check gate before committing.
• Edge cases checked: I confirmed the step is included in the aggregated failure summary so a drift failure cannot be silently ignored.
• What you did not verify: I did not wait for a live GitHub Actions PR run from this branch yet.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

• Backward compatible? (Yes)
• Config/env changes? (No)
• Migration needed? (No)
• If yes, exact upgrade steps:

Failure Recovery (if this breaks)

• How to disable/revert this change quickly: Revert this commit to remove the added config:docs:check step from check-additional.
• Files/config to restore: .github/workflows/ci.yml
• Known bad symptoms reviewers should watch for: unexpected PR failures in check-additional caused by legitimate config baseline changes that need regenerated baseline files.

Risks and Mitigations

List only real risks for this PR. Add/remove entries as needed. If none, write None.

• Risk: PRs that intentionally change config surfaces will now fail until the generated baseline files are refreshed.
  • Mitigation: the failure message already tells contributors to run pnpm config:docs:gen and commit the updated baseline files.