132 lines
4.6 KiB
Markdown
132 lines
4.6 KiB
Markdown
# V1 Block 07 — Child Tasks
|
|
|
|
Status: Planned
|
|
|
|
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
|
|
|
|
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.
|
|
|
|
## Chunk 7.2 — Child entry defaults
|
|
|
|
Recommended Codex level: medium
|
|
|
|
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.
|
|
|
|
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
|
|
|
|
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.
|
|
|
|
BREAKPOINT: Stop here. Confirm `high` mode before implementing auto-completion propagation.
|
|
|
|
## Chunk 7.4 — Parent auto-completion
|
|
|
|
Recommended Codex level: high
|
|
|
|
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
|
|
```
|