Create a project from scratch, on approval (blocked on an ownership decision) #29

New Issue

2026-09-08T22:06:50Z

dev-agent commented

2026-09-08 22:06:50 +00:00

Deferred by decision. Genuinely new scope — nothing in the spec suggests the agent creates repositories.

Shape

Operator directs the agent to start a brand-new project; the agent proposes creating the repository, the operator approves, the agent creates it and begins architecture planning. The approval half is reuse, not new mechanism: A4's gate machinery already does propose → revision-bind → approve → act.

The blocker: creating a repo makes the agent its owner

We established that in Gitea write access includes merging pull requests, and an owner can also set or unset branch protection — that is why B2 now requires the default branch to be protected, and why the sandbox is owned by dongar with the agent as a write collaborator.

An agent that creates its own repository starts as owner of it. It could therefore merge its own PRs and remove any protection it configured, silently reopening the gate we deliberately made structural. Having the agent configure its own constraints is not a constraint.

Options, none free:

Create under an org where the agent is a member rather than owner — preferred; keeps the ownership boundary that already works.
Create, then transfer ownership to the operator — an extra step that can fail halfway, leaving the agent owning a repo.
Accept an advisory PR gate on agent-created repos until the operator protects them — explicitly weaker, and easy to forget.

Decide this before implementing; the code is small, the property is not.

Deferred by decision. Genuinely new scope — nothing in the spec suggests the agent creates repositories. ### Shape Operator directs the agent to start a brand-new project; the agent proposes creating the repository, the operator approves, the agent creates it and begins architecture planning. The approval half is **reuse, not new mechanism**: A4's gate machinery already does propose → revision-bind → approve → act. ### The blocker: creating a repo makes the agent its owner We established that in Gitea **write access includes merging pull requests, and an owner can also set or unset branch protection** — that is why B2 now requires the default branch to be protected, and why the sandbox is owned by `dongar` with the agent as a write collaborator. An agent that creates its own repository starts as **owner** of it. It could therefore merge its own PRs and remove any protection it configured, silently reopening the gate we deliberately made structural. Having the agent configure its own constraints is not a constraint. Options, none free: 1. **Create under an org where the agent is a member rather than owner** — preferred; keeps the ownership boundary that already works. 2. **Create, then transfer ownership to the operator** — an extra step that can fail halfway, leaving the agent owning a repo. 3. **Accept an advisory PR gate on agent-created repos** until the operator protects them — explicitly weaker, and easy to forget. Decide this before implementing; the code is small, the property is not. ### Related - #27 per-project state (prerequisite) - #28 room per project - #26 multiple forges

dev-agent referenced this issue

2026-09-08 22:07:59 +00:00

Idea: one agent instance per project, with automated provisioning #30

dev-agent referenced this issue

2026-09-30 21:06:14 +00:00

Propose the Development Plan #84

dev-agent referenced this issue

2026-10-02 18:26:03 +00:00

Revise the deployment model: an agent host and tool VMs #90

Sign in to join this conversation.