Pulse: email output channel spawns an unshipped `gws` CLI; checks/calendar.ts needs undocumented credentials

[anikinsasha]

Running LifeOS 7.1.1. While auditing our Google-touching surfaces we found two Pulse components that appear unable to work in a stock install. Asking whether they're vestigial or have a setup path we missed — happy to help with a doc note or a removal patch either way.

1. The email output channel depends on a gws CLI that isn't shipped

LifeOS/install/LIFEOS/PULSE/lib.ts (job output dispatch, case "email") spawns:

const gwsPath = Bun.which("gws") ?? "/opt/homebrew/bin/gws"
Bun.spawn([gwsPath, "gmail", "+send", "--to", recipient, ...])

As far as we can tell, gws isn't shipped with LifeOS, isn't documented anywhere in the repo, and doesn't appear to be a public Homebrew formula. Also no stock PULSE.toml job uses output = "email", so the channel is unreachable out of the box even before the missing binary.

Questions: is gws a private/planned dependency? If not, would you take a change that either documents how to obtain/configure it or drops the email channel?

2. checks/calendar.ts requires credentials no setup flow creates

LifeOS/install/LIFEOS/PULSE/checks/calendar.ts reads GMAIL_CLIENT_ID, GMAIL_CLIENT_SECRET, and GOOGLE_CALENDAR_REFRESH_TOKEN from .env, but we couldn't find any documented flow that mints these three values, and the check isn't scheduled in the stock PULSE.toml. The only doc reference we found is the failure-mode line in DOCUMENTATION/Pulse/PulseSystem.md ("Calendar returns NO_EVENTS always → set GOOGLE_CALENDAR_REFRESH_TOKEN").

Same question: is this awaiting a documented OAuth setup flow, or is it vestigial and better removed?

For context, we've disabled both locally (patched out the email case; calendar check left unscheduled). If either has a future, we'd rather align with your direction than diverge.

[danielmiessler]

Fixed in the fail-loud sense, with the honest caveat. The email dispatch now checks for the gws binary before spawning and logs exactly what's missing and what to do ("install and auth the Google Workspace CLI, or switch this job's output to log/ntfy/voice") instead of an opaque ENOENT. Same for the deadline-raced spawn from #1546, which this path also gained. What we didn't do: bundle or document a full gws acquisition flow, because it's a private CLI with an interactive OAuth mint and no stock job uses the email channel; the channel stays available for installs that bring their own. calendar.ts's three credentials got the same treatment by association: unset means a clear skip, not a crash. Courteous, accurate report; thank you.