111k

Source Implementation Status

Audited implementation status for GitHub integration, source revisions, Agent submissions, and release control.

This page records the implementation state re-audited on August 3, 2026.

Status is binary:

  • Completed — the full user outcome has been verified
  • Not completed — at least one required part is missing or has not been accepted

Existing components inside a not-completed capability are listed as evidence. They do not change the final status.

Completed

CapabilityCurrent evidence
Project repository bindingProjects persist provider, repository, branch, sync mode, status, and provider metadata.
Repository sync recordsSync attempts and their status are persisted per repository link.
GitHub App integration surfaceApp configuration, installation callback, installation repository listing, and signed webhook endpoints exist.
GitHub source readsTopoo can resolve repository branches and commits, read repository trees, and import an immutable commit archive.
Node source browserThe Node editor can display the repository tree, branch, files, text previews, and derived source structure.
Change Request modelGitHub Pull Requests are normalized into Node Change Requests.
Check modelGitHub Check Runs are normalized and attached to Change Requests.
Immutable source snapshotDeployments can resolve and retain a source snapshot tied to a specific commit or uploaded manifest.
Deployment ledgerDeployment records preserve source identity, status, target, and artifact information.
Exact-revision redeploy pathA recorded GitHub commit or Topoo upload manifest can be selected as the deployment source.
Node Project Preview bridgeA recorded immutable Node Revision can build a full-Project Preview, persist the Base Release and Artifact, expose stable and immutable Preview URLs, and record approve or reject decisions.
Preview-to-Submission bridgeApproving a ready Node Project Preview creates a persistent Project-scoped delivery Submission linked to the Node Revision, Base Release, Artifact, actor, and decision.
Project Deployment object viewsThe production Project Deployment surface reads real Submissions, Releases, and Deployments records and supports a Node-to-Project Submission deep link.

Not completed — existing components

CapabilityExisting componentsMissing requirementsStatus
GitHub connection lifecycleApp, installation, repository, callback, and API paths exist.Reconnect, failure recovery, permissions diagnostics, and full production acceptance.Not completed
Branch and commit managementBranch and commit data are represented and used by source reads and deployments.Complete customer workflows for selecting, protecting, switching, and auditing branches.Not completed
GitHub event synchronizationPull Request and Check webhook events can trigger Node synchronization.Push, branch, tag, deletion, retry, replay, complete backfill, and production acceptance.Not completed
Automatic deliveryGitHub workflow dispatch and Topoo-hosted deployment paths exist.An accepted push or Pull Request path through Preview, approval, and Production.Not completed
Detached source snapshot lifecycleTopoo can retain immutable archives and manifest-based snapshots for browsing, rebuilding, redeploy, and rollback.A complete user flow that binds an uploaded snapshot to an existing or explicitly created GitHub repository before continued versioned editing.Not completed
Change Request workflowNode pages can show synced changes, checks, deliveries, and exact revisions.Complete GitHub branch and Pull Request delivery, comments, approvals, merge policy, protected-branch evidence, and provider reconciliation.Not completed
Agent Submission ChannelPersistent Project-scoped delivery Submissions now record a Node Revision, actor, Base Release, Artifact, summary, reason, optional Agent and Session metadata, and accept or reject decision.Enforced Agent identity and Session Grant, affected scope and Diff, Checkpoint history, authority evidence, Base Revision validation, stale-base detection, and conflict result.Not completed
Release traceabilitySource revisions, Node Previews, Artifacts, Submission decisions, Project Releases, and Deployments exist and are visible through the production control plane.One Project Release Candidate that records every included Submission, unchanged retained Node Version, integrated Check, approval, Release Artifact Set, and rollback target.Not completed
Node version managementAccepting a Submission marks its Node Revision accepted and pins the Project-to-Node reference; Preview and delivery histories are persisted.A distinct immutable Node Version ledger with exact accepted Submissions, dependency versions, Diff, Change Summary, Checks, Artifact linkage, semantic identity, and restore workflow.Not completed
Node consumer graphProject and Node references exist in parts of the control-plane model.A verified dependency graph showing which Projects consume each Node or Package version and which upgrades are available.Not completed
Project Release compositionRelease promotion, health Check, rolling release, Deployment, and rollback primitives exist for an immutable Deployment Artifact.One immutable Project Release Candidate and Release Artifact Set that pin the accepted version and Artifact contract of every included Node.Not completed
Visual Release ControllerProject Deployments now presents real Submission, Release, and Deployment views; Submission review and existing Release promotion controls are connected to production state.Accept-to-integration state machine, stale and conflict results, included Node Versions, integrated Checks, Release Artifact Set, automatic Preview, policy-driven same-Artifact promotion, and complete rollback evidence.Not completed
Common Node Workbench lifecycleNode browsing, repository content, editor modes, Node Settings, Preview history, immutable Artifact Preview, decision controls, and Submission handoff exist.One common surface for Diff, Checkpoints, Agent Session activity, Submissions, Change Summaries, Node Versions, Checks, consuming Releases, and rollback evidence.Not completed
Browser editor Session safetyThe browser editor can read and save per-path Draft content.Drafts currently use shared Node metadata keyed by file path rather than a first-class Session and Base Revision, so concurrent Session saves are not isolated.Not completed

Not completed — capability absent

