God object risk.
The first AI-generated design proposed one TaskManager that would own request
parsing, task validation, in-memory storage, due-date sorting, completion logic,
and future notification hooks.
That shape would make the POC harder for engineers to take over:
- One class would have too many reasons to change.
- Tests would need to set up unrelated behavior.
- Adding persistence later would risk breaking validation and sorting.
- The boundary between demo-only state and business rules would be unclear.
Split responsibilities before implementation:
- Boundary layer parses user input and formats output.
- Task service owns create, list, sort, and complete behavior.
- Task model defines typed fields.
- In-memory store is explicitly demo-only and replaceable.
The design is creating a god object. Split it by responsibility:
keep request parsing at the boundary, task lifecycle logic in a service,
task fields in a typed model, and demo-only state in an in-memory store.
Do not add persistence, notifications, or auth yet.
The corrected design is captured in
docs/examples/task-tracker-poc/DESIGN_SUMMARY.md and the takeover evidence is
captured in docs/examples/task-tracker-poc/ENGINEER_HANDOFF.md.