zopu-code/docs/dogfood-plan.md

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
   --base dogfood/v0
   --title "