## Issue Triage — 2026-02-27

### 1) Develop branch contained v2.0.0 code (v1.x overwritten / history unclear) — **INCIDENT-VC-2026-02-25**
- **Current Status:** Mitigated workaround in progress (plan executed: create `v2-develop` to preserve v1.x); root cause unknown; branch hygiene still at risk.
- **Impact Assessment:**
  - **User Impact:** **Critical** (anyone tracking `develop` or depending on v1.x snapshots can be broken)
  - **Functional Impact:** **Yes** (breaks expected build/runtime compatibility and upgrade paths)
  - **Brand Impact:** **High** (signals release engineering instability)
- **Technical Classification:**
  - **Issue Category:** Bug / Process (Release Engineering)
  - **Component Affected:** Repo management, CI/CD, Branching strategy
  - **Complexity:** **Architectural change** (branch protections + release workflow hardening)
- **Resource Requirements:**
  - **Required Expertise:** Git/GitHub administration, CI/CD, release management
  - **Dependencies:** Understanding of any automation (bots/sync) that can move code between branches
  - **Estimated Effort:** **5/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. **Freeze `develop`** temporarily (protect branch; require PRs; disallow force-push; require status checks).
  2. **Audit branch movement**: check GitHub audit log, rulesets, bot tokens, deploy keys, and any automation (including Linear sync) with write access.
  3. **Define canonical branches**: `v1/develop`, `v2/develop` (or `release/1.x`, `release/2.x`) and document them in `CONTRIBUTING.md`.
  4. Add CI guardrails: fail CI if v2-only files appear in v1 branch (and vice versa) via a lightweight “branch contract” check.
  5. Publish a short advisory to users: which branch to use for v1 vs v2; expected stability.
- **Potential Assignees:** **Odilitime** (repo coordination), **lalalune** (v2 context), **anchapin** (stability/guardrails)

---

### 2) GitHub ↔ Linear bidirectional sync caused issue tracking “mess” — **INCIDENT-PM-2026-02-25**
- **Current Status:** Open (acknowledged; cleanup needed).
- **Impact Assessment:**
  - **User Impact:** **Medium** (contributors can’t reliably find/track work)
  - **Functional Impact:** **Partial** (doesn’t break runtime, but breaks delivery)
  - **Brand Impact:** **Medium** (public tracker appears disorganized)
- **Technical Classification:**
  - **Issue Category:** UX / Process
  - **Component Affected:** Project management tooling (GitHub Issues, Linear integration)
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Linear/GitHub integration configuration, triage operations
  - **Dependencies:** Decision: one-way sync vs two-way; mapping rules
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Switch to **one-way sync** (Linear → GitHub or GitHub → Linear) or restrict which labels/projects sync.
  2. Define a **single source of truth** for status fields (to prevent flip-flopping).
  3. Run a cleanup pass: dedupe, close mirrors, normalize labels, and re-link PRs/issues.
  4. Add a “Triage SOP” doc: how new issues get labeled + routed.
- **Potential Assignees:** **Stan ⚡** (raised/confirmed sync behavior), **Odilitime** (repo ops)

---

### 3) URL in message triggers duplicate LLM calls (processed as text + attachment) — **elizaos/eliza #6486**
- **Current Status:** **Open** (user reports duplicated responses and doubled cost).
- **Impact Assessment:**
  - **User Impact:** **High** (common behavior: sending URLs)
  - **Functional Impact:** **Partial** (core chat works, but produces incorrect output and higher cost)
  - **Brand Impact:** **High** (visible duplication + cost amplification)
- **Technical Classification:**
  - **Issue Category:** Bug / Performance
  - **Component Affected:** Webapp chat pipeline, SSE streaming, message normalization (text vs attachments)
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Server message handling, webapp message composition, streaming/SSE
  - **Dependencies:** Clarify exact pathway that generates “attachment preview” message; test harness for SSE aggregation
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P0** (cost + correctness regression on a common input)
- **Specific Actionable Next Steps:**
  1. Add instrumentation: log when a single user message spawns >1 LLM request (include correlation IDs).
  2. Ensure URL preview/metadata is **merged into one canonical message** pre-LLM, or mark preview events as non-LLM-triggering.
  3. Add regression test: “message with URL yields exactly one model invocation and one streamed response.”
  4. Patch SSE aggregator to guard against concatenating two “assistant” payloads into one final message.
- **Potential Assignees:** **Odilitime** (core/runtime familiarity), **anchapin** (defensive fixes), **lalalune** (runtime/message flow context)

---

