## Issue Triage — 2026-05-01

### 1) Secure agent key management + “keep secrets local” baseline
- **Issue Title & ID:** Agent key security + local secret storage baseline (Discord Action Item) — **DISCORD-2026-04-30-KEYS**
- **Current Status:** Identified in Discord (0xtdl01); no tracked GitHub issue yet
- **Impact Assessment:**
  - **User Impact:** **Critical** (any self-host / local dev running agents)
  - **Functional Impact:** **Partial** (agents can run, but unsafe to deploy broadly)
  - **Brand Impact:** **High** (security posture is highly visible for agent frameworks)
- **Technical Classification:**
  - **Issue Category:** **Security**
  - **Component Affected:** **Core Framework**, **Self-host runtime**, **Plugin System** (credential handling)
  - **Complexity:** **Architectural change** (needs conventions + tooling)
- **Resource Requirements:**
  - **Required Expertise:** AppSec, secure storage (OS keychains), threat modeling, Node/Bun runtime internals
  - **Dependencies:** Align with self-host bearer auth work; define runtime config/secret interfaces for plugins
  - **Estimated Effort (1–5):** **5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Create a GitHub issue with explicit threat model: secrets at rest, in logs, in crash dumps, in plugin configs, and in memory.
  2. Define a **Secret Provider** interface (env, OS keychain, encrypted file, external vault) and prohibit raw key material in persisted character/app state.
  3. Add **redaction utilities** for logs + structured logging guidelines for plugins/providers.
  4. Add CI checks for “known secret patterns” leaking into logs/artifacts (basic secret scanning).
- **Potential Assignees:**
  - **odilitime** (security hardening + infra experience; x402 work suggests auth familiarity)
  - **Shaw (shawmakesmagic)** (core architecture decisions)
  - **0xtdl01** (originator; can help spec + implement)

---

### 2) Self-hosted deployment security validation (CORS + bearer auth) and misconfiguration hardening
- **Issue Title & ID:** Self-host security review for newly added CORS + bearer auth — **INFRA-SELFHOST-AUTH-CORS**
- **Current Status:** Changes landed (dev log: “CORS support, bearer authentication” + cross-platform build fixes); needs validation + secure defaults
- **Impact Assessment:**
  - **User Impact:** **High** (self-hosted users; likely growing with v3)
  - **Functional Impact:** **Yes** (misconfig can break access or expose endpoints)
  - **Brand Impact:** **High** (publicly exploitable misconfig risk)
- **Technical Classification:**
  - **Issue Category:** **Security / UX**
  - **Component Affected:** **API / Self-host runtime**
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Web security (CORS), auth middleware, deployment ergonomics
  - **Dependencies:** Documentation updates; alignment with plugin paid routes / x402
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Add integration tests that fail if:
     - CORS is overly permissive by default (`*` with credentials, wildcard origins, etc.).
     - Bearer auth can be bypassed on any privileged route.
  2. Ship “secure-by-default” configuration presets (dev/prod) and explicit warnings on unsafe CORS settings.
  3. Provide a minimal self-host hardening guide: reverse proxy, TLS termination, allowed origins, token rotation.
- **Potential Assignees:**
  - **odilitime** (infra/auth)
  - **lalalune** (CLI/infra integration + deployment ergonomics)
  - **meanstackofdoom** (review + test coverage)

---

### 3) Provider/SDK dependency upgrades risk regressions across Anthropic/OpenAI + AI core dependency
- **Issue Title & ID:** Regression sweep for SDK bumps (Anthropic 0.92.0, OpenAI provider 3.0.55, AI dep 6.0.172, provider-utils 4.0.25) — **DEPS-AI-SDK-REGRESSION**
- **Current Status:** Updates completed per dev log; regression status unknown
- **Impact Assessment:**
  - **User Impact:** **High** (large portion of users rely on these integrations)
  - **Functional Impact:** **Yes** (model calls and tool execution are core)
  - **Brand Impact:** **Medium/High** (breakages look like “framework instability”)
