Eunomia Community Radar

Eunomia Community Radar

Turn daily community discussion into one durable answer and one compact view of what eBPF practitioners are trying to solve. Every daily run publishes exactly one combined Q&A and community briefing. Never invent a question or publish without real public primary sources; coverage, freshness, and access gaps are reported honestly and never stop the publication itself.

Required Context

Read before monitoring:

• CLAUDE.md
• .agents/README.md
• .github/publisher/media/community-watchlist.yaml
• .github/publisher/media/community-feedback.md
• docs/ebpf-qa/index.md
• the publication standard

Keep the watchlist as the allowlist. Adding a workspace, server, channel, or forum is a durable scope change and requires an explicit repository edit.

Workflow

1. Review The Full Daily Window

Apply the hybrid source policy declared in the watchlist:

• Slack sources marked archive_opt_in: true use the approved private read-only archive as the primary source and the visible browser as the fallback.
• Discord and any chat source without an archive remain visible-browser-only.
• Mailing lists and Reddit use ordinary public browser pages and never APIs.
• Official documentation may be read in the normal browser.

Do not use hidden APIs, internal endpoints, unapproved chat exports, network interception, or scraped message archives for any source. Archive access must satisfy every invariant in the Archive Access Invariants section.

Review every accessible allowlisted channel for the previous 24 hours. Use visible channel navigation, date dividers, and Page Up, Page Down, Home, or End key presses. The optional visible-channel-review.mjs helper may collect text that is currently rendered in the visible browser and move the same visible message pane with keyboard input. It must never launch a crawler, call a platform endpoint, persist a transcript, or bypass access controls.

Read only approved public channels and threads. Never enter restricted, private, direct-message, customer, or partner channels for editorial mining. If a listed channel is inaccessible, record the coverage gap in the run result instead of claiming it was quiet.

2. Select The Daily Question

Choose the most useful concrete technical question seen in the daily window. Prefer questions that recur, expose a poorly documented boundary, or connect several discussions. The question must be:

• relevant to eBPF, Linux observability, runtime extension, profiling, security, or adjacent Agent infrastructure;
• answerable from public primary sources or a reproducible local experiment;
• useful without the original participant's identity or deployment details; and
• materially different from an existing Q&A, tutorial, or blog post.

When no single message is strong enough, combine related same-day signals into one practical question. Partial archive coverage, inaccessible or sparse sources, or a thin daily window never stop publication: continue selecting and verifying a real question from existing readable archive material, a genuine unresolved question from the monitored communities regardless of age, permitted public community pages, or public primary documentation, and say in the internal run result which fallback supplied the question. Never publish a placeholder, promotional topic, or speculation, and never fabricate a question or evidence.

3. Write The Answer

Name the article with the anonymized practitioner question. Answer it in detail before discussing the wider community. Write from the technical issue, not the chat wording. Remove names, handles, employers, organization names, timestamps, exact infrastructure, internal URLs, logs, tokens, IP addresses, and distinctive phrasing. Never quote or link a closed-community message on the public page.

Verify the answer with official documentation, upstream repositories, standards, kernel documentation, or papers. Search results can locate sources but cannot replace reading them. Separate established behavior, operational advice, and open limitations. Add a References section after the answer with only the public sources used.

Title/H1 note: keep the H1 free of underscores, backticks, and apostrophes. The publisher renders the question as the page H1 and the validator re-checks that the exact Markdown title string is present verbatim in the live HTML; the site's H1 pipeline strips underscores and HTML-encodes apostrophes, so such characters force a failed live-content check and an extra redeploy. Put helper names as ordinary words in the H1 and reserve backticked code for the answer body.

4. Summarize The Day's Discussion

After the references, add Community discussion today. Cover as much of the daily window as the allowlist and browser access permit. State the number of communities and channels reviewed, then synthesize the main technical themes, where practitioners are getting stuck, and what questions remain unresolved.

Anonymize identity and deployment details without stripping away the technical substance. For every substantive theme, explain the concrete problem or symptom, the likely mechanism or boundary, the practical diagnostic or resolution path, and what remains uncertain. Cite the public primary sources that support these mini-answers. When the daily window contains several real technical discussions, this section should normally be at least twice as detailed as a terse trend-only summary; do not reduce each discussion to one sentence.

Summarize across discussions rather than listing messages. Do not publish participant names, handles, employers, channel names, message links, exact timestamps, private topology, or wording that can be searched back to one person. It is acceptable to say that a channel had no substantive technical discussion. Never treat inaccessible channels as zero activity.