A vertical slice to bootstrap the product loop on the canonical zopu-code repo.
Primitives (packages/primitives, all tested + lint/type clean):
- GitRemoteRuntime: Gitea REST client (createIssue, createBranch,
createPullRequest, listIssues, getIssue) as an Effect context service with
a fetch-backed transport. Live-verified against puter/zopu-code.
- GitLocalRuntime: clone, addWorktree, commit, push, currentBranch,
setRemoteUrl over a pluggable Shell (host subprocess now, AgentOS VM exec
later). Tested against real temp git repos.
- agent-os: Codex support via @agentos-software/codex-cli — codexSoftware
bundle (codex+git), makeCodexAgentOsConfig(), codexSessionEnv() for the
OpenAI base URL/key.
Env:
- GITEA_URL/GITEA_TOKEN wired into convex.ts and convex.config.ts.
- .env.example documents the self-hosted git section.
Agents (packages/agents):
- zopu-dev: development agent that creates issues on the canonical repo and
starts autonomous work runs. git-remote tools (create/list/branch/PR) wired
to GitRemoteRuntime; start_workflow tool enqueues a work run.
- flue run zopu-dev verified live (lists/creates issues on real Gitea).
Backend (packages/backend):
- workflows.startIssueWork mutation: fetches a Gitea issue server-side and
admits a queued work run. The Codex VM spawn body is the next step.
Add a thin orchestration layer that drives the existing Orb runtime to
progress issue-scoped work. OrbProjectManager creates/resumes Orb runs,
assembles context packs, projects OrbEvents into durable project events,
detects needs-input and work-complete conditions, forwards follow-up
messages, and runs the Git/Gitea lifecycle on completion.
Port interfaces (OrbAdapter, OrbRunPort, GitLifecyclePort) make the
orchestrator testable with fakes. The real adapters wrap OrbRuntime and
runPostRunGiteaLifecycle without reimplementing Docker, AgentOS, or
OpenCode.
Idempotency: duplicate starts reuse active runs, duplicate completion
returns cached results, cancel is idempotent. Never auto-merges.
88 tests pass (19 orchestration + 12 event-mapping + orb suite), 2 live
tests skipped; lint and type checks clean.
The in-process DockerSandboxClient could never satisfy AgentOS 0.2.10's
sandbox serialization contract: AgentOS serializes sandbox mounts through
getSerializableClientConfig, which reads client.baseUrl and passes it to the
sidecar. An in-process object has no network endpoint.
Replace the custom adapter with the supported boundary: SandboxAgent.start
with sandbox-agent/docker, which starts a sandbox-agent server inside a
Docker container with a dynamically mapped host port and returns a
SandboxAgent client whose baseUrl both the main process and the sidecar
subprocess reach over 127.0.0.1. Dispose calls destroySandbox so no
containers are left behind.
Remove 700+ lines of dead DockerSandboxClient infrastructure (PID tracking,
log files, signal handling) now handled natively by the sandbox-agent
server. Add a sqlite_file database descriptor to AgentOs.create so session
storage works. Wrap command execution in sh -c for the SandboxAgent API.
Apply chmod 600 to the real OpenCode config path containing the gateway key.
The real proof with the main .env now passes all three stages:
ORB_STAGE_DOCKER_OK, ORB_STAGE_AGENTOS_OK, ORB_STAGE_MODEL_TURN_OK,
ending ORB_PROOF_PASSED with zero leftover containers.
Update README to describe the real SandboxAgent + Docker topology and
remove the misleading 'missing sidecar' limitation.
Fix detached process startup in docker-sandbox.ts: capture the real process
group PID via setsid, redirect stdout/stderr to durable log files, refresh
status and exit code after natural completion, make getProcessLogs return real
logs, and implement bounded TERM/KILL cleanup with no leftover containers.
Switch the adapter to node:child_process (supported by Bun) so tests execute
under vitest, add -i to docker exec so staged files reach cat, and assert the
launcher is nonempty before launch.
Ensure Orb creation disposes the VM before its sandbox on partial failure
(AgentOS creation or OpenCode linking), and dispose the VM before its sandbox
in OrbHandle.dispose. Fix the Effect state callbacks (tapError/sync/asVoid) and
prepareRepository branch/base shell quoting.
Split normalizeSessionEvent to stay under the complexity limit without
suppressing the rule. Raw outbound prompts stay unchanged; only persisted and
logged event copies are redacted.
Rewrite scripts/orb-proof.ts to emit explicit stable stage markers for Docker,
AgentOS/OpenCode, and the model turn; ORB_GATEWAY_* fall back safely to
AGENT_MODEL_* without printing secrets; an unreachable gateway is BLOCKED not
passed; container removal is verified after disposal.
Strengthen tests: drop the any-failure createOrb test and add focused Docker
lifecycle coverage (PID, logs, status, exit code, stop/kill, removal) guarded
only when Docker is unavailable.
Add the complete project-scoped Zopu chat, Signal extraction, and
work-routing loop:
Backend (signalRouting.ts):
- Agent-token-gated functions for the full routing cycle: list evidence,
create signal, list signals, list active issues, attach signal to
issue, create issue from signal, begin issue, get project context,
list projects
- attachSignalToIssue requires signal.projectId to exist and equal
issue.projectId (org equality alone is insufficient)
- createIssueFromSignal is idempotent: queries existing attachments
before creating, returns created/reused flag
- Duplicate attach retries return existing relation without emitting a
duplicate event
- All functions deny-by-default with agent token validation
Schema:
- Add signalIssueAttachments table with indexes by signal, issue, and
the composite (signalId, issueId) for idempotent lookups
Agent tools (tools/signals.ts):
- Nine Flue tool definitions bound to the organization-scoped agent
instance ID, calling the agent-gated Convex functions
- Organization ID never accepted as free input; always from the bound
instance
Zopu agent (zopu.ts):
- Comprehensive routing-loop instructions: assess actionability, identify
project, create signal only when actionable, route via attach or create,
explain outcome, optionally begin
- Wiring of routing tools into the agent definition
Tests (signalRouting.test.ts):
- Authentication: invalid token rejected on every function
- Project scoping: evidence, signals, issues scoped correctly
- Idempotency: duplicate attach, duplicate create-from-signal, duplicate
signal creation
- Attach vs create: both paths verified
- Cross-project rejection: signal and issue must be in same project
- Org-scoped signal attach rejected (no projectId)
- Provenance: exact raw text preserved through routing loop
- Begin issue: transition and auth verification
- Add db.ts: a typed ConvexHttpClient-backed PersistenceAdapter implementing
the full Flue store surface (submissions, streams, runs, attachments).
- Add app.ts: Hono server mounting Flue routing and registering the model
provider from @code/env/agent.
- Update zopu agent to read provider config via env() and switch
dev/build scripts to load ../../.env.
