Checking what the machine guessed, before any of it is published

[sridharkalaibala]

The pass made estimating a whole menu cheap and left confirming it at one dish at a time - open the item, save it - which on 272 dishes is the same 272 presses, moved one step along. A feature that stops there publishes nothing, because confirming is the only thing that lets a badge out.

This is the other half, and I should have built it with the first.

What the rows show is the point

A shop scanning calorie figures is being asked to check arithmetic it has no way to check. A shop reading "Grilled Chicken - High protein, Heart healthy" is being asked the question it can actually answer: is that sentence true of my food?

Those badges are exactly what confirming publishes, so the row leads with them and the numbers sit behind. They are derived on the read, by the same claimsFor the customer menu uses, so what a shop approves is what a customer will see rather than a second opinion computed somewhere else.

Confirming changes no number

Not one figure is written - only who stands behind the ones already there. A confirm that also edited would be a second way for values to reach a dish, and the whole feature rests on there being exactly one: the item form, where a person types them. A test asserts the write touches nothing but the source fields.

Only rows that are currently estimated, enforced in the filter rather than trusted from the page: somebody may have answered a dish by hand between the screen reading the list and the button being pressed, and that answer is already the shop's word.

After a confirm the screen reads back rather than striking rows out, because the server may have skipped some and the page should show what is actually left rather than what it assumed happened.

One that would have gone wrong quietly

fillCategories took no argument and hard-wired the pass's picker. A second screen calling it would have filled that one and left its own showing nothing but "The whole menu" - correct-looking, and silently narrowing nothing.

Also, both pre-existing on develop and both red

.husky/pre-push and scripts/check-locally.js carry a shebang and were committed non-executable. The README endpoint badge was two routes behind.

Checks

• 10,630 API tests; root suite 2,504 of 2,507 (the three need frontend/public built)
• 5 new tests, most of them on the confirm-writes-no-number seam
• 8 new keys translated into all 17 packs

[github-actions]

Merged to develop. Anyone can test this - you do not need write access.

Try it at https://develop.posnic.io, or run it yourself:

git fetch origin develop && git checkout develop
npm install && npm --prefix api install
npm run dev   # then http://localhost:3000

When you have tested it, say what you did and what happened, and set
QA passed or QA failed. If you cannot set labels, just comment -
a maintainer will.

Reporting that something is broken is as useful as fixing it. It is
better found here than by a shopkeeper.