docs(plan): daily digest presence event (control-plane side)

[marcusrbrown]

Adds the implementation plan for the control-plane side of the daily digest presence event — migrating the daily oversight Discord post off the legacy webhook onto the gateway daily_digest presence event so it posts as the Fro Bot user.

This is a planning artifact, not implementation. It is the third of three steps:

1. Gateway daily_digest schema variant + render template (fro-bot/agent).
2. Redeploy the gateway image with that version (marcusrbrown/infra).
3. This plan — teach the signer the new event type, derive cheap counts and the report link in the scheduled run, and add the announce step gated off by a dedicated DAILY_DIGEST_ENABLED variable so it stays dormant until the gateway variant is live.

The plan is purely additive: the legacy webhook keeps running untouched, and removal is deferred to a separate follow-up after go-live. The announce step is gated by its own per-event variable rather than the global announce kill switch (which would mute the existing live events).

[fro-bot]

Verdict: PASS

Plan is well-grounded. Every code reference verified against the actual codebase: EventType union and VALID_EVENT_TYPES set are exactly as described at lines 4 and 6 of gateway-announce.ts; the metadata overlay pattern in reconcile-repos.yaml matches what Unit 3 says to copy; the legacy webhook step exists at line 412 of fro-bot.yaml and is untouched per scope; the yaml package is already a direct dep (^2.6.0); the origin brainstorm document exists.

Blocking issues

None.

Non-blocking concerns

One thing worth watching at implementation time: the plan says the count script "reads metadata/repos.yaml" and "assumes the overlay has placed it on disk" — but the overlay step uses git checkout origin/data -- metadata/ which stages the file in the index, not just writes it to disk. reconcile-repos.yaml notes this explicitly (lines 51-52: "leaves metadata/ staged in the index"). The script should read the working-tree path directly (metadata/repos.yaml), which is fine — git checkout does write it to the working tree — but the plan's framing as a disk-read assumption slightly obscures the staging artifact. Not a bug in the plan, but pin the exact behavior in the Unit 2 fixture commentary so the test author doesn't conflate the two.

The report-URL discovery step's GH_TOKEN note is correct and important — it's easy to miss during wiring. The plan calls it out clearly. No further concern.

Missing tests

None — the plan's test scenarios for Units 1 and 2 are thorough (byte-exact HMAC path, kill-switch short-circuit, UTC date boundary with fixed clock, error-vs-quiet-day distinguishability). Unit 3 and 4 are explicitly test-free with rationale.

Risk assessment: LOW

The dormant-ship gate (DAILY_DIGEST_ENABLED default unset) cleanly isolates control-plane changes from the not-yet-deployed gateway schema. The legacy webhook is untouched. Both new code paths (signer extension and count script) are fail-soft and covered by unit tests. The cross-repo contract point (context shape vs. gateway issue #765) is called out as a pin-before-enable requirement. The only execution risk is the URL discovery race, which the plan handles as a skip-on-miss rather than a fail.

---

Run Summary

Field	Value
Event	pull_request
Repository	fro-bot/.github
Run ID	27099973186
Cache	hit
Session	ses_15cd26837ffeQdkiljEqm31iwt