| Metric | Value | Copy |
|---|---|---|
| Current count | {{ count }} | |
| Session max | {{ sessionMax }} | |
| Step size | {{ step }} | |
| Started at | {{ startedAtLabel }} |
| Action | Change | Result | Time | Copy |
|---|---|---|---|---|
| {{ entry.action }} | {{ entry.deltaDisplay }} | {{ entry.resultCount }} | {{ entry.atLabel }} |
A tally is a recorded count of repeated items or events, and simple tallies start to drift as soon as interruptions, grouped items, or corrections enter the picture. This tool keeps that running count visible, editable, and reviewable inside one session so you do not have to reconstruct the total from memory.
That matters in ordinary work more often than people expect. A quick inventory pass, a set of exercise repetitions, a headcount at a door, or a pile of matched parts can all look trivial until someone double-clicks, loses their place, or decides halfway through that one press should represent a pair or a bundle instead of a single unit.
The package handles that problem with a basic add and subtract counter, a configurable Step size, a running Session max, and a short Activity history. It also layers in a small strategy panel that comments on drift and session quality by reading your own increment, decrement, and reset pattern.
That guidance is useful, but it has a boundary: a clean-looking session does not prove that the real-world count is correct. The tool reflects how consistently you used the counter, not whether the underlying shelf, room, or checklist was itself counted without mistakes.
The strongest default is to leave Step size at 1 when each press truly equals one event. Count upward with Add, use Subtract only for genuine overshoots, and glance at Session max before you reset so you do not lose the highest point from the current run.
Grouped counting becomes useful when one press stands for a stable bundle, such as two laps, five packages, or ten identical parts. In those cases, set Step size before you start. Changing it mid-session is allowed, but it makes the later Activity rows harder to interpret because earlier rows were recorded under a different unit meaning.
The most trustworthy run is one where Current count, Session max, and the recent Activity rows all tell the same story about how the total was reached.
This package is a rule-based session tally rather than a predictive model. The current count is always treated as a whole number, the step is always at least one whole unit, and subtract actions cannot drive the count below zero. That makes the main number easy to reason about even if you type fractional or empty input into the Step size field.
Session max behaves differently from the main count. It only moves upward when a new peak is reached, which means it acts as a memory of the highest total seen in the current run. Reset clears both the live count and that peak, refreshes Started at, and begins a new session trail.
The Activity panel is intentionally short and recent. The log begins with a Start row, each new action is inserted at the top with its change and resulting count, and the package keeps only the latest twenty entries. That is enough for session review, but it is not a long-term audit archive.
The strategy panel is built from simple summary rules. It counts increment, decrement, and reset actions, computes how often directional actions required correction, and compares the current total with the session peak.
| Output | Built from | Threshold or limit | Interpretation |
|---|---|---|---|
| Current count | Running total after each add or subtract | >= 0 | The reportable total for the active session |
| Session max | Highest count reached before corrections or reset | Peak only | Shows whether the session had rollbacks after a high point |
| Control drift | Correction rate plus gap between Current count and Session max | >= 35% decrements or gap >= 2 steps | Warns that overshoot or rollback is becoming meaningful |
| Review session quality | Total actionable events and reset timing | >= 12 actions for strong trail | Comments on whether the history is rich enough to trust or export |
The precision message also depends on Step size. A step of 1 is treated as strict one-click-per-event counting, a step of 10 or more is treated as grouped batch counting, and values in between are described as mid-grain updates. In other words, the package interprets your unit choice as part of the workflow, not just as arithmetic.
For fair comparisons across sessions, keep Step size stable from start to finish. If you change the unit halfway through, Current count still remains correct mathematically, but Session max, correction pressure, and the wording in Counter Strategy become harder to interpret as one coherent story.
Follow this sequence when the count needs to stay explainable from start to finish.
A clean session ends with a stable Current count, a believable Session max, and an Activity trail that explains any corrections instead of hiding them.
Current count is the number you would usually report. Session max is the high-water mark of the session, so any gap between those two fields means corrections happened after the peak. That does not automatically make the tally wrong, but it does mean the session deserves a quick review before you treat it as settled.
When the tally matters, verify the last few Activity rows and confirm that Step size still represents the same unit you meant to count at the beginning.
Set Step size to 2 before starting an inventory pass where each press stands for a matched pair. After eighteen presses on Add +2, Current count and Session max both read 36, and Counter Strategy describes the run as a mid-grain count with controlled drift.
That is a good fit for grouped work because the unit meaning stayed stable from the first click to the last. The total is easy to explain and the session did not need corrective churn.
Leave Step size at 1 and imagine a quick attendance pass that reaches a Session max of 40 before multiple correction clicks pull Current count down to 18. With 40 increment actions and 22 decrement actions, Control drift shifts to the warning about 35 percent decrements.
The message does not tell you the true attendance. It tells you the counting process was noisy enough that the newest Activity rows should be checked before the number is reported.
Suppose you were using Step size 10 to count cartons and had already reached 120. If Reset is pressed, Current count drops to 0, Session max returns to 0, and Started at jumps to a new timestamp.
That is not a calculation bug. It means the current session has been replaced. The practical recovery path is to export or copy metrics before resetting whenever the existing run still has reporting value.
The package clamps the running total at zero and disables subtracting at that floor. That prevents a correction click from turning into a negative tally.
The tool keeps the latest twenty entries, starting from the most recent row. It is built for session review, not for long-term logging.
Use it when one press truly stands for a fixed batch, such as a pair, a pack, or a block of repeated reps. Set the unit before the run so the Activity log stays interpretable.
No. It reads your own Add, Subtract, and Reset pattern. It can flag drift in the session, but it cannot inspect the outside task you were counting.
The session state, metrics, activity trail, and JSON snapshot are generated in the browser, and this package declares no tool-specific server-processing step.