Configure hawk-mod from Slack, not from a file on the host

[tytremblay]

Stacked on #9 — base is manage-user-groups, so review that one first.

Which user group declares students is a decision a Slack admin makes, and until now only an SSH session could change it. src/slack/authz.ts already rejected that shape of problem once:

"a fresh install had an empty roster, so nobody could run /hawkmod, and the only way out was a shell on the host running the CLI. An app whose first-run instruction is 'SSH into the server' is broken."

That principle got applied to admin authority and then left unapplied to the settings that decide who is monitored.

What moves

student-group, mentor-group, managed-groups, alert-channel.

src/settings.ts resolves each database → environment → unset, so the env var becomes a seed rather than the source of truth. Nothing breaks for a running host and there is no flag day — a value set from Slack simply wins.

/hawkmod config
• student-group — students   (set here)
• mentor-group  — mentors    (set here)
• managed-groups — —         (not set)
• alert-channel — C0123ABCD  (from ALERT_CHANNEL_ID)

/hawkmod config set mentor-group @mentors

Showing where each value came from is half the feature. "Which group is it actually using, and who set it" is the question asked when the roster looks wrong, and answering it previously took two rounds of guessing and an SSH session.

What cannot move, and why that's an allowlist rather than an oversight

Slack credentials can't be configured from Slack — you can't set the thing that lets hawk-mod reach Slack. And TOKEN_ENCRYPTION_KEY must never be reachable: changing it makes every stored token undecryptable and every enrolled adult invisible, with coverage still reporting 100%. A test asserts those keys stay unreachable, so widening the allowlist carelessly fails CI.

Two safety properties worth reviewing closely

Handles are validated against Slack before storing. A stored typo reads exactly like an empty group: nobody rostered, nobody monitored, no complaint. The sweep would raise it eventually; refusing it turns tomorrow's finding into an error the person who caused it is still reading.

Changing a role group re-syncs immediately. Leaving it until 3am would mean the setting looked applied and was not.

The alert channel forced an honest reckoning

Making ALERT_CHANNEL_ID optional made the typechecker surface all five places that assumed a channel exists. An unset alert channel means a finding recorded and announced to nobody — the exact failure this project defines itself against. So it's an error at boot and an error at every use, naming the finding going unreported and the command that fixes it. It is never silent.

Verified

• CLI on a completely empty environment (env -i) — exits 0, migrations apply. settings.ts reads process.env directly rather than through config(), which would throw at import time and break import-roster / findings. This is the constraint CLAUDE.md is most emphatic about.
• Precedence end-to-end against a real database: env-only reads env; after setSetting it reads slack; the editable-group allowlist widens; setting_changes records (unset) -> mentors by Ty.

npm run typecheck && npm test && npm run format:check && npm run build — 94 tests, all green.

Not in scope

Cron schedules and TZ stay in the environment. They're read once at boot to register jobs, so making them live means re-registering jobs on change — real work for something set once. Say the word if you want them too.

🤖 Generated with Claude Code