--- name: time-and-work-attribution description: "⭐ OWNER CORRECTION (2026-07-18): Dispatch repeatedly inflates timescales ('years of code', 'months ago', 'weeks ago') on a young project, and mis-attributes work across days ('today was a big day' for work that landed last night). FIX: never date work from feel — check `git log` timestamps, which are deterministic ground truth." metadata: node_type: feedback type: feedback originSessionId: 1060dea9-0dc3-42b4-958d-2a6f7a6c0c58 modified: 2026-07-21T19:14:30.230Z --- **Owner, 2026-07-18 (verbatim):** *"you keep saying months and years but the changelog tells you it's been like a month or two"* and *"you should be able to keep track of time no? Like you even mix up work. Like you'll say today was a major day but most of what you mention was the previous day / night."* ## THE TWO FAILURES 1. **Inflated timescales.** Said static tests had stood "for years"; said things landed "weeks/months ago." The project is young and moves fast — whole bodies of work that feel long-established were written within weeks. Get the actual age from the first commit in `git log`, never from feel. 2. **Mis-attributed work across days.** Calls work "today" that landed the previous day or overnight. Within one long conversation everything reads as "now" — there are no timestamps on conversation turns, so recency is indistinguishable from a session 40 messages back. ## ⭐⭐ THE MECHANISM — owner explained it 2026-07-21, and it is the root cause Owner, verbatim: *"your sense of how long we've been doing this is scewed because I always leave you running on my Ally. Even while I'm alseep."* **The Dispatch session is left running continuously — for days, through the night.** So conversation position and elapsed time are completely decoupled: a gap of one message can be eight hours, and forty messages can be twenty minutes. Dispatch had been reading conversation length as a proxy for elapsed time, which is why it told the owner "it's late, this is a clean place to stop" at **1:40 in the afternoon** (2026-07-21). ⇒ **NEVER infer the time of day, the date, or how long anything took from where you are in the conversation.** There is no relationship. Read `<env>` for the date, run `date` in bash for granularity, and read `git log` for when work actually happened. Do not say "tonight", "it's late", "earlier today", or "we've been at this for hours" unless a tool just told you so. ## ⭐ WHY IT MATTERS (not just pedantry — it BIASES ADVICE) Describing something as years old makes it sound entrenched and load-bearing, which pushed Dispatch toward "careful, incremental, reversible" recommendations. The real picture — written weeks ago, by us, reasons still in living memory — is far CHEAPER to change. The inflated timescale was making the trim sound more dangerous than it is. Owner: *"that's why I kinda push back when you go on about changing years of code."* ## THE FIX (deterministic tools first — the project's own rule) - **Never date work from feel. Check `git log` / commit timestamps.** Commits carry real times; conversation turns don't. - Prefer naming the commit or the change over saying "today"/"recently" at all. - `CHANGELOG.md` dates and the engineering metrics log ([[engineering-metrics-log]]) are the other cheap sources of truth. - If Dispatch starts describing RobCo like an old codebase, that's the tell — owner has standing permission to push back, but Dispatch should catch it first. ## THE STANDING RULE ON PROJECT AGE Never assert the project's age, start date, or a release date from memory — **derive it from `git log` / `CHANGELOG.md` at the moment you need it.** Any number written down here would be stale within weeks; that is exactly the failure this file exists to prevent. Default posture: nothing in this repo is old, legacy, or long-standing. *Corrected 2026-07-20: removed the hardcoded project-age anchor, test counts, and release date — all derivable and all rotting. The rule replaces the numbers.* Related: [[engineering-metrics-log]], [[reframing-review-2026-07-13]].