# Council Briefing: 2025-03-28

## Monthly Goal

December 2025: Execution excellence—complete token migration with high success rate, launch ElizaOS Cloud, stabilize flagship agents, and build developer trust through reliability and clear documentation.

## Daily Focus

- Reliability posture improved via merged stability and test work, but trust is threatened by fresh breakpoints in dependency resolution and social integrations (Twitter), requiring fast triage to preserve “execution excellence.”

## Key Points for Deliberation

### 1. Topic: Release Hygiene & Dependency Integrity

**Summary of Topic:** New issues highlight that install-time breakage (missing plugin versions) can nullify shipped improvements; the Council must harden packaging/versioning and define a rapid-response protocol for ecosystem-wide dependency faults.

#### Deliberation Items (Questions):

**Question 1:** What is our standard response when a published dependency/version mismatch blocks installs for a meaningful segment of builders?

  **Context:**
  - `GitHub Issue #4101: "No matching version found for @elizaos/plugin-sql@^0.25.6" (npm notarget).`
  - `Daily Digest (Mar 28): flagged #4101 as "Needs Attention" requiring immediate resolution.`

  **Multiple Choice Answers:**
    a) Hotfix immediately: publish/restore the missing version(s), then backfill a postmortem and CI guardrails.
        *Implication:* Optimizes developer trust in the short term, but risks repeating the failure if root causes aren’t automated out.
    b) Ship a CLI-side compatibility shim: auto-resolve to a known-good version range and warn users.
        *Implication:* Reduces ongoing breakage and support load, but adds complexity and can mask deeper release discipline problems.
    c) Enforce a hard freeze: block new merges/releases until the packaging pipeline is made reproducible and verified end-to-end.
        *Implication:* Maximizes long-term reliability and predictability, but slows shipping cadence and may frustrate contributors.
    d) Other / More discussion needed / None of the above.

**Question 2:** How aggressively should we consolidate version lines (v0.25.9, v1.0.0-beta, v2) to reduce migration entropy and support burden?

  **Context:**
  - `Discord (Mar 27): “Users are transitioning between different versions (v0.25.9, v1.0.0, v2) with various migration challenges.”`
  - `Discord action item: “Create migration guide from v0.25.9 to v1.0.0.”`

  **Multiple Choice Answers:**
    a) Maintain parallel tracks, but publish an official support matrix and migration tooling per track.
        *Implication:* Preserves flexibility for power users while reducing confusion through explicit guarantees and documentation.
    b) Accelerate convergence: declare a primary track and deprecate older branches on a fixed timeline.
        *Implication:* Sharpens focus and reliability, but may strand users who rely on legacy plugin compatibility.
    c) Keep all tracks open-ended; rely on community support and best-effort fixes.
        *Implication:* Maximizes short-term velocity but undermines the ‘reliable, developer-friendly’ North Star through unpredictability.
    d) Other / More discussion needed / None of the above.

---


### 2. Topic: Social Surface Stability (Twitter/Discord/Telegram)

**Summary of Topic:** Twitter integration regressions (links/hashtags, generation flags, duplicate status behavior) remain a high-visibility trust vector; simultaneously, community-facing automation (Discord community manager) is maturing and should be operationalized safely.

#### Deliberation Items (Questions):

**Question 1:** Do we treat Twitter plugin reliability as a “tier-0” stability objective (release-gating), given its public-facing risk profile?

  **Context:**
  - `GitHub Issue #4102: “not getting links and hashtags in my twitter post”.`
  - `Discord action item (Mar 27): “Fix issue with Twitter plugin on v1 that tweets unrelated content (RaglioKen).”`

  **Multiple Choice Answers:**
    a) Yes—tier-0: Twitter correctness is release-gating with dedicated tests and canary accounts.
        *Implication:* Protects brand and user trust, but increases release overhead and requires automation investment.
    b) Tier-1: Fix quickly, but do not gate releases; provide clear “known issues” and toggles.
        *Implication:* Maintains shipping tempo while containing damage, but accepts ongoing public glitches.
    c) Deprioritize: shift social emphasis to Discord/other channels until Twitter stabilizes externally.
        *Implication:* Reduces exposure to platform volatility, but sacrifices growth and visibility where many builders discover us.
    d) Other / More discussion needed / None of the above.

**Question 2:** How should we operationalize the new Discord community manager feature to avoid governance/abuse failures (timeouts, greetings) while still improving community UX?

  **Context:**
  - `PR #4099: “feat: Discord community manager… greet users… timeout users.”`
  - `Daily Digest (Mar 28): community engagement feature shipped; flagged as completed work.`

  **Multiple Choice Answers:**
    a) Deploy with conservative defaults: greetings on, timeouts off by default, explicit role-based allowlists.
        *Implication:* Minimizes harm and reputational risk, but delays realizing full moderation automation benefits.
    b) Deploy fully enabled with audit logging and rollback controls; iterate from live telemetry.
        *Implication:* Maximizes immediate operational value, but increases the risk of accidental moderation incidents.
    c) Keep feature behind an experimental flag until we have policy docs + test harness + incident playbook.
        *Implication:* Builds governance maturity and trust, but slows community-facing improvements.
    d) Other / More discussion needed / None of the above.

