# V1 Block 07 — Child Tasks

Status: Completed

Purpose: Support breaking a large task into smaller owned child tasks without adding dependency complexity.

## Chunk 7.1 — Parent/child model rules

Recommended Codex level: medium

Status: Completed

Tasks:

Implement parent/child ownership fields and helpers:

- parent task id on child tasks
- list/query children by parent
- parent can be incomplete while children are planned/completed
- parent/child helpers must remain domain-only and UI-independent

Rules:

- This is not full task dependency support.
- Do not add arbitrary DAG/dependency logic.
- Children are owned by parent only.
- Child ownership does not block scheduling unless a later planned feature explicitly adds dependency behavior.

Acceptance criteria:

- Test: child references parent.
- Test: parent can query/aggregate children through helper.
- Test: child ownership does not create dependency/blocking behavior.

Execution notes:

- Added `ChildTaskView` as a domain-only read projection over task lists.
- Added `ChildTaskSummary` for direct child status counts.
- Exported child-task helpers through `lib/scheduler_core.dart`.
- Parent/child ownership uses existing `Task.parentTaskId`.
- Helpers query direct children and parent relationships without adding dependency/DAG behavior.
- Parent auto-completion is explicitly not implemented in this chunk.
- Added `test/child_tasks_test.dart` for ownership, aggregation, incomplete parent behavior, and scheduling non-blocking behavior.
- `dart format lib test`, `dart analyze`, `dart test`, and `git diff --check` passed.

## Chunk 7.2 — Child entry defaults

Recommended Codex level: medium

Status: Completed

Tasks:

Support row-style child entry data:

- child title
- priority up/down/dropdown value
- reward up/down/dropdown value
- time required
- optional project override

Rules:

- If no priority is set, children are inserted in the order added.
- Children can have their own reward, priority, difficulty, and time.
- Children inherit project from parent unless overridden.
- Reward can remain `not set`; do not treat missing reward as very low reward.
- Preserve original entry order for children that have no explicit priority.

Acceptance criteria:

- Tests cover child creation with explicit fields.
- Tests cover no priority preserving insertion order.
- Tests cover inherited project and overridden project.
- Tests cover reward `not set` remaining distinct from very low reward.

Execution notes:

- Added `ChildTaskEntry` for row-style child creation data.
- Child entries support title, nullable priority, reward, difficulty, duration, and optional project override.
- Child entries inherit the parent project when no override is supplied.
- Missing priority remains null so children without explicit priority can preserve row insertion order.
- Missing reward remains `RewardLevel.notSet`, distinct from `RewardLevel.veryLow`.
- Added tests for explicit child fields, project inheritance/override, reward not-set behavior, and no-priority row order.
- `dart format lib test`, `dart analyze`, `dart test`, and `git diff --check` passed.

BREAKPOINT: Stop here. Confirm `extra high` mode before implementing the child-task edge-case regression suite.

## Chunk 7.3 — Child-task edge-case regression test suite

Recommended Codex level: extra high

Status: Completed

Tasks:

Before implementing parent auto-completion, add or expand tests for edge cases that could make child tasks behave like unwanted dependency logic.

Cover these cases:

- parent with zero children does not auto-complete by accident
- parent with planned children remains incomplete
- child completion updates child state without forcing parent completion until all children are complete
- parent completion can force-complete remaining children only through the explicit parent-complete action
- child tasks keep their parent id when scheduled, pushed, moved to backlog, or marked complete
- children without priority preserve row insertion order
- children with priority can be sorted by priority without losing stable insertion order within same-priority groups
- parent project inheritance works
- child project override works
- child task reward `not set` remains distinct from very low reward
- no arbitrary dependency/DAG fields or scheduling-blocking behavior are introduced

Rules:

- Tests should name the business rule being protected.
- Prefer small fixtures over large scenario setup.
- Do not mark this chunk complete unless `dart analyze` and `dart test` pass.
- Do not implement new user-facing behavior in this chunk unless needed to make the edge-case tests compile against planned domain APIs.

Acceptance criteria:

- A dedicated child-task test group exists.
- Tests cover ownership, ordering, inheritance, and non-dependency behavior.
- Existing scheduling and backlog tests still pass.

Execution notes:

- Added a dedicated `Child task edge-case regressions` test group.
- Covered zero-child parent non-auto-completion, planned-child parent remaining incomplete, child completion not forcing parent/sibling completion, parent completion not forcing children before an explicit parent-complete action, parent-id preservation across schedule/push/backlog/complete operations, stable priority sorting, and direct-only ownership.
- Confirmed child project inheritance/override and `RewardLevel.notSet` behavior remain covered by child-entry tests.
- Added `ChildTaskView.childrenOfSortedByPriority` for stable priority ordering of direct children.
- Did not implement parent auto-completion, parent-complete force propagation, dependency/DAG behavior, or scheduling blockers.
- `dart format lib test`, `dart analyze`, `dart test`, and `git diff --check` passed.

BREAKPOINT: Stop here. Confirm `high` mode before implementing auto-completion propagation.

## Chunk 7.4 — Parent auto-completion

Recommended Codex level: high

Status: Completed

Tasks:

Implement completion rules:

- Parent auto-completes when all children complete.
- Marking parent complete force-completes remaining children.
- Completing from any child can provide a domain-level option/result to mark entire parent complete.
- Parent/child completion should update relevant task statistics without duplicating events.

Rules:

- Do not silently complete sibling child tasks when one child completes.
- Do not complete parent until every child is complete unless the explicit parent-complete action is selected.
- Do not add generalized dependency resolution.

Acceptance criteria:

- Test: all children completed completes parent.
- Test: parent complete force-completes children.
- Test: partial child completion does not complete parent.
- Test: completing one child does not complete siblings.
- Test: explicit parent-complete action records the correct completion state for parent and remaining children.

Commit suggestion:

```text
feat(tasks): support parent-owned child tasks
```

Execution notes:

- Added `ChildTaskCompletionService` and `ChildTaskCompletionResult`.
- Completing a child now completes its parent only when all direct children are complete.
- Completing one child does not complete siblings.
- Partial child completion leaves the parent incomplete and exposes `canCompleteParentExplicitly`.
- Explicit parent completion force-completes remaining direct children and records `forceCompletedChildIds`.
- Parent completion is direct-child only; no generalized dependency graph behavior was added.
- Completion propagation updates task status and `updatedAt` without adding duplicate statistics events.
- Added tests for all-child auto-completion, parent force-completion, partial completion, sibling safety, and explicit parent-complete result metadata.
- `dart format lib test`, `dart analyze`, `dart test`, and `git diff --check` passed.