### 4) Twitter input functionality not working (user report; version/product unclear) — **DISCORD-2026-02-26-TWITTER-INPUT**
- **Current Status:** Needs info (Odilitime asked for version/product; no follow-up yet).
- **Impact Assessment:**
  - **User Impact:** **Medium → High** (Twitter is a key integration; scope unknown until repro)
  - **Functional Impact:** **Partial** (blocks Twitter ingestion workflows if widespread)
  - **Brand Impact:** **Medium** (integration reliability perception)
- **Technical Classification:**
  - **Issue Category:** Bug / UX
  - **Component Affected:** Twitter integration (likely plugin-twitter), ingestion/input adapters
  - **Complexity:** **Moderate effort** (pending repro)
- **Resource Requirements:**
  - **Required Expertise:** Twitter API, plugin-twitter, auth/config, rate limiting
  - **Dependencies:** Reporter must provide: elizaOS version, plugin version, deployment type (cloud/local), logs
  - **Estimated Effort:** **2/5** (once repro exists)
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Post a standardized intake checklist in Discord: version, plugin list, config redactions, exact failing command/UI path, logs.
  2. Attempt reproduction on latest plugin-twitter + recent merged fixes (noted recent auth loop/media work in plugin-twitter).
  3. If reproducible, open a GitHub issue in the correct repo (`elizaos-plugins/plugin-twitter`) with logs + steps.
- **Potential Assignees:** **2-A-M** (recent plugin-twitter bugfix work), **Odilitime** (triage + routing)

---

### 5) Code bot behavior in org repos (auto-follows org / unexpected fork behavior) — **DISCORD-2026-02-26-CODEBOT-ORG**
- **Current Status:** Open question; unanswered.
- **Impact Assessment:**
  - **User Impact:** **Medium** (affects teams using org repos + automation)
  - **Functional Impact:** **No** (not core runtime), but can create governance/security concerns
  - **Brand Impact:** **Medium** (unexpected bot actions reduce trust)
- **Technical Classification:**
  - **Issue Category:** Security / UX (governance + permissions)
  - **Component Affected:** Dev tooling / code bot integration, GitHub App permissions
  - **Complexity:** **Complex solution** (depends on bot architecture and GitHub App scopes)
- **Resource Requirements:**
  - **Required Expertise:** GitHub Apps, OAuth scopes, bot implementation details
  - **Dependencies:** Identify which “code bot” (name/app), installation scope, event triggers
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Identify the bot and list its granted scopes; confirm whether it can “follow” accounts or just fork/clone.
  2. Document expected behaviors for org installs (README + security note).
  3. Add an opt-out/least-privilege install guide.
- **Potential Assignees:** **Odilitime** (reported), **greptile-apps** (review/analysis support), repo admins familiar with bot config

---

### 6) Legal/compliance uncertainty around “Hyperscape” (RuneScape-related) and Jagex risk — **DISCORD-2026-02-26-HYPERSCAPE-LEGAL**
- **Current Status:** Open risk; no official response from rights holder.
- **Impact Assessment:**
  - **User Impact:** **Medium** (impacts contributors deciding where to spend time)
  - **Functional Impact:** **No** (not a core framework defect)
  - **Brand Impact:** **High** (legal ambiguity can harm trust and partnerships)
- **Technical Classification:**
  - **Issue Category:** Security / Compliance (Legal)
  - **Component Affected:** Ecosystem governance, community projects
  - **Complexity:** **Complex solution** (requires policy + possibly legal counsel)
- **Resource Requirements:**
  - **Required Expertise:** Open-source licensing, IP/trademark risk, governance
  - **Dependencies:** Project ownership clarity; whether it uses copyrighted assets or trademarks
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1** (brand/compliance risk)
- **Specific Actionable Next Steps:**
  1. Create a short **community policy**: IP/trademark guidelines for plugins/projects promoted under elizaOS channels.
  2. Require Hyperscape to publish: asset provenance, naming/trademark approach, disclaimer, and takedown plan.
  3. If needed, move discussion to a clearly “unaffiliated community project” space to reduce implied endorsement.
- **Potential Assignees:** **Odilitime** (community lead), maintainers with governance experience (add a designated “Compliance/Governance” owner)

---

### 7) OpenAI provider lacks custom endpoint URL (blocks OpenAI-compatible services) — **elizaos/eliza #6490**
- **Current Status:** **Open** (feature request).
- **Impact Assessment:**
  - **User Impact:** **Medium** (blocks a class of providers; not everyone)
  - **Functional Impact:** **Partial** (core works, but reduces integration flexibility)
  - **Brand Impact:** **Medium** (competitiveness vs other frameworks)