- **Technical Classification:**
  - **Issue Category:** **Bug / Maintenance**
  - **Component Affected:** **Model Integration**, **Core runtime provider layer**
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Provider integrations, API contract testing, prompt/tool schema compatibility
  - **Dependencies:** CI matrix + fixture prompts; may depend on external API changes
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Run a compatibility test suite: streaming, tool calls, JSON mode, retries, rate-limit handling.
  2. Add “golden transcript” tests for 2–3 canonical agent tasks to detect subtle behavior drift.
  3. Document version pins + rollback steps for self-host users.
- **Potential Assignees:**
  - **Shaw (shawmakesmagic)** (core provider layer)
  - **2-A-M** (runtime wiring + triggers experience; good for integration tests)
  - **greptile-apps** (review/verification support)

---

### 4) LifeOps schedule persistence + asset path bugs (open PR)
- **Issue Title & ID:** LifeOps schedule persistence + asset path issues — **elizaos/eliza#7132**
- **Current Status:** PR opened by **jqmwa**; not confirmed merged
- **Impact Assessment:**
  - **User Impact:** **Medium/High** (users relying on LifeOps scheduling)
  - **Functional Impact:** **Partial** (core runtime works; LifeOps workflows unreliable)
  - **Brand Impact:** **Medium** (broken scheduling undermines “agent reliability”)
- **Technical Classification:**
  - **Issue Category:** **Bug**
  - **Component Affected:** **Core Framework / LifeOps module**
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** State persistence, runtime file/path handling, cross-platform paths
  - **Dependencies:** Cross-platform build fixes; potential dependency on new app runtime packaging
  - **Estimated Effort (1–5):** **2**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Reproduce on at least 2 OSes (Windows + Linux/macOS) and verify schedule survives restart.
  2. Add regression tests for schedule serialization + asset resolution.
  3. Merge PR if it passes; otherwise request changes with failing test artifacts.
- **Potential Assignees:**
  - **jqmwa** (author)
  - **Dexploarer** (app/core pathing + packaging)
  - **odilitime** (cross-platform stability review)

---

### 5) Plugin-lifecycle decoupling coordination (core ↔ plugins) to avoid ecosystem breakage
- **Issue Title & ID:** Decouple agent server from apps + standardized plugin lifecycle — **elizaos/eliza#7204** (and linked cross-repo work)
- **Current Status:** Reported as coordinated change in weekly summary; ongoing integration risk across plugin repos
- **Impact Assessment:**
  - **User Impact:** **High** (plugin authors + all users depending on plugins)
  - **Functional Impact:** **Yes** (plugin loading/execution is core to elizaOS)
  - **Brand Impact:** **High** (plugin breakage reads as “ecosystem unstable”)
- **Technical Classification:**
  - **Issue Category:** **Bug / Architectural**
  - **Component Affected:** **Plugin System**, **Core Framework**
  - **Complexity:** **Architectural change**
- **Resource Requirements:**
  - **Required Expertise:** API design, semver discipline, migration tooling
  - **Dependencies:** Registry updates; plugin maintainers coordination; docs
  - **Estimated Effort (1–5):** **4**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Publish a single “Plugin Lifecycle Spec” (init/start/stop, capability negotiation, config/secret access).
  2. Provide a migration guide + codemod examples for top plugins (Telegram, Discord, Anthropic).
  3. Add a cross-repo CI “canary” that loads a representative set of plugins against main.
- **Potential Assignees:**
  - **Shaw (shawmakesmagic)** (architecture owner)
  - **2-A-M** (runtime wiring)
  - **Dexploarer** (app runtime impacts)
  - **baogerbao** (plugin/community coordination)

---

### 6) Red-team swarm testing methodology (agent safety + exploit discovery)
- **Issue Title & ID:** Red team swarm testing harness + methodology — **DISCORD-2026-04-30-REDTEAM**
- **Current Status:** Proposed in Discord (0xtdl01); no GH issue yet
- **Impact Assessment:**
  - **User Impact:** **Medium** now, **High** as v3/self-host adoption grows
  - **Functional Impact:** **Partial** (quality/safety gate, not runtime requirement)
  - **Brand Impact:** **High** (proactive security testing signals maturity)
- **Technical Classification:**
  - **Issue Category:** **Security / Quality**
  - **Component Affected:** **Core Framework**, **Tooling/Test Harness**
  - **Complexity:** **Complex solution**
