#849 Live Swamp Club event console on /feed — scrolling stream of all non-sensitive events

Problem

The Swamp Club event stream is alive — sign-ups, tier-ups, badges, extension publishes/pulls, feed posts, lab issue lifecycle, CLI activity — but on-site there is nowhere to watch it happen. The activity is locked in the Discord automated-activity channel and the telemetry pipeline. We want a public, on-site window into the system's heartbeat: a scrolling console-log of events as the platform processes them.

Proposed solution

Add a live, scrolling event console to /feed — a console-log / syslog style window that streams events in real time as they are processed, newest at the bottom (or top), auto-scrolling, like tail -f on the Swamp. Each line is one event: timestamp, actor (tier-colored OperativeName), a human verb, and the public subject (e.g. "published @you/thing v1.2", "reached Mire Walker", "shipped lab #844", "pulled @swamp/foo").

Scope: Swamp Club event stream, non-sensitive only

Default-allow the Swamp Club event stream; deny a sensitive list. Concretely:

Exclude — sensitive (hard deny):

• All billing: checkout_started, billing_portal_opened, subscription_changed, subscription_change_previewed, subscription_canceled, subscription_payment_failed
• page_view

Exclude — auth / PII-adjacent (recommend deny; confirm): password_reset, password_reset_request, email_verified, verification_email_resent, oauth_redirect, and likely sign_in / sign_out. These reveal individual account/security activity with little public value. (sign_up and daily_sign_in are celebratory and stay.)

Include — everything else (the stream): sign_up, daily_sign_in, badge_awarded, tier_up, feed_post_approved, extension_published, extension_pulled, release_published, collective_created/_deleted/_invite_sent/_invite_accepted/_invite_declined/_member_removed/_role_changed, the lab lifecycle events (issue_created, issue_status_changed, issue_assigned), click_link, copy_install_command, and cli_invocation.

Two scope calls to confirm: cli_invocation (very high volume — the millionth-invocation counter; great for a fast-scrolling "alive" feel but may need sampling/aggregation) and release_published / cli_invocation originate outside the web app (CLI / external CI). User direction is "swamp club originated only … other than that, we go" — default is to include them as part of the Swamp Club event stream unless we decide CLI/CI is out of scope.

Streaming mechanism

Reuse the existing SSE pattern (routes/api/v1/lab/stream.ts + the in-memory event bus in lib/infrastructure/lab-issue-event-bus.ts). Add an endpoint that tails the processed-event stream and an island on /feed that renders the scrolling log. Paint an initial buffer of the last N events, then stream live. Apply the allow/deny filter server-side (never send sensitive events over the wire). Rate-limit / coalesce bursts; consider sampling cli_invocation if it drowns the signal.

Privacy / safety constraints (non-negotiable)

• Render-safe projection only. Never send raw event properties to the client — whitelist per-event-type fields. Properties can carry emails, tokens, IPs. No email leaks, ever.
• Respect private collectives. Do not surface private-collective lab issue activity or private-extension events publicly. Honor the same visibility gate the firehose-subscription work uses (subject collective visibility).
• Anonymous events. cli_invocation from anonymous distinct_ids must render without identity (e.g. "an operative") — never expose anon hashes, IPs, or user agents.
• No sensitive leakage by omission failure. The filter is allow-list-shaped at the field level even for allowed events.

Alternatives considered

• Discord-only (status quo): not on-site, not public, not in the product. The whole point is "having it all locked up in automated-activity isn't enough."
• A static recent-activity list (no streaming): loses the live "console log" feel that makes it compelling.

Acceptance

• /feed shows a scrolling, auto-updating console of live events, newest continuously appended.
• Billing events and page_view never appear; the auth/PII-adjacent denylist is applied (final list confirmed with maintainer).
• The server streams only a render-safe, field-whitelisted projection — raw properties are never sent to the client; no emails/tokens/IPs/anon hashes leak.
• Private-collective and private-extension events are excluded from the public stream.
• Volume is manageable (burst coalescing and/or cli_invocation sampling) without the console feeling dead.
• Related: this is the on-site sibling of the event firehose-subscription direction.