- **Technical Classification:**
  - **Issue Category:** Feature Request
  - **Component Affected:** Model Integration (OpenAI provider), configuration system
  - **Complexity:** **Simple fix → Moderate effort** (depending on config plumbing + docs)
- **Resource Requirements:**
  - **Required Expertise:** Provider abstraction, config/env handling, security considerations (SSRF/validation)
  - **Dependencies:** Decide config surface: env var, config file, runtime setting; ensure safe URL validation
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Implement `OPENAI_BASE_URL` (or provider-specific `baseUrl`) with allowlist/validation.
  2. Update docs + examples for third-party OpenAI-compatible endpoints.
  3. Add tests ensuring default remains official endpoint; overrides work.
- **Potential Assignees:** **lalalune** (core/provider architecture), **anchapin** (safe defaults/validation)

---

### 8) Ollama plugin embedding failures on Linux — **elizaos-plugins/plugin-ollama #17**
- **Current Status:** Open (investigation noted in weekly summary).
- **Impact Assessment:**
  - **User Impact:** **High** (Linux is a common deployment target; embeddings are foundational)
  - **Functional Impact:** **Yes** (RAG/memory/search workflows can break)
  - **Brand Impact:** **Medium**
- **Technical Classification:**
  - **Issue Category:** Bug
  - **Component Affected:** Plugin System → `plugin-ollama` embeddings
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Ollama API, embeddings pipeline, Linux env/debugging
  - **Dependencies:** Repro details: distro, Ollama version, model, CPU/GPU, containerization
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Reproduce on Ubuntu LTS + Docker; capture request/response payloads.
  2. Confirm model compatibility and endpoint paths for embeddings vs chat.
  3. Add CI “smoke test” (optional/nightly) for embeddings call against a mocked Ollama server.
- **Potential Assignees:** Plugin maintainers; **Odilitime** (triage), contributors with Linux runtime expertise

---

## Top 5–10 Highest Priority (Immediate Focus)
1. **P0 — INCIDENT-VC-2026-02-25:** `develop` branch contained v2.0.0 code; harden branching/release engineering.
2. **P0 — elizaos/eliza #6486:** URL messages trigger duplicate LLM calls (cost + duplicated output).
3. **P1 — INCIDENT-PM-2026-02-25:** GitHub ↔ Linear bidirectional sync causing tracker chaos; enforce single source of truth.
4. **P1 — elizaos-plugins/plugin-ollama #17:** Embedding failures on Linux (breaks RAG workflows).
5. **P1 — DISCORD-2026-02-26-TWITTER-INPUT:** Twitter input not working (needs structured repro; likely common integration).
6. **P1 — DISCORD-2026-02-26-HYPERSCAPE-LEGAL:** Legal/compliance risk needs policy + positioning.
7. **P2 — elizaos/eliza #6490:** Custom OpenAI endpoint support to unlock OpenAI-compatible providers.
8. **P2 — DISCORD-2026-02-26-CODEBOT-ORG:** Clarify bot/org behavior; document + least privilege.

---

## Patterns / Themes Indicating Deeper Issues
- **Release engineering and repo governance gaps:** Branch contamination + unclear provenance suggests missing protections, auditability, and a formal v1/v2 branching model.
- **Automation/tooling risk surface:** Linear sync issues and “code bot” uncertainty point to insufficiently controlled third-party integrations with write access.
- **Cost amplification bugs in common paths:** The duplicate LLM call issue shows message normalization/streaming contracts aren’t well-guarded by tests.
- **Integration reliability + incomplete bug intake:** Twitter issue stalled due to missing environment details—needs a tighter support-to-issue pipeline.

---

## Process Improvement Recommendations
1. **Branch & Release SOP:** Document branch purposes (v1 vs v2), enforce GitHub rulesets, and add CI “branch contract” checks.
2. **Automation Access Review (quarterly):** Inventory GitHub Apps/bots, reduce scopes, rotate tokens, and require approvals for workflow changes.
3. **Unified Triage Intake Templates (Discord → GitHub):** Provide a mandatory checklist (version, logs, repro steps) and a bot-assisted form that opens a GitHub issue.
4. **Regression Tests for Cost/Streaming:** Add tests that assert **one user message → one model invocation** in key scenarios (URLs, attachments, previews).
5. **Governance/Compliance Guidelines for Community Projects:** A lightweight IP/trademark policy and “not endorsed” labeling to reduce brand/legal exposure.