## Issue Triage — 2026-02-18

### 1) [Bug] URL in message triggers duplicate LLM calls (text + attachment) — elizaos/eliza #6486
- **Current Status:** OPEN (reported; no fix linked)
- **Impact Assessment:**
  - **User Impact:** High (any webapp user posting URLs)
  - **Functional Impact:** Partial (chat works but produces duplicated outputs + 2x cost)
  - **Brand Impact:** High (visible “broken” responses + unnecessary spend)
- **Technical Classification:**
  - **Issue Category:** Bug / Performance
  - **Component Affected:** Webapp + Server message ingestion / SSE streaming (URL preview/attachment pipeline)
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** TypeScript runtime/message pipeline; client streaming (SSE) behavior; attachment normalization
  - **Dependencies:** None explicit, but may intersect with attachment provider behavior in plugin-bootstrap / message service
  - **Estimated Effort:** 3/5
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Reproduce with a minimal webapp run and enable logging around message normalization (text vs attachments).
  2. Identify the exact stage where URL preview metadata becomes an “attachment” that triggers an additional LLM call.
  3. Implement a single-source-of-truth rule:
     - either (a) treat URL previews as *context enrichment only* (no second LLM invocation), or
     - (b) collapse text+attachment into one LLM request with deterministic ordering.
  4. Add regression test: “message containing URL results in exactly one model invocation and one streamed response.”
  5. Add metric guardrail: count LLM calls per user message and alert if > 1 in normal flow.
- **Potential Assignees:** **odilitime** (core/runtime), **lalalune** (runtime/message flow), **anchapin** (defensive fixes)

---

### 2) Spartan setup is brittle: `bun install` hangs; missing plugins require manual cloning — (Discord-reported; no issue ID provided)
- **Current Status:** Known problem; partially self-mitigated by a user; “not polished yet” (team acknowledged)
- **Impact Assessment:**
  - **User Impact:** Critical (blocks new developers from installing/running Spartan)
  - **Functional Impact:** Yes (cannot install/run without manual intervention)
  - **Brand Impact:** High (first-run experience failure)
- **Technical Classification:**
  - **Issue Category:** UX / Bug / Documentation
  - **Component Affected:** Plugin System + Monorepo/workspace dependency graph; Spartan installer workflow (bun)
  - **Complexity:** Complex solution (likely requires packaging + workspace design cleanup)
- **Resource Requirements:**
  - **Required Expertise:** Bun workspaces, package publishing/versioning, monorepo dependency hygiene, plugin registry conventions
  - **Dependencies:** “Plugin upgrades” currently blocking Spartan polish work (per Odilitime)
  - **Estimated Effort:** 5/5
- **Recommended Priority:** **P0** (because it blocks installation and ecosystem adoption)
- **Specific Actionable Next Steps:**
  1. Convert the Discord report into a tracked GitHub issue (Spartan repo or elizaos/eliza as appropriate) with exact steps + expected behavior.
  2. Publish a canonical “Spartan minimal set”:
     - required plugins vs optional plugins
     - exact versions (or `latest`) and workspace resolution strategy
  3. Add a preflight script (CI + local) that validates all required plugins resolve without manual git clones.
  4. Provide a “golden path” install command (one-liner) and ensure it is run in CI on clean environments.
  5. If plugins are intentionally not published yet, update installer to pull from git with pinned SHAs (and document it).
- **Potential Assignees:** **odilitime** (plugin upgrades + platform), **lalalune** (architecture/workspaces), **standujar** (DX/automation), **hanzlamateen** (infra maintenance)

---

### 3) Spartan Docker files exist but “currently non-functional” — (Discord-reported; no issue ID provided)
- **Current Status:** Blocked/Incomplete (acknowledged broken)
- **Impact Assessment:**
  - **User Impact:** Medium–High (many users rely on Docker for reproducible setup)
  - **Functional Impact:** Partial (alternative install paths exist but are brittle)
  - **Brand Impact:** Medium (signals unfinished deployment story)
