# Issue Triage — 2026-02-20

## 1) [Bug] URL in message triggers duplicate LLM calls — processed as both text and attachment (webapp) — elizaos/eliza #6486
**Current Status:** OPEN (reported; 1 comment)

### Impact Assessment
- **User Impact:** **High** (any webapp user pasting URLs; common behavior)
- **Functional Impact:** **Partial** (chat still works, but produces duplicated output and extra cost)
- **Brand Impact:** **High** (visible duplication + “wasting tokens” perception)

### Technical Classification
- **Issue Category:** Bug / Performance (cost amplification)
- **Component Affected:** Webapp message ingestion + Server streaming/SSE aggregation (`/api/v1/chat/completions` pipeline likely adjacent)
- **Complexity:** Moderate effort

### Resource Requirements
- **Required Expertise:** TypeScript; client message serialization; server chat pipeline; SSE/stream framing; attachment/url-metadata handling
- **Dependencies:** None, but needs clarity on intended behavior for URL preview/metadata
- **Estimated Effort (1–5):** **3**

### Recommended Priority: **P0**
This directly doubles LLM calls (cost) and creates broken output for a common input pattern.

### Specific Actionable Next Steps
1. Reproduce with instrumentation: log when a single user message becomes multiple “content items” (text + attachment/preview).
2. Identify the decision point: where URL detection turns into an “attachment” while preserving original text.
3. Implement a single-source-of-truth rule:
   - Either (a) keep URL in text and **do not** create a preview attachment for LLM input, or
   - (b) move URL to attachment only and remove from text before LLM invocation.
4. Add regression tests:
   - One message containing URL → exactly **one** model invocation and one streamed response.
5. Add metrics guardrail: detect duplicate model calls for the same message id and warn.

### Potential Assignees
- **borisudovicic** (cloud/chat pipeline context)
- **odilitime** (core/runtime + message flow changes)
- **anchapin** (targeted bugfix PRs; defensive handling)


## 2) [Bug/UX] `npx milady` installs an unrelated Alibaba tool instead of Milady (npm package confusion) — GitHub issue #324 (repo: milady-ai/milady)
**Current Status:** OPEN (created from Discord; project is pre-release; workaround is GitHub release binaries)

### Impact Assessment
- **User Impact:** **High** (anyone trying the “standard install” path)
- **Functional Impact:** **Yes** (prevents intended installation and onboarding)
- **Brand Impact:** **Critical** (supply-chain optics; users may assume compromise)

### Technical Classification
- **Issue Category:** Bug / UX (distribution), Security-adjacent (package name collision/typosquat risk)
- **Component Affected:** CLI distribution (npm), release & install docs
- **Complexity:** Moderate effort (may involve renaming, scoping, npm ownership, docs updates)

### Resource Requirements
- **Required Expertise:** npm publishing, package naming strategy, release engineering
- **Dependencies:** npm package availability/ownership; decision on official package name & scope
- **Estimated Effort (1–5):** **3**

### Recommended Priority: **P0**
This is a front-door installation failure with strong reputational and security implications.

### Specific Actionable Next Steps
1. Decide canonical install command and package name (prefer scoped: `@elizaos/milady` or similar).
2. Publish a protected scoped package and update all docs/readmes to the new command.
3. Add a prominent warning banner in current docs and Discord pinned message until fixed.
4. If feasible, coordinate with npm to address the conflicting/unrelated package (advisory/abuse report if misleading).
5. Add CI to verify `npx <command>` resolves to expected package before releases.

### Potential Assignees
- **odilitime** (raised/confirmed from Discord; release direction)
- **Kenk** (docs + developer guidance)
- **jin** (site/news updates to broadcast correct install path)


## 3) [Bug/DevEx] Spartan setup requires manual cloning of missing plugins; `bun install` hangs; Docker files exist but don’t work — DISCORD-2026-02-17-SPARTAN-SETUP + spartan build/staging PR (2026-02-19)
**Current Status:** Reported in Discord; acknowledged as “not polished”; non-functional Docker; staging/build compatibility PR opened in `elizaos/spartan`

