Allow review by any eligible invited team member

AGENTS.md

@@ -24,6 +24,6 @@ If PR submission is unavailable, disclose it and give a concrete handoff: curren
 
 ## Review and maintenance
 
-One eligible independent human code-owner approval and the three required checks permit auto-merge. The primary normally reviews; the backup reviews primary-authored changes and can review when the primary is unavailable. Never self-approve, use AI acting through the author account as independent approval, or bypass waiting for an eligible reviewer. File changes invalidate approval; comments alone do not. Report open PRs as pending, not published. AI review is optional.
+One eligible independent human team-member approval and the three required checks permit auto-merge. The team consists of people invited to this repository whose invitation is accepted and whose effective permissions allow their approval to satisfy GitHub's required-review rule (write or higher under the standard roles). Any such team member may approve someone else's change; no designated primary approver or backup is required. Public readers and pending invitations do not qualify. Never self-approve, use AI acting through the author account as independent approval, or bypass waiting for an eligible reviewer. File changes invalidate approval; comments alone do not. Report open PRs as pending, not published. AI review is optional.
 
 Normal intake must not change instructions, CI, or approvers to accommodate a submission. Such maintenance and starter upgrades require an explicit owner request and a separate PR recording requester and authorized scope. The reviewer verifies that request at the existing approval checkpoint under existing rules. Preserve project knowledge, original evidence, and local adaptations; record selective adoption accurately. No automatic sync, schedule, or extra authorization gate. GitHub setting changes require authorized application and effective verification; merging configuration files is insufficient.

CONTRIBUTING.md

@@ -47,7 +47,7 @@ python3 checks/validate.py --root . --category document-status --format text
 
 Exactly `curator/internal-references`, `curator/evidence-provenance`, and `curator/document-status` are required documentation checks. Evidence relevance, wording, duplication, and unreachable external links are advisory findings, but a human reviewer can request changes. Passing metadata checks does not prove a claim true. AI assistance is optional; no AI sign-off or fourth gate is required.
 
-Request the primary owner's review, or the backup for primary-authored work or primary unavailability. One eligible independent human code-owner approval suffices; nobody self-approves and an AI using an owner's account is not independent human review. Without an eligible reviewer, the PR waits. Enable native auto-merge for this PR once authorized submission is available; repository-level enablement alone is insufficient. File changes invalidate approval and rerun checks; comments alone do not. Valid approval and passing checks authorize publication without a second manual confirmation.
+Request review from any invited team member with accepted repository access and effective write permission or higher. One eligible independent human approval suffices; no designated primary approver or backup is required. Nobody self-approves and an AI using the author's account is not independent human review. Public readers and pending invitations do not qualify. Without an eligible reviewer, the PR waits. Enable native auto-merge for this PR once authorized submission is available; repository-level enablement alone is insufficient. File changes invalidate approval and rerun checks; comments alone do not. Valid approval and passing checks authorize publication without a second manual confirmation.
 
 If native access cannot submit a PR, provide a handoff containing the current statement and source, proposed change, supporting evidence, unresolved questions, and related open PR if known. Say that submission is pending. Cowork PR support is unverified; a handoff does not demonstrate direct submission and must not silently become a Claude Code-only requirement.
 

README.md

@@ -4,7 +4,7 @@ Status: current
 
 Curator is a reusable starter for evidence-backed project knowledge. Each project gets an independent repository, separate from production code, with readable explanations, traceable sources, and one maintained home per topic.
 
