Reviewer-Gate Task Right-Sizing

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

A feature adds a parser and UI result display. Teaching parseLine(text) returns a value or identifiable parse error; UI presents both states. Avoid one task per line or one unreviewable whole-product task.

Mechanism

Draw boundaries around independently reviewable behavior with inputs, deliverables and checks. Parser owns its contract/fixtures; UI consumes the settled contract and owns interaction checks. Coordinate coupled signatures/callers and keep setup/docs/tests with the deliverable they support. Retain integration verification.

Bad example

Create tasks for every variable/line and scatter UI signature adaptations across unrelated parallel tasks, leaving no owner for complete behavior.

Good example

Define two teaching deliverables: parser success/error contract with normal/empty/invalid checks; UI result/error feedback and recovery consuming that contract. Coordinate coupled signatures/call adaptations in one coherent delivery, state dependencies and add final integration checks. Each task has an independently acceptable/rejectable result, not a line-count boundary.

Why the change matters

Tiny fragments lack behavior; oversized tasks obscure independent review. Contracts provide meaningful verdicts while dependencies/integration preserve cross-task correctness.

Observable expectation

An illustrative reviewer can accept parsing but reject UI error feedback, proving separate standards, while an integration check detects a caller/signature mismatch.

Require needed inputs/tests/adaptations and no orphan one-line fragments. More tasks do not establish better decomposition.

Limits

Cross-cutting changes may need larger coordination/integration units. File/time counts are not universal limits. An unsettled shared contract prevents coupled tasks from being treated as independently ready.