### Impact Assessment
- **User Impact:** **High** (developers attempting Spartan onboarding)
- **Functional Impact:** **Partial → Yes** (blocks clean setup for many; “works if you know how”)
- **Brand Impact:** **High** (first-time contributor experience is poor)

### Technical Classification
- **Issue Category:** Bug / UX / Documentation (onboarding)
- **Component Affected:** Plugin System (dependency resolution), Build tooling (bun), Docker, Spartan repo scaffolding
- **Complexity:** Complex solution (cross-repo coordination + packaging decisions)

### Resource Requirements
- **Required Expertise:** Monorepo tooling, bun, Docker, plugin registry conventions, release packaging
- **Dependencies:** Ongoing plugin upgrades; missing/renamed plugin packages; registry alignment
- **Estimated Effort (1–5):** **5**

### Recommended Priority: **P1**
This is a primary developer adoption blocker, especially ahead of beta/onboarding pushes.

### Specific Actionable Next Steps
1. Publish an authoritative “Spartan Minimal Setup” matrix:
   - Required vs optional plugins; exact repos/branches (`next` vs stable).
2. Make Docker functional or remove it temporarily to avoid false promises:
   - Ensure Docker builds without manual cloning.
3. Add a scripted bootstrap:
   - `bun run spartan:bootstrap` that fetches required plugins automatically (or uses registry).
4. Add CI “fresh machine” install test:
   - Validate `bun install && bun run start` in a clean environment.
5. Align the spartan staging PR (core-compat/service/build fixes) with a tagged milestone and changelog.

### Potential Assignees
- **odilitime** (acknowledged current state; core/build familiarity)
- **lalalune** (next/v2 architecture + multi-language packaging implications)
- **hanzlamateen** (large-scale dependency/build maintenance work)


## 4) [Bug/Platform] Embedding failures on Linux environments — elizaos-plugins/plugin-ollama #17
**Current Status:** OPEN (under investigation per weekly summary)

### Impact Assessment
- **User Impact:** **Medium–High** (Linux is common for self-hosting; embeddings are core for retrieval)
- **Functional Impact:** **Partial** (agents may run, but RAG/memory/search quality breaks)
- **Brand Impact:** **Medium** (self-host reliability perception)

### Technical Classification
- **Issue Category:** Bug / Compatibility
- **Component Affected:** Model Integration (Ollama), Embeddings pipeline
- **Complexity:** Moderate effort (environment-specific; dependency / binary / runtime differences)

### Resource Requirements
- **Required Expertise:** Linux runtime debugging; Ollama API; embeddings formats; Node/Rust/Python interop depending on plugin implementation
- **Dependencies:** Repro details (distro, ollama version, model, CPU/GPU)
- **Estimated Effort (1–5):** **3**

### Recommended Priority: **P1**
Embeddings are foundational for agent usefulness; Linux failures impede the most common hosting environment.

### Specific Actionable Next Steps
1. Collect a minimal reproducible case (exact command/config, ollama version, model name).
2. Add diagnostic logging around request payload and response parsing.
3. Validate platform-specific handling (file paths, HTTP chunking, UTF-8, numeric array parsing).
4. Add a Linux CI job (or containerized integration test) to prevent regressions.

### Potential Assignees
- **odilitime** (model/provider integration familiarity)
- **lalalune** (systems-level debugging across runtimes)
- **community maintainer of plugin-ollama** (if identified; otherwise recruit from contributors)


## 5) [Feature] Support custom OpenAI endpoint URL for OpenAI provider — elizaos/eliza #6490
**Current Status:** OPEN

### Impact Assessment
- **User Impact:** **Medium** (users of OpenAI-compatible providers: SiliconFlow, etc.)
- **Functional Impact:** **Partial** (core works for OpenAI; blocks compatible alternatives)
- **Brand Impact:** **Medium** (integration flexibility expectations)

