New projects from conversation (M2.5, PR B)

- propose_project(name, purpose, decisions) in a conversation goes up for
  a go-ahead (checked: a slug, not an existing project, no trailing
  question).
- On go, the provisioning checklist (D1): a repository with a README,
  protection on its default branch, the agent as a collaborator, a build
  VM, a deploy key, and the project entry as YAML with <...> to fill in.
- On "done", the agent reads its configuration again and adds the new
  project live (build_loop_agent(load=...); only additions), then checks
  what was provided (D4, verified, not assumed): permissions and
  protection as it sees them, then on a throwaway branch with an empty
  commit, a branch push must succeed and a push to the default branch and
  merging its own PR must be refused. The check's PR is closed and its
  branch deleted. Failures are said per item; nothing starts.
- Checked: the tracking issue (the distilled decisions, carrying the new
  item's ID), and the project's item, agreed and labelled `design`, whose
  first milestone is ARCHITECTURE.md and the build plan. A conversation
  waiting on provisioning doesn't close as idle.
- The walk replays exactly from its seed (item IDs too), and event IDs
  stay unique across simulated restarts, as a server's are.
- The test config holds output to 8192 tokens, under the test key's
  per-request cost cap.

Tests: new-project unit tests (checklist and its YAML parse as config, done
before the entry, what isn't set up, a checked project's record and first
PR, an existing name), protection enforced by a hook on the fake forge,
the walk proposing projects and saying done, and an e2e new project in a
repository the test operator provisions from the agent's checklist.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PPQ14L3LikyefCMFBqEbKE

docs/Development-Plan.md

@@ -190,7 +190,7 @@ between milestones (D2, D4). End-to-end: a two-milestone feature.
 - Deferred: a milestone with no changes that wasn't expected to change code is
   still raised with the operator (D4).
 
-**M2.5 Conversations and new projects.** *Needs discussion;* the design was agreed
+**M2.5 Conversations and new projects.** **Done** (#106 and this PR). *Needs discussion;* the design was agreed
 in this PR (`general` scope, L1, L5; the new-project sequence, D1). Work started in
 conversation, record issues carrying their item's ID, the new-project flow and its
 project entry (D1, D8, #29). After M1.4. End-to-end: a small new project, in a
@@ -205,8 +205,20 @@ deletes afterwards.
     settles a filing cut off by a crash.
   - A conversation closes after `tuning.loop.general_idle_s` without a message; a
     reply in its thread then starts a new one that continues it.
-- **PR B, new projects:** the proposal, the checklist, reload-and-verify, and the
-  tracking issue; the e2e with a per-run repository.
+- **PR B, new projects — done (this PR).**
+  - `propose_project(name, purpose, decisions)` goes up for a go-ahead.
+  - On go, the checklist: repository, protection, collaborator, build VM, deploy
+    key, and the project entry as YAML to fill in.
+  - On "done", the agent reads its configuration again and adds the new project
+    live (only additions). It then checks the access: the repository's
+    permissions and protection as the agent sees them, then in practice on a
+    throwaway branch with an empty commit (a branch push must succeed, a push to
+    the default branch and merging its own PR must be refused); the branch and PR
+    are removed. Anything that fails is said, and nothing starts.
+  - When all is well: the tracking issue with the distilled decisions, and the
+    project's item, agreed and labelled `design`, whose first milestone is
+    `ARCHITECTURE.md` and the build plan. A conversation waiting on provisioning
+    doesn't close as idle.
 
 **M2.6 Roles and capability profiles.** *Pre-approved.* `driver`, `helper`,
 `expert`, `classifier` (L9); escalation triggers; delegation and `ask_expert` on the