-**Initial starter publication:** [subvisual/curator](https://github.com/subvisual/curator), authorized on 16 October 2026. The owner explicitly waived independent human seed review once for this initial snapshot, following independent AI review and local verification. This exception does not apply to future changes. Primary approver `ABZerra` is the current code owner; the backup remains intentionally pending, so primary-authored changes must wait for an eligible independent owner. Native settings must be verified separately; live review/merge behavior and Cowork PR submission remain unverified. License selection is deferred; public visibility alone does not grant a general reuse license.
+**Initial starter publication:** [subvisual/curator](https://github.com/subvisual/curator), authorized on 16 October 2026. The owner explicitly waived independent human seed review once for this initial snapshot, following independent AI review and local verification. This exception does not apply to future changes. Any invited team member with accepted access and effective write permission or higher may approve someone else's change. No designated primary approver or backup is required; an author still needs independent human approval. Native settings must be verified separately; live review/merge behavior and Cowork PR submission remain unverified. License selection is deferred; public visibility alone does not grant a general reuse license.
 
 ## Start here
 

SETUP.md

@@ -6,22 +6,22 @@ This procedure prepares an independent project knowledge repository. Local start
 
 ## A. Establish the repository from sources
 
-1. Record the destination (personal account or organization), project purpose, intended readers, primary human approver, backup, and contributor access. Prefer an organization for teams. Ask only for missing information. Projects are private by default; public visibility needs the project's explicit decision. All repository readers must also be able to access retained external originals.
-2. Verify the destination's plan supports required PRs, eligible code-owner review, required checks, stale-approval dismissal, strict branch freshness, and auto-merge for the chosen visibility. If an upgrade is needed, explain it and leave setup incomplete; do not weaken controls or make a project public as a workaround. Check current [GitHub ruleset availability](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets) against the actual account.
+1. Record the destination (personal account or organization), project purpose, intended readers, invited team members and their effective contributor/reviewer access. Prefer an organization for teams. Ask only for missing information. Projects are private by default; public visibility needs the project's explicit decision. All repository readers must also be able to access retained external originals.
+2. Verify the destination's plan supports required PRs, eligible independent team-member review, required checks, stale-approval dismissal, strict branch freshness, and auto-merge for the chosen visibility. If an upgrade is needed, explain it and leave setup incomplete; do not weaken controls or make a project public as a workaround. Check current [GitHub ruleset availability](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets) against the actual account.
 3. After external setup is authorized, create an independent repository from the reviewed starter, using `main` as the accepted branch. Inspect the initial seed before it is trusted: an independent eligible human must review the seed, including workflows and validators, before privileged execution or publication of accepted project knowledge. A first commit is not proof of reviewed provenance. If the account cannot support an independently reviewed bootstrap, stop external setup with a concrete limitation rather than self-approving or bypassing review.
 4. Record the verified starter source repository, commit, and release in `.curator/origin.json`, with project kind and an accurate adoption record. Do not invent a published release for this unreleased local starter. Preserve local adaptations and the original source identity for later selective upgrades.
 5. Apply and verify the native controls below. Copying a template, CODEOWNERS, workflow, or policy file does not apply GitHub settings. Leave setup incomplete until the effective controls are confirmed.
 6. Inspect supplied documents, notes, links, and accessible originals first. Preserve evidence using [CONTRIBUTING.md](CONTRIBUTING.md). Identify coherent topics and ask only about meaningful gaps or conflicts; use an interview when sources are sparse. Replace the template index with useful supported explanations and explicit unknowns, rather than empty folders or invented facts.
-7. Open the initial documentation PR. If the primary authored it, the backup reviews. Enable auto-merge for the PR; passing required checks and valid independent human approval publish the knowledge. No eligible reviewer means waiting, not a timeout bypass.
+7. Open the initial documentation PR. Any eligible invited team member other than the author may review. Enable auto-merge for the PR; passing required checks and valid independent human approval publish the knowledge. No eligible reviewer means waiting, not a timeout bypass.
 
-For **Curator itself**, the public destination is [subvisual/curator](https://github.com/subvisual/curator), with description “Curator — a reusable starter for evidence-backed project knowledge.” Primary approver `ABZerra` is an active organization member with repository administrator access; the organization has the Team plan. On 16 October 2026 the owner explicitly authorized a one-time exception to independent human seed review for the initial starter publication after independent AI review and local validation. This is not a standing bootstrap bypass for adopters or later changes. The backup remains intentionally pending. CODEOWNERS lists only the verified primary until an eligible backup is established; future primary-authored changes cannot obtain independent code-owner approval during this gap. Required reviews, stale-approval dismissal, required checks, and administrator enforcement remain required. Contributor scope and live enforcement behavior remain unverified. License selection is deferred, with no default license. No first project is required.
+For **Curator itself**, the public destination is [subvisual/curator](https://github.com/subvisual/curator), with description “Curator — a reusable starter for evidence-backed project knowledge.” Repository administrator `ABZerra` is an active organization member with repository administrator access; the organization has the Team plan. On 16 October 2026 the owner explicitly authorized a one-time exception to independent human seed review for the initial starter publication after independent AI review and local validation. This is not a standing bootstrap bypass for adopters or later changes. The owner subsequently replaced the designated primary/backup rule with approval by any eligible invited team member. Invitations must be accepted and the reviewer must have effective write permission or higher. No backup role is required, and authors cannot approve their own changes. Required reviews, stale-approval dismissal, required checks, and administrator enforcement remain required. Contributor scope and live enforcement behavior remain unverified. License selection is deferred, with no default license. No first project is required.
 
 ## Native review and merge configuration
 
 Use repository Settings and the account's supported native ruleset or branch-protection UI. Verify the effective state, including overlapping organization rules, rather than relying on a saved configuration screen. Both personal and organization destinations must satisfy the same outcomes.
 
-1. In `.github/CODEOWNERS`, configure a single wildcard rule covering every file with the verified primary and backup accounts, both eligible with the required repository access. Use actual verified logins; do not activate sample identities. Listing two owners allows either to approve; it does not require two approvals or decide whether the primary is unavailable. Keep coverage for the CODEOWNERS file and workflow/check changes themselves.
-2. In Settings → Rules → Rulesets (or the supported branch-protection equivalent), target `main`, activate enforcement, require pull requests and **one** approval, require code-owner review, and dismiss stale approvals after file/diff changes. Do not add a separate last-push approval requirement that would unintentionally demand a second reviewer. Comments alone must leave approval intact.
+1. Invite the intended team and verify each reviewer's accepted access and effective write permission or higher. Public visibility and a pending invitation do not make someone an eligible reviewer. Do not grant access to unrelated people or silently elevate read-only collaborators. The team is repository-specific, not everyone in the organization. Inspect inherited organization and team grants: GitHub counts any qualifying write-access reviewer, so effective access must match the intended invited team. There is no designated primary/backup pair or maintained reviewer roster in CODEOWNERS.
+2. In Settings → Rules → Rulesets (or the supported branch-protection equivalent), target `main`, activate enforcement, require pull requests and **one** independent approval, disable the designated code-owner review requirement, and dismiss stale approvals after file/diff changes. This lets any eligible invited team member approve someone else's change. Do not add a separate last-push approval requirement that would unintentionally demand a second reviewer. Comments alone must leave approval intact. Existing repositories adopt this through an owner-authorized maintenance PR; apply and read back the settings only after that change is reviewed. Removing CODEOWNERS alone does not configure the rule.
 3. Require precisely these three documentation status contexts, selecting the expected GitHub App when the UI supports it:
 
    - `curator/internal-references`
@@ -51,10 +51,10 @@ The following checks require observed evidence; publication alone does not mark
 
 | Area | Evidence required to mark verified |
 | --- | --- |
-| Destination and access | Exact account/repository identity, visibility, qualifying plan, reader and contributor access; verified primary/backup eligibility |
+| Destination and access | Exact account/repository identity, visibility, qualifying plan, reader and contributor access; verified invited-team reviewer eligibility |
 | Seed trust | Independent human review of the initial seed and workflow/check implementation before relying on it |
 | Effective protection | Active rules for `main`, no bypass, direct/force push and deletion restrictions, and administrative applicability |
-| Review eligibility | One eligible code-owner approval suffices; author cannot approve; owner-authored work waits for backup |
+| Review eligibility | One eligible invited team member's approval suffices; the author cannot approve their own change; no primary/backup roles |
 | Check enforcement | Exact three contexts, expected App binding where supported, all required; failed or missing context blocks merge |
 | Branch freshness | PR must be current with `main`; stale results do not permit merge after accepted-branch changes |
 | Approval lifetime | File changes dismiss approval and rerun checks; comments do not dismiss it |

checks/README.md

@@ -61,6 +61,6 @@ No parsing operation fetches external sources. The runner's GitHub API transport
 
 Bind required status contexts to the observed Actions app during [owner setup](../SETUP.md). That binding is not authentication of a unique workflow: trusted writers and administrators remain a governance boundary. Every workflow, check, instruction and ownership edit requires existing eligible human review and an explicitly requested maintenance PR. Proposed rules cannot authorize their own adoption. Test proposed validator code locally without privileged credentials; merge under the old validators. Use additive schema migrations when needed.
 
-The [auto-merge workflow](../.github/workflows/enable-auto-merge.yml) only enables GitHub's native auto-merge; it neither approves nor directly merges. After verifying protections, enable repository variable `CURATOR_AUTOMERGE_ENABLED=true`. Until then the workflow is dormant. A denied mutation leaves an unsuccessful workflow run and a pending enablement action; an assistant must report that limitation, never promise automatic publication. It is not a fourth required documentation check. Repository settings and CODEOWNERS are not configured by these files.
+The [auto-merge workflow](../.github/workflows/enable-auto-merge.yml) only enables GitHub's native auto-merge; it neither approves nor directly merges. After verifying protections, enable repository variable `CURATOR_AUTOMERGE_ENABLED=true`. Until then the workflow is dormant. A denied mutation leaves an unsuccessful workflow run and a pending enablement action; an assistant must report that limitation, never promise automatic publication. It is not a fourth required documentation check. Repository settings and collaborator permissions are not configured by these files.
 
 Action pins were resolved from public upstream tags: checkout v4.2.2 and setup-python v5.6.0. Parser dependencies are markdown-it-py 4.0.0 and mdurl 0.1.2, locked to downloaded wheel hashes. Dependency upgrades follow the same owner-requested maintenance workflow.