### Technical Classification
- **Issue Category:** Feature Request
- **Component Affected:** Model Integration (OpenAI provider), Config system
- **Complexity:** Simple fix → Moderate effort (depending on provider abstractions and validation)

### Resource Requirements
- **Required Expertise:** Provider abstraction; config parsing; security validation (SSRF considerations)
- **Dependencies:** Ensure endpoint override doesn’t break auth headers, streaming, or model listing
- **Estimated Effort (1–5):** **2**

### Recommended Priority: **P2**
Valuable for ecosystem compatibility, but not a system failure.

### Specific Actionable Next Steps
1. Add config field (env + config file) like `OPENAI_BASE_URL` / `openai.endpointUrl`.
2. Enforce allowlist/validation guidance to mitigate SSRF risk in hosted contexts.
3. Update docs with examples for common OpenAI-compatible providers.
4. Add a small integration test against a mock OpenAI-compatible server.

### Potential Assignees
- **odilitime** (already active in provider work per monthly contributions)
- **lalalune** (provider/routing architecture)
- **anchapin** (small, safe config change + guards)


## 6) [Security/Brand/Docs] Token migration confusion: ai16z vs elizaos are different contracts; users missed migration deadline; lack of clear support path — DISCORD-2026-02-19-TOKEN-MIGRATION
**Current Status:** Active community confusion; multiple unanswered questions; no clear ticket/support workflow referenced

### Impact Assessment
- **User Impact:** **High** (many token holders; repeated questions)
- **Functional Impact:** **No** (not core framework runtime), but impacts ecosystem participation
- **Brand Impact:** **Critical** (trust, legitimacy, and professionalism concerns)

### Technical Classification
- **Issue Category:** Documentation / UX (support), Risk Management
- **Component Affected:** Community ops, official docs/site, announcements, support workflow
- **Complexity:** Moderate effort (process + documentation + possible tooling)

### Resource Requirements
- **Required Expertise:** Community operations, documentation, basic web/content updates; optionally lightweight support tooling
- **Dependencies:** Final authoritative decisions from Ops on migration policy (late migration?) and official contract references
- **Estimated Effort (1–5):** **3**

### Recommended Priority: **P1**
Even if not “code,” this is a trust-and-clarity emergency that repeatedly drains community bandwidth.

### Specific Actionable Next Steps
1. Publish a single canonical “Token FAQ” pinned everywhere (Discord, website, GitHub discussions):
   - Are tokens the same? (No)
   - Official contract addresses
   - Migration status and whether late migration is possible
   - Rationale for contract design choices (in plain language)
2. Create an official support intake path (even minimal):
   - A public GitHub Discussion category or a simple form + triage SOP
3. Add an automated Discord bot response for common token keywords (ai16z, migration, contract).
4. Ensure moderators have a copy-paste macro with the canonical answers and links.

### Potential Assignees
- **ElizaBAO** (community announcements/verification comms)
- **MDMnvest** (already directing users; can help consolidate canonical links)
- **Kenk** (documentation + developer-facing guidance)
- **Odilitime** (technical clarifications; alignment with Ops)


## 7) [Security/Brand] “Why is the token mintable?” remains unanswered — DISCORD-2026-02-19-TOKEN-MINTABILITY
**Current Status:** Unanswered in Discord summary; recurring concern

### Impact Assessment
- **User Impact:** **Medium–High** (enough to repeatedly ask; affects investor/user trust)
- **Functional Impact:** **No**
- **Brand Impact:** **High** (mintability perceived as rug risk without explanation)

### Technical Classification
- **Issue Category:** Security (perception + governance) / Documentation
- **Component Affected:** Token contract governance documentation; transparency reporting
- **Complexity:** Simple fix (if just explanation) → Moderate (if contract changes required)

### Resource Requirements
- **Required Expertise:** Smart contract literacy; ability to explain mint authority, multisig, timelocks; comms
- **Dependencies:** Confirm actual on-chain mint authority state; confirm governance controls
- **Estimated Effort (1–5):** **2**

### Recommended Priority: **P1**
High-trust impact; resolution may simply be transparent explanation + proof.

