docs(adr): verify ADR-0010's administrative-settings rollout gap

[ss-o]

Summary

Resolves checklist item 3 of ADR-0010's "Decision review required" section with actual verification instead of leaving it as an open question.

What was checked (2026-07-25, via gh api)

• GET /repos/{owner}/{repo}/private-vulnerability-reporting across all 88 non-fork repos in the org: 86 return enabled: true; the remaining 2 (.github-private, .trunk) 404 because they are private repositories and GitHub only exposes this feature on public ones.
• GET /repos/{owner}/{repo}/releases on the two repositories that have actually cut a release (zsh-lint, packaged zsh): both show immutable: false on their only release. No repo or org-level default toggle for this was found either.
• Looked for an API-visible signal for "advisory notifications" and concluded there isn't one: this is the incident owner's personal GitHub notification configuration, not a repository or organization setting.

What this does not resolve

Checklist item 2 (naming a backup incident contact and verifying that person's repository/advisory permissions) is unchanged and still blocks acceptance. That is a decision for a maintainer to make, not something derivable from repository state.

References

• decisions/0010-security-incident-response.md
• Issue #454

[Copilot]

Pull request overview

Updates ADR-0010’s “Administrative verification” section to replace an open audit note with concrete verification results (recorded 2026-07-25), and reflects that verification in the “Decision review required” checklist.

Changes:

• Replace the prior “not administratively verified” note with API-based verification details for private vulnerability reporting, release immutability, and notification scope.
• Mark checklist item 3 as completed and update the rationale for keeping the ADR in PROPOSED state to focus on the remaining escalation-route gap.

[ss-o]

Pushed a second commit naming wicoop as the backup incident contact (checklist item 2), per maintainer decision. All three resolvable checklist items are now closed; item 4 (accept/reject) is intentionally left for a maintainer.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (2)

decisions/0010-security-incident-response.md:78

• Escalation currently assumes the incident owner can add the backup as a draft-advisory collaborator, but the escalation condition is explicitly that the owner cannot act within the acknowledgement SLA. Reword this so the access-grant action is performed by whoever is available and authorized (e.g., any org maintainer with admin access to the affected repo).

If the owner cannot act within the acknowledgement SLA, escalate to wicoop and
add them as a collaborator on the affected repository's draft security
advisory, per the Ownership section above.

decisions/0010-security-incident-response.md:151

• This paragraph says “Items 1 through 3 are resolved”, but item 2 is not actually resolved if verification of backup permissions is still pending. Update this paragraph to avoid overstating acceptance readiness.

Items 1 through 3 are resolved; the remaining gaps (release immutability,
personal notification settings) are disclosed rather than hidden, not left
unaddressed. Item 4, the actual accept, amend, or reject decision, is a
maintainer call this ADR cannot make for itself.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (1)

decisions/0010-security-incident-response.md:89

• The escalation section says the owner cannot act, but then requires the owner to grant advisory collaborator access. That’s internally inconsistent and makes the escalation path unclear when the incident owner is unavailable.

If the owner cannot act within the acknowledgement SLA, escalate to wicoop.
The owner grants wicoop collaborator access on the affected repository's
draft security advisory at that time (see Ownership above). If the owner
cannot act specifically because ss-o, the only org admin, is unreachable, no
one else in the org can currently perform that grant, and wicoop responds
using whatever access they already hold until the org has a second admin.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (1)

decisions/0010-security-incident-response.md:88

• In the Escalation section, the first sentence says the owner cannot act, but the next sentence says “The owner grants wicoop collaborator access…”. Even with the later “if ss-o is unreachable” caveat, this is still internally confusing about who performs the grant in the handoff scenario. Rewording to explicitly name ss-o as the actor when reachable makes the escalation flow consistent and easier to follow.

If the owner cannot act within the acknowledgement SLA, escalate to wicoop.
The owner grants wicoop collaborator access on the affected repository's
draft security advisory at that time (see Ownership above). If the owner
cannot act specifically because ss-o (the org's only admin as of 2026-07-25)
is unreachable, no one else in the org can perform that grant, and wicoop