- **Technical Classification:**
  - **Issue Category:** Bug / DevOps / UX
  - **Component Affected:** Deployment/CLI/Docker toolchain for Spartan
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** Docker, bun runtime images, monorepo builds, env/config management
  - **Dependencies:** Resolution of plugin upgrade/publishing story (Issue above) to avoid broken builds
  - **Estimated Effort:** 3/5
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Add CI job that builds Docker image on every PR and runs a minimal “agent starts + healthcheck ok”.
  2. Ensure Docker build does not rely on manual plugin clones (either vendor/pin or pull from registry).
  3. Provide a docker-compose example with required services (db, etc.) clearly marked optional/required.
- **Potential Assignees:** **hanzlamateen** (infra scale changes), **lalalune** (build/deps), **odilitime** (platform integration)

---

### 4) `npx milady` installs the wrong package (Alibaba tool) — milady-ai/milady #324
- **Current Status:** OPEN (issue created; workaround: use GitHub release binaries)
- **Impact Assessment:**
  - **User Impact:** High (anyone following `npx milady` instructions)
  - **Functional Impact:** Yes (users install unrelated tool; cannot run intended project)
  - **Brand Impact:** Critical (trust + safety perception; looks like a supply-chain mix-up)
- **Technical Classification:**
  - **Issue Category:** Bug / Security (distribution integrity) / Documentation
  - **Component Affected:** Packaging & distribution (npm name/entrypoints), release process
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** npm publishing, package naming/ownership, CLI entrypoints, release automation
  - **Dependencies:** npm namespace/package availability; potential rename / scoped package strategy
  - **Estimated Effort:** 3/5
- **Recommended Priority:** **P0** (distribution integrity + brand risk)
- **Specific Actionable Next Steps:**
  1. Confirm intended npm package name(s) and immediately reserve/claim the correct name if possible.
  2. If name is unavailable, publish under a scoped package (e.g., `@milady-ai/milady`) and update all docs to avoid ambiguous `npx milady`.
  3. Add an install guard in docs and CLI output: verify package metadata (author/repo URL) post-install.
  4. Ship a short-term safe command (`npx @scope/milady`) and pin it everywhere.
  5. Add a “Distribution Safety” checklist to releases (npm package verification, dry-run install).
- **Potential Assignees:** **odilitime** (opened/triaged in Discord), **davidhq** (reporter for validation), a maintainer with npm publish rights for milady repo

---

### 5) Feature Request: Support custom OpenAI endpoint URL for OpenAI provider — elizaos/eliza #6490
- **Current Status:** OPEN
- **Impact Assessment:**
  - **User Impact:** Medium (users of OpenAI-compatible providers like SiliconFlow)
  - **Functional Impact:** Partial (blocks a common integration path)
  - **Brand Impact:** Medium (framework seen as less flexible than competitors)
- **Technical Classification:**
  - **Issue Category:** Feature Request
  - **Component Affected:** Model Integration (OpenAI provider config)
  - **Complexity:** Simple fix → Moderate effort (depending on how config is modeled across runtimes)
- **Resource Requirements:**
  - **Required Expertise:** Provider configuration, HTTP client construction, env/config documentation
  - **Dependencies:** Ensure compatibility with auth headers, base path differences, and any streaming quirks
  - **Estimated Effort:** 2/5
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Add config key (env + config file) like `OPENAI_BASE_URL` (or provider-scoped equivalent).
  2. Ensure it propagates through both server and any direct-to-provider paths.
  3. Add documentation + example using a known OpenAI-compatible endpoint.
  4. Add a small integration test that asserts requests target the configured base URL.
- **Potential Assignees:** **lalalune** (core/provider architecture), **odilitime** (core), **anchapin** (safe guards)

---

### 6) Spartan setup documentation missing “required vs optional plugins” + reliable steps — (Discord-reported; no issue ID provided)
- **Current Status:** Not started (explicitly requested)
- **Impact Assessment:**
  - **User Impact:** High (new dev onboarding friction)
  - **Functional Impact:** Partial (workarounds exist but costly)
  - **Brand Impact:** High (DX quality signal)
- **Technical Classification:**
  - **Issue Category:** Documentation / UX
  - **Component Affected:** Plugin System / Spartan onboarding
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** Knowledge of Spartan’s actual dependency requirements; ability to validate steps on clean machines
  - **Dependencies:** Needs alignment with ongoing plugin upgrades and final “minimal set”
  - **Estimated Effort:** 2/5
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Produce a “Spartan Quickstart (30 min)” doc with:
     - prerequisites (bun version, OS notes)
     - required plugins list
     - optional plugins grouped by use case
     - known failure modes + fixes (including the reported hang)
  2. Add a “verified on” CI badge: doc steps must pass in a clean container runner weekly.
