You are the lead engineering agent responsible for shipping the first working Zopu dogfooding loop today.

You are not here to merely produce a plan. You must inspect the repository, create isolated Paseo workspaces, spawn parallel GLM 5.2 coding agents, supervise them, review their work, request corrections, integrate their branches, run the complete system, and leave the repository in a demonstrably working state.

You have shell access and may use the Paseo CLI to create and manage other Codex agents.

All child agents must use:

  --provider codex/glm-5.2

The current repository is the Zopu monorepo. It already contains product documentation, design documentation, technical documentation, Effect primitives, Convex backend code, web/mobile/desktop applications, agent code, project-management primitives, Signals, and partial AgentOS/Rivet integration.

The starting branch is expected to be:

  feat/projects-backend

Verify this rather than blindly assuming it.

The final integration branch should be:

  dogfood/v0

Your job is to manage the entire implementation through parallel isolated worktrees.

======================================================================
1. PRODUCT OBJECTIVE
======================================================================

Ship the smallest complete Zopu dogfooding loop for the Zopu repository itself:

1. The user opens the Zopu web application.
2. The user selects the Zopu project.
3. The project has access to:
   - product.md / PRODUCT.md
   - design.md / DESIGN.md
   - tech.md / TECH.md
   - AGENTS.md
   - repository source and Git history
4. The user sends a message through project chat.
5. Zopu stores the exact message as evidence and extracts a Signal.
6. The Signal either:
   - attaches to an existing related work unit; or
   - creates a new work unit.
7. For this version, an existing ProjectIssue may serve as the work-unit implementation.
8. Starting the work unit creates or resumes an execution run.
9. The Zopu orchestration agent delegates coding to an Orb.
10. The Orb consists of:
    - AgentOS
    - OpenCode
    - an attached Docker sandbox
    - repository checkout/worktree
    - project context
    - runtime tools
    - model-gateway configuration
11. OpenCode:
    - reads the issue and project context;
    - edits the repository;
    - runs tests;
    - iterates on failures;
    - asks questions when blocked;
    - commits and pushes a branch;
    - opens a pull request.
12. Events, Signals, steps, questions, artifacts, commits and the PR are shown in the work-unit card.
13. The user can send a contextual follow-up to the same work unit.
14. The same orchestration context and OpenCode run should continue when possible.
15. The user manually reviews and merges the PR.

The completed proof should be something like:

  User:
  “Add a health endpoint that exposes the current build commit.”

  Result:
  ✓ exact message evidence stored
  ✓ Signal created
  ✓ Work Unit created or updated
  ✓ work started
  ✓ Orb provisioned
  ✓ OpenCode session started
  ✓ repository changed
  ✓ tests executed
  ✓ branch committed and pushed
  ✓ pull request opened
  ✓ work card updated
  ✓ contextual follow-up reaches the active work

======================================================================
2. HARD SCOPE
======================================================================

This is a narrow dogfooding implementation.

Implement only:

- one user;
- one organization;
- one project;
- one repository: zopu-code;
- web application only;
- one primary mutating execution at a time;
- OpenCode as the coding harness;
- GLM 5.2 as the inference model;
- Docker as the full execution sandbox;
- AgentOS as the harness/orchestration environment;
- Convex as the existing control-plane backend;
- self-hosted Git/Gitea as source control;
- manual pull-request merge.

Do not build:

- general multitenancy;
- arbitrary repository onboarding;
- customer-facing billing;
- mobile UI;
- desktop UI;
- TUI changes;
- stable production deployment of generated applications;
- multiple sandbox providers;
- agent swarms;
- elaborate prioritization systems;
- complex work-unit status taxonomy;
- Slack, Telegram or email ingestion;
- broad refactors unrelated to the dogfooding loop;
- speculative frameworks that are not needed by the loop.

ProjectIssue may remain the backend representation of a Work Unit for this version.

Project events may represent execution steps and activity.

Project artifacts may represent:
- work.md;
- steps.md;
- agent reports;
- test output;
- diffs;
- commits;
- pull requests.

