Source-to-Deployment Boundary

Source and deployment are connected but they are not the same object.

Node delivery and Project deployment are also connected but they are not the same authority.

Source explains where a change came from.

Deployment explains which artifact is running, where it is running, and how it reached that environment.

Node Workbench and Lifecycle Model defines the canonical objects used on both sides of this boundary.

Source owns

• provider and repository identity
• branch or reference
• commit or source revision
• monorepo root path or package boundary
• author and review context
• sync and import state

Deployment owns

• the accepted Project Release identity
• the exact Node versions included in that release
• immutable Node Artifact identities and the sealed Release Artifact Set
• build and release status
• target environment
• promotion and rollback history
• domain and route bindings
• runtime version
• operator or Agent
• deployment time

Every deployment must reference the source revision that produced it, but deployment history must not be reduced to repository history.

Node delivery and Project deployment

A Node owns one problem-oriented delivery history. It can accept Submissions, publish immutable Node Versions, and produce Artifacts when it has a build capability.

A Project decides which Node versions form the product:

Session
→ Submission
→ Node Version
→ optional Node Artifact
→ Project Release Candidate
→ Release Artifact Set
→ Preview
→ Approval
→ Production

Publishing a Node Version does not silently update a Project. A Project must explicitly accept that version into a Release Candidate. This preserves local change: one Node can advance while every unchanged Node remains pinned to its previously accepted version.

Editor and deployment boundary

Node Workbench is the primary interaction surface for Source editing and Node lifecycle state.

It may show:

• Code, visual, workflow, schema, document, or Agent editor adapters
• working Diff and Base Revision
• Submissions and Change Summaries
• Checks, Node Versions, Artifacts, and Node Preview
• which Project Releases consume the Node Version

These editor adapters operate on the same canonical Source. A visual or no-code editor must not create an unversioned state that bypasses Source, Diff, Submission, or audit.

Project Deployment remains the authority for integrated Preview, Production promotion, Environment binding, and rollback. Putting lifecycle controls inside Node Workbench does not transfer Production authority to the editor, Node, Agent, or Session.

Deployment entry modes

Topoo supports three ways to bring work into the deployment system. They share the same release, audit, and runtime model after the source snapshot is created.

GitHub synchronization does not have to mean that every commit immediately overwrites Production. A Project can choose to:

• synchronize source without deploying
• automatically create an isolated Preview
• promote automatically after required checks pass
• require human approval before Production promotion

The entry mode changes how source arrives. It must not weaken the controls that determine what is allowed to run.

Change summaries

Every accepted source change must carry a human-readable change summary. A Git commit message may be part of that summary, but it is not the complete audit record.

A change summary should explain:

• what changed
• why the change was needed
• who requested it
• who or which Agent performed it
• which files, modules, resources, or behaviors may be affected
• which checks were run and whether they passed
• which commit, build, artifact, and deployment were produced
• which approval and promotion decisions were made
• whether the change was later superseded or rolled back

Topoo should generate an initial summary from the request, source diff, Agent activity, and validation results. The summary remains reviewable so that a person can correct the explanation before promotion.

The result is an audit trail that explains intent, not only file history.

Release control

Topoo may accept changes from people and multiple Agents, but production promotion must pass through one deterministic release-control path.

The release controller is responsible for:

• accepting channel-specific submissions
• validating the expected base revision
• detecting overlapping file or resource ownership
• building and testing one integrated source state
• creating a versioned release artifact
• sealing one accepted Release Artifact Set
• promoting only that accepted Release Artifact Set
• recording who or what submitted, integrated, approved, and deployed the change

An Agent submission is a proposed change, not an instruction to overwrite the current production state.

Multi-Agent isolation

A Project may have ten or more Agents working at the same time across several Nodes. One Node may also receive work from several Sessions or Agents, and one coherent task may cross several Nodes. Concurrency must not mean that the Agents share one mutable working copy or overwrite one another's unfinished work.

Node carries the durable problem, responsibility, permissions, source scope, and delivery history. Work Session is a temporary Project-scoped transaction that may be created in Codex, VS Code, Claude, or another client and linked to one or more authorized Nodes.

Each Agent task receives:

• a bounded task and expected base revision
• an isolated Git worktree, snapshot, or equivalent Session Workspace
• an explicit source and resource scope
• its own change summary, checks, and submission record

Topoo then:

• detects overlapping files, dependencies, resources, and responsibilities
• keeps unaccepted Agent work outside the integrated source state
• reviews and merges accepted submissions through release control
• builds and tests the resulting integrated revision
• creates a deployment only from that accepted, immutable revision

An Agent can propose a change. It cannot silently redefine the current Project state or independently replace Production.

Submission channels

Channels can express different authority:

The exact labels may evolve, but submission authority and deployment authority must remain separate.

Required traceability

A release record should be able to answer:

• which source revision was used
• what changed and why
• which person or Agent requested and performed the change
• which submissions were included
• which checks passed or failed
• which artifact was produced
• which environment received it
• who or what approved and promoted it
• whether rollback is available

This traceability is the foundation for safe multi-Agent delivery.

From any running deployment, an operator should be able to trace:

Deployment → Release Artifact Set → Node Artifact → Node Version → Source Revision → Change Summary → Submission → person or Agent → Checks and Approval