fix: bound food dialog waits and budget combined writes

[milldr]

Summary

Fix custom-food creation/logging timeout paths in crono rather than changing the meal prompt.

Diagnosis

The September 10 attempts ended with remote automation timeouts. The installed CLI and repository use a 120-second budget for combined creation and logging, and 60 seconds for standalone logging. Several fallback selectors select the first matching control even when hidden, with no explicit action timeout; those waits can consume the operation budget. The shared search selector also contains an extra parenthesis. A real Chromium fixture reproduced a further issue: waiting for the first td can wait on a hidden nutrition-editor cell instead of a search result.

The original remote DOM/step trace is unavailable, so the precise stalled element in that session cannot be established. Missing diary rows do not establish whether a custom food was saved. No production diary writes were made during this investigation.

Changes

• Filter out hidden controls and bound click, fill, and focus waits.
• Correct the search selector and wait for an exact visible food name.
• Budget 180 seconds for logging and 300 for create-and-log, independently of login; retain 120 for creation alone.
• Verify the add-food dialog closes before returning success.
• Report write errors as unconfirmed and warn against recreating foods or retrying from an absent diary row alone.
• Add runtime/unit regressions and a reusable compiled-code Chromium fixture test.

Validation

• npm ci --ignore-scripts
• npm run lint
• npm run format:check
• npm run build
• Full Vitest suite: 25 files, 251 tests passed (credential environment overrides removed for isolated credential-store tests).
• CHRONO_TEST_CHROMIUM= npm run test:food-browser: standalone log and create-and-log passed against intercepted HTML, each with exactly one diary submission; saved name and macros verified.
• Built CLI --help and npm pack --dry-run passed.
• git diff --check passed; target main merged (already up to date).

Local validation ran on Node 22.20.0. Browser fixtures never contact Cronometer; this is not a claim of live production end-to-end verification. Existing dependency audit reports 14 vulnerabilities; dependency upgrades are outside this fix. Catalog search and explicit dates for custom-food/log commands remain separate limitations.

Want tembo to make any changes? Add a comment with @tembo and i'll get back to work!

    

[tembo]

Follow-up live validation using a fresh local build and the existing environment credentials:

• npm run build passed; node dist/index.js export servings -d 2026-09-10 --json authenticated and completed with valid JSON.
• Ran the compiled automation runner and generated browser code against real Cronometer in one authenticated remote browser, with explicit pre-save stop points. No food or diary save was executed.
• The live catalog contains the exact custom food Gomez, Buffalo Chicken Turtle with Ranch. The selected detail panel shows 60 g protein, 105 g net carbs, and 58 g fat, with Diary Group Lunch. This establishes that the original custom-food creation saved successfully despite the timeout; it must not be recreated.
• The patched logging flow reached the existing food serving detail panel successfully. The patched creation flow opened the new-food form and completed nutrient entry, stopping before Save Changes.
• Fresh unfiltered September 10 export after validation matches the two pre-existing Breakfast rows. No new diary entries were made.

Boundary: final Save Changes and Add to Diary actions were intentionally not exercised live, so this is authenticated pre-submit validation rather than proof of a production write.

Additional finding outside this PR: the servings exporter returned zero calories/macros for both existing Breakfast foods while the live diary UI showed populated nutrition (460 kcal total). Its nutritional fields therefore cannot currently be trusted for write verification; this merits a separate export-parser investigation.

[tembo]

Follow-up fixes and live write validation:

• Fixed misleading servings JSON: the real CSV has only Day, Time, Group, Food Name, Amount, Category. Missing, blank, or invalid nutrient fields now remain null rather than fabricated zero values. Text output labels them unknown and suppresses incomplete totals.
• Accept uppercase ADD TO DIARY while refusing disabled submission controls. The compiled browser fixture now exercises that casing.
• Build, lint, formatting, all 254 tests, and both compiled Chromium fixture flows pass.
• On September 10, used the rebuilt automation with environment credentials to log the existing Gomez custom food once under Lunch. A fresh live diary check confirmed no duplicate before submission; pre-submit food details matched 60 g protein, 105 g carbs, 58 g fat.
• The operation returned success and exited. After reloading Cronometer in the same authenticated session, the persisted diary contains one Serving with Lunch totals of 1182 kcal, 60 g protein, 105 g carbs, and 58 g fat. No new custom food was created.
• A valid unfiltered September 10 export was saved as the pre-write baseline. The final export currently returns HTTP 429; waiting for its cooldown before completing the independent export diff. No further food write will be attempted.