state-accuracy-check

Verify timer, counter, and live-state accuracy after modifying auto-track and pause/resume logic.

Updated Jun 15, 2026
One-click install
npx skills add https://github.com/ravenslight2010/Production-run-calculator --skill state-accuracy-check-ravenslight2010
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: state-accuracy-check
Source: https://github.com/ravenslight2010/Production-run-calculator/tree/main/.agents/skills/state-accuracy-check
Command: npx skills add https://github.com/ravenslight2010/Production-run-calculator --skill state-accuracy-check-ravenslight2010

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Changes to live production-run state logic (auto-track counters, dough supply, pause/resume, SSE sync) can silently corrupt timers and counters, causing wrong case counts, frozen dough timers, or stale SSE echoes overwriting operator edits. This Skill provides a systematic verification checklist to catch those accuracy regressions before they ship. ## Core Features & Use Cases - Seven Accuracy Categories: Covers clock isolation, case/skid auto-track counters, dough tray/batch counters, pause/resume consistency, Frontline/Sauce cadence, SSE counter drift, and the press-done model. - Cross-Run Safety Checklist: Verifies the three lines of defense (lastFormRunIdRef guard, empty-over-populated guard, deep-equality reset guard) that prevent form resets from clobbering another run's data. - Reset Reference Table: Documents exactly which bookkeeping refs reset in resetBookkeeping(), on run resume, and via fireAutoTrackNow(), so ref lifecycle changes stay consistent. - Use Case: After editing useAutoTrack.ts to change tray depletion cadence, walk the dough-supply category to confirm remainder carry, seeding refs, and the pressDone gate still behave correctly. ## Quick Start Ask the assistant to run the state accuracy check on your recent changes to LiveRunContext.tsx or useAutoTrack.ts before committing them.

Frequently Asked Questions about state-accuracy-check

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I verify auto-track counter accuracy after editing useAutoTrack?

Check that lastExpectedCasesRef tracks unclamped expectedCasesRaw and updates on every tick, that formResetSkippedRef re-baselines after a form reset to zero, and that tray/batch decrements are gated on pressDone. Then run the focused hook and provider tests listed in the skill.

Why does the case counter jump to a wrong value after resuming a paused run?

This is the stale-delta catch-up failure: after a pause or SSE form reset, the form shows zero while lastExpectedCasesRef holds a large value, so the first tick writes the whole backlog. The formResetSkippedRef guard must skip that first write and re-baseline.

When should I use state-accuracy-check versus sync-invariant-check?

Use state-accuracy-check for timer, counter, auto-track, pause/resume, and live-form accuracy. Use sync-invariant-check for transport and persistence concerns like LWW stamps, SSE merge order, and server convergence. Post-wake first-tick changes may require both.

Does the press-done model work the same on web and mobile?

No. The web pressDone contract is count-based (casesCompleted plus casesInFreezer versus casesNeeded), while mobile uses a time-based expectedCasesRaw feed-complete gate. The two platforms must be verified independently from their current checkouts.

What prevents a form reset from overwriting another run's data?

Three guards: the lastFormRunIdRef check in the autosave effect, the empty-over-populated guard in saveProfile, and the shouldResetFormOnRunSwitch deep-equality check. Every form.reset() call site must also stamp lastFormRunIdRef with the target run ID.