Android — 5 decisions

Everything the build loop is currently blocked on, with real device pixels and every option rendered. Options marked NEW are ones I added — the loop only proposed the ones it could see from inside the code.

my recommendation new option, not offered by the loop broken today

Reply with letters — e.g. 1D 2B 3A 4B 5 yes. Or say defaults and I'll take every green one.
1

Floating pill covers content

BROKEN NOW

The Help / Profile / Ask Thyme pill floats top-right over every tab. At 2× accessibility font "Ask Thyme" doubles in width and shoves Help/Profile 143px left, straight over the Dish Log CALORIES stat — and the pill wins the touch: tap the number, Help & Support opens. Also clips List section headers in landscape.

Real device — Dish Log at 2× font. Reads "CALO(?)(E)S"
Dish Log at 2x font with pill covering the CALORIES stat
Real device — List, landscape, scrolled. "UNGROUPED" sliced, + button reduced to a sliver
List in landscape with the section header sliced by the pill
AReserve the band app-wide
every tab, every font size
Ask Thyme?
1,840
CALORIES

Content can never enter the pill's strip. One rule, no per-screen auditing.

Costs ~40dp of vertical space on every tab at every font size — including the 99% of users at 1×, who never had the problem.

BReserve only where things collide
Dish Log + List only
Ask Thyme?
1,840
CALORIES

Same fix, applied only to the two screens that demonstrably break.

Has to be re-audited every time any screen gains a header. This is exactly how it got missed the first time.

DShrink the pill at large fontNEW
at 2× the label collapses to an icon
?
1,840
CALORIES

Fixes the cause, not the symptom. The overlap exists because the "Ask Thyme" label doubles in width at 2×. Collapse it to its icon above a font threshold and the pill stops growing — Help/Profile never move.

Zero space cost at any font size. Loses the "Ask Thyme" wordmark for 2× users, who are the ones most likely to want the label.

EPill hides on scrollNEW
scroll down → pill slides away
Ask Thyme?
1,840
CALORIES

Standard Android pattern. The pill is only over content because you scrolled; hide it on scroll-down, return it on scroll-up.

Zero permanent space cost. Biggest change of the four, and Ask Thyme becomes one scroll-up away rather than always present. Diverges from iOS, which keeps it pinned.

My pick: D — the loop framed this as "how much space do we sacrifice", but nothing is actually wrong at 1× font. D removes the cause and costs nothing. A is the safe answer if you'd rather not gate behaviour on font scale; it was my pick before I looked at why the pill grows.

2

Swap-review residue

DEAD FEATURE

Swap review is gone on both platforms — you dropped it on iOS, Android never built it. But the review row still shows a ⇄ swap glyph and the words "Possibly replaces", which describe a flow that no longer exists.

A / B / C rendered on the real card
Three renderings of the swap residue options
ALeave as-is

⇄ glyph + "Possibly replaces Whole Milk · 91% match".

Advertises an action that does nothing.

BDe-action itPICK

Info dot instead of the swap arrow, "Already have Whole Milk · 91% match".

Keeps the genuinely useful duplicate warning; stops it looking tappable.

CBadge only

Drop the advisory line entirely; the IN KITCHEN badge carries it.

You lose which item it duplicates and the match strength.

DFold the count into the badgeNEW
IN KITCHEN ×2

Badge says how many duplicates; the whole advisory row disappears. Recovers a full row of vertical space on every duplicate item — which is the same space Q1 option A would spend.

Loses the item name and the 91% match figure. Best if you think "you already have some" is the whole message.

3

Empty-kitchen copy

NEEDS iOS TOO

The empty kitchen tells you to use hardware, with the software way in sitting 200px below it. Identical string on iOS (MainTabView.swift:7018), unconditional, no Halo-ownership check — so this is a shared copy decision, not a parity gap. This is the screen a new app-only user is most likely to land on first, and the site has been app-first since August.

Real device — empty kitchen today
Empty kitchen screen with Halo-first copy
AApp-first, Halo as upgradePICK
Nothing here yet.
Add items by text below, or scan them with a Halo.
+ Add to kitchen…

Names the thing that's actually on screen first.

BKeep Halo-first
Scan items with your Halo device to view them here!
+ Add to kitchen…

No change.

Tells an app-only user the product needs hardware they don't own.

DAction-led, no hardware mentionNEW
Your kitchen is empty.
Add your first item below.
+ Add to kitchen…

Shortest path. Halo gets discovered in Profile/onboarding, not on an empty state.

Zero Halo surface here — worse if you want empty states doing hardware marketing.

EBranch on Halo ownershipNEW
Halo owners: "Scan an item to get started."

Everyone else: "Add your first item below."

Right message for both audiences instead of one compromise.

Real work on both platforms, and needs a reliable ownership signal. The correct long-term answer, not the fast one.

4

Refresh discoverability

LOW STAKES

All four tabs refetch on tap. LIST and COOK say so — "0 to buy · tap to refresh". KITCHEN's poster and DISH LOG's wordmark are equally tappable and say nothing. Nobody is stranded; it's just invisible on two of four.

Green = labels its refresh · Red = tappable but silent
2x2 of the four tabs showing which label their refresh
ALabel all fourPICK

Add "tap to refresh" to KITCHEN + DISH LOG.

Puts utility text on a poster and a wordmark — the two most designed things in the app.

BLeave it

Nothing is broken.

DPull-to-refresh everywhereNEW

Add the standard gesture on all four tabs and stop relying on a tap target nobody can see. Keep the taps working.

More work than a string. But it's the gesture every Android user already tries first, and it makes the labels unnecessary rather than better.

5

Re-point the loop's queue?

YES / NO

Seven of the last twenty commits were censuses and scan-guards — tooling that audits the loop's own instruments. It does find real bugs, and the instruments have caught things nothing else would. But it's the second time in five days the queue has drifted this way, and the four decisions above would move the app further than another census.

YESRe-point at release-blocking workPICK

I add a line to the loop prompt: prioritise unhappy paths, release regressions and the decided items above; build new scan tooling only when a bug is found that existing instruments missed.

NOLeave it alone

The instruments keep paying off; let it self-direct.

Reply with letters — 1D 2B 3A 4D 5 yes — or defaults for every green pick.
Once you answer I'll write the rulings into the loop's prompt so it acts on the next run and never re-asks.