Room per project, created by the agent #28

New Issue

2026-09-08T22:06:49Z

dev-agent commented

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

Deferred by decision — filed so the reasoning is not lost. Depends on #27 (per-project state).

Why it is attractive

With one room and several projects, a bare approve is genuinely ambiguous. A4 anticipates this and prescribes reply-relation binding in Matrix, with the agent asking when a bare approval is unclear.

A room per project makes the disambiguation structural instead of protocol: an approve in project X's room can only mean project X. Channel identity carries the binding — nothing to parse, nothing for the operator or the model to get wrong. That is the same move A4 makes elsewhere, and it replaces work rather than adding to it: no reply-relation threading, no approve <project> syntax, no ambiguity test.

Note A1 gives each agent a room, not each project, so this is an extension rather than a requirement.

Work

MatrixTransport becomes multi-room: /sync already returns every joined room, so the change is removing a filter and tagging inbound messages with their room, plus a target on sends. InboundMessage gains a room.
The currently configured room becomes the control room, where use <project> and project onboarding happen — a project's room does not exist yet at that moment.
Room creation is an external side effect, so it takes the intent-log treatment like opening a PR. Make it idempotent with a deterministic canonical alias (#nisse-dev-<project>:<domain>): a crash between creating the room and recording its id then resolves by alias lookup instead of creating a second room. Same trick as deterministic document ids in A17.
Agent creates the room and invites the operator when a project is first taken up.

Unverified

Whether the bot may create rooms and claim aliases on the homeserver. Worth checking before leaning on the alias for idempotency.

Deferred by decision — filed so the reasoning is not lost. Depends on #27 (per-project state). ### Why it is attractive With one room and several projects, a bare `approve` is genuinely ambiguous. A4 anticipates this and prescribes reply-relation binding in Matrix, with the agent asking when a bare approval is unclear. **A room per project makes the disambiguation structural instead of protocol**: an `approve` in project X's room can only mean project X. Channel identity carries the binding — nothing to parse, nothing for the operator or the model to get wrong. That is the same move A4 makes elsewhere, and it *replaces* work rather than adding to it: no reply-relation threading, no `approve <project>` syntax, no ambiguity test. Note A1 gives each **agent** a room, not each project, so this is an extension rather than a requirement. ### Work - `MatrixTransport` becomes multi-room: `/sync` already returns every joined room, so the change is removing a filter and tagging inbound messages with their room, plus a target on sends. `InboundMessage` gains a room. - The currently configured room becomes the **control room**, where `use <project>` and project onboarding happen — a project's room does not exist yet at that moment. - Room creation is an external side effect, so it takes the intent-log treatment like opening a PR. Make it idempotent with a **deterministic canonical alias** (`#nisse-dev-<project>:<domain>`): a crash between creating the room and recording its id then resolves by alias lookup instead of creating a second room. Same trick as deterministic document ids in A17. - Agent creates the room and invites the operator when a project is first taken up. ### Unverified Whether the bot may create rooms and claim aliases on the homeserver. Worth checking before leaning on the alias for idempotency.

dev-agent referenced this issue

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

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

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

Sign in to join this conversation.