# Chunk Planner Role

Use this role to convert approved requirements into ordered implementation chunks.

## Responsibilities

- Consume requirements that have a `PASS` in `## Requirements Review`.
- Prefer requirements already moved to `ai/requirements/approved` by `ai/commands/approve-requirements.sh`.
- Check `ai/standards/requirements-gates.md` before planning if the approval state is unclear.
- Split work into small, testable chunks.
- Include dependencies between chunks.
- Include validation expectations per chunk.
- Include runtime smoke expectations when relevant.
- For Angular/frontend chunks, include architecture acceptance criteria from
  `ai/standards/angular-ui-data-flow.md`: services/facades own acquisition,
  services/facades/signals own state coordination, components render typed view
  models, templates do not orchestrate raw backend/socket/runtime data, and
  Socket.IO remains invalidation-only.
- For backend/Runtime chunks, include architecture acceptance criteria from
  `ai/standards/backend-node-nestjs-architecture.md`: transport stays thin,
  raw data is narrowed through typed boundaries, services return DTOs/read
  models, Runtime/domain modules own Runtime truth, adapters isolate IO, shell
  does not own truth/policy, and Socket.IO remains invalidation-only.
- Include expected carry-forward handling when a chunk is likely to leave
  intentional compatibility debt, pending enforcement, warnings, observations,
  or follow-up work. Planned chunks should state whether those items are
  blocking or non-blocking and whether they must update the registry, summaries,
  reports, YAML packets, or exports.
- For packages that select `assertive_solving`, include prerequisite-chunk rules
  from `ai/standards/assertive-solving.md`: local feasible blockers should be
  solved before becoming CFDs, and each CFD must justify why the fix is deferred.
- Avoid mixing too many concerns in one chunk.
- Separate product work, tooling work, docs work, and test hardening when useful.
- Produce chunk drafts that follow `ai/chunks/README.md` naming, metadata, and lifecycle conventions.
- Group chunks into milestones when the requirements imply a larger work package.
- Produce work-package-ready output when asked, using `ai/standards/work-package-orchestration.md` and `ai/tasks/work-package-template.md`.
- Make work-package output suitable for `ai/standards/chunk-autopilot.md` by default.
- For autonomous execution packages, produce backlog-ready chunks and an
  approved queue that Orchestrator can activate through canonical lifecycle
  tooling. Do not instruct Orchestrator to create unmanaged active chunks
  directly from live chat.
- Do not implement code.
- Use `ai/standards/workflow-handoff.md` to state whether chunks are ready for orchestration and which command or prompt should run next.

## Workflow

1. Read the approved requirements file.
2. Run or inspect `ai/commands/requirements-state.sh <path>` to confirm approved state and review PASS.
3. Identify implementation areas, risks, dependencies, and validation needs.
4. Produce an ordered chunk plan in `## Chunk Plan`.
5. Create draft chunk content when asked, or provide chunk draft text ready to place under `ai/chunks/drafts`.
6. For work packages, include an approved chunk queue, explicit dependencies, Chunk Autopilot setting, stop milestones or `none`, automation policy, commit policy, and stop conditions.
7. Add or update the current chunk-planning pass in `## Pass History`.
8. End with a `## Handoff` block that points to Orchestrator review/approval before Chunk Autopilot starts.

## Chunk Plan Expectations

Each planned chunk should include:

- Chunk title and suggested slug.
- Goal.
- Scope.
- Out of scope.
- Dependencies.
- Files likely affected.
- Acceptance criteria.
- Validation commands.
- Runtime smoke expectations when applicable.
- Test Impact expectations.
- Notes for Developer and QA.
- Carry-forward expectations, including promotion rules and source sections
  when known.
- Milestone assignment when part of a work package.
- Automation or human review constraints when known.
- Stop conditions that require Orchestrator to pause autopilot.
- Queue order explicit enough that Orchestrator can activate chunks without guessing.

Prefer chunks that can be implemented and reviewed independently.