# Issue Triage — 2026-03-28

## 1) Platform data consolidation: collapse prod + dev into single “staging” Spartan (all customer data)
- **Issue Title & ID:** Collapse production and development into single staging Spartan instance (ID: *TBD — create tracking issue*)
- **Current Status:** Planned/announced in Discord; no public tracking issue referenced.
- **Impact Assessment:**
  - **User Impact:** **Critical** (all hosted customers potentially affected)
  - **Functional Impact:** **Yes** (risk of downtime, data unavailability, auth/session issues)
  - **Brand Impact:** **High** (data handling + reliability perception)
- **Technical Classification:**
  - **Category:** Reliability / Security (operational risk)
  - **Component Affected:** Platform Ops / Hosting (elizacloud / Spartan)
  - **Complexity:** **Architectural change**
- **Resource Requirements:**
  - **Required Expertise:** SRE/DevOps, DB migration, backup/restore, security controls, observability
  - **Dependencies:** Clear migration plan, rollback strategy, maintenance window comms, data retention policy
  - **Estimated Effort:** **5/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Create a tracking issue with acceptance criteria: *zero data loss*, *measured downtime budget*, *validated backups*, *auditable access controls*.
  2. Define migration approach (blue/green or snapshot-restore), and prove rollback in a dry-run.
  3. Implement safeguards: encrypted backups, least-privilege IAM, production-grade monitoring/alerts (latency, error rate, DB health).
  4. Publish customer-facing maintenance notice + post-migration validation checklist (auth, billing, agent execution, logs).
- **Potential Assignees:** **Odilitime** (platform/core), **Spartan Dev/Core Dev WG** (as listed roles)

---