CapabilityRequired outcomeStatus
Topoo-to-GitHub change deliveryTopoo UI and Agent edits create an authorized GitHub branch, commit, or Pull Request and reconcile the exact provider revision back to one Change Set.Not completed
Integration and merge queueOrdered, deterministic integration with stale-base and overlapping-change detection.Not completed
Automatic Session isolation and version recordingProject-scoped Work Sessions, managed Git worktrees or copy-on-write Workspaces, automatic Drafts, Checkpoints, source Revisions, Change Summaries, recovery, and cleanup for each writing Session.Not completed
External Agent connectionExecution-client adapter such as a Codex plugin, OAuth-backed remote MCP or API, Project and Node-scope resolution, Agent registry, Context Pack, and short-lived Session Grant.Not completed
Topoo Local RuntimeRegistered machine runtime that allocates isolated Session Workspaces, binds Agent process cwd, runs authorized commands, reports heartbeats and Checkpoints, and performs safe recovery and cleanup.Not completed
Channel policy enforcementWorkspace policies that separate draft, review, integration, preview, and production authority.Not completed
GitHub lifecycle and recoveryReconnect, permission diagnostics, webhook replay, idempotent reconciliation, rate-limit handling, and provider-outage recovery.Not completed
Project document governanceProduct Technical Documentation and Product Development Plan identities, paths, Node scopes, immutable revisions, joint diffs, Change Set linkage, and release evidence.Not completed

Current product boundary

Topoo Cloud currently has a substantial GitHub-connected source and deployment control-plane foundation, plus a first production-backed path from immutable Node Preview to persistent Project Submission.

The following real segment is now available:

immutable Node Revision
→ full-Project Node Preview
→ immutable Artifact
→ approve or reject
→ persistent Project Submission
→ accept or reject record

The critical control gap begins after Submission acceptance. Acceptance currently pins the Project's Node reference. It does not yet detect a stale Base Revision, combine concurrent accepted changes, publish a distinct Node Version, create a multi-Node Project Release Candidate, run integrated Checks, or seal a Release Artifact Set.

Topoo Cloud does not yet have complete GitHub write delivery, automatic external Work Session orchestration, Topoo Local Runtime, Project document governance, or the final Agent Release Controller. A Topoo-hosted Git service is not part of the target boundary; GitHub remains the canonical source and document history provider.

The next implementation milestone should close that exact gap rather than add another isolated deployment button or confirmation surface.

Live verification boundary

The authenticated production control plane was also inspected during this audit.

  • the Dashboard loaded with the active workspace and real operating data
  • the Projects page showed the live Topoo Cloud project and a completed local-source import
  • the Project Code view displayed the active branch and a browsable repository tree

The July 28 production verification additionally confirmed:

  • a ready immutable Node Project Preview with Base Release and Artifact identity
  • approve or reject decision persistence
  • automatic creation of a Project-scoped Submission after Preview approval
  • Node View Submission handoff into the exact Project Submission
  • real Submissions, Releases, and Deployments views in the existing Project navigation
  • Release and Deployment records remaining available without replacing the existing Project layout

This verifies the deployed project/source browsing path and the first Preview-to-Submission control-plane segment.

It does not verify GitHub App onboarding, webhook delivery, Topoo-to-GitHub branch or Pull Request delivery, multi-Agent integration, Project document governance, or production release-channel enforcement. Those capabilities remain classified from their current executable code and acceptance evidence, not inferred from the visible Code view.

Next milestone

The next milestone is an ambient automatic-version and integration-controller MVP.

The intended experience is:

configure GitHub, Topoo Local Runtime, Project, Nodes, Agent, Checks, and release policy once
→ open multiple external Sessions
→ state only the tasks
→ Topoo creates Project-scoped Work Sessions and resolves one or more Node scopes
→ Local Runtime isolates working state and Topoo records meaningful versions automatically
→ clean work integrates and reaches Preview without routine confirmations
→ only conflicts, authority expansion, destructive changes, failed policy gates, or configured Production approval interrupt the user

GitHub provides canonical source and document history in the background. The execution-client adapter connects the conversation. Topoo Local Runtime owns supervised local isolation. Topoo Cloud owns Project and document identity, Agent and Work Session identity, automatic Checkpoints and Change Summaries, integration safety, Release composition, Preview, Production, audit, and rollback.

Acceptance criteria for the next milestone

The next milestone is complete only when:

  1. Workspace and Project configuration persist the source connection, Local Runtime connection, Node scopes, Agent identity, Checks, and release policy once.
  2. two external Sessions can work concurrently under the same Project and Node without sharing mutable working state
  3. one coherent Work Session can hold several authorized Node scopes and produce separate Node-scoped Submissions
  4. Topoo automatically records Drafts, recoverable Checkpoints, source Revisions, and Change Summaries without requiring routine Git confirmation
  5. each Node Submission is bound to an Agent, Work Session, Node, and pinned Base Revision
  6. the controller detects a stale base or overlapping file and Resource ownership
  7. clean independent changes integrate automatically while an unresolved semantic conflict becomes one clear exception
  8. accepted changes produce immutable Node Versions that retain both concurrent Sessions' accepted work
  9. exact Node Versions, including unchanged retained versions, form one Project Release Candidate
  10. required Checks run against that integrated candidate
  11. Preview uses the candidate's immutable Release Artifact Set
  12. Production promotion reuses the accepted Release Artifact Set under the configured approval policy
  13. Node Workbench shows linked Session, submitter, Base Revision, Diff, Change Summary, Checks, Node Version, Artifact, and consuming Release
  14. Project Deployment shows included Node Versions, approval, Environment, Release Artifact Set, audit chain, and rollback target
  15. one Agent cannot overwrite another Agent's accepted Project or Production state