Corrective Action: Day-of-Week Misidentification and Date Arithmetic Failure in Daily Recap

← Back to Corrective Actions 2026-04-14

Corrective Action: Day-of-Week Misidentification and Date Arithmetic Failure in Daily Recap

Date: April 14, 2026 Category: Enforcement Bypass / Date-Sensitive Operation Without Tool Verification Impact: Three iterations required to produce an accurate daily recap for April 13. Calendar framed as a rest day instead of a workday. Build log skipped per "Sunday" logic. "Tomorrow at a Glance" labeled wrong twice. User required to manually correct day-of-week and date arithmetic across two rounds. Resolution Time: ~10 minutes across three correction cycles

Incident

What Happened

During a /daily-recap run on April 14, 2026 (recapping April 13), two related failures occurred:

Incident 1: Day-of-week misidentification. The recap identified April 13, 2026 as "Sunday" when it was Monday. This cascaded into multiple downstream errors:

  • Calendar was framed as "All day Home -- no meetings scheduled. Clean build day." This is Sunday framing, not Monday framing. A Monday with zero meetings is notable and worth investigating; a Sunday with zero meetings is expected.
  • The build log section was skipped entirely. The /daily-recap command specifies: "Sunday = weekly review handles it, skip build log." Since the command believed it was Sunday, the build log was suppressed.
  • "Tomorrow at a Glance" was labeled "Monday, April 14" -- one day off in both day-of-week and date.

Incident 2: Date arithmetic error persisting after first correction. After Chris stated that April 13 was Monday (not Sunday), the second attempt corrected the day-of-week but introduced a new date error: "Tomorrow at a Glance" was labeled "Tuesday, April 15" instead of the correct "Tuesday, April 14." The day-of-week was fixed (Tuesday is correct for the day after Monday), but the date was incremented by an extra day. This required a third iteration with Chris providing the explicit correction.

Timeline

Time Event
Session start /daily-recap invoked for April 13, 2026
Gather phase datetime.sh was run -- but its output reflects today (April 14), not the recap target date (April 13)
First output Recap labels April 13 as "Sunday." Calendar framed as rest day. Build log skipped. Tomorrow = "Monday, April 14."
First correction Chris: "April 13 was Monday, not Sunday."
Second output Day-of-week corrected to Monday. But "Tomorrow at a Glance" now reads "Tuesday, April 15" instead of "Tuesday, April 14."
Second correction Chris: "Tomorrow is April 14, not April 15."
Third output Calendar fetched live. All dates and days correct. Recap accurate.

Root Cause

The root cause is not that datetime.sh was skipped. The script was run. The problem is that datetime.sh outputs the current date (April 14, the day the recap was being written), while the recap target was the previous day (April 13). The failure has two distinct mechanisms:

Mechanism 1: Day-of-week derived from model reasoning instead of tool output

datetime.sh output on April 14 would have shown DAY_OF_WEEK="Monday" (April 14, 2026 is a Monday). The recap needed the day-of-week for April 13 -- one day prior. Instead of computing this from the tool output (if today is Monday, yesterday was Sunday... wait, that IS what would happen), the model needed to recognize that datetime.sh tells you TODAY's day, and the recap date requires subtracting one day.

However, the actual failure is more fundamental: April 13, 2026 is a Monday, and April 14, 2026 is a Tuesday. If datetime.sh was run on April 14 and returned DAY_OF_WEEK="Tuesday", then the model should have derived that April 13 = Monday. Instead, the model identified April 13 as Sunday -- which is neither today's day nor yesterday's day computed correctly from any starting point. This means the model performed day-of-week reasoning independent of the datetime.sh output entirely, relying on an internal calendar model that was wrong.

Mechanism 2: Date arithmetic performed without anchoring to script output

After the first correction ("April 13 is Monday"), the second attempt got the day-of-week right for tomorrow (Tuesday) but produced the wrong date (April 15 instead of April 14). The model computed "tomorrow" by adding 1 to the recap date (April 13 + 1 = April 14) but instead produced April 15. This is simple arithmetic failure: the model either added 2 instead of 1, or confused the recap date with the current date and added 1 to April 14 to get April 15.

Category: Enforcement Bypass / Tool Output Disregarded

The CLAUDE.md enforcement rule states: "ALWAYS run /datetime before any operation involving dates or scheduling. Do NOT trust the date shown in the system prompt."

The spirit of this rule is that all date reasoning must be grounded in tool output, not model inference. Running the script and then ignoring its output to perform independent calendar reasoning violates the rule just as completely as not running it at all.

The /daily-recap command includes ./scripts/datetime.sh in its Gather phase, but the command does not explicitly instruct: "Use the DAY_OF_WEEK value from datetime.sh output to derive the recap date's day-of-week." The command assumes the executor will ground all date references in the script output. That assumption failed.

Fix Applied

