Commit 6061a710 authored by Vacaliuc, Bogdan's avatar Vacaliuc, Bogdan
Browse files

plan: initialization.md + Initialization-prompt.md v2.2 banner sync 



initialization.md §0 banner: replace v2.1 split (Administrator
read-only / §2.5 user-manual) with v2.2 contract: Administrator
Phase 1 walks §1-§11 in full including §2.5 under a phase-scoped
init-check-* allowlist; Phase 2 strictly read-only after the
irrevocable transition.

Initialization-prompt.md §0 banner: re-narrow the v1 fallback's
use-case list. The "v2.1 canonical path for write-capability
verification" framing is replaced with the actual v2.2 use case:
re-verify write capability after a credential rotation without
disturbing a running Administrator Phase 2 loop (since the Phase 1
→ Phase 2 allowlist transition is irrevocable, you can't ask the
running Administrator to re-do §2.5 — you launch this short-lived
session instead).

Co-Authored-By: default avatarClaude Opus 4.7 (1M context) <noreply@anthropic.com>
parent 11d1708b

plan/Initialization-prompt.md

+14 −11
Original line number Diff line number Diff line
@@ -12,15 +12,16 @@ 
>

> **When to use this file (not Administrator-prompt.md):**

>

> 1. **Write-capability verification (v2.1 canonical path).**

>    Administrator is read-only on the repository in v2.1, so it

>    cannot perform initialization.md §2.5 (push/delete a scratch

>    `init-check-*` ref to verify the credential grants write

>    capability). This Initialization-prompt.md session retains the

>    `init-check-*` push allowlist and is the canonical

>    agent-driven path for §2.5. Run it once after each credential

>    rotation; afterwards Administrator phase 1 just asks the user

>    to confirm "verified" before entering phase 2.

> 1. **Re-verify write capability after a credential rotation,

>    without disturbing a running Administrator Phase 2 loop.**

>    Administrator's push allowlist is phase-scoped (v2.2):

>    Phase 1 has the `init-check-*` allowlist, Phase 2 is

>    strictly read-only, and the transition is irrevocable. So if

>    your PAT or SSH key rotates while a Phase 2 loop is running,

>    you can't ask Administrator to re-do §2.5 — instead, launch

>    this Initialization-prompt.md session in any free clone; it

>    retains the same narrow `init-check-*` allowlist for one

>    short-lived session and exits cleanly.

> 2. You are constrained to three concurrent sessions total and

>    cannot afford a fourth session for the Administrator.

> 3. You want to re-run the full initialization checklist alone
@@ -31,8 +32,10 @@ 
>    Initialization)".

>

> **For routine startup,** start the Administrator agent first per

> `plan/orchestration.md` §13.1; use this v1 fallback session only

> for §2.5 write verification or the other cases above.

> `plan/orchestration.md` §13.1 — its Phase 1 walks §1-§11 in

> full (including §2.5) under the same `init-check-*` allowlist

> this fallback uses. Use this v1 fallback session only for the

> cases above.



This file (when used) is the prompt for a one-shot Initialization

session that walks the [initialization.md](initialization.md)

plan/initialization.md

+26 −17
Original line number Diff line number Diff line 
# {tasking-branch} — Initialization agent checklist



## 0. v2 deprecation banner (updated for v2.1)

## 0. v2 deprecation banner (updated for v2.2)



> **In v2 the standalone Initialization session is deprecated for

> routine startup.** Most of its work is now performed by **phase 1

> of the Administrator agent**; see

> routine startup.** Its work is now performed by **Phase 1 of the

> Administrator agent**; see

> [Administrator-prompt.md](Administrator-prompt.md) and

> `plan/orchestration.md` §6.4 / §9.6 / §13.1.

>

> **v2.1 split** (per orchestration.md §3 / §8 v2.1 contract):

> **v2.2 contract** (walks back the v2.1 split per orchestration.md

> §3 / §8 v2.2):

>

> - **Read-only checks** (§1, §2.1-§2.4, §3-§11): performed by

>   Administrator phase 1.

> - **§2.5 write-capability verification (push + delete a scratch

>   `init-check-*` ref):** **NOT** performed by Administrator,

>   because v2.1 makes Administrator read-only on the repository.

>   The user runs §2.5's commands manually OR launches the v1

>   standalone [Initialization-prompt.md](Initialization-prompt.md)

>   session (which retains its narrow `init-check-*` push allowlist).

>   Administrator phase 1 then asks the user to confirm "verified"

>   before entering phase 2 monitoring.

> - Administrator Phase 1 walks **§1-§11 in full**, including §2.5

>   write-capability verification. It pushes and deletes

>   `init-check-<YYYYMMDD-HHMMSS>-*` scratch refs under a narrow

>   phase-scoped allowlist (per orchestration.md §8 v2.2). Every

>   init-check-* ref is deleted before "Phase 1 complete." is

>   declared.

> - Once Phase 1 completes, the Administrator's push allowlist

>   drops to empty. **Phase 2 is strictly read-only** on the remote

>   (`git ls-remote` only).

>

> **v1 standalone Initialization-prompt.md fallback** retains the

> same `init-check-*` allowlist and is used when:

>

> - You need to re-verify write capability after a credential

>   rotation **without disturbing a running Administrator Phase 2

>   loop** (Phase 2 cannot re-enter Phase 1 logic — the allowlist

>   transition is irrevocable per orchestration.md §8 v2.2).

> - You're constrained to three concurrent sessions total and can't

>   afford a fourth slot for the Administrator.

>

> This file remains **canonical for the checklist content** —

> Administrator phase 1 walks §1-§11 (skipping §2.5), and the v1

> Initialization-prompt.md fallback or a manual user invocation

> covers §2.5. Re-init flows (credentials rotated, machine moved,

> Administrator Phase 1 and the v1 fallback both walk §1-§11.

> Re-init flows (credentials rotated, machine moved,

> `{base-branch}` switched) re-walk this document the same way.



---