CI-13 [HUMAN GATE]: Private-repository cutover — prove private-mode CI, budgets, runner trust; maintainer flips visibility for v0.3.0

[Chris0Jeky]

Wave: Smart CI Fabric (ADR-0066 §Acceptance conditions). Tracker: CI-00 #2324. Human gate — the maintainer performs the visibility change, the spend ceiling, the branch-protection edits and any runner registration; agents prepare and verify, never flip.

Context

Maintainer directive (2026-08-30): the repository goes private for the v0.3.0 release and must work on a personal GitHub Pro account first. The full checklist is docs/ci/PRIVATE_REPO_CUTOVER_CHECKLIST.md (reconciled from the pack for personal-account mode). This issue is the executable version.

A. Prerequisites (agent-verifiable, waivable only with a recorded reason)

• CI-01 baseline recorded; CI-09 storage under the 1 GB allowance or a spend decision recorded here.
• CI-02 planner in shadow mode with the recall report over >=20 PRs.
• CI-03 Smart CI / Required Gate in observation mode with zero false reds over >=20 PRs; landed verifier proven.
• CI-11 every external action SHA-pinned; hosted-only R4 fixture green.
• Rehearsal while still public, hosted-only, no runner attached: R0 docs PR, R2 ordinary PR, R3 migration/auth/MCP PR, R4 workflow PR, cancelled/superseded PR, normal merge -> bounded main verifier, direct-push simulation -> full escalation, nightly no-change skip, release dry-run.
• Public-asset review: GitHub Pages frontend (pages-frontend.yml), release assets, packages, docs links, the awesome-selfhosted/launch-kit references (#2242) — each has a decision (stays public elsewhere / moves / retires).
• Automated review integrations (Codex GitHub App, Copilot review) — private-mode billing verified, not assumed; review cadence adjusted so reviews run after CI stabilises, not after every micro-push.

B. Maintainer actions (in order; each recorded here with date + evidence)

1. Confirm GitHub plan (Pro) and set a monthly Actions spend ceiling + alert (Billing settings).
2. Pause merges briefly; capture current required-check and Actions settings (gh api repos/Chris0Jeky/Taskdeck/branches/main/protection, actions/permissions).
3. Register Smart CI / Required Gate as required; set strict: true; keep the three security contexts; decide enforce_admins / break-glass (CI-03 supplies the exact commands).
4. Flip sha_pinning_required on (CI-11).
5. Change repository visibility to private (Settings -> Danger zone). Agents never do this.
6. Re-check: Actions permissions, fork-PR approval policy, Dependabot, Pages/package/release visibility, runner association, collaborator list.
7. Run in private mode: R0, R2, R4 PRs, one merge (main verifier), one nightly dispatch, one no-publish release rehearsal; verify hosted-minute accounting against the ceiling.
8. Only now: register the isolated runners (CI-04) and switch CI_EXECUTION_MODE to hybrid; verify self-hosted jobs consume no hosted minutes and expose no secrets.
9. Resume merges; record post-cutover evidence on CI-00.

C. Rollback

• Previous workflow files stay reachable by tag/commit; the manual hosted full-qualification workflow stays available; runners can be detached in one step; previous branch-protection contexts are recorded in step 2. Do not flip visibility back merely to regain free minutes before understanding a failure — use the hosted override first.

Acceptance

• Sections A and B complete with evidence; the repository is private; v0.3.0 can be cut from a private repository with the required gate enforced.

[Chris0Jeky]

Two gaps in the A-to-I prerequisite set, found while building a standing v0.3.0 readiness view (PR #2438). Both are answerable in one reply; neither is urgent.

SC-6 in OUTSTANDING_TASKS.md permits the visibility change only after sections A to I of docs/ci/PRIVATE_REPO_CUTOVER_CHECKLIST.md are complete. Mapping those sections to their named owners against the live milestones gives this:

Section	Owner	State
A. Decisions (maintainer)	#2324, #2337	Human
B. Measure before changing	CI-01 #2325, CI-09 #2333	#2325 closed; #2333 open, v0.3
C. Planner and gate	CI-02 #2326, CI-03 #2327	Open, v0.3
D. Event topology	CI-03 #2327	Open, v0.3
E. Test right-sizing	CI-05 #2329, CI-07 #2331, CI-08 #2332	Open, v0.3
F. Runners	CI-04 #2328	Open, v0.3, human
G. Supply chain	CI-11 #2335	Open, v0.3
H. Nightly and release	CI-10 #2334	Open, v0.4
I. Rehearsal while still public	none named	unowned

Everything lines up except the last two rows.

Q1. Is checklist section H really a cutover prerequisite?

#2334 (CI-10: change-driven nightly coordinator, weekly full sweep, clean-from-tag release qualification) sits on the v0.4 milestone, but SC-6 makes section H a prerequisite for a v0.3.0 action. Those cannot both be right.

• A. Section H is genuinely required before cutover. Then #2334 moves to v0.3 and becomes a release blocker.
• B. Section H is not required before cutover. Then the checklist should say so, and SC-6's "sections A–I" narrows to the sections that are.
• C. Part of section H is required and part is not. Then it needs splitting at whatever boundary you name.

Q2. Who owns checklist section I?

Section I lists eleven pre-cutover rehearsal scenarios (R0/R2/R3/R4 PR classes, a cancelled/superseded PR, a normal merge to main verifier, a direct-push escalation, a nightly no-change skip, a weekly deep run, and a release dry-run with no publish), all hosted-only with no runner attached. No issue owns them, so nothing tracks whether they have been run.

• A. Seed a CI-14-style child issue under #2324 that owns the rehearsal matrix and its evidence.
• B. Fold it into #2327, which already owns the gate contract and event topology.
• C. Keep it as a checklist-only item you run yourself at cutover time, with no issue.

Not asserted

I have not changed any milestone, added any issue, or edited the checklist. The readiness view in PR #2438 records both rows as open questions rather than resolving them, so whichever way this goes the file follows the answer instead of pre-empting it.

[Chris0Jeky]

Maintainer decision packet applied (2026-09-03). The packet is a ruling record from the maintainer's decision cockpit, not evidence that any external action was performed; docs and OUTSTANDING_TASKS.md are updated in PR #2442.

Rulings for the CI-13 human gate:

• SC3 — Actions overage ceiling: $10/month hard ceiling. Applying it (Billing → Spending limits), confirming the Pro plan and verifying Codex/Copilot billing on a private repository remain the maintainer's own actions; none is inferred as done. Section A checkbox stays open until the setting is evidenced here (B2).
• SC8 — public-asset decision: private development repository + public release/source mirror. Releases, checksums/provenance and the GPL source stay public through a mirror; GitHub Pages keeps publishing; the launch kit and awesome-selfhosted wording point at the mirror. Mechanics seeded as CI-16 #2439; docs/ci/PRIVATE_REPO_CUTOVER_CHECKLIST.md A and docs/REVIVAL_PLAN.md commitment 6 record it.
• SC1 confirmed with the private-Pro approval-boundary amendment (ADR-0066; step J.6 re-checks the Actions approval policy in private mode).
• SC4 — no pre-ruling on strict / enforce_admins / break-glass; decided after the observation window.
• SC-5 (sha_pinning_required), SC-6 (visibility) and SC-7 (runners) stay blocked on their prerequisites.

[Chris0Jeky]

Correction to my earlier packet: Q2 was wrong, please disregard it. Q1 stands.

I claimed checklist section I had no owner. It does. Line 3 of docs/ci/PRIVATE_REPO_CUTOVER_CHECKLIST.md reads "Executable copy: CI-13 #2337 (record evidence there)", which covers section I exactly as it covers every other section. There is nothing to assign and no decision needed. Caught in review of PR #2438 and corrected there.

A second correction from the same review, in the opposite direction, which matters more:

Section F is not a human gate, and I had it in the wrong column. Its four boxes are isolated VMs, no host mounts or personal credentials with one job per host, a tested hosted override and offline-runner behaviour, and tested workspace/Docker/cache cleanup with a documented VM reset and revocation path. That is all agent-preparable and all of it must land before cutover. Only the registration tokens and the GitHub association are human, and those are SC-7, which runs after. Classifying #2328 as wholly human would send required pre-cutover engineering out of the technical queue and let SC-6 look ready while section F is unbuilt.

Q1 is unchanged and still needs your answer: CI-10 #2334 owns checklist section H while sitting on the v0.4 milestone, and SC-6 makes sections A to I prerequisites for a v0.3.0 action. Either section H is not truly required before cutover, or #2334 belongs in v0.3.

Noted separately: I have not touched OUTSTANDING_TASKS.md for the SC-3 and SC-8 rulings. PR #2442 owns that file and is applying the whole 2026-09-03 packet, so recording them from a second PR would put two writers on one seam.

[Chris0Jeky]

Q1: agent recommendation, not a ruling (coordinator pass, 2026-09-03).

The inconsistency: docs/ci/PRIVATE_REPO_CUTOVER_CHECKLIST.md section H is owned by CI-10 #2334, which sits on the v0.4 milestone, while SC-6 makes sections A to I a v0.3.0 prerequisite. Section H has three boxes, and they are not the same kind of work:

1. One coordinator owns nightly/quality; honest-green no-change night; weekly full sweep. Consolidation. Nothing in private-mode cutover depends on it; the nightlies keep running in private mode as they do today, only against the private minute allowance. docs/ci/SMART_CI.md §9 already places nightly consolidation in phase 3, behind a 100 percent recall gate that itself needs the SC-4 observation window to complete.
2. Mutation remains manual (ADR-0052). Already true since 2026-08-19; a checkbox to tick, not work.
3. Release rebuilds from the exact tag in a clean hosted context; SBOM/provenance and digest verification release-owned; a release dry-run succeeds with ordinary self-hosted runners offline. This is the only box cutover depends on: v0.3.0 is cut from the private repository, so the tag-driven release must be proven to run hosted-only with no runner attached. Its concrete residual today is the double trigger in ci-release.yml and release-security.yml (push: tags: v* plus release: published), already recorded on #2334.

Recommendation: option B, split the section rather than move the issue. Keep #2334 on v0.4 for boxes 1 and 2 (rename its section H ownership to "H.1 nightly consolidation"), and carve box 3 out as a small v0.3 child (CI-10a "clean-from-tag release qualification, hosted-only dry run", owner to be a Codex lane) that becomes the section H prerequisite SC-6 actually needs. CI-09 #2333 (section B) already owns the release cache and artifact boundaries, so CI-10a is a natural sibling of the two open #2333 PRs.

Why not the alternatives:

• A: move #2334 wholesale to v0.3. Pulls nightly consolidation, which is gated behind recall evidence the SC-4 window has not produced, onto the release-critical path. That makes v0.3.0 wait on v0.4-class work.
• C: drop section H from the A-to-I prerequisite. Leaves the private-mode release path unproven at the moment the first private release is cut, which is exactly the failure the checklist exists to prevent.

If you rule B, the agent side is: open the CI-10a child on v0.3, edit section H into H.1 (v0.4) and H.2 (v0.3), and update docs/releases/V0_3_0_READINESS.md table row H. No maintainer action beyond the ruling.

[Chris0Jeky]

Maintainer rulings, 2026-09-03 (in-session, later than the packet).

Q1 = A. Checklist section H is a cutover prerequisite in full. CI-10 #2334 moves from v0.4 to v0.3 (Priority I) and is a release blocker; no split, no CI-10a child. The maintainer accepted that this pulls work forward. #2334 depends on CI-01 (closed), CI-03 #2327 and CI-05 #2329, both already v0.3, so no other issue changes milestone. Its scope still triages #1210 and #2180 (no milestone).

SC-3 re-ruled: deferred, no paid overage. The packet's $10/month ceiling is superseded. GitHub Pro is confirmed; the included 3,000 minutes/month are the entire hosted budget and are spent on Linux jobs only. Windows (x2) and any macOS (x10) legs run locally (the laptop registered as the Windows runner under CI-04 #2328; agent-run proving checks until then) or carry a local fallback. GitHub's default $0 spending limit is the effective hard ceiling.

Still the maintainer's on this issue: at step J.7 read Billing → Spending limits back, confirm it shows $0, record it here; verify Codex/Copilot billing on a private repository. Checklist A box 1 is checked; box 2 and the Windows-runner box carry the ruling.

Recorded in OUTSTANDING_TASKS.md §J, docs/ci/PRIVATE_REPO_CUTOVER_CHECKLIST.md A/H, docs/releases/V0_3_0_READINESS.md and ADR-0066 (amendment) in the same PR.