Immediate Resolution

  1. Chris identified the day-of-week error on first output. Model corrected to Monday.
  2. Chris identified the date arithmetic error on second output. Model corrected to April 14.
  3. On third iteration, a live Google Calendar fetch was executed, providing external verification of the schedule for both April 13 (recap day) and April 14 (tomorrow). The recap was produced accurately.

Code/Configuration Changes

None applied in-session. This CAR specifies the prevention measures.

Verification

The third iteration produced accurate output with correct day-of-week (Monday for April 13), correct "tomorrow" (Tuesday, April 14), and calendar events verified against Google Calendar.

Prevention Measures

Rules Added

MEMORY.md Critical Lessons (add):

NEVER derive day-of-week or perform date arithmetic from model reasoning. Run datetime.sh, read its output, and compute all dates mechanically from the DAY_OF_WEEK and DATE_ISO values. If the operation involves a date other than today (e.g., yesterday's recap), subtract/add days from DATE_ISO using date -d and output the result -- do not calculate in your head. Two errors on April 14, 2026: model identified Monday as Sunday, then computed April 13 + 1 = April 15.

skills/enforcement/vf-self-correction.md Detection Triggers (add to Planning Triggers table):

If You're Doing This You're Actually Doing This
Writing a day-of-week (Monday, Tuesday, etc.) without quoting datetime.sh output Model-based calendar reasoning. Run datetime.sh, read the DAY_OF_WEEK line, derive from that.
Computing "tomorrow" or "yesterday" by reasoning about dates instead of using date -d Mental date arithmetic. Use date -d "$DATE_ISO + 1 day" +%A or equivalent.

skills/enforcement/vf-self-correction.md Anti-Rationalization Table (add to Verification Rationalizations):

If You're Thinking This The Reality Source
"I know what day of the week April 13 is" No you don't. Models get day-of-week wrong routinely. Run the tool. Apr 14, 2026 daily-recap CAR
"datetime.sh only gives today's date, so I need to compute yesterday myself" Use date -d "2026-04-13" +%A to get the day-of-week for any date. Never compute day-of-week in your head. Apr 14, 2026 daily-recap CAR

Structural Fix: /daily-recap Command

The /daily-recap Gather phase currently runs ./scripts/datetime.sh but does not mandate how to handle recap dates that differ from today. Add to the Gather phase after the datetime.sh call:

# datetime.sh gives TODAY. For recap of a different date, also run:
# date -d "YYYY-MM-DD" "+%A" to get that date's day-of-week
# date -d "YYYY-MM-DD + 1 day" "+%A %F" to get tomorrow's day and date
# NEVER derive day-of-week from model reasoning.

And add to the Day Detection section:

**Day detection must use datetime.sh output, not model inference.**
If recapping a date other than today, run:
  date -d "{recap-date}" "+%A"
to determine the day-of-week. Do not reason about it.

Detection Triggers

  1. Pre-output scan: Before presenting any recap, verify that every day-of-week label and every date in the output can be traced to a datetime.sh value or a date -d computation. If any day-of-week was derived from model reasoning, stop and recompute.

  2. Tomorrow verification: Before writing "Tomorrow at a Glance," explicitly compute: date -d "{recap-date} + 1 day" "+%A, %B %d". Write that value. Do not compute it mentally.

  3. Sunday/Saturday detection: Before applying weekend logic (skip build log, etc.), verify the day-of-week was tool-derived. Weekend misidentification changes command behavior (build log suppression, "weekly review handles it" logic). This makes day-of-week errors high-impact, not cosmetic.

Lessons

  1. Running the tool is necessary but not sufficient. The enforcement rule says "run /datetime." The actual requirement is "ground all date reasoning in tool output." These are different. A model can run the tool, receive the output, and then perform independent calendar reasoning that contradicts the output. The enforcement should say: "All date values in output must be mechanically derived from datetime.sh output or date -d computation. No model-inferred days or dates."

  2. Date arithmetic is not a language model competency. Models frequently get day-of-week wrong for specific dates, and make off-by-one errors in date addition. This is a known limitation, not an edge case. Every date operation should be delegated to date (the Unix command), the same way every HubSpot write is delegated to Ledger. The model's role is to call the tool and format the result, not to compute the result and hope it matches.

  3. Cascading errors from wrong day-of-week are high-impact in operational commands. The /daily-recap command has behavioral branches based on day-of-week: Sunday skips the build log, Saturday triggers reflection mode, weekdays trigger standard mode. A day-of-week error does not just produce a wrong label -- it changes which sections are generated, what gets published, and what gets skipped. This makes it a structural error, not a cosmetic one.

  4. Correction persistence across iterations is not guaranteed. The first correction (Monday, not Sunday) was accepted but the second output still had a date error. Corrections to one value do not automatically propagate to derived values. Each derived value must be independently verified against tool output.

Document Control

Version Date Author Changes
1.0 April 14, 2026 Architect (for V) Initial CAR from daily-recap incidents