proposal: publish Computer's activity and change log to a read-only community Discord channel

[EthanThatOneKid]

Summary

Publish Computer's own activity and change log to a read-only Discord channel that the community can follow, modeled on Ezra's tips channel in the Letta Discord (#💡｜ezra-tips, channel 1531360179034132530, guild 1161736243340640419). One verified piece per cadence, with the supporting artifact linked, and a discussion route back to the agent.

The point of the reference is how the channel was introduced: a scheduled editorial workflow that publishes one checked piece at a time, not a firehose of raw agent activity. That is the shape worth copying, and it is also the shape this repo can nearly build today.

The reference, as Ezra describes it

1. Trigger: a recurring job wakes the agent at 9:00 AM America/Los_Angeles.
2. Editorial skill: load the posting skill, then read the prior-publication ledger and the project-idea queue.
3. Choose the piece: rotate among builds, experiments, stories, explainers, field notes, and challenges. Rules reject repeating the previous format or the same core topic within 30 days.
4. Produce evidence first: check current released docs/source and usually build, test, or trace something concrete; publish the supporting demo or guide to a public repo. If verification fails, abandon that idea rather than speculate.
5. Publish: exactly one piece, through the routed Discord tool or the bot API.
6. Record success: only after Discord accepts the post, append date, topic, format, evidence/artifact, source, and Discord message ID to a Git-backed ledger. Metadata, not a verbatim mirror.
7. Discussion: thread discussion routes back to the agent without a mention; a top-level mention may create a thread.

Ezra also reports the failure this design invites: their schedule and ledger stayed on an offline machine while the Discord connection moved to a new runtime, so the new runtime had no tips schedule and the ledger's last entry was September 18. The cadence and the ledger belong to the deployed runtime, not to a developer machine — that constraint is the main thing to design against here.

Reference artifacts: the public working repo behind the channel is https://github.com/ezra-letta/ezra (demos, experiments, field notes, challenges, public guides — the evidence that each post points at).

What already exists in this repo

• Run history. Redacted lifecycle events under the run-history/v1/ Blob namespace, reachable through read_run_record and list_run_history; this is the raw material for a change log. The read surface that renders it internally is proposal: add a factory activity view to the web chat #64.
• Redaction. lib/redaction.ts already exists, and run records are stored redacted by design. A public surface must reuse it rather than invent a second policy.
• Schedules. eve supports root-authored schedules as single files under agent/schedules/ (defineSchedule({ cron, run })), with a handler form that selects a channel target via to(...) and sends with a pre-built app principal. On Vercel each schedule becomes a Cron Job evaluated in UTC, so a 9:00 AM America/Los_Angeles cadence is 0 16 * * * or 0 17 * * * depending on DST. This repo has no agent/schedules/ yet, and declared subagents cannot own schedules.
• Discord inbound. PR feat: answer ordinary @Computer mentions in the internal Discord channel #67 adds ordinary @Computer mentions through a Gateway bridge (bridge/discord-gateway/) that forwards signed events to /eve/v1/discord-mentions. Admission there requires an explicit mention in every case, including inside threads, and the public tier is deliberately deferred (Enforce the Discord public tier server-side: per-tool gating, not prompt-level trust #16, proposal: support ordinary @mentions in the internal Discord channel #66) — so today Computer cannot answer anywhere public, and cannot be reached in a thread without being mentioned.
• Repo visibility. wazootech/computer is public; wazootech/computer-memory (redacted run records and memory) is private. A public log has to be composed from redacted material, never mirror the private store.

Proposed behavior

• Channel. One read-only channel in the Wazoo Discord: @everyone denied Send Messages, Computer's bot allowed. Humans participate in threads. The channel is not on any admission allowlist for top-level messages.
• Cadence. One in-repo schedule (agent/schedules/activity-log.ts, handler form) at 9:00 AM America/Los_Angeles. The schedule lives in the deployment, so it survives a runtime move.
• Selection. An editorial skill that reads the ledger and a candidate queue and rotates format and topic with a repeat guard (no repeat of the previous format, no repeat of a core topic within 30 days).
• Evidence first. Every post cites something checkable: a merged PR, a commit, a run record, a reproduced command output, or a published artifact. If nothing verifies, publish nothing that cadence and record the skip with its reason.
• One post. At most one message per cadence, written by a single writer, idempotent on a content hash so a retry after a partial failure cannot double-post.
• Ledger. Append only after Discord returns a message ID. Recommended home: a Git-backed JSON file in a public repo (metadata only — date, topic, format, evidence link, source, Discord message ID), so the repeat guard is auditable by readers. The exact home is an open question below.
• Discussion route. Thread replies whose parent is the activity channel are admitted without a mention — a deliberate, channel-scoped exception to the mention rule in proposal: support ordinary @mentions in the internal Discord channel #66 — and a new top-level mention creates a thread. This is the one admission-matrix change the reference workflow requires.

Failure modes that must stay legible

• No schedule, or no ledger, in the running deployment: post nothing, record the skip reason, and surface it in the internal channel. This is the reference's own outage; it should be loud, not silent.
• Discord rejects or the post fails: no ledger append, retry on the next cadence, no duplicate.
• Evidence fails verification: skip and record the attempt, per the reference rule against speculation.
• A candidate that cannot be published without private detail: drop it; never widen redaction to make a post possible.

Open questions

• Which repo holds the published artifacts and the ledger: a new public repo of our own, an existing public repo (for example wazootech/wazoo-factory, which is public and already describes an Eve runtime and Discord channel), or a directory in this already-public repo?
• Should the log cover factory runs only, or also repository activity (opened issues, merged PRs, reviewer escalations)?
• Strictly read-only at top level, or should a top-level human message also open a thread?
• Who moderates a busy thread, and does the agent have a stated escalation path to a human?
• Does publishing belong to Computer or to the developer-support agent in proposal: introduce Data, a developer-support agent, and split this repo into a two-agent eve workspace #72? Recommendation: the change log is Computer's own record and stays with Computer; public developer-support answers belong to the other agent.

Acceptance criteria

• A read-only channel exists; a human without a role cannot post to it, and the bot can.
• One scheduled run in the deployment produces at most one message, at the intended local time, and the local time is correct across a DST boundary.
• Every published message links at least one verifiable artifact, and a message with no verifiable evidence is skipped and recorded instead.
• The ledger records date, topic, format, evidence, source, and Discord message ID, and it is appended only after Discord accepts the post.
• Re-running the schedule twice in the same cadence cannot publish twice.
• Someone can reply in a thread under the channel without mentioning the bot and get a response; a top-level mention opens a thread.
• No private or unredacted content from wazootech/computer-memory reaches the channel.

Non-goals

• Not a public support or Q&A channel. The public admission tier stays where Add a controlled Discord channel for Computer #3 and Enforce the Discord public tier server-side: per-tool gating, not prompt-level trust #16 put it.
• Not a verbatim mirror of run records, and not a live feed.
• No new write capability on the web surface; this is an outbound publishing path plus one narrow thread-admission exception.

[EthanThatOneKid]

Cross-reference: the agent split that would own the public developer-support surface is proposed in #72. This channel is Computer's own record and stays with Computer regardless of how #72 is settled.

[EthanThatOneKid]

Recommendation on the open question in this issue (publishing owner), refining my earlier note on this thread:

Split it by artifact class, not by channel.

• Data owns the editorial, #ezra-tips-shaped channel (once proposal: introduce Data, a developer-support agent, and split this repo into a two-agent eve workspace #72 lands). In the reference, the channel belongs to the developer-support agent and its subject matter is that agent's own work product: guides, field notes, experiments, challenges, demos, which is exactly the layout of the public ezra-letta/ezra repo. Copying the pattern means copying its ownership.
• Computer owns a raw activity log if we want one at all: runs, branches, PRs, CI state, sourced from the already-redacted run-history/v1/ records. A log is verifiable and low-editorial; it has no formats to rotate.
• The machinery is shared, not owned: schedule shape, ledger contract, evidence gate, and thread routing belong in the shared core so either agent can adopt them.

Why not one Computer-owned editorial channel:

1. The rotation rules only mean something for editorial pieces. A run log cannot rotate among builds/experiments/stories/challenges, so merging the two makes the rules decorative.
2. Different verification ladders. Computer's claims are machine-attested by run records, CI, and PR state; a teaching piece has to be reproduced against released docs or source and abandoned when it cannot be, which is an editorial judgment.
3. Voice. This repo commits to Computer's ship's-computer register (Add a controlled Discord channel for Computer #3). An editorial teaching voice is a second persona, and a public channel that mixes both reads as neither.
4. A channel and its threads are one surface. Owning the editorial channel means answering its thread replies, which is the public developer-support surface that Enforce the Discord public tier server-side: per-tool gating, not prompt-level trust #16 gates and proposal: introduce Data, a developer-support agent, and split this repo into a two-agent eve workspace #72 assigns to Data.
5. One writer per surface (the first rule of proposal: introduce Data, a developer-support agent, and split this repo into a two-agent eve workspace #72's contract) also means one ledger per publisher. Two publishers on one channel collide on the ledger.

Sequencing: if a channel ships before Data exists, ship the raw log under Computer (it is the only agent that exists) and leave the editorial loop for Data. Do not build the editorial loop on Computer and migrate it later.