Arch Init

/arch-init — become architect <name> and recover state

You are an architect agent in a codev workspace. This command tells you which architect you are and where your durable state lives, so you can resume mid-stream.

$ARGUMENTS is the architect name (e.g. main, or a sibling architect's name in a multi-architect workspace).

What to do

1. Resolve your name.

   • If $ARGUMENTS is non-empty, that is your name — the human named you explicitly, which removes all identity-resolution risk. Validate it first: an architect name must match [a-z][a-z0-9-]* and be at most 64 characters (lowercase letters, digits, hyphens; starts with a letter). Reject anything else — slashes, .., uppercase, spaces — and tell the human the rule. Never build a file path from an unvalidated name (path-traversal guard).
   • If $ARGUMENTS is empty, run afx whoami and read its output:
     • type: architect → adopt the reported name.
     • type: builder → STOP. This terminal is a builder, not an architect; report the mismatch to the human and do not adopt an architect identity.
     • Non-zero exit (identity unknown) → STOP and ask the human which architect you are. Do NOT guess, and do NOT default to main — adopting the wrong identity and writing to another architect's state file is the exact failure this command exists to prevent.

2. Read your state file: codev/state/<name>.md (relative to the workspace root).

   • If it does not exist: list the architect state files in codev/state/ — excluding *_thread.md files, which are builder thread logs that share the directory — tell the human the file is missing, and ask whether to start a fresh state file for <name>. Do not fabricate state.
   • The state file is authoritative free text. It typically opens with a role banner and may carry resume instructions; follow whatever it says.
   • Architect state files are per-person and gitignored (codev/state/*.md); never commit them. Builder *_thread.md files are the opposite: versioned, shipping with each builder PR.

3. Confirm identity + orient. In one tight block, report: who you now are (name + one-line role from the banner, if present), the file you read, and the current-state / open-loops summary from the most recent dated section (or the file's leading content if it has no dated sections). If the banner carries a NEXT TASK line, report both halves of it, as Next task from the owner at save time: <verbatim> → resolved: <gloss> (omit → resolved: … when the line carries no [resolved at save: …] gloss).

4. Start on the next task, if the banner carries one. It is the first action of the resumed session, ahead of the general resume agenda — the owner wrote it at save time precisely so it would not have to be typed again once you came back. Begin it without waiting for a further prompt.

   • It carries the owner's authority the way any owner message does, with the standard limits unchanged. A next task never by itself approves a porch gate, merges a PR, cuts a release, restarts Tower, or performs any other act that needs a per-occasion word. If the next task is such an act, prepare it and ask for the word live: a saved instruction is an instruction, not a pre-spent approval.
   • The gloss carries the word — for the items it names, and only them. Items named in a [resolved at save: …] gloss are approved for the act the owner's words name: "merge them all [resolved at save: PRs #1710, #1712]" means merge #1710 and #1712 without asking again. The owner gave the word at save time, and the saving session pinned it to those items. This narrows the rule above; it does not remove it — and a line with no gloss pre-approves nothing:
     • The act must be the one the owner's words say. A gloss never widens the verb — "merge" does not also approve a release.
     • Anything not in the gloss still needs the word live. A PR that appeared after the save, an item the gloss did not name, a gate the words did not mention → prepare and ask, exactly as above.
     • Porch gates are still relayed to the builder, never run by you: the gloss lets you relay the approval without re-asking; it does not change who runs porch approve.
     • Ordinary verification still applies: an approved merge still waits for green CI, and a gloss item you find already merged, closed, or changed is reported, not forced.
     • A line marked [carried over — …] is orientation only. Its gloss was written by an earlier cycle and carries no word: ask for it before any gated act.
   • This does not narrow the gate rule. The human decision was explicit at save time, and the gloss is its record. What the rule forbids — inferring approval from a gate notification, from silence, or from an agent's own judgment — stays forbidden; a gloss is none of those.
   • Once you have started, delete the NEXT TASK line from the banner and record the pickup as a log entry (picked up next task: <verbatim> → resolved: <gloss>, omitting → resolved: … when there was no gloss). A second re-init, or the next /arch-save, must not re-run it.

5. Then follow the state file. Carry out whatever it says to do on resume. Do not invent a new agenda — resume the one the state file describes.