======================================================================
3. OPERATING RULES
======================================================================

Before changing anything:

1. Run:
   - pwd
   - git status
   - git branch --show-current
   - git remote -v
2. Read:
   - root AGENTS.md
   - product documentation
   - design documentation
   - technical documentation
   - smoke/testing documentation
3. Inspect existing packages and flows before creating replacements.
4. Confirm whether the current orchestration framework is Flue rather than Flask. Treat speech-to-text references to “Flask agent” as untrusted until confirmed in the code.
5. Inspect:
   - Signals primitive
   - ProjectIssue primitive
   - project workspace hooks
   - project-manager agent
   - Zopu agent
   - daemon
   - AgentOS registry
   - Git/Gitea actions
   - existing smoke tests
6. Search for current TODOs and unfinished contracts.
7. Reuse existing abstractions when they are sound.
8. Do not redesign the entire repository.

Engineering requirements:

- Follow existing Effect v4 conventions.
- Preserve dependency direction.
- Use tagged domain errors rather than generic thrown strings.
- Validate external data with schemas.
- Preserve exact provenance for user messages and agent events.
- Keep infrastructure implementation out of pure domain packages.
- Do not expose model, Git, Convex or infrastructure credentials in generated repository files.
- Never let generated model text become trusted evidence without provenance.
- Do not auto-merge pull requests.
- Do not run multiple mutating agents in the same Git checkout.
- Keep every child agent inside an isolated Paseo worktree.
- Every child agent must commit its work.
- Prefer that every child agent pushes its branch and opens a PR targeting dogfood/v0.
- If the Git CLI cannot open a PR automatically, require the agent to leave exact commands and a complete PR description.
- Do not let child agents merge their own branches.
- The lead agent reviews and integrates them.

When an agent is blocked:

- inspect its logs;
- send a focused follow-up using `paseo send`;
- do not restart from scratch unless the workspace is broken;
- continue supervising other lanes in parallel.

Do not stop after spawning agents. You must monitor and integrate them.

======================================================================
4. INITIAL BRANCH PREPARATION
======================================================================

Inspect the current branch.

If currently on feat/projects-backend:

  git pull --ff-only
  git switch -c dogfood/v0
  git push -u origin dogfood/v0

If dogfood/v0 already exists:

  git switch dogfood/v0
  git pull --ff-only

If the expected branch is different, inspect the repository history and choose the branch containing the current projects backend work. Do not discard existing uncommitted work.

Run the baseline checks before spawning agents. Record failures but do not spend the entire session fixing unrelated pre-existing problems.

Suggested baseline:

  bun install
  bun run check

Also inspect package-specific scripts and use the actual commands defined by the repository.

======================================================================
5. PASEO ORCHESTRATION
======================================================================

Verify Paseo first:

  paseo status
  paseo ls

If the daemon is unavailable, inspect:

  tail -n 200 ~/.paseo/daemon.log

Do not continue spawning until Paseo works.

For every child lane:

1. Create a worktree workspace:

   paseo workspace create \
     --isolation worktree \
     --mode branch-off \
     --new-branch <branch> \
     --base dogfood/v0 \
     --title "<title>" \
     --json

2. Read the returned workspaceId.

3. Start the child agent:

   paseo run \
     --provider codex/glm-5.2 \
     --workspace <workspaceId> \
     --title "<title>" \
     --background \
     --json \
     "<full lane prompt>"

4. Save:
   - branch;
   - workspaceId;
   - agentId;
   - task;
   - current status.

Maintain an orchestration note in a temporary file outside committed product code, for example:

  /tmp/zopu-dogfood-orchestration.md

Track:

| Lane | Branch | Workspace ID | Agent ID | Status | PR |
|------|--------|--------------|----------|--------|----|

Use:

  paseo ls
  paseo inspect <agentId>
  paseo logs <agentId>
  paseo send <agentId> "<focused instruction>"
  paseo wait <agentId>

Do not block waiting on one child while others are still running. Poll all first-wave agents periodically.

======================================================================
6. SHARED CHILD-AGENT PREFIX
======================================================================

