chore(sunset): remove journal-entry pipeline and gate off Bluesky step

[marcusrbrown]

Why

The Fro Bot 'operational log' issues that scripts/journal-entry.ts produced were noise \u2014 nobody was reading them and they were accumulating in the issue tracker (54 issues open across 5 weeks before this PR). The journal-entry pipeline was the wrong primitive for control-plane observability: GitHub issues are heavy artifacts optimized for human attention, not low-signal automated trail.

Sunsetting the journal pipeline entirely and gating off Bluesky posting pending a re-evaluation of social channels. Discord posting stays intact \u2014 a follow-up brainstorm will design tighter integration with fro-bot/agent's long-lived Discord gateway (deployed to gateway.fro.bot via marcusrbrown/infra) for proactive control-plane notifications instead of issue-based logging.

What changes

Journal pipeline \u2014 removed in full

• scripts/journal-entry.ts deleted (191 lines)
• scripts/journal-entry.test.ts deleted (209 lines)
• .github/workflows/social-broadcast.yaml \u2014 \ud83d\udcd3 Journal entry step removed; journal_text/journal_metadata/repo inputs dropped; FRO_BOT_PAT secret no longer required (downgraded from required: true to required: false since the only consumer was the journal step)
• .github/workflows/poll-invitations.yaml \u2014 \ud83d\udcd3 Journal \u2014 invitation accepted step removed
• .github/workflows/fro-bot.yaml \u2014 \ud83d\udcd3 Journal \u2014 daily oversight step removed
• .github/workflows/survey-repo.yaml \u2014 journal_text/journal_metadata/repo inputs and secrets: block dropped from the social-broadcast call
• persona/fro-bot-persona.md \u2014 Journal/Internal tone bullet and 2 ### Journal Entry example sections removed
• All 54 open operational-log issues closed with a sunset comment pointing at this PR
• Runtime-created journal and journal-active GitHub labels deleted

Bluesky \u2014 disabled (not deleted)

• scripts/bluesky-post.ts retained (no edits) so the code is available for future reactivation
• .github/workflows/social-broadcast.yaml \u2014 \ud83e\udd8b Post to Bluesky step gated with if: false && ... plus a preamble comment explaining the gate
• .github/workflows/poll-invitations.yaml \u2014 same if: false gate on its inline Bluesky step

Discord \u2014 untouched

scripts/discord-notify.ts and all Discord webhook invocations remain in production. The follow-up brainstorm will decide whether to replace webhook-based posting with gateway-relayed messages.

Stats

• 7 files changed: 12 insertions(+), 477 deletions(-)
• 54 issues closed
• 2 labels deleted
• 0 quality-gate regressions: 644 tests passing, types clean, lint clean

What's next

A follow-up brainstorm (separate PR / docs/brainstorms entry) will scope how fro-bot/.github (control plane) should leverage fro-bot/agent's Discord gateway. Research already done: see internal note for the gateway capability matrix and integration gaps.

[fro-bot]

Clean sunset. The journal pipeline is removed cohesively — source, tests, persona examples, and every workflow consumer (fro-bot.yaml daily oversight, poll-invitations.yaml invitation-accepted, social-broadcast.yaml core step, survey-repo.yaml caller inputs) all drop together. Grep confirms no orphan node scripts/journal-entry invocation remains in workflows. Issue-as-log was always the wrong primitive for low-signal control-plane telemetry; gating to Discord-only until the gateway integration lands is the right call.

The if: false && ... pattern on the Bluesky steps is the correct sunset gate: short-circuits without re-indenting the step, keeps the rest of the condition documented for the eventual revival, and the env wiring stays intact so reactivation is a one-token diff. Preamble comments above both gates carry their weight.

Verdict: PASS

Blocking issues

None.

Non-blocking concerns

• .github/workflows/social-broadcast.yaml:32-33 — FRO_BOT_PAT is declared as an optional secret but no step in the reusable workflow consumes it anymore. Now dead surface. Drop the declaration entirely (and the corresponding pass-through in any future callers) unless you're keeping it as a forward hook for a near-term re-add. If the latter, a one-line comment naming the intended consumer would justify the carry.
• .github/workflows/social-broadcast.yaml:21-25 — bluesky_text is now a true no-op input. The description correctly flags this, but consider whether to also drop the input plumbing in survey-repo.yaml:291-293 to make the gate honest at the call site. Either is defensible; the current state means we generate copy that nothing reads.
• scripts/bluesky-post.ts is retained but now has zero invocation paths. Confirm it's exercised by CI in some form (lint/typecheck) so it doesn't bitrot silently while gated off.

Missing tests

None. The journal tests were correctly removed with the script. The Bluesky gate is configuration, not logic — no test surface to add.

Risk assessment: LOW

Deletions-only on the journal side; the gating change cannot fire the Bluesky step under any input combination because false && X is unconditionally false in GitHub Actions expression evaluation. No new actions pinned, no untrusted input flowing into run: blocks, no permission expansion, no secret newly exposed to logs. Downgrading FRO_BOT_PAT from required: true to required: false matches reality and tightens the contract.

---

Run Summary

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

[fro-bot]

Both addressable items from the prior review landed in 47d136c:

• social-broadcast.yaml:31-37 — FRO_BOT_PAT secret declaration is gone. The reusable workflow now only declares secrets it actually consumes. Contract matches reality.
• survey-repo.yaml:291-292 — bluesky_text dropped from the call site with a comment explaining how to revive it. The gate is honest end-to-end now: no caller generates copy that gets discarded downstream.

Third item (scripts/bluesky-post.ts bitrot risk while gated off) remains unaddressed, but it's the weakest of the three and not worth holding the PR. ESLint + tsc passes in CI should catch typical drift; runtime regressions in the BlueSky API contract won't surface until reactivation, which is the trade-off for keeping the code parked instead of deleting it. Acceptable.

Verdict stands: PASS. Ship it.

---

Run Summary

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