⚠ Memory drifts from reality — verify with API before acting

Severity: medium Lesson date: 2026-06-23 Status: active

What happened

On 2026-06-23 00:28 UTC, Helper did a direct GitHub API check and found three pieces of memory that were out of date:

1. "Phase 4 (FWV v8 contamination cleanup) is in progress, awaiting operator sign-off" — actually shipped at 8c093ef on 2026-06-22 18:37 UTC. The cleanup was complete, including a 24-file diff with 169 name swaps.
2. "Region Schema pact wording is uncommitted in cards working tree, awaiting operator" — actually committed at 081e2f3 on 2026-06-22 16:03 UTC. The wording chrome drafted was applied by cards and is now in FVS Studio main.
3. "FreshCards canonical lives at avidtech6/freshcards standalone repo" — actually 404 on both casings. The standalone repo no longer exists. Canonical FreshCards code lives only at avidtech6/freshvibestudio/studio/modules/freshcards/.

If Helper had acted on the memory without verifying, plans would have referenced phantom state (a "to-be-done" Phase 4 that's already done, a "to-be-signed-off" Region Schema that's already in main, a "to-be-pushed" FreshCards repo that doesn't exist).

The rule

Memory is fast recall, not ground truth. Treat it as a hint, not a fact.

Before acting on a memory entry about external state (a commit, a repo, a deploy, a doc on a server, a token, a user's preference), verify with the source of truth:

• GitHub repo state → GET /repos/<owner>/<name> or git ls-remote
• GitHub commit state → GET /repos/<owner>/<name>/commits?per_page=5
• Cloudflare deploy state → GET /accounts/{ACCT}/pages/projects/<name>/deployments
• A token's status → check expiry, test on read-only endpoint
• A URL's content → web_fetch (don't trust cached responses)
• A user-stated preference → re-ask in the current session

If verification disagrees with memory, the verification wins. Update memory after, not before, the verified action.

How to check before acting on a memory entry

• [ ] Date of the memory entry — when was this written? If > 7 days old, verify harder.
• [ ] Source of the memory — was it observed directly, or relayed from another Mavis/operator?
• [ ] Type of state — is it a fact (verifiable) or a preference (subjective)?
• [ ] Is verification cheap? — if yes, just do it. Don't optimize for fewer API calls.
• [ ] What's the worst case if memory is wrong? — high blast radius = verify harder.

Why memory drifts

• Time decay — facts change faster than memory is updated
• Cross-session relay loss — when a Mavis relays a finding through the operator, the operator may not relay the full state back
• Operator sign-offs that happen out-of-band — the operator signs off in a Mavis thread; another Mavis's memory doesn't get the update
• Out-of-session commits — the operator pushes from their local machine; Mavis memory doesn't see the push until next session
• Implicit state — "the docHub build is in progress" is implicit in chat but not in memory

The corollary

docHub exists in part to solve this. The dev/_meta/bootstrap.json is regenerated on every content change. The dev/reports/ log captures what actually happened. The dev/decisions/ log captures what was actually decided. docHub is the source of truth; memory is the index.

If memory and docHub disagree, docHub wins.

Cross-references

• D-062 — Phase 4 shipped (the new state that displaced the old "in progress" memory)
• D-061 — FreshCards canonical location (the new state that displaced the old "standalone repo" memory)
• Report: 2026-06-23-freshcards-state-check — the verification that surfaced the drift
• All other dangerous/ entries — this lesson is the meta-lesson; verify before any of the others