Prepend the following instructions to every child prompt:

You are implementing one isolated lane of the Zopu dogfood v0 loop.

Repository base branch:
  dogfood/v0

Your branch is already isolated in a Paseo Git worktree.

Before changing code:

1. Read root AGENTS.md.
2. Read the product, design and technical Markdown files.
3. Read smoke/testing documentation.
4. Inspect the current implementation before proposing replacements.
5. Preserve the existing Effect v4, Convex, Flue, AgentOS and repository boundaries.
6. Do not edit generated Convex output manually.
7. Do not edit vendored repositories.
8. Do not modify mobile, desktop or TUI code unless this task explicitly requires it.
9. Do not build general multitenancy, arbitrary repository support or speculative abstractions.
10. Keep the implementation focused on the one-repository Zopu dogfooding loop.

While working:

- Make incremental changes.
- Preserve existing behavior outside your lane.
- Add focused tests.
- Use tagged errors and schema validation at boundaries.
- Do not store credentials in source code.
- Do not merge branches.
- Do not alter another lane’s primary ownership unless required to fix a compile contract. When cross-lane changes are unavoidable, keep them minimal and document them.

Before finishing:

1. Run formatting/linting for every changed file.
2. Run targeted tests.
3. Run package type checks.
4. Run the root check.
5. Clearly separate pre-existing unrelated failures from failures caused by your changes.
6. Review `git diff`.
7. Commit all intended changes.
8. Push your branch.
9. Open a pull request targeting dogfood/v0 when tooling permits.
10. Return:
    - summary;
    - changed files;
    - architecture decisions;
    - tests run;
    - exact failures;
    - environment variables;
    - PR URL or exact PR creation instructions;
    - remaining limitations.

======================================================================
7. FIRST-WAVE PARALLEL LANES
======================================================================

Spawn all four first-wave agents immediately.

----------------------------------------------------------------------
LANE A — PROJECT CHAT, SIGNALS AND WORK ROUTING
----------------------------------------------------------------------

Branch:

  dogfood/zopu-orchestrator

Title:

  Zopu Signals Orchestrator

Prompt:

Implement the project-scoped Zopu chat, Signal extraction and work-routing loop.

Inspect the existing:
- Zopu agent;
- Signals primitive;
- ProjectIssue primitive;
- Convex Signal functions;
- project-issue functions;
- current Flue routes and authenticated agent transport;
- project workspace hooks.

Goal:

A user sends a message in the selected project context.

The system must:

1. store the exact user message as evidence;
2. create a Signal only when the message contains an actionable problem, request, opportunity, blocker or decision;
3. inspect related open ProjectIssues;
4. choose one of:
   - attach the Signal to a related existing ProjectIssue;
   - create a new ProjectIssue from the Signal;
5. return a clear user-facing explanation of what happened;
6. optionally allow the issue to be started;
7. preserve project and organization scope;
8. be idempotent under retries.

Required tools or application capabilities:

- read selected project;
- read project context documents;
- list recent project Signals;
- list active ProjectIssues;
- create Signal from exact stored evidence;
- attach Signal to an existing ProjectIssue;
- create ProjectIssue from Signal;
- optionally begin the ProjectIssue.

Rules:

- The model must not supply or rewrite the raw source message.
- Store a reference to the exact persisted message.
- Do not create work from casual chat.
- Ask one focused clarification when genuinely ambiguous.
- Repeated delivery of the same message must not create duplicate Signals or duplicate attachments.
- Reject cross-project and cross-organization access.
- Use a proper relation if multiple Signals need to attach to one ProjectIssue.
- Do not create generic WorkUnit architecture in this lane unless the repository already has it and it is required.
- Do not implement background ingestion.
- Do not touch Orb runtime implementation.

Acceptance examples:

Message:
  “The work-unit card should expose the generated PR.”

Expected:
- exact message persisted;
- Signal created;
- attached to an existing UI/workspace issue if relevant;
- otherwise a new ProjectIssue is created.

Tests:

- authentication;
- project scoping;
- idempotency;
- attach versus create;
- exact-message provenance;
- casual conversation does not create work;
- cross-project rejection.