**Question 3:** Given repeated Telegram/Twitter client issues, do we need a unified “client conformance suite” (contract tests) across social plugins before the next stability push?

  **Context:**
  - `Discord action items (Mar 27): “Fix Telegram client image processing…”, “Fix Twitter client in v2 to handle duplicate status errors.”`
  - `PR list includes multiple plugin fixes and test expansions (e.g., #4090 tests for agent types).`

  **Multiple Choice Answers:**
    a) Yes—create a minimal conformance suite (auth, posting, attachments, rate limits) and require it for plugin releases.
        *Implication:* Improves multi-platform reliability and reduces regressions, reinforcing the “execution excellence” principle.
    b) Partial—only add contract tests for the most-used paths (posting + error handling), expand later.
        *Implication:* Balances speed and stability, but leaves edge-case regressions likely.
    c) No—rely on community testing and fast patching; focus engineering on core runtime instead.
        *Implication:* Preserves core velocity but keeps social surfaces fragile and support-intensive.
    d) Other / More discussion needed / None of the above.

---


### 3. Topic: Developer Trust: DX, Docs, and Observability

**Summary of Topic:** Major progress landed on DX scaffolding (environment settings GUI, expanded tests, reduced noisy logs), but builders still experience confusion across versions and lack tracing/clarity—documentation discoverability and operational observability are now strategic levers.

#### Deliberation Items (Questions):

**Question 1:** Should we define a single canonical “developer journey” (install → first agent → first plugin → deploy) and gate releases on it being clean across supported versions?

  **Context:**
  - `Discord (Mar 27): repeated questions on “Where should I put the JSON character file in Eliza v2?” and migration confusion.`
  - `PR #4080: “Environment Settings GUI… manage local and global environment variables directly from the Web UI.”`

  **Multiple Choice Answers:**
    a) Yes—formalize the journey as a release gate with automated smoke tests and docs checks.
        *Implication:* Directly advances the North Star (developer-friendly reliability) but requires continuous maintenance.
    b) Define the journey, but treat it as a guideline; fix breakages opportunistically.
        *Implication:* Improves coordination without slowing releases, but allows chronic papercuts to persist.
    c) No—focus on power-user flexibility; let community tutorials diversify the journey.
        *Implication:* Encourages experimentation, but increases newcomer churn and support load.
    d) Other / More discussion needed / None of the above.

**Question 2:** Do we prioritize adding first-class tracing for LLM interactions (LangSmith-like) as a core trust feature for builders operating agents at scale?

  **Context:**
  - `Discord (Mar 27, coders): “Is there any way to do tracing on Eliza's LLM interactions similar to LangSmith?” (ad0ll) — unanswered.`
  - `Daily Digest (Mar 28): expanded test coverage (#4090) indicates a readiness push for reliability tooling.`

  **Multiple Choice Answers:**
    a) Yes—build native tracing hooks (spans, prompts, tool calls, token metrics) and a minimal UI viewer.
        *Implication:* Increases debuggability and enterprise-grade credibility, but adds platform surface area to maintain.
    b) Integrate with existing tools via an open telemetry/OTel-style adapter first; UI later.
        *Implication:* Delivers composability fast and aligns with open principles, but may feel fragmented to newcomers.
    c) Defer tracing; focus on docs and deterministic behavior improvements first.
        *Implication:* Keeps focus on immediate friction points, but limits advanced operator confidence and scaling.
    d) Other / More discussion needed / None of the above.

**Question 3:** What is the Council’s stance on “documentation as a shipping artifact” (SEO, discoverability, migration guides) versus “best-effort” docs in high-velocity periods?

  **Context:**
  - `Discord (Mar 27): “Improve documentation visibility and SEO for eliza.how” (jin).`
  - `Discord action item (Mar 27): “Create migration guide from v0.25.9 to v1.0.0” (kaisermerkle).`

  **Multiple Choice Answers:**
    a) Docs are release-gating: no major change ships without migration notes and updated canonical docs.
        *Implication:* Maximizes developer trust and reduces support debt, but slows iteration during rapid architecture shifts.
    b) Hybrid: gate only critical paths (install, migrate, auth/secrets, core APIs), allow non-critical docs to lag.
        *Implication:* Targets the highest leverage documentation while preserving velocity.
    c) Best-effort: prioritize code shipping and rely on community to patch docs.
        *Implication:* Fastest development pace, but accumulates confusion debt and undermines the “developer-first” posture.
    d) Other / More discussion needed / None of the above.