- **Potential Assignees:** **standujar** (docs + automation), **odilitime** (accuracy), **Einav Livne** (reporter; can validate if willing)

---

### 7) Security/Trust integration exploration (MoltBridge / Security Oracle): move from API keys to cryptographic identity (request signing) — (Discord discussion; no elizaOS issue ID provided)
- **Current Status:** Concept / integration inquiry (unanswered DM request)
- **Impact Assessment:**
  - **User Impact:** Medium (relevant to agent marketplaces and A2A economy safety)
  - **Functional Impact:** No (not blocking current core runtime)
  - **Brand Impact:** Medium–High (security posture; response to malicious skills bypass incident referenced in community)
- **Technical Classification:**
  - **Issue Category:** Security / Feature Request / Architecture
  - **Component Affected:** Agent Identity, API auth patterns, plugin ecosystem trust signals
  - **Complexity:** Architectural change
- **Resource Requirements:**
  - **Required Expertise:** Applied cryptography (Ed25519), identity standards (e.g., ERC-8004 concepts), secure API design, trust graph modeling
  - **Dependencies:** Needs an endorsed identity/auth standard and integration points in runtime/plugin registry
  - **Estimated Effort:** 4/5
- **Recommended Priority:** **P3** (unless tied to an imminent marketplace launch or active exploit scenario)
- **Specific Actionable Next Steps:**
  1. Create an elizaos/eliza tracking issue: “A2A Identity: request signing + verifiable agent identity interface”.
  2. Define minimal interface: `signRequest(payload)`, `verify(signature, publicKey)`, key rotation, replay protection (nonce/timestamp).
  3. Decide where identity lives: core runtime vs plugin middleware.
  4. Schedule a technical sync with MoltBridge/Security Oracle maintainers to align on message formats and trust signals.
- **Potential Assignees:** **lalalune** (architecture), **odilitime** (core), external collaborators **Dawn / Vlt9** (domain owners)

---

## Highest-Priority Summary (Top 5–10 to address now)
1. **P0:** Spartan install brittleness (bun hang, manual plugin cloning, upgrade blockers) — *blocks adoption*
2. **P0:** `npx milady` installs wrong package — milady-ai/milady **#324** — *distribution integrity / brand risk*
3. **P1:** URL messages trigger duplicate LLM calls — elizaos/eliza **#6486** — *2x cost + broken UX*
4. **P1:** Spartan Docker files non-functional — *deployment reliability gap*
5. **P1:** Spartan Quickstart docs with required vs optional plugins — *reduce repeated support load*
6. **P2:** Custom OpenAI endpoint URL — elizaos/eliza **#6490** — *unblocks OpenAI-compatible providers*
7. **P3:** A2A cryptographic identity + trust graph integration exploration — *strategic security capability*

---

## Patterns / Themes Indicating Deeper Architectural Problems
- **Packaging & distribution fragility across the ecosystem:** Spartan’s plugin dependency resolution and Milady’s `npx` confusion both point to insufficiently standardized release/publishing practices (namespacing, version pinning, “golden path” installers).
- **Message ingestion pipeline lacks “exactly-once” semantics:** The duplicate URL processing suggests the system doesn’t enforce a single normalized representation of a user message before model invocation.
- **Docs and CI not tightly coupled to real onboarding paths:** Repeated setup failures imply the documented workflow (or implied workflow) is not continuously validated in clean environments.

---

## Process Improvements (Prevent Recurrence)
1. **Add “Golden Path” CI:** nightly clean-environment runs for:
   - Spartan install/start
   - Docker build + minimal healthcheck
   - Webapp chat smoke test (including URL message case)
2. **Adopt a Release/Distribution Checklist:** for every CLI/package:
   - verify `npx` installs the intended artifact
   - verify package ownership/metadata
   - pin scope names to avoid collisions
3. **Enforce “One Message → One Model Call” invariants:** add metrics and tests that assert per-user-message invocation counts in common flows (URLs, attachments, previews).
4. **Convert Discord pain points into issues within 24 hours:** create a lightweight template for “Discord-reported blocking setup issue” including logs, OS, bun version, and reproduction steps.