Likely ownership:

- packages/agents/src/agents/zopu*
- packages/agents/src/tools/*
- packages/backend/convex/signals*
- packages/backend/convex/projectIssues*
- packages/backend/convex/schema*
- Signal/project-issue primitives only as required.

----------------------------------------------------------------------
LANE B — ORB RUNTIME FOUNDATION
----------------------------------------------------------------------

Branch:

  dogfood/orb-runtime

Title:

  AgentOS OpenCode Orb Runtime

Prompt:

Build the first real Zopu Orb runtime as a focused infrastructure/application package.

Do not wire it into the existing project-manager agent yet. Provide the runtime contract, implementation and a bounded proof.

Definition:

An Orb is one logical execution workspace for one ProjectIssue run.

For this version it contains:

- AgentOS actor;
- OpenCode harness;
- Docker sandbox;
- mounted repository workspace;
- project context;
- model-gateway configuration;
- process/log handling;
- normalized execution events;
- cleanup lifecycle.

Required stack:

- existing Effect v4 conventions;
- @rivet-dev/agentos;
- @agentos-software/opencode;
- @rivet-dev/agentos-sandbox or the current supported equivalent;
- Docker sandbox provider;
- existing repository preparation primitives;
- existing model-gateway conventions.

Do not use `opencode serve` unless the repository already requires it for a proven reason. Prefer native AgentOS/OpenCode ACP integration.

Define a narrow domain and application contract:

- OrbId;
- OrbRunId;
- OrbSessionId;
- Orb state;
- run state;
- normalized OrbEvent;
- tagged failures.

Suggested operations:

- create or resolve Orb;
- prepare repository;
- attach Docker sandbox;
- open OpenCode session;
- send initial task;
- send follow-up;
- stream normalized events;
- execute commands;
- read process logs;
- cancel;
- collect results;
- dispose or suspend.

Keep product-domain concepts separate from infrastructure leases.

Do not make AgentOS VM state equal the work-unit state.

Actor identity must include:
- project;
- issue/work unit;
- run.

Runtime behavior:

1. Create AgentOS actor.
2. Create one Docker sandbox for the Orb.
3. Prepare a project checkout or worktree.
4. Mount the sandbox project directory into AgentOS at a stable path.
5. Configure OpenCode under its expected configuration location.
6. Run OpenCode inside AgentOS.
7. Execute Bun, package-manager, test and build commands through Docker.
8. Stream meaningful events without exposing secrets.
9. Support bounded cancellation and cleanup.
10. Preserve enough session identity to send a later follow-up.

Security:

- no permanent provider credentials in project files;
- no global Git credential;
- use run-scoped runtime credentials when possible;
- redact secrets from logs;
- restrict writable mounts;
- no production deployment capability;
- no automatic merge capability.

Proof fixture:

Provide one local command or opt-in integration test that:

1. creates an Orb;
2. starts a Docker sandbox;
3. writes or prepares a tiny TypeScript project;
4. opens OpenCode;
5. sends a bounded task;
6. executes one command in Docker;
7. streams events;
8. cancels or completes;
9. cleans up.

Document:

- environment variables;
- local startup;
- Docker requirements;
- AgentOS endpoint;
- model gateway;
- filesystem layout;
- current limitations.

Do not modify:
- Zopu chat behavior;
- project-manager delegation;
- web UI.

----------------------------------------------------------------------
LANE C — WEB WORKSPACE AND WORK CARDS
----------------------------------------------------------------------

Branch:

  dogfood/web-workspace

Title:

  Zopu Web Work OS

Prompt:

Turn the current project workspace into the minimal web Work OS required for dogfooding.

Use the existing Convex backend, project Signals, ProjectIssues, project events, artifacts and Flue agent transport.

Do not make backend schema changes unless a tiny compatibility fix is absolutely required. Coordinate through existing contracts.

Product projection:

- ProjectIssue appears to the user as a Work Unit.
- Signals are source evidence and inputs.
- Project events are the step/activity timeline.
- Project artifacts include plans, logs, diffs, commits and PRs.
- A selected Work Unit has contextual chat.
- Project chat is global within the selected project.

Required interface:

Header:
- Zopu;
- current project;
- project/runtime connection status;
- basic project switcher if already supported.

Main surface:
- global project conversation;
- active Work Unit cards;
- lightweight Signals display;
- persistent composer.

Collapsed Work Unit card:
- title;
- latest summary;
- linked Signal count;
- current activity;
- step count;
- artifact count;
- PR indicator;
- needs-input indicator when available.

Expanded Work Unit:
- objective;
- linked Signals and provenance;
- current plan or steps;
- event/activity timeline;
- questions/blockers;
- artifacts;
- commit or PR information;
- contextual chat composer;
- start or continue action.

Composer modes:

- Project
- Selected Work Unit

Project mode sends messages to the Zopu/global project agent.

Work Unit mode sends messages to the existing issue-scoped project-manager agent identity.

Do not create visible chat threads or session history navigation.

A follow-up to a selected Work Unit should use the same issue identity and continue the existing agent context.

Visual direction:

- dark;
- calm;
- Apple-like;
- large rounded surfaces;
- readable dense information;
- minimal borders;
- restrained accent;
- mobile-responsive web, but do not build native apps;
- no Kanban board;
- no model selector;
- no thinking-level selector;
- no raw infrastructure debug UI in the main experience.

Implementation guidance:

- Refactor oversized workspace components into focused components when useful.
- Keep queries/mutations in hooks.
- Keep presentation components mostly pure.
- Preserve Convex reactivity.
- Do not duplicate native/mobile abstractions.
- Make loading, empty, error and needs-input states clear.
- PR links must be directly usable.

Acceptance:

A signed-in user can:

1. open the Zopu project;
2. chat globally;
3. see a resulting Work Unit;
4. start it;
5. select it;
6. inspect Signals, events and artifacts;
7. send a contextual follow-up;
8. open a resulting PR.

Tests:

- event-to-card projection;
- artifact display;
- composer scope switching;
- selected issue identity;
- empty state;
- needs-input display.

----------------------------------------------------------------------
LANE D — SINGLE-NODE EXECUTION DEPLOYMENT
----------------------------------------------------------------------

Branch:

  dogfood/runtime-deploy

Title:

  Zopu Dedicated Runtime Deployment

Prompt:

Create the smallest reproducible deployment for the Zopu execution plane on a fresh Debian dedicated server.

Context:

- Convex is already deployed.
- The dedicated server has approximately 12 CPU cores and 40 GB RAM.
- Debian is freshly installed.
- The execution plane should initially be single-node.
- Docker sandboxes will execute repository workloads.
- The web app does not need to be deployed in this lane.

Deploy or document:

1. Docker Engine.
2. Bun.
3. single-node Rivet Engine / current required AgentOS runtime.
4. Zopu agent service.
5. Bun/Effect daemon.
6. Docker access required for Orb sandboxes.
7. persistent logs.
8. health checks.
9. restart behavior.
10. repository update workflow.

Prefer:

- Docker Compose for infrastructure where appropriate;
- systemd for long-running application services where useful;
- private networking;
- Tailscale when available;
- Caddy only for endpoints that genuinely need HTTP exposure;
- single-node persistent filesystem storage;
- non-root services where practical.

Do not introduce:

- Kubernetes;
- PostgreSQL solely for Rivet;
- multi-node coordination;
- public administration endpoints;
- secrets committed to the repository;
- web-app deployment;
- production generated-app hosting.

Deliverables:

- install/bootstrap script;
- Compose file or equivalent;
- systemd service files where useful;
- environment template;
- deployment documentation;
- health-check script;
- start/stop/restart commands;
- log inspection commands;
- update-to-commit procedure;
- rollback procedure;
- Docker cleanup guidance;
- disk-space monitoring;
- firewall/private-network notes.

Required environment groups:

- Convex;
- self-hosted Git/Gitea;
- model gateway;
- AgentOS/Rivet;
- Zopu agent;
- daemon;
- Docker sandbox;
- service authentication.

The deployment must be reproducible on a clean Debian host.

Do not require the developer’s MacBook to remain online after deployment.

======================================================================
8. FIRST-WAVE MONITORING
======================================================================

After spawning all four first-wave agents:

1. Record all agent and workspace IDs.
2. Run `paseo ls`.
3. Inspect each agent after a few minutes.
4. Read logs for stalled or questioning agents.
5. Send corrections when needed.
6. Ensure agents are not editing each other’s lanes unnecessarily.
7. Prevent lane B from wiring into project-manager prematurely.
8. Prevent lane C from inventing a new backend schema.
9. Prevent lane D from overengineering deployment.
10. Prevent lane A from creating a second competing work-unit model.

Use concise interventions.

Examples:

  paseo send <agentId> "Keep ProjectIssue as the v0 Work Unit. Do not introduce a second generic work-unit schema."

  paseo send <agentId> "Do not wire project-manager yet. Finish the Orb port, adapter and proof fixture only."

  paseo send <agentId> "Use existing Convex contracts. Avoid backend schema changes in the UI lane."

Wait until each first-wave agent is idle, then inspect:

  paseo inspect <agentId>
  paseo logs <agentId>

Review each branch yourself.

For every lane:

- inspect commit history;
- inspect diff;
- run targeted tests;
- run package checks;
- verify no secrets;
- verify no unrelated broad refactors;
- verify documentation;
- verify branch was pushed;
- verify PR targets dogfood/v0.

Do not merge a failing lane merely because the child says it works.

======================================================================
9. FIRST-WAVE MERGE PROCESS
======================================================================

Recommended merge order:

1. dogfood/zopu-orchestrator
2. dogfood/orb-runtime
3. dogfood/web-workspace
4. dogfood/runtime-deploy

Before every merge:

  git switch dogfood/v0
  git pull --ff-only
  git fetch origin
  git log --oneline --decorate --max-count=10 origin/<branch>
  git diff dogfood/v0...origin/<branch>

Run lane-specific checks.

Merge using the repository’s normal PR workflow when possible.

If merging locally:

  git merge --no-ff origin/<branch>

Resolve conflicts conservatively.

After each merge:

  bun install
  run targeted checks
  git push origin dogfood/v0

Do not squash away useful commits unless repository policy requires squashing.

======================================================================
10. SECOND-WAVE LANE — WIRE PROJECT MANAGER TO ORBS
======================================================================

Only spawn this lane after the Orb runtime branch is integrated into dogfood/v0.

Branch:

  dogfood/orb-wiring

Title:

  Project Manager Orb Wiring

Create its Paseo workspace from the updated dogfood/v0 branch.

Prompt:

Wire the existing ProjectIssue execution flow to the merged Orb runtime.

Goal:

The issue-scoped project-manager becomes a thin orchestration agent.

OpenCode inside the Orb performs repository implementation.

Required flow:

1. User starts a ProjectIssue.
2. The project-manager creates or resumes its Orb run.
3. The project-manager assembles a concise context pack from:
   - ProjectIssue;
   - exact Signal evidence;
   - project context files;
   - AGENTS.md;
   - relevant repository metadata;
   - previous work artifacts.
4. The project-manager sends the implementation objective to OpenCode.
5. OpenCode edits and verifies in the Docker sandbox.
6. Orb events are normalized into durable project events.
7. Meaningful updates refresh the issue summary.
8. OpenCode questions create a needs-input condition visible to the user.
9. A later contextual user message is forwarded to the same OpenCode session when the session remains valid.
10. A resumable replacement session may be created only when required by runtime loss, with previous context restored.
11. Verification runs in Docker.
12. Once verification passes:
    - commit;
    - push branch;
    - create PR using the existing Git/Gitea lifecycle.
13. Store:
    - branch;
    - commit;
    - diff;
    - verification report;
    - PR metadata;
    - agent summary.
14. Mark completed only when:
    - a PR exists; or
    - a verified no-change result is explicitly recorded.
15. Never merge automatically.

Refactor the current Git lifecycle so it can be invoked from the Orb/application layer without requiring a particular interactive Flue shell, while preserving compatible existing adapters.

Failure mapping:

- runtime unavailable:
  infrastructure failure with clear reason;
- missing user context:
  needs input;
- failed tests that can be repaired:
  agent continues;
- unrecoverable repeated failure:
  failed with logs and evidence;
- cancellation:
  terminate OpenCode and sandbox processes;
- Git rejection:
  preserve commit and expose exact failure;
- PR creation failure:
  retain pushed branch and retry safely.

Idempotency:

- starting the same active issue must not create duplicate active runs;
- repeated completion events must not create duplicate commits or PRs;
- follow-up messages must not accidentally create a separate unrelated issue;
- retries must reuse stable run identity where safe.

Tests:

- fake Orb adapter;
- fake Git adapter;
- first-message start;
- follow-up forwarding;
- needs-input handling;
- cancellation;
- duplicate-start prevention;
- successful PR completion;
- failed PR creation recovery;
- one opt-in live local integration test.

Do not add multi-agent parallel execution.

======================================================================
11. SECOND-WAVE REVIEW AND MERGE
======================================================================

Monitor the orb-wiring agent closely.

This lane crosses several boundaries and is the most likely to overreach.

Intervene if it:

- edits repository code directly from project-manager;
- bypasses the Orb abstraction;
- creates a new source-control system;
- duplicates the existing project issue lifecycle;
- exposes raw OpenCode event noise directly to the UI;
- auto-merges;
- starts several mutating runs for one issue.

Review and merge it into dogfood/v0 only after:

- fake integration tests pass;
- affected packages type-check;
- cancellation works;
- idempotency is demonstrated;
- no secrets appear in logs or artifacts.

======================================================================
12. FINAL LANE — END-TO-END DOGFOOD INTEGRATION
======================================================================

After all implementation lanes are merged, spawn the final integration agent.

Branch:

  dogfood/e2e-integration

Title:

  Zopu Dogfood End-to-End

Prompt:

Integrate and prove the complete Zopu dogfood v0 loop.

Do not add new product scope. Fix integration defects and missing glue only.

Required live scenario:

1. Authenticate.
2. Select or bootstrap the Zopu project.
3. Confirm project context files are available.
4. Send this or an equivalently tiny deterministic request through project chat:

   “Add a health endpoint that exposes the current build commit.”

5. Confirm the exact user message is durably stored.
6. Confirm a Signal is created.
7. Confirm the Signal creates or attaches to a ProjectIssue.
8. Confirm a Work Unit card appears.
9. Start the Work Unit.
10. Confirm project-manager delegates to an Orb.
11. Confirm AgentOS starts.
12. Confirm Docker sandbox starts.
13. Confirm repository checkout/worktree is prepared.
14. Confirm OpenCode session starts with the correct context.
15. Confirm OpenCode modifies the branch.
16. Confirm tests or verification run.
17. Confirm progress events update the work card.
18. Confirm artifacts are generated.
19. Confirm commit and push succeed.
20. Confirm a Gitea PR is created.
21. Confirm the web UI exposes the PR link.
22. Send a contextual follow-up to the same Work Unit.
23. Confirm the follow-up reaches the same active or resumably restored work context.

Extend the existing smoke/test infrastructure rather than creating a disconnected framework.

The smoke harness must support:

- preflight-only;
- one complete run;
- sanitized JSON report;
- bounded timeout;
- stable success marker;
- stable blocked marker;
- cleanup instructions.

Preflight checks:

- Convex reachable;
- authentication valid;
- project exists;
- Git repository reachable;
- Git credentials valid;
- daemon healthy;
- Zopu agent healthy;
- Rivet/AgentOS healthy;
- Docker healthy;
- OpenCode package available;
- model gateway reachable;
- GLM model usable;
- repository writable;
- Gitea PR creation available.

Verification matrix:

- primitive tests;
- backend tests;
- agents type check;
- daemon type check/build;
- Orb tests;
- web tests;
- web build;
- root check;
- smoke preflight;
- live dogfood scenario.

Produce:

  docs/DOGFOOD_V0.md

It must contain:

- architecture summary;
- exact service startup order;
- required environment variables;
- local MacBook development flow;
- dedicated-server runtime flow;
- exact demo procedure;
- health checks;
- logs;
- failure recovery;
- cleanup;
- known limitations;
- next incremental milestones.

Commit, push and open a PR targeting dogfood/v0.

======================================================================
13. FINAL INTEGRATION RESPONSIBILITIES
======================================================================

After the final agent completes:

1. Review its branch.
2. Run the full verification matrix yourself.
3. Merge it into dogfood/v0.
4. Push dogfood/v0.
5. Deploy or start the execution plane using the runtime runbook.
6. Run the real smoke flow.
7. Open the web application.
8. Verify the Work Unit card and contextual chat manually.
9. Verify the PR exists in the self-hosted Git system.
10. Capture exact remaining failures.

If the full live path cannot complete:

- identify the first broken boundary;
- fix that boundary;
- do not mask it with fake success data;
- rerun from a clean Signal or deterministic test issue;
- preserve logs and artifacts.

The final system must not claim that a PR exists unless it exists in Git.

======================================================================
14. QUALITY GATES
======================================================================

A lane is not done merely because code was generated.

Every merged lane must satisfy:

- no uncommitted intended changes;
- no secrets committed;
- no generated Convex files manually edited;
- no unrelated mobile/desktop/TUI changes;
- no second conflicting work-unit abstraction;
- no automatic PR merge;
- tagged errors for infrastructure failures;
- schema validation at external boundaries;
- idempotent retry behavior where relevant;
- focused tests;
- clear documentation;
- branch pushed;
- PR or merge record available.

The complete v0 must satisfy:

- project chat works;
- exact evidence is retained;
- Signal appears;
- work appears;
- work starts;
- Orb starts;
- OpenCode runs;
- Docker executes commands;
- events update;
- user can answer a question;
- changes are committed;
- PR is created;
- PR is visible in the UI.

======================================================================
15. RESOURCE AND CONCURRENCY LIMITS
======================================================================

For this v0:

- maximum one mutating Orb per project;
- maximum two child coding agents changing adjacent integration code at the same time;
- no parallel mutation inside one worktree;
- no agent may work directly in the lead agent’s checkout;
- heavy build and browser work stays in Docker;
- use bounded model and execution timeouts;
- terminate abandoned Docker containers;
- archive finished Paseo agents after all work is integrated.

When agents are no longer needed:

  paseo archive <agentId>

Do not archive them until their logs and work have been reviewed.

======================================================================
16. COMMUNICATION WITH THE USER
======================================================================

Do not repeatedly ask the user to choose between reasonable implementation details.

Make grounded decisions from the repository.

Ask the user only when blocked by something that cannot be inferred, such as:

- unavailable server credentials;
- unavailable Git token;
- missing model-gateway key;
- a required destructive infrastructure action;
- an irreversible product decision outside v0 scope.

When requesting input, provide:

- the exact blocker;
- the exact command or credential needed;
- what work continues without it;
- the safest default.

Continue supervising all unblocked lanes while waiting.

======================================================================
17. FINAL REPORT
======================================================================

When finished, provide a concise but complete report:

## Dogfood status

- Project chat:
- Signal extraction:
- Work routing:
- Web cards:
- Contextual chat:
- Orb runtime:
- Docker execution:
- OpenCode:
- Git commit/push:
- PR creation:
- Dedicated runtime:
- End-to-end smoke:

## Integrated branches

For each branch:
- purpose;
- final commit;
- PR;
- tests.

## Running services

- service;
- machine;
- port or endpoint;
- health status.

## Demo instructions

Exact steps to reproduce the loop.

## Known limitations

Only real limitations, not speculative roadmap items.

## Next three increments

Choose the three highest-leverage improvements after the dogfooding loop works.

Your mission is complete only when the dogfooding loop is either demonstrably working or reduced to one clearly identified external blocker with all other implementation complete.