{
  "meta": {
    "agent": "planner",
    "task_id": "343",
    "title": "Release strategy — multi-repo, multi-sprint coordinated releases with staged validation",
    "created_at": "2026-04-08T12:00:00Z"
  },
  "inputs": [
    {
      "name": "issue-343",
      "type": "context",
      "ref": "https://github.com/AgentSDE/agent-core/issues/343",
      "notes": "Feature request for release strategy with multi-repo coordination and staged E2E validation"
    },
    {
      "name": "PR #342 learnings",
      "type": "context",
      "ref": "PR #342 pipeline refactor",
      "notes": "Manual RC branch + staged E2E validation workflow that this feature codifies"
    },
    {
      "name": "AGENTS.md",
      "type": "context",
      "ref": "AGENTS.md",
      "notes": "Codebase knowledge: directive system, phase pipeline, worktree management, gate mechanics"
    },
    {
      "name": "TaskEntity",
      "type": "file",
      "ref": "src/database/entities/task.entity.ts",
      "notes": "Current task data model — single repo, single issue, linear phase pipeline"
    },
    {
      "name": "PhaseRouterService",
      "type": "file",
      "ref": "src/phase-router/phase-router.service.ts",
      "notes": "Phase orchestration, gate mechanics, GATE_MAP by directive"
    },
    {
      "name": "WorktreeService",
      "type": "file",
      "ref": "src/worktree/worktree.service.ts",
      "notes": "Per-issue worktree creation, branch naming, cleanup"
    },
    {
      "name": "ArtefactsService",
      "type": "file",
      "ref": "src/artefacts/artefacts.service.ts",
      "notes": "Artefact routing by repo, sync to artefacts repo"
    }
  ],
  "outputs": [
    {
      "name": "release-strategy.md",
      "type": "spec",
      "format": "md",
      "content": "Comprehensive design document covering lifecycle, data models, pipeline changes, validation, API, and execution plan"
    },
    {
      "name": "release-manifest-schema.json",
      "type": "schema",
      "format": "json",
      "content": "JSON schema for release manifest data model"
    },
    {
      "name": "execution-plan.md",
      "type": "plan",
      "format": "md",
      "content": "Ordered implementation tasks with dependencies, complexity estimates, parallelisation, milestones"
    }
  ],
  "files": [
    {
      "path": "plan/release-strategy.md",
      "action": "create",
      "reason": "Main design document for release strategy feature"
    },
    {
      "path": "plan/release-manifest-schema.json",
      "action": "create",
      "reason": "JSON schema for release manifest data model"
    },
    {
      "path": "plan/execution-plan.md",
      "action": "create",
      "reason": "Actionable implementation task list"
    },
    {
      "path": "src/database/entities/task.entity.ts",
      "action": "inspect",
      "reason": "Understand current task model for release extension design"
    },
    {
      "path": "src/phase-router/phase-router.service.ts",
      "action": "inspect",
      "reason": "Understand gate and phase mechanics for release phase design"
    },
    {
      "path": "src/worktree/worktree.service.ts",
      "action": "inspect",
      "reason": "Understand worktree management for multi-repo RC branch design"
    },
    {
      "path": "src/artefacts/artefacts.service.ts",
      "action": "inspect",
      "reason": "Understand artefact routing for release-scoped artefacts"
    },
    {
      "path": "src/internal-adapter/internal-adapter.service.ts",
      "action": "inspect",
      "reason": "Understand phase progression and signal handling"
    }
  ],
  "steps": [
    {
      "id": "S1",
      "summary": "Define release lifecycle model — phases, actors, gates, directive mapping",
      "acceptance": [
        "Document defines release phases (planning → development → staging → validation → ship) with entry/exit criteria",
        "Each phase specifies which actor (agent/human/CI) owns it and what gates apply",
        "Existing directives (careful/auto/quick) are mapped to release-level gate behavior"
      ],
      "depends_on": []
    },
    {
      "id": "S2",
      "summary": "Design multi-repo coordination model — RC branches, dependency graph, merge flow",
      "acceptance": [
        "RC branch naming and creation strategy documented for multi-repo scenarios",
        "Cross-repo dependency tracking approach defined (which repo changes require coordinated changes in other repos)",
        "Promotion flow (feature → RC → staging → master) documented with conflict resolution strategy"
      ],
      "depends_on": [
        "S1"
      ]
    },
    {
      "id": "S3",
      "summary": "Design data models — ReleaseManifest, ReleaseTask, CrossRepoDependency schemas",
      "acceptance": [
        "ReleaseManifest schema defined with release ID, repo list, branch map, issue list, lifecycle state",
        "ReleaseTask schema links existing TaskEntity to a release with role/ordering metadata",
        "CrossRepoDependency schema captures repo-to-repo change dependencies",
        "All schemas include field reference tables with types and descriptions"
      ],
      "depends_on": [
        "S1",
        "S2"
      ]
    },
    {
      "id": "S4",
      "summary": "Design pipeline/phase extensions — validate, promote phases and release-scoped signals",
      "acceptance": [
        "New phases (validate, promote) specified with integration points in PHASE_ORDER and PhaseRouterService",
        "Signal protocol extensions for release-scoped completion documented",
        "ClaudeInvocationService env var additions for release context specified"
      ],
      "depends_on": [
        "S1",
        "S3"
      ]
    },
    {
      "id": "S5",
      "summary": "Design validation/gating model — E2E tier integration, failure handling, rollback",
      "acceptance": [
        "E2E tier execution as release gates documented (which tiers, when, on which branches)",
        "Failure handling strategy defined: auto-fix threshold, human escalation criteria",
        "Partial validation failure and promotion rollback paths documented"
      ],
      "depends_on": [
        "S4"
      ]
    },
    {
      "id": "S6",
      "summary": "Design API/webhook changes — release CRUD, status, promotion endpoints",
      "acceptance": [
        "REST API endpoints for release management specified (create, update, query, promote)",
        "Webhook event handling for cross-repo PR merges and CI results documented",
        "Integration with existing ControlApiModule controller pattern confirmed"
      ],
      "depends_on": [
        "S3",
        "S4"
      ]
    },
    {
      "id": "S7",
      "summary": "Write execution plan — ordered tasks with complexity, dependencies, milestones",
      "acceptance": [
        "Every task is specific enough to become a standalone GitHub issue",
        "Tasks have S/M/L complexity estimates and explicit dependency references",
        "Milestone structure defined (M1–M4) with parallelisation opportunities identified",
        "Execution plan is structured for both human review and agent-actionable breakdown"
      ],
      "depends_on": [
        "S1",
        "S2",
        "S3",
        "S4",
        "S5",
        "S6"
      ]
    }
  ],
  "risks": [
    {
      "risk": "Design scope creep — release strategy touches nearly every agent-core module",
      "mitigation": "Constrain initial design to minimum viable release flow (single-repo RC → validate → promote), then layer multi-repo as extension"
    },
    {
      "risk": "Sprint-aware planning adds significant state complexity",
      "mitigation": "Defer sprint tracking to follow-on design; focus on release lifecycle and validation gates first"
    },
    {
      "risk": "Cross-repo dependency conflicts during RC branch promotion",
      "mitigation": "Design explicit conflict resolution protocol with human escalation path"
    }
  ],
  "assumptions": [
    "Release strategy builds on existing TaskEntity and phase pipeline rather than replacing them",
    "E2E tier infrastructure (agent-core-e2e) is available and can be triggered programmatically",
    "Release manifests will be stored in agent-core-artefacts alongside existing task artefacts",
    "The design document is the sole deliverable — no code changes in this issue"
  ],
  "open_questions": [
    "Should releases be a new DB entity (ReleaseEntity) or metadata on TaskEntity groupings?",
    "What is the minimum set of E2E tiers required as a release gate vs. optional quality signals?",
    "Should sprint tracking be part of the initial release model or deferred to a follow-on?",
    "How should the release manifest handle issues deferred mid-sprint — close RC branch or rebase?"
  ]
}