#Completeness is not feature creep
Completing a task is not the same as inventing product scope. Three levels separate the work that belongs to the request from the work that belongs to a product decision.
This distinction is foundational.
Layr separates three levels.
#Level A — Interaction completeness
Behavior required to make an already-supported action correct.
Example:
- Delete
- → safety strategy
- → pending
- → success
- → failure
- → recovery
Usually implement.
#Level B — Product inference
Capabilities already established elsewhere.
Example:
The existing invoice detail screen already supports:
- Edit
- Download
- Delete
A new card may need to preserve those capabilities.
Reuse established behavior.
#Level C — New product scope
New capability or business rule.
Examples:
- Refund
- Duplicate
- Reminder automation
- AI summary
- Recurring invoice conversion
Do not implement without explicit product evidence or approval.
#The implied-completeness test
Before adding behavior, ask:
- Is this required for an existing action to work correctly?
- Does the product already contain this behavior?
- Is it supported by routes, APIs, types, tests, or established patterns?
- Would omitting it leave the task broken, ambiguous, unsafe, or unrecoverable?
- Would adding it create a new capability or business rule?
If #5 is yes, it is probably new product scope.