[codeforester]

Summary

• add CODEOWNERS coverage for release workflows, VERSION, packaging metadata, locks, and release validators
• document the independent-review and emergency-recovery controls for production releases
• prepare the repository for the matching protected-main and v* tag rulesets

Validation

• UV_CACHE_DIR=/private/tmp/base-cli-uv-cache uv run --extra dev pytest -q tests/test_security_documentation.py tests/test_validate_docs.py
• Ruff and git diff --check pass

After this merges, apply the repository ruleset changes from #484: one approval, code-owner review, last-push approval, and immutable v* tags.

Relates to #484.

[codeforester]

Doc accuracy (verified live, false assurance in an incident-response context): this asserts a repository ruleset already protects v* tags from deletion/force-update, but verified directly against the GitHub API (gh api repos/basefoundry/base-cli/rulesets): only two branch-target rulesets exist ("Base branch naming", "Base default branch protection") and there is no tag-target ruleset at all. The branch ruleset's pull_request rule also shows require_code_owner_review: false and required_approving_review_count: 0 — code-owner review isn't enforced yet either. This PR's own description confirms the gap: "After this merges, apply the repository ruleset changes from #484: ... and immutable v* tags." The incident-response paragraph right below this assumes these controls hold — a reader relying on this doc during an actual credential-compromise incident would believe tags are immutable and CODEOWNERS is enforced when neither is true yet.

[codeforester]

Security gap: this file doesn't protect itself — no pattern matches /.github/CODEOWNERS. Once code-owner review is enabled via the planned ruleset change, a PR that only edits this file (e.g. removes an entry, adds a third owner) still won't require review from @codeforester/@rameshulugar, defeating the control this PR is meant to bootstrap.

[codeforester]

Scope too broad (verified via grep): /scripts/validate_* matches far more than "release validators." Confirmed: validate_consumers.py is invoked only from compatibility.yml, validate_docs.py only from docs.yml, and validate_coverage.py/validate_consumer_typing.py/validate_schemas.py/validate_contract_fixtures.py(.mjs) only from tests/full_validate.sh (ordinary PR quality gates). Once code-owner review is enforced, a routine PR touching e.g. validate_coverage.py or validate_docs.py gets blocked pending sign-off from exactly two named individuals, despite having nothing to do with packaging or releasing — contradicting this PR's and issue #484's stated "release-path" scope.

[codeforester]

Scope too broad: protecting the entire /pyproject.toml sweeps in unrelated dev-tooling config, not just release/packaging metadata — the file also contains [tool.pytest.ini_options], [tool.mypy], [tool.coverage.*], and [tool.ruff]/[tool.ruff.lint] sections. A contributor tweaking a lint rule or adding a pytest marker needs @codeforester/@rameshulugar approval under the same rule meant for release/packaging metadata, once enforcement is on.

[codeforester]

Doc gap: this prose enumerating what CODEOWNERS covers omits .github/workflows/issue-branch-policy.yml, even though the CODEOWNERS file protects it. A future maintainer trusting this doc as the authoritative list might remove/edit that CODEOWNERS entry not realizing it's intentionally protected, or be confused why that unrelated-looking workflow requires maintainer sign-off.