### Specific Actionable Next Steps
1. Verify mint authority status on-chain and document it with links/screenshots and how to verify independently.
2. If mint authority exists, explain:
   - Who controls it, via what multisig
   - Under what conditions it could be used
   - Any planned renouncement/timelock
3. Publish a short “Token Security Posture” page and pin it.

### Potential Assignees
- **Ops team** (mint authority facts)
- **Odilitime** (technical explanation coordination)
- **ElizaBAO** (public comms)


## 8) [Docs] Contract address information not easily accessible; repeated user requests — DISCORD-2026-02-19-CONTRACT-ADDR-DOCS
**Current Status:** Reported as an action item; users redirected manually

### Impact Assessment
- **User Impact:** **High** (repeated questions)
- **Functional Impact:** **No**
- **Brand Impact:** **Medium–High** (looks disorganized; scam risk if users search elsewhere)

### Technical Classification
- **Issue Category:** Documentation / UX
- **Component Affected:** Discord channel pins, website/docs, “official links” page
- **Complexity:** Simple fix

### Resource Requirements
- **Required Expertise:** Docs/content editing; Discord moderation
- **Dependencies:** None (assuming contracts are already finalized)
- **Estimated Effort (1–5):** **1**

### Recommended Priority: **P2**
Fast win; reduces scam surface area.

### Specific Actionable Next Steps
1. Add a single pinned “Official Contracts & Links” message in the relevant Discord channels.
2. Mirror the same info on an official website page with a stable URL.
3. Add “how to verify” instructions (chain explorer steps).

### Potential Assignees
- **MDMnvest** (already doing routing)
- **Kenk** (docs)
- **jin** (site/news publishing support)


---

# Conclusion

## A) Top highest-priority issues to address immediately (next 5–10)
1. **P0 — elizaos/eliza #6486:** URL messages trigger duplicate LLM calls (cost + broken output).
2. **P0 — milady-ai/milady #324:** `npx milady` installs the wrong package (distribution/security optics).
3. **P1 — Spartan setup & Docker broken (Discord + spartan build PR):** developer onboarding blocker.
4. **P1 — plugin-ollama #17:** embeddings failing on Linux (core capability degraded for self-hosters).
5. **P1 — Token migration confusion (Discord):** single-source-of-truth FAQ + support intake path.
6. **P1 — Token mintability question (Discord):** publish verifiable explanation/proof.
7. **P2 — Custom OpenAI endpoint (elizaos/eliza #6490):** compatibility improvement for OpenAI-like providers.
8. **P2 — Contract address discoverability (Discord):** pinned canonical links + website mirror.

## B) Patterns/themes suggesting deeper architectural problems
- **Input normalization is leaky across modalities (text vs attachment):** The URL duplication bug indicates insufficient deduplication and unclear rules for multi-part message construction before model invocation.
- **Onboarding friction from plugin sprawl and version drift:** Spartan requiring manual cloning + non-functional Docker points to missing “golden path” packaging and CI validation of fresh installs.
- **Platform compatibility gaps (Linux embeddings):** Suggests integration tests are not covering the most common self-host environment for model plugins.
- **Support/documentation debt translating into trust risk:** Token-related confusion shows the project lacks a robust “single canonical answer” system and a formal user-support intake pipeline.

## C) Recommendations for process improvements
1. **Add “fresh install” CI gates** for key repos (Spartan, core templates): clean machine/container install must pass before merges.
2. **Introduce a message-ingestion contract** (schema + invariants): enforce “one user message → one model invocation” unless explicitly multi-call, with metric assertions.
3. **Expand integration test matrix** to include Linux for model/embedding plugins (container-based is sufficient).
4. **Create a lightweight public support workflow**:
   - GitHub Discussions category + triage labels + moderator macros
   - One pinned “Official Links / Contracts / Migration FAQ” maintained like release notes
5. **Release/distribution hardening**:
   - Pre-release checklist includes verifying `npx`/install commands resolve correctly
   - Publish only scoped packages for critical CLIs to reduce namespace collision risk