Recommendation

Yes, a weekly automation would help, but not as a verbatim replay of the old manual pipeline.

Why

• V: is mapped to \\server-host\Google Drive.
• Naive full-tree recursion on live V: timed out at 120 seconds during this review.
• Client-case roots are active in June 2026, so there is ongoing churn.
• The prior V-drive email-to-PDF workflow already has a proven safe pattern: inspection, QA, --plain-body-only --skip-existing, copy-back, and rollback artifacts.

Recommended automation shape

• Run weekly, local to the machine that already has V: / \\server-host\Google Drive access.
• Discover only new .msg / .eml files in approved live case roots.
• Exclude staging and legacy lanes such as z - Email Files*, E-H, I-L, z-UPS Flight 2976 Cases, and prior PDF repository/output lanes.
• Write manifests, exceptions, rollback, and QA artifacts under C:\Users\SAguiar\Documents\Codex.
• Convert with the proven email_files_to_pdf.py runner using --plain-body-only --skip-existing.
• Copy PDFs back beside the original indexed email locations without overwriting existing PDFs.
• Keep a processed-state file so the run is incremental and does not keep churning the same legacy trees.

Cautions

• I would not automate the exact old UPS-style lane. UPS and similar legacy repositories need explicit exclusions.
• If Teams updates are required, the current Teams connector still lacks ChatMessage.Send / Chat.ReadWrite, so messaging must be fixed first.
• Remote/cloud migration is viable only if the remote runner can reach \\server-host\Google Drive; until then, local execution is the safe default.