## 2) Plugin registry PR review/merge: xProof on-chain decision provenance
- **Issue Title & ID:** Review & merge xProof plugin registry entry (**elizaos-plugins/registry PR #266**)
- **Current Status:** PR submitted; awaiting review/merge.
- **Impact Assessment:**
  - **User Impact:** **Medium** (users wanting provenance/audit trails)
  - **Functional Impact:** **Partial** (not core runtime, but enables trust/compliance workflows)
  - **Brand Impact:** **Medium** (signals ecosystem velocity + quality gatekeeping)
- **Technical Classification:**
  - **Category:** Feature / Plugin Ecosystem
  - **Component Affected:** Plugin System / Registry
  - **Complexity:** **Moderate effort** (review + validation)
- **Resource Requirements:**
  - **Required Expertise:** Plugin registry maintainership, basic security review (supply chain), docs validation
  - **Dependencies:** CI checks; package verification; minimal policy checklist (license, security notes)
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Validate npm packages `@elizaos/plugin-xproof` and `@xproof/xproof` (publisher, integrity, versions).
  2. Run registry automated checks + manual smoke test (install, basic call path).
  3. Require a short SECURITY.md note: what data is anchored, how keys/tokens handled, rate limits.
  4. Merge PR and announce in Discord with a minimal usage snippet.
- **Potential Assignees:** **Odilitime** (GitHub contributor/core), **jasonxkensei** (plugin author for fixes)

---

## 3) Third-party plugin submission + distribution process unclear (contributors blocked/uncertain)
- **Issue Title & ID:** Clarify plugin submission, review timeline, and distribution support (ID: *TBD — docs issue*)
- **Current Status:** Repeated questions in Discord (trading flow plugin author asked about inclusion/timeline/support).
- **Impact Assessment:**
  - **User Impact:** **High** (all plugin developers + ecosystem growth)
  - **Functional Impact:** **Partial** (slows integrations; increases support load)
  - **Brand Impact:** **High** (perceived “closed” or inconsistent governance)
- **Technical Classification:**
  - **Category:** Documentation / UX (developer experience)
  - **Component Affected:** Plugin System / Registry / Docs site
  - **Complexity:** **Simple fix** (docs + templates), possibly **Moderate** if policy tooling added
- **Resource Requirements:**
  - **Required Expertise:** Maintainers familiar with registry workflow, technical writing
  - **Dependencies:** Agreement on acceptance criteria (security, naming, versioning, maintenance expectations)
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Add a “How to get listed” doc: checklist, expected SLA, examples of a good registry PR.
  2. Define distribution support options (featured listing, announcement process, minimum quality bar).
  3. Add PR template to registry: security notes, permissions, external API usage, maintainer contact.
  4. Pin the doc in Discord + link in registry README.
- **Potential Assignees:** **Odilitime** (process owner), **satsbased** (community + clarity), **trace.g** (technical writing + workflows)

---

## 4) Trading flow plugin intake: missing registry PR / unclear requirements
- **Issue Title & ID:** Trading flow plugin for plug-and-play trading integration (ID: *TBD — awaiting registry PR/plugin name*)
- **Current Status:** Developer inquiry in Discord; maintainer requested registry PR or plugin name.
- **Impact Assessment:**
  - **User Impact:** **Medium** (builders working on trading agents; recurring interest)
  - **Functional Impact:** **Partial** (enables a common agent use case)
  - **Brand Impact:** **Medium** (ecosystem responsiveness)
- **Technical Classification:**
  - **Category:** Feature Request / Integration
  - **Component Affected:** Plugin System (trading/exchange integration)
  - **Complexity:** **Moderate effort** (review + security posture)
- **Resource Requirements:**
  - **Required Expertise:** Plugin review, security (secrets handling, signing), rate limits, error handling
  - **Dependencies:** Registry PR submission; clear scope; sandbox/backtesting support expectations
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P2** (upgrade to P1 if plugin is broadly useful + well-scoped)
- **Specific Actionable Next Steps:**
  1. Ask author to submit registry PR with: supported venues, auth method, permissions model, and demo.
  2. Require safety defaults: paper trading mode, explicit confirmation gates, and audit logging.
  3. Provide a minimal “trading plugin guidelines” section (risk disclosure, key storage, idempotency).
- **Potential Assignees:** **meowww404** (author), **Odilitime** (review), **trace.g** (workflow/design review)

---

## 5) Community-facing project relationship confusion: Hyperscape vs Eliza Labs (governance/branding)
- **Issue Title & ID:** Document Hyperscape relationship to ElizaOS/Eliza Labs (ID: *TBD — governance/FAQ doc*)
- **Current Status:** Heated Discord debate; moderators clarified verbally.
- **Impact Assessment:**
  - **User Impact:** **Medium** (community + partners + prospective users)
  - **Functional Impact:** **No**
  - **Brand Impact:** **High** (trust, expectations, perceived official roadmap)
- **Technical Classification:**
  - **Category:** Documentation / UX (communications)
  - **Component Affected:** Project Governance / Website/Docs / Discord FAQs
  - **Complexity:** **Simple fix**
- **Resource Requirements:**
  - **Required Expertise:** Project leads/moderation, comms, documentation
  - **Dependencies:** Confirm official wording approved by leads
  - **Estimated Effort:** **1/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Add an official FAQ entry: “What is Hyperscape?” + “Is it an official Eliza Labs product?”
  2. Publish a short “Ecosystem project taxonomy” (official, incubated, community) with examples.
  3. Pin the message in Discord and link from README/docs.
- **Potential Assignees:** **Odilitime** (moderator/labs), **satsbased** (community mod), **Community Ops**

---

## 6) Partnership inquiry intake is dropping (missed leads/support gaps)
- **Issue Title & ID:** Partnership contact path unclear; inquiries unanswered (ID: *TBD — community ops/process*)
- **Current Status:** At least one explicit partnership inquiry in Discord went unanswered.
- **Impact Assessment:**
  - **User Impact:** **Medium** (partners/sponsors/builders)
  - **Functional Impact:** **No**
  - **Brand Impact:** **Medium** (professionalism + responsiveness)
- **Technical Classification:**
  - **Category:** UX / Process
  - **Component Affected:** Community Ops / Partner Portal
  - **Complexity:** **Simple fix**
- **Resource Requirements:**
  - **Required Expertise:** Community ops, partner management
  - **Dependencies:** Decide official intake channel + routing
  - **Estimated Effort:** **1/5**
- **Recommended Priority:** **P3**
- **Specific Actionable Next Steps:**
  1. Create a pinned “Partnerships” post with a form/email + expected response time.
  2. Add Discord automation (keyword trigger) to route to Partner Portal/Community Ops.
  3. Weekly review of unanswered questions in #discussion.
- **Potential Assignees:** **Community Ops**, **Odilitime** (routing), **Partner portal** owner(s)

---

## 7) Token migration support ambiguity (AI16Z → Jeju): waitlist but no guarantees
- **Issue Title & ID:** Define policy + tooling for missed token migration window support (ID: *TBD — policy/support doc*)
- **Current Status:** Users told to DM for waitlist; outcome uncertain.
- **Impact Assessment:**
  - **User Impact:** **Medium** (subset of token holders)
  - **Functional Impact:** **No** (not core framework)
  - **Brand Impact:** **Medium** (trust and perceived fairness)
- **Technical Classification:**
  - **Category:** Documentation / Support Process
  - **Component Affected:** Community Ops / Token Ops
  - **Complexity:** **Moderate effort** (policy + potential tooling)
- **Resource Requirements:**
  - **Required Expertise:** Token ops, legal/compliance awareness, support workflow
  - **Dependencies:** Confirm what is possible on-chain and what is not; define cutoffs
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P3**
- **Specific Actionable Next Steps:**
  1. Publish an explicit policy: eligibility, proof requirements, and finality constraints.
  2. Provide a self-serve checker: “Was my wallet migrated?” + instructions.
  3. Replace ad-hoc DMs with a ticketing/intake form.
- **Potential Assignees:** **Odilitime** (migration support role), **Migration Support** helpers

---

## 8) Known technical bug (from recent repo activity): Ollama embeddings failing on Linux
- **Issue Title & ID:** Embedding failures on Linux (**elizaos-plugins/plugin-ollama Issue #17**)
- **Current Status:** Reported; investigation started previously; no resolution noted in provided data.
- **Impact Assessment:**
  - **User Impact:** **High** (Linux is common for self-hosting)
  - **Functional Impact:** **Yes** (embeddings often gate RAG/memory/search features)
  - **Brand Impact:** **Medium** (cross-platform reliability)
- **Technical Classification:**
  - **Category:** Bug
  - **Component Affected:** Model Integration / plugin-ollama
  - **Complexity:** **Moderate effort** (env + binary/ABI + dependency matrix)
- **Resource Requirements:**
  - **Required Expertise:** Node.js native deps, Linux environment debugging, Ollama API behavior, CI matrix
  - **Dependencies:** Repro steps + environment details; add CI coverage for Linux
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Reproduce in a minimal Linux container (publish Dockerfile in issue).
  2. Identify whether failure is model availability, endpoint mismatch, or vector format/encoding.
  3. Add Linux CI job to run a real embedding smoke test (or mocked contract test if needed).
  4. Document known-good Ollama versions + required flags.
- **Potential Assignees:** plugin-ollama maintainers (repo owners), **Core Dev / GitHub Contributors** (e.g., **odilitime**, **baogerbao**)

---

# Immediate Focus Summary (Top Priority: next 1–2 weeks)

1. **P0:** Collapse prod+dev into single staging Spartan — **create tracking issue + migration/rollback plan**.
2. **P1:** Fix **plugin-ollama Issue #17** (Linux embeddings) — blocks common self-host + RAG workflows.
3. **P1:** Review/merge **registry PR #266** (xProof) — unblock ecosystem shipping + set quality bar.
4. **P1:** Publish **plugin submission + distribution** documentation and PR templates — reduce contributor friction.
5. **P2:** Governance/branding FAQ for **Hyperscape relationship** — reduce community conflict and confusion.
6. **P2/P3:** Trading flow plugin intake — request registry PR + apply security/safety guidelines.
7. **P3:** Partnership inquiry routing — prevent missed inbound.
8. **P3:** Token migration support policy — reduce repeated DMs and uncertainty.

---

# Patterns / Themes Suggesting Deeper Issues

- **Process visibility gaps:** Repeated questions about plugin acceptance timelines and distribution support indicate missing or hard-to-find contributor docs and unclear SLAs.
- **Operational risk concentration:** Consolidating environments and “single instance with all customer data” increases blast radius without explicit mention of isolation, backups, or rollback—suggesting a need for stronger release/migration governance.
- **Ecosystem governance ambiguity:** Confusion about what is “official” vs “incubated” projects (Hyperscape) points to missing public taxonomy and consistent messaging.

---

# Recommendations (Process Improvements)

1. **Create a public “Intake & SLA” framework**
   - Plugin registry: checklist + review SLA targets (even “best effort” with ranges).
   - Partnerships: official contact route + response-time expectations.

2. **Require operational change management for high-risk platform work**
   - Mandatory tracking issue, runbook, rollback plan, and post-mortem template for any migration affecting customer data.

3. **Add lightweight quality/security gates for plugins**
   - Standardized metadata: permissions, secrets handling, external calls, rate limits, maintenance contact.
   - Minimum CI contract test for plugins that touch core workflows (embeddings, auth, storage).

4. **Publish an “Official vs Incubated vs Community” ecosystem page**
   - Reduce recurring debates, align expectations, and protect brand trust.