Auto-only tracking
Auto-only tracking
Every tracked metric in the chirag127/oriz* family must be
automatically captured. Manual entry, manual timer, manual
journal — not allowed for anything that is a system metric.
What
If a thing is a metric — a number, a timestamp, a duration, a
count, an event, a state, a status — its capture must be
automatic. No "I'll write it down later". No "start the timer
when the meeting begins". No spreadsheet column the user types
into. No Discord-bot /log command. No daily standup form.
If automatic capture for a metric is not possible today, the metric is not tracked until it can be made automatic. We do not fall back to manual.
Why
- Manual tracking decays. Humans forget to start, fudge stops, skip days, retro-fill incorrectly, lie about durations to make themselves feel better. The data drifts further from reality every week.
- Dishonest data is worse than no data. A manual time-tracking log that says "8 hours of deep work" when the truth was 4 hours of deep work + 4 hours of context-switching produces wrong decisions downstream. Untracked is honest; manual-tracked is often dishonest.
- Untracked is information. A 2-hour gap in Wakatime data is a fact: the user was away from the keyboard. That gap is worth capturing as a gap, not papered over.
- Auto scales. Adding a new tracked dimension means adding a hook / SDK / cron job once, and from then on it captures forever. Manual tracking has linear cost-per-metric in human attention, which is the scarce resource.
How — examples in the current stack
| Metric | Auto source |
|---|---|
| Coding time | Wakatime IDE plugin (heartbeat on file activity) |
| Page views | Cloudflare Web Analytics + GA4 + Microsoft Clarity |
| Errors / exceptions | Sentry SDK |
| Operational logs | Cloudflare Workers Tail (live) + Better Stack Logs (aggregation) |
| Uptime | Better Stack + Instatus auto pings |
| Lifestream events | JSONL append on git events / npm publish events / CI events (auto webhook → CF Worker → JSONL) |
| Build success / fail | GitHub Actions workflow status |
| Spending | Would be manual → therefore the family does not spend money. The no-card-on-file rule enforces this from the other direction. |
When NOT to apply this rule
This rule applies to METRICS, not content.
- Journal / thoughts entries on
oriz-journal-siteare intentionally manual creative writing. They are CONTENT that the user wants to write. They are not a system metric. - Blog posts, README files, design briefs, knowledge bundle entries — same: intentionally human-written content, not metrics.
- Code itself is content, not a metric.
The line: if the value is "what was the user doing / how much / when?" → metric, must be auto. If the value is "what does the user want to say?" → content, manual is fine and expected.
Concrete walk-back consequences
- Toggl Track REJECTED as of 2026-06-20 (same day it was
adopted). Manual timer = manual data entry. See
services/business/productivity/toggl-trackfor the audit trail anddecisions/architecture/time-tracking-wakatime-onlyfor the walk-back narrative. - Wakatime stays as the sole time-tracking pick — auto via IDE plugin, fits the rule.
- Future tracking decisions must justify their auto-capture story up front. "We'll add a manual fallback for non-coding time" → no, by this rule.
Exceptions
None for metrics. Content is not subject to this rule (see "When NOT to apply" above).
See also
decisions/architecture/auto-tracking-everywhere.md— the family-wide decision that locks this principle, with concrete auto-event source list for the lifestreamdecisions/architecture/time-tracking-wakatime-only.md— the walk-back of Toggldecisions/architecture/lifestream-jsonl-canonical.md— the JSONL stream that consumes auto sourcesrules/interaction/never-hit-quotas.md— paired rule on the architecture-not-survival posturerules/no-card-on-file.md— auto-tracking spending = no spendingrules/interaction/future-overrides-past.md— why this rule supersedes the earlier "Toggl + Wakatime both" direction from the same day