# Council Briefing: 2025-12-17 ## 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 - As Kraken listing and migration chatter peak, the Council’s critical priority is preserving trust by hardening the token-migration surface area (security + exchange coordination) while simultaneously proving Cloud readiness through visible reliability wins. ## Key Points for Deliberation ### 1. Topic: Token Migration & Exchange-Edge Trust (Kraken/Bithumb + Site Security) **Summary of Topic:** The migration narrative is now the public face of ElizaOS: Kraken listing (Dec 19) increases scrutiny while unresolved exchange delays and a reported migration-site compromise risk reputational damage precisely during the execution-excellence directive. #### Deliberation Items (Questions): **Question 1:** What is the Council’s stance on exchange-held migration delays (e.g., Bithumb): do we escalate publicly, support quietly, or offer an off-exchange escape hatch? **Context:** - `Discord 2025-12-15: Korean users frustrated about Bithumb delay; response: "exchanges are responsible for migrating tokens held on their platforms" (Omid Sa/community).` - `Discord 2025-12-16: Kraken listing Dec 19 and 1:6 distribution ratio discussed (Serikiki).` **Multiple Choice Answers:** a) Escalate publicly with a clear deadline and a formal status page naming exchange blockers. *Implication:* Maximizes transparency and pressure, but risks adversarial relationships with exchanges during listing window. b) Maintain quiet bilateral escalation while publishing a neutral, frequently updated migration FAQ/status dashboard. *Implication:* Preserves partnerships while still reducing confusion; slower to satisfy the most vocal community segments. c) Offer a structured off-exchange remedy (support-assisted withdrawal/migration pathway) and de-emphasize exchange timelines. *Implication:* Shifts control back to users and the team but increases support load and operational complexity. d) Other / More discussion needed / None of the above. **Question 2:** How should we handle the reported migration-site security allegation to maximize trust without amplifying panic? **Context:** - `Discord 2025-12-15: "A potential security issue with the ElizaOS migration site was reported"; Q/A: "Is the ElizaOS migration site hacked/hijacked?" → "We're looking at it."` **Multiple Choice Answers:** a) Immediate public incident bulletin with scope, mitigations, and an independent audit commitment. *Implication:* High-trust posture if handled well; any uncertainty in early details may fuel further speculation. b) Silent fix-first approach, then publish a postmortem only if evidence confirms compromise. *Implication:* Reduces short-term panic but risks backlash if the community believes information was withheld. c) Publish precautionary guidance now (safe URLs, wallet hygiene, verification steps) while investigation proceeds, plus a time-boxed update cadence. *Implication:* Balances calm and transparency; sets expectations and reduces harm regardless of final finding. d) Other / More discussion needed / None of the above. **Question 3:** Given the Kraken listing and distribution ratio attention, what messaging frame should we adopt to prevent 'project is finished / team is silent' narratives from metastasizing? **Context:** - `Discord 2025-12-16: "Some users expressed concerns about the project's status, questioning whether ElizaOS is finished"; A: "No, ElizaOS isn't finished" (Kenk).` - `Discord 2025-12-16: Kraken listing Dec 19 + 1:6 ratio (Serikiki).` **Multiple Choice Answers:** a) Roadmap-forward: publish a short 'next 30 days' execution board (migration completion, Cloud launch milestones, flagship stabilization). *Implication:* Converts uncertainty into predictable delivery signals; commits the team to visible dates. b) Reliability-forward: emphasize shipped fixes, tests, and stability metrics over roadmap promises. *Implication:* Aligns with execution excellence and reduces overcommitment, but may feel vague to token-focused users. c) Ecosystem-forward: spotlight builders (contests, reference agents, community deployments) as proof of life. *Implication:* Builds social proof quickly; must be paired with core reliability wins to avoid 'marketing-only' perception. d) Other / More discussion needed / None of the above. --- ### 2. Topic: Cloud Launch Readiness (Streaming UX, Auth, and Create→Publish→Monetize Loop) **Summary of Topic:** Cloud capability is advancing (integrations, end-to-end business cycle vision), but the Council must decide what 'launch' means: a hardened minimal path with impeccable UX, or a broader platform debut that risks reliability debt at the worst moment. #### Deliberation Items (Questions): **Question 1:** What is our launch threshold for ElizaOS Cloud: minimal reliable deployment path, or full create→publish→monetize→promote loop on day one? **Context:** - `Discord 2025-12-14: Cloud focus includes "create → publish → monetize → promote" plus SEO/ads/social integrations (shaw).` - `Discord 2025-12-16 core-devs: "Push cloud PR for testing" and ongoing cloud work (Stan ⚡).` **Multiple Choice Answers:** a) Launch a minimal, rock-solid 'deploy + storage + logs + billing stub' and gate advanced growth features behind an alpha flag. *Implication:* Aligns strongly with execution excellence and reduces blast radius; delays the platform narrative of monetization. b) Ship the full loop at launch to claim category leadership, accepting controlled rough edges. *Implication:* Maximizes market impact but risks developer trust if onboarding or reliability falters. c) Two-tier launch: public beta for core deploy, invite-only 'Eliza-Alpha' for monetization/promote features. *Implication:* Preserves ambition while protecting trust; requires clear comms and operational discipline. d) Other / More discussion needed / None of the above. **Question 2:** How urgent is the streaming UX bug in Actions UI relative to other Cloud blockers, and should it become a launch gate? **Context:** - `Discord 2025-12-16 core-devs: "streaming works in the monorepo but there are rendering issues in Actions that need fixing" (Stan ⚡).` **Multiple Choice Answers:** a) Make it a hard launch gate: streaming perception is a first-impression reliability signal. *Implication:* Optimizes UX trust but may delay launch if the root cause is non-trivial. b) Soft gate: ship with a known-issues note and prioritize a patch within 72 hours post-launch. *Implication:* Protects schedule while acknowledging imperfection; requires rapid response credibility. c) Defer: treat it as non-critical and focus on auth, storage correctness, and deployment success rates. *Implication:* Prioritizes functional reliability, but risks 'feels broken' sentiment even if backend is solid. d) Other / More discussion needed / None of the above. **Question 3:** Do we standardize on JWT auth + data isolation now (as a platform foundation), or keep legacy headers until Cloud stabilizes? **Context:** - `GitHub top PR: "feat(auth): implement JWT authentication and user management" (PR #6200, standujar) with ENABLE_DATA_ISOLATION toggle.` - `Discord 2025-12-16 core-devs: "Rebase authentication PR on the monorepo" (Stan ⚡).` **Multiple Choice Answers:** a) Adopt JWT/data isolation as the default for Cloud (legacy header mode only for local/dev). *Implication:* Establishes a scalable multi-tenant foundation; increases integration/testing burden immediately. b) Keep legacy mode as default until Cloud proves stability; run JWT as opt-in beta. *Implication:* Reduces near-term risk but postpones foundational security/tenancy decisions. c) Hybrid: JWT for Cloud-hosted agents, legacy headers for self-hosted framework users during transition. *Implication:* Balances platform needs and OSS ergonomics; increases documentation and support complexity. d) Other / More discussion needed / None of the above. --- ### 3. Topic: Developer Experience & Reliability Flywheel (DB Migrations, PR Proof, AI-Assisted Workflow) **Summary of Topic:** Developer trust is trending upward via heavy refactors, tests, and SQL/migration fixes, but field reports still show friction (Postgres permissions/migrations, foreign key failures). The Council must choose which DX investments become mandatory protocol versus optional tooling. #### Deliberation Items (Questions): **Question 1:** What is the Council’s canonical 'known-good' database path for contributors (PGlite, Docker Postgres, managed Neon), given recurring local Postgres migration failures? **Context:** - `Discord 2025-12-16 coders: FenrirFawks had persistent migration issues on local Postgres 18 without superuser; Stan suspects schema permissions.` - `Discord 2025-12-15: Twitter replies caused foreign key constraint failures; "latest codebase has SQL fixes" mentioned.` **Multiple Choice Answers:** a) Standardize on PGlite for local dev by default; Postgres as an advanced/CI-only path with strict docs. *Implication:* Maximizes ease-of-entry and reproducibility; may mask Postgres-only issues until later. b) Standardize on Dockerized Postgres with one blessed compose file and required permissions/scripts. *Implication:* Aligns dev with production realities; higher setup overhead but fewer 'works on my machine' cases. c) Standardize on managed Neon for dev/test environments with free-tier guidance and CLI automation. *Implication:* Fast onboarding and realistic infra; introduces external dependency and account friction. d) Other / More discussion needed / None of the above. **Question 2:** Should the 'PRs larger than 20 lines require a video' rule become enforced policy across repos, and if so, how do we prevent it from slowing delivery? **Context:** - `Discord 2025-12-16 core-devs: "What's the new rule for PRs larger than 20 lines?" → "include a video of it working" (shaw).` **Multiple Choice Answers:** a) Enforce it broadly with CI checklists/templates; allow exemptions for pure refactors/tests/docs. *Implication:* Improves review confidence and trust-through-shipping; requires governance clarity to avoid friction. b) Keep it as a strong recommendation for UI/behavior changes only, not a universal rule. *Implication:* Preserves velocity while still raising quality where it matters most; less consistent evidence in reviews. c) Replace videos with automated e2e smoke tests + reproducible scripts, making human demos optional. *Implication:* Scales better long-term but demands up-front investment in test harnesses and infra. d) Other / More discussion needed / None of the above. **Question 3:** Do we formalize AI-assisted development (bots, review agents, environment containers) as first-class infrastructure to accelerate execution excellence, or keep it ad hoc? **Context:** - `Discord 2025-12-16 core-devs: cjft notes pain in "handling AI reviews repeatedly" and suggests "a GitHub bot"; R0am mentions claudekit hooks; discussion of environment containers and multi-instance workflows.` **Multiple Choice Answers:** a) Formalize: build/choose a sanctioned GitHub review-bot + contributor workflow, and publish 'AI coding' playbooks. *Implication:* Raises throughput and consistency; requires careful safeguards to prevent low-quality automated approvals. b) Semi-formal: keep tools optional but provide curated recommendations (claudekit, worktrees, containers) and a reference setup. *Implication:* Improves DX without forcing change; benefits may be uneven across contributors. c) Defer: prioritize core product reliability; revisit workflow automation after Cloud launch stabilizes. *Implication:* Avoids tool-churn during critical launches, but leaves current productivity bottlenecks unresolved. d) Other / More discussion needed / None of the above.