Maintainer directive 2026-08-20: "we should add a clean up to that UI that makes it clear what the process for doing measured and unmeasured waterings is." This papercut has now bitten the maintainer twice, both times on the first plant of a watering session:
- 2026-07-25 (p01): pressed Glug expecting to specify the amount next → phantom unmeasured row → ruled: delete the phantom.
- 2026-08-20 (p11, Office Corn Plant): same expectation → Glug logged an unmeasured pour at 18:10:04Z, the "1 cup" chip logged a second pour at 18:10:09Z → the record says the plant was watered twice.
The mental-model mismatch
The operator's model: Glug opens a watering, then I describe it (two steps, one event).
The UI's model: every control is a complete log action (Glug = "log an unmeasured pour, now"; a chip = "log a measured pour, now").
Both bites happened after time away from the app — the interface's model doesn't survive a memory gap, which is the test a kitchen-appliance UI has to pass. Twice-bitten by the person who designed the workflow means the control layout is the defect, not the operator.
Fix directions (Design leads and chooses; the row-semantics half is Data's)
- Amend window: for N seconds after a Glug, the amount strip re-labels to make its role explicit ("add amount to this glug") and amends the just-logged unmeasured row instead of appending a new pour. Journal is append-only, so an amend is a correction event (
kind: amend / supersede), not an edit — Data designs that record.
- Explicit paths: two visually distinct affordances — "Log unmeasured glug" vs amount-first ("tap an amount = logs a measured pour"). No hidden ordering.
- Undo/merge toast: after any pour row lands, a brief "logged ⅔ cup — undo" toast; two pours on one plant within the session-gap window offer "merge".
Whichever lands, the acceptance test is the lived one: an operator who hasn't touched the app in a month waters the first plant without creating a phantom or a duplicate.
Related: the duplicate p11 rows from today are queued for maintainer-approved cleanup (separate curation action, not this issue); the p06 ⅔-merge and p01 phantom-delete precedents apply.
— filed by Workflow ⚙️ at maintainer direction; milestone deliberately unset (grill Q8 timing bucket)
Maintainer directive 2026-08-20: "we should add a clean up to that UI that makes it clear what the process for doing measured and unmeasured waterings is." This papercut has now bitten the maintainer twice, both times on the first plant of a watering session:
The mental-model mismatch
The operator's model: Glug opens a watering, then I describe it (two steps, one event).
The UI's model: every control is a complete log action (Glug = "log an unmeasured pour, now"; a chip = "log a measured pour, now").
Both bites happened after time away from the app — the interface's model doesn't survive a memory gap, which is the test a kitchen-appliance UI has to pass. Twice-bitten by the person who designed the workflow means the control layout is the defect, not the operator.
Fix directions (Design leads and chooses; the row-semantics half is Data's)
kind: amend/ supersede), not an edit — Data designs that record.Whichever lands, the acceptance test is the lived one: an operator who hasn't touched the app in a month waters the first plant without creating a phantom or a duplicate.
Related: the duplicate p11 rows from today are queued for maintainer-approved cleanup (separate curation action, not this issue); the p06 ⅔-merge and p01 phantom-delete precedents apply.
— filed by Workflow ⚙️ at maintainer direction; milestone deliberately unset (grill Q8 timing bucket)