- **Resource Requirements:**
  - **Required Expertise:** Offensive testing, sandboxing, prompt injection testing, test automation
  - **Dependencies:** Secret management baseline (P0 item #1); deterministic replay tooling
  - **Estimated Effort (1–5):** **4**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Define 10–20 core adversarial scenarios (prompt injection, data exfiltration, tool misuse, wallet drain patterns).
  2. Build a harness for multi-agent “swarm” fuzzing with replayable seeds and artifact capture.
  3. Gate releases with a minimal “security regression suite.”
- **Potential Assignees:**
  - **0xtdl01** (driver)
  - **NubsCarson** (testing discipline; monetization features benefit from safety gates)
  - **odilitime** (security review)

---

### 7) Local LLM data storage solution (privacy-preserving runtime state + model artifacts)
- **Issue Title & ID:** Local LLM data storage (privacy + portability) — **DISCORD-2026-04-30-LOCALDATA**
- **Current Status:** Mentioned in Discord; not tracked
- **Impact Assessment:**
  - **User Impact:** **Medium** (self-host, privacy-sensitive users)
  - **Functional Impact:** **Partial** (enables offline/private workflows)
  - **Brand Impact:** **Medium** (privacy story matters for adoption)
- **Technical Classification:**
  - **Issue Category:** **Feature Request / Security**
  - **Component Affected:** **Core Framework / Storage layer**
  - **Complexity:** **Architectural change**
- **Resource Requirements:**
  - **Required Expertise:** Storage design, encryption at rest, data lifecycle management
  - **Dependencies:** Secret provider interface (Issue #1); cross-platform path conventions
  - **Estimated Effort (1–5):** **4**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Decide scope: embeddings cache, conversation store, tool artifacts, fine-tune files, etc.
  2. Pick a default local store (SQLite + file blobs) with optional encryption.
  3. Provide import/export + “wipe all private data” control.
- **Potential Assignees:**
  - **Dexploarer** (app/runtime + local UX implications)
  - **Shaw (shawmakesmagic)** (core storage abstractions)
  - **0xtdl01** (privacy/security requirements)

---

### 8) v3 “all social platforms + iMessage” integration readiness (scope control + MVP definition)
- **Issue Title & ID:** Social integrations breadth (incl. iMessage) for v3 — **V3-SOCIAL-INTEGRATIONS**
- **Current Status:** Announced as a key v3 feature; integration “to be completed”
- **Impact Assessment:**
  - **User Impact:** **Medium/High** (major adoption driver, but not all users)
  - **Functional Impact:** **Partial** (core runtime works without it)
  - **Brand Impact:** **High** (public promise; delivery affects credibility)
- **Technical Classification:**
  - **Issue Category:** **Feature Request**
  - **Component Affected:** **Plugin System / Platform connectors**
  - **Complexity:** **Complex solution**
- **Resource Requirements:**
  - **Required Expertise:** Platform APIs, bot policies/compliance, event routing, message normalization
  - **Dependencies:** Plugin lifecycle spec (Issue #5); event routing standards (e.g., prior work like #7116)
  - **Estimated Effort (1–5):** **5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Define MVP platforms + success criteria (don’t treat “all platforms” as a single milestone).
  2. Standardize message/event schema across connectors.
  3. Add a conformance test kit for connectors (send/receive/edit/attachments).
- **Potential Assignees:**
  - **Shaw (shawmakesmagic)** (v3 direction)
  - **2-A-M** (event routing + triggers)
  - **baogerbao** (coordination + contributor onboarding for connectors)

---

### 9) Cloud monetization correctness: org credits debiting (open PRs)
- **Issue Title & ID:** Debit organization credit balances (pay-as-you-go hosting) — **elizaos/cloud#473, #474**
- **Current Status:** Open PRs by **NubsCarson** (per dev log)
- **Impact Assessment:**
  - **User Impact:** **Medium** (Cloud customers)
  - **Functional Impact:** **Yes** for monetization path (billing correctness)
  - **Brand Impact:** **High** (billing bugs create trust issues)
- **Technical Classification:**
  - **Issue Category:** **Bug / Feature**
  - **Component Affected:** **Cloud / Billing**
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Payments/billing ledgers, idempotency, concurrency, audit logs
  - **Dependencies:** Subscription management roadmap; database migrations
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Ensure debits are **idempotent** and resilient to retries/timeouts.
  2. Add ledger/audit table or immutable event log for disputes.
  3. Add unit/integration tests for concurrency (double-charge prevention).
- **Potential Assignees:**
  - **NubsCarson** (author)
  - **Shaw (shawmakesmagic)** (review for platform alignment)
  - **meanstackofdoom** (test/QA support)

---

### 10) Documentation gap: “Where can I see examples beyond docs?”
- **Issue Title & ID:** Add curated examples gallery + runnable templates — **DOCS-EXAMPLES-GALLERY**
- **Current Status:** User asked in Discord; pointed to an examples channel; not formalized in docs site
- **Impact Assessment:**
  - **User Impact:** **Medium** (onboarding friction)
  - **Functional Impact:** **No**
  - **Brand Impact:** **Medium** (perceived maturity)
- **Technical Classification:**
  - **Issue Category:** **Documentation / UX**
  - **Component Affected:** **Docs / Examples**
  - **Complexity:** **Simple fix**
- **Resource Requirements:**
  - **Required Expertise:** Technical writing, minimal maintainer review
  - **Dependencies:** None
  - **Estimated Effort (1–5):** **1**
- **Recommended Priority:** **P3**
- **Specific Actionable Next Steps:**
  1. Create a docs page: “Examples Index” with 5–10 canonical recipes (Discord bot, Telegram, scheduling, paid route, workflow).
  2. Provide copy-paste configs + expected outputs.
  3. Link the Discord examples channel as “community gallery.”
- **Potential Assignees:**
  - **baogerbao** (community/doc coordination)
  - **lalalune** (docs + tooling)
  - **greptile-apps** (review for accuracy)

---

## Highest-Priority Summary (Top 5–10 to address now)
1. **P0:** Agent key security + local secret storage baseline (**DISCORD-2026-04-30-KEYS**)
2. **P0:** Self-host auth/CORS security validation + safe defaults (**INFRA-SELFHOST-AUTH-CORS**)
3. **P1:** AI SDK/provider upgrade regression sweep (**DEPS-AI-SDK-REGRESSION**)
4. **P1:** LifeOps schedule persistence + asset path fixes (**elizaos/eliza#7132**)
5. **P1:** Plugin lifecycle decoupling coordination + canary CI (**elizaos/eliza#7204**)
6. **P1:** Red-team swarm testing harness (**DISCORD-2026-04-30-REDTEAM**)
7. **P1:** Cloud org credit debit correctness + idempotency (**elizaos/cloud#473, #474**)
8. **P2:** Local LLM data storage solution (**DISCORD-2026-04-30-LOCALDATA**)
9. **P2:** v3 social/iMessage integration MVP definition (**V3-SOCIAL-INTEGRATIONS**)
10. **P3:** Examples gallery docs page (**DOCS-EXAMPLES-GALLERY**)

---

## Patterns / Themes Suggesting Deeper Architectural Risks
- **Security maturity lagging behind platform expansion:** Self-host improvements (auth/CORS) and discussions about local keys indicate security needs to become a first-class architectural layer, not a set of ad-hoc patches.
- **Cross-repo change coordination risk:** Plugin-lifecycle decoupling plus frequent dependency upgrades create ecosystem-wide break potential without strong conformance tests and canary CI.
- **Reliability issues cluster around persistence + cross-platform paths:** LifeOps persistence and “asset path” bugs align with ongoing cross-platform build fixes—suggesting a need for a unified storage/path abstraction and OS-matrix testing.

---

## Process Recommendations (to prevent repeats)
1. **Introduce a Security Readiness Checklist** for each release: secret handling, logging redaction, auth/CORS defaults, dependency diff review.
2. **Add cross-repo canary CI** that boots the runtime and loads top plugins against `main` on Linux/Windows/macOS.
3. **Adopt “golden workflow” regression tests** for providers after SDK bumps (streaming + tool calls + retries).
4. **Convert Discord action items into GitHub issues within 24 hours** (with labels: `security`, `self-host`, `v3`, `plugin-system`) to prevent silent scope creep.
5. **Define MVP scopes for v3 claims** (especially “all platforms”) with measurable milestones to protect delivery credibility.