MC-4408

ROOT CAUSE (confirmed, not a code bug): GWS OAuth refresh token expired/revoked on Google's side (invalid_grant). Timeline: all runs healthy through 03:30 UTC, first failure 04:01 UTC — token hit the 7-day Testing-mode refresh-token expiry window. M365 token healthy. Script working correctly: it detects permanent auth failure and exhausts retries as designed. FIX (external, owner action): single Google re-auth via VNC (Chrome at 100.118.207.3:5901, display :1) refreshes the GWS token. SAME Google account/session re-auths NotebookLM — fixing this simultaneously clears MC-4402 (NotebookLM, social-pulse + radio audio). One VNC login closes both. DEDUP: MC-4407 cancelled as duplicate. Escalation already live in MC-4402 (waiting) — no new alert raised to avoid double-ping. NOTE: credentials-meta.json absent, so the proactive T-1 expiry warning (MC-4253) had nothing to read and didn't fire. Worth a follow-up to stamp token issue-time on refresh so advance warning works next cycle.

GWS OAuth refresh token expired/revoked (invalid_grant) — Google-side, not a code bug. All runs healthy through 03:30 UTC, first failure 04:01 UTC = 7-day Testing-mode token expiry. M365 healthy; script detected the permanent failure correctly. Fix is external: one VNC Google re-auth (100.118.207.3:5901, display :1) refreshes GWS AND NotebookLM — clears both this and MC-4402 in one login. MC-4407 cancelled as dup; escalation already live in MC-4402 (no new ping). Follow-up worth opening: stamp token issue-time on refresh so MC-4253's T-1 expiry warning fires next cycle (credentials-meta.json was absent).

Covered by MC-4402 (Google auth re-auth). Diagnosis correct + valuable: GWS invalid_grant = 7-DAY TESTING-MODE TOKEN EXPIRY (healthy through 03:30 UTC, first fail 04:01 = the 7-day window). M365 healthy; script detected correctly — not a code bug. Root insight carried to MC-4402 (durable fix = publish the OAuth app). Closing as covered.

Shadow reviewer verdict: FAIL (advisory only). Ticket was gated to done by the orchestrator/operator — not reopening; the gate is authoritative. Reasons: The ticket requires investigating and resolving the oauth-health-check failure (invalid_grant error). The worker correctly diagnoses this as a Google-side expired/revoked OAuth refresh token requiring manual re-authentication, but the committed diff contains zero code or configuration changes related to the ticket — it only updates session memory files and heal-state metadata. No test evidence exists. The actual fix (Google re-auth via VNC) is an external manual action with no committed proof it was performed, and the worker themselves notes the ticket is 'covered by MC-4402' meaning the fix hasn't happened here. Gaps: - No committed change addressing the oauth-health-check failure or the invalid_grant error - No evidence the Google re-auth was actually performed (only described as needed) - No test or smoke evidence related to the oauth-health-check task - Diff is entirely unrelated memory/session files — ticket requirements not met by code changes