---
phase: 05-mvp-deployment
plan: 04
type: execute
wave: 2
depends_on:
  - 05-03
files_modified:
  - docker-compose.prod.yml
  - docker-compose.fullstack.yml
  - Dockerfile
  - .env.example
  - README.md
  - docs/deploy-architecture.md
autonomous: true
requirements:
  - PH05-05
must_haves:
  truths:
    - "Production handoff uses a bot-only compose artifact instead of the internal full-stack harness."
    - "Internal E2E compose brings up the bot, platform-agent, and shared volume with explicit health-gated startup."
    - "Deployment docs and env examples match the split compose artifacts and shared `/agents` contract."
  artifacts:
    - path: "docker-compose.prod.yml"
      provides: "Bot-only deployment handoff artifact"
    - path: "docker-compose.fullstack.yml"
      provides: "Internal E2E harness with shared volume and dependency gating"
    - path: ".env.example"
      provides: "Documented runtime contract for Phase 05 deployment"
  key_links:
    - from: "docker-compose.fullstack.yml"
      to: "docker-compose.prod.yml"
      via: "shared service definition or explicit duplication"
      pattern: "matrix-bot"
    - from: "docs/deploy-architecture.md"
      to: "docker-compose.prod.yml"
      via: "operator handoff instructions"
      pattern: "prod"
---

<objective>
Split deployment artifacts by operational intent so operator handoff and internal E2E testing stop sharing the same compose contract.

Purpose: Phase 05 needs an explicit bot-only production artifact and a separate full-stack compose harness aligned with the shared-volume design.
Output: `docker-compose.prod.yml`, `docker-compose.fullstack.yml`, and updated env/docs describing when to use each.
</objective>

<execution_context>
@/Users/a/.codex/get-shit-done/workflows/execute-plan.md
@/Users/a/.codex/get-shit-done/templates/summary.md
</execution_context>

<context>
@.planning/PROJECT.md
@.planning/ROADMAP.md
@.planning/STATE.md
@.planning/phases/05-mvp-deployment/05-RESEARCH.md
@.planning/phases/05-mvp-deployment/05-VALIDATION.md
@.planning/phases/04-matrix-mvp-shared-agent-context-and-context-management-comma/04-03-SUMMARY.md
@docs/deploy-architecture.md
@docker-compose.yml
@Dockerfile
@.env.example

<interfaces>
Current root compose contract:

```yaml
services:
  platform-agent:
    ...
  matrix-bot:
    build: .
    env_file: .env
    environment:
      AGENT_BASE_URL: http://platform-agent:8000
      SURFACES_WORKSPACE_DIR: /workspace
```
</interfaces>
</context>

<tasks>

<task type="auto">
  <name>Task 1: Create split prod and fullstack compose artifacts</name>
  <files>docker-compose.prod.yml, docker-compose.fullstack.yml, Dockerfile, .env.example</files>
  <read_first>docker-compose.yml, Dockerfile, .env.example, docs/deploy-architecture.md, .planning/phases/05-mvp-deployment/05-RESEARCH.md, .planning/phases/05-mvp-deployment/05-VALIDATION.md</read_first>
  <acceptance_criteria>
    - `docker-compose.prod.yml` defines only the bot-side runtime required for operator handoff.
    - `docker-compose.fullstack.yml` includes the internal platform-agent service, shared volume mounts, and health-gated startup rather than sleep-based sequencing.
    - `.env.example` documents the Phase 05 env contract without requiring the reader to inspect the old root compose file.
  </acceptance_criteria>
  <action>Create two explicit compose artifacts per PH05-05: a bot-only `docker-compose.prod.yml` for deployment handoff and a `docker-compose.fullstack.yml` for internal E2E runs. Align mounts and env values with the Phase 05 shared `/agents` volume direction from research. Reuse the existing Dockerfile unless a small compatibility edit is required. Do not keep the old single-file compose setup as the only documented runtime.</action>
  <verify>
    <automated>docker compose -f docker-compose.prod.yml config > /tmp/phase05-prod-compose.yml && docker compose -f docker-compose.fullstack.yml config > /tmp/phase05-fullstack-compose.yml && rg -n "^services:$|^  matrix-bot:$|^volumes:$|/agents" /tmp/phase05-prod-compose.yml && test -z "$(rg -n "^  platform-agent:$" /tmp/phase05-prod-compose.yml)" && rg -n "^  matrix-bot:$|^  platform-agent:$|condition: service_healthy|healthcheck:|/agents" /tmp/phase05-fullstack-compose.yml</automated>
  </verify>
  <done>Both compose files render successfully and express distinct operational roles: prod handoff vs internal full-stack testing.</done>
</task>

<task type="auto">
  <name>Task 2: Update deployment docs and operator guidance for the split artifacts</name>
  <files>README.md, docs/deploy-architecture.md</files>
  <read_first>README.md, docs/deploy-architecture.md, docker-compose.prod.yml, docker-compose.fullstack.yml, .env.example</read_first>
  <acceptance_criteria>
    - README or deploy doc tells the operator exactly which compose file to use for production vs internal E2E.
    - The docs describe the shared `/agents` volume behavior and reference the relevant env vars.
    - The old root `docker-compose.yml` is no longer the primary documented deployment path.
  </acceptance_criteria>
  <action>Update the repo docs so the Phase 05 deployment story is executable without inference: production handoff stays bot-only, full-stack compose is for internal E2E, and shared-volume file behavior is described in the same terms as the runtime artifacts. Keep documentation narrowly scoped to the shipped compose split; do not widen into platform-master or future storage design.</action>
  <verify>
    <automated>rg -n "docker-compose\\.prod|docker-compose\\.fullstack|/agents|prod handoff|full-stack" README.md docs/deploy-architecture.md .env.example && rg -n "production|deploy" README.md docs/deploy-architecture.md | rg "docker-compose\\.prod" && test -z "$(rg -n "docker compose up|docker-compose\\.yml" README.md docs/deploy-architecture.md | rg "production|deploy")"</automated>
  </verify>
  <done>The docs and env guidance match the new compose artifacts and no longer imply a single shared deployment file.</done>
</task>

</tasks>

<verification>
Render both compose files, then grep the docs for the new artifact names and `/agents` references so the operator contract is explicit and consistent.
</verification>

<success_criteria>
An operator can deploy the Matrix bot with the bot-only compose file, while developers can run the internal end-to-end harness separately without reinterpreting the deployment docs.
</success_criteria>

<output>
After completion, create `.planning/phases/05-mvp-deployment/05-04-SUMMARY.md`
</output>
