## Issue Triage — 2026-04-27

### 1) **Security/Brand Risk: “feat(virus): add autonomous rust agent (concept art)” — PR #6613**
- **Current Status:** Open PR (unmerged); flagged in automated review as malware-like behavior (persistence + stealth + unrestricted shell exec)
- **Impact Assessment:**
  - **User Impact:** High (if merged, creates a credible path to users running unsafe binaries)
  - **Functional Impact:** Partial (not required for core framework, but impacts distribution/trust)
  - **Brand Impact:** **High** (association with “virus/RAT” behavior is reputationally catastrophic)
- **Technical Classification:**
  - **Issue Category:** Security
  - **Component Affected:** Examples / Native agent packaging (Rust)
  - **Complexity:** Simple fix (policy decision + closure/removal), but requires security review rigor
- **Resource Requirements:**
  - **Required Expertise:** Security engineering, maintainer familiarity with repo policy, release/distribution awareness
  - **Dependencies:** None
  - **Estimated Effort (1-5):** 1–2
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Immediately request changes or close PR with a clear security rationale (persistence, idle stealth, LLM-directed shell).
  2. If any value is desired, move concept to an external repo and replace with a safe “autonomous agent skeleton” that has:
     - no persistence mechanisms,
     - no stealth/idle triggers,
     - no arbitrary shell execution (or requires explicit interactive approval + allowlisted commands).
  3. Add/clarify contribution policy: disallow PRs that implement persistence/stealth/unbounded command execution under official org.
- **Potential Assignees:** `lalalune` (core stability/maintainer), `odilitime` (core dev), plus a security-focused reviewer (e.g., a maintainer who handled prior security reports)

---

### 2) **Release Integration Blocker: “Integrate 29 commits from shaw/checkpoint-20260426-eliza branch” — Issue #7108**
- **Current Status:** Open issue tracking branch integration; risk of drift/release blockage
- **Impact Assessment:**
  - **User Impact:** Medium–High (delays shipping v3 / app readiness; blocks downstream testers)
  - **Functional Impact:** **Yes** (release path + features referenced in dev log remain unlanded)
  - **Brand Impact:** Medium (visible “almost ready” messaging + lag can erode confidence)
- **Technical Classification:**
  - **Issue Category:** Bug / Release Engineering
  - **Component Affected:** Core framework + app-core + automation surfaces (cross-cutting)
  - **Complexity:** Moderate effort (conflict resolution, regression testing, incremental merges)
- **Resource Requirements:**
  - **Required Expertise:** Git/rebase & conflict resolution, CI/release pipeline familiarity, broad code ownership
  - **Dependencies:** CI green on develop; may depend on pending-review PRs landing/being reverted cleanly
  - **Estimated Effort (1-5):** 3–4
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Break the 29 commits into mergeable slices (by subsystem) and land sequentially with CI gates.
  2. For each slice: run targeted suites (agent runtime smoke, app-core build, workflow/automation tests, chat route streaming).
  3. Maintain a short-lived “release candidate” branch to reduce churn while integrating.
  4. Update issue #7108 with a checklist of commit groups + owners + expected test commands.
- **Potential Assignees:** `shawmakesmagic` (branch owner/context), `lalalune` (release stabilization), `2-A-M` (automation/trigger reliability), `Dexploarer` (app-core surfaces)

---

### 3) **User-Facing Link Breakage: “Milady Play Store link from GitHub repo returns ‘item not available’” — ID: DISCORD-2026-04-26-MILADY-LINK (needs GH issue)**
- **Current Status:** Reported in Discord; not yet tracked as a GitHub issue (per provided data)
- **Impact Assessment:**
  - **User Impact:** Medium (blocks new installs for Android users following official link)
  - **Functional Impact:** Partial (distribution/access issue)
  - **Brand Impact:** **High** (broken “official” install link signals low quality/reliability)
- **Technical Classification:**
  - **Issue Category:** UX / Documentation
  - **Component Affected:** Repository docs / release links (likely README / website / app listing references)
  - **Complexity:** Simple fix (update URL / correct listing / conditional messaging)
- **Resource Requirements:**
  - **Required Expertise:** Release/distribution knowledge (Play Store listing), docs maintenance
  - **Dependencies:** If listing is delisted/unavailable, requires product decision + correct public messaging
  - **Estimated Effort (1-5):** 1–2
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Create a GitHub issue in the appropriate repo (likely `elizaos/eliza` or `elizaos/elizaos.github.io`) linking the exact broken URL and screenshot/error text.
  2. Identify source of truth: Play Store package name + current listing state (published/unpublished/region restricted).
  3. Fix: update link(s) and add fallback install instructions (APK/GitHub Releases/TestFlight-equivalent if applicable).
  4. Add a link-check step in docs CI for top distribution links.
- **Potential Assignees:** `Dexploarer` (app-core/app surfaces), `binkyfishai` (UX polish), `lalalune` (maintainer)

---

### 4) **Monetization Infrastructure Pending Review: “Multi-chain agent-to-agent payments integration (7 chains)” — ID: DEVLOG-2026-04-26-A2A-PAYMENTS (PR TBD)**
- **Current Status:** “Awaiting review” per dev log; unclear PR linkage in provided data
- **Impact Assessment:**
  - **User Impact:** Medium (blocks builders relying on A2A commerce rails)
  - **Functional Impact:** Partial (not required for basic agents, but core to monetization roadmap)
  - **Brand Impact:** Medium (payments reliability is trust-sensitive)
- **Technical Classification:**
  - **Issue Category:** Feature / Security (payments require threat modeling)
  - **Component Affected:** Agent commerce/payments layer, plugin system, middleware
  - **Complexity:** Complex solution (multi-chain semantics, replay protection, signing, idempotency)
- **Resource Requirements:**
  - **Required Expertise:** Web3 payments, transaction safety, middleware, test harness design
  - **Dependencies:** x402 route protection/harness (recently landed in PR #7100); auth/consent flows for paid actions
  - **Estimated Effort (1-5):** 4
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Locate/attach the exact PR(s) to a tracking issue; ensure reviewers know the entrypoints and threat model.
  2. Require: replay protection tests, chain failure-mode tests, and “dry-run” mode for devnets.
  3. Add documentation: supported chains, settlement guarantees, and operator config knobs.
- **Potential Assignees:** `odilitime` (payments/x402 direction), `NubsCarson` (monetization plumbing), plus a security reviewer

---

### 5) **Cloud Monetization Pending Review: “Debit organizational credit balances” — elizaos/cloud PRs #473 and #474**
- **Current Status:** Open PRs (pending review) per contributor log
- **Impact Assessment:**
  - **User Impact:** Medium–High (business clients + billing correctness)
  - **Functional Impact:** Partial (core for Cloud commercial usage)
  - **Brand Impact:** High (billing correctness is trust-critical)
- **Technical Classification:**
  - **Issue Category:** Bug / Feature (billing/ledger behavior)
  - **Component Affected:** Cloud billing, org accounting, API
  - **Complexity:** Moderate effort (needs careful review + test coverage)
- **Resource Requirements:**
  - **Required Expertise:** Backend billing/ledger design, database transactions, API invariants
  - **Dependencies:** Auth/consent correctness; accurate model classification/pricing (recently fixed in cloud#470)
  - **Estimated Effort (1-5):** 3
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Enforce invariants: idempotent debits, audit trail, negative balance rules, concurrency safety.
  2. Add/verify tests for: concurrent requests, partial failures, refunds/chargebacks (if applicable), admin overrides.
  3. Run staging simulation with representative org workloads before merge.
- **Potential Assignees:** `NubsCarson` (author), `0xSolace` (cloud auth/db stabilization), `RemilioNubilio` (cloud auth flow context)

---

### 6) **Auth UX/Correctness Pending Review: “Rebuilt auth consent flow” — ID: DEVLOG-2026-04-26-AUTH-CONSENT (PR TBD)**
- **Current Status:** Awaiting review per dev log
- **Impact Assessment:**
  - **User Impact:** High (blocks onboarding/connectors; increases support burden)
  - **Functional Impact:** **Yes** (auth is a gateway dependency for many features)
  - **Brand Impact:** High (broken consent/login flows are immediately visible)
- **Technical Classification:**
  - **Issue Category:** UX / Bug
  - **Component Affected:** Cloud auth, app-core onboarding, connector permissions
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** OAuth/consent flows, frontend onboarding UX, backend session handling
  - **Dependencies:** Steward-based auth architecture (noted in weekly summary); provider switcher behavior (recent fixes like PR #7094)
  - **Estimated Effort (1-5):** 3
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Identify the PR(s) and ensure end-to-end tests cover: login → consent → token storage → disconnect/reconnect.
  2. Validate edge cases: “CLI-auth present but app OAuth not connected” (class of bug fixed in PR #7094).
  3. Add a minimal “auth flow contract test” to CI to prevent regressions.
- **Potential Assignees:** `0xSolace`, `RemilioNubilio`, `2-A-M`

---

### 7) **Release Readiness: “Eliza v3 nearing completion; ship criteria unclear” — ID: RELEASE-V3-READINESS (tracking item)**
- **Current Status:** Announced as “nearly complete” in Discord; no explicit ship checklist in provided data
- **Impact Assessment:**
  - **User Impact:** High (users waiting for v3; reduces churn if delivered)
  - **Functional Impact:** Partial–Yes (depends what v3 includes; likely core app + cloud integration expectations)
  - **Brand Impact:** Medium–High (public timelines/expectations)
- **Technical Classification:**
  - **Issue Category:** Release Engineering / UX
  - **Component Affected:** Core + App + Cloud integration
  - **Complexity:** Moderate effort (coordination + final QA)
- **Resource Requirements:**
  - **Required Expertise:** Release management, CI, packaging (desktop/mobile), smoke testing
  - **Dependencies:** #7108 integration, pending auth/monetization reviews, app packaging link correctness
  - **Estimated Effort (1-5):** 3
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Create a v3 ship checklist: required PRs, blockers, target platforms, rollback plan.
  2. Define “must-pass” suites (app-core build, agent runtime smoke, automation workflow generation, connector onboarding).
  3. Schedule a short release-candidate freeze window while landing #7108 slices.
- **Potential Assignees:** `shawmakesmagic`, `lalalune`, `Dexploarer`, `2-A-M`

---

### 8) **Documentation/Architecture Clarity: “HTN implementation details unclear; risk of concept confusion (HTN vs HTM) + missing docs” — ID: DOCS-HTN-CLARITY**
- **Current Status:** Discord discussion indicates uncertainty about actual HTN implementation in v2; need documentation and verification
- **Impact Assessment:**
  - **User Impact:** Medium (builders can misuse planning features or overestimate capabilities)
  - **Functional Impact:** No (doesn’t block runtime, but blocks correct adoption)
  - **Brand Impact:** Medium (architecture confusion harms credibility with technical users)
- **Technical Classification:**
  - **Issue Category:** Documentation
  - **Component Affected:** Core planning system / agent goal decomposition
  - **Complexity:** Moderate effort (confirm implementation + write docs + examples)
- **Resource Requirements:**
  - **Required Expertise:** Familiarity with planner codepaths, ability to write reference docs/examples
  - **Dependencies:** None, but should align with upcoming v3 messaging
  - **Estimated Effort (1-5):** 2–3
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Audit current code: what is “HTN-lite” today, what triggers/steps exist, where decomposition happens.
  2. Publish a short design note: definitions, current state, roadmap to “full HTN” (LLM planning) with boundaries.
  3. Add a minimal example agent demonstrating the current planning/decomposition API.
- **Potential Assignees:** `odilitime` (framework), `2-A-M` (automation/planning adjacent), `thirti.eth` (context contributor) for review

---

### 9) **Ecosystem/Payments Roadmap: “Enable plugins to accept $elizaOS and $DegenAI as x402 payment methods” — ID: PAYMENTS-X402-TOKENS**
- **Current Status:** Mentioned as “lowest-hanging fruit” in Discord; work referenced as previously started (November)
- **Impact Assessment:**
  - **User Impact:** Medium (builders monetizing agents/plugins)
  - **Functional Impact:** Partial (monetization optional but strategic)
  - **Brand Impact:** Medium (token utility narratives are public-facing)
- **Technical Classification:**
  - **Issue Category:** Feature
  - **Component Affected:** Plugin system, x402 middleware, payment configuration
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** x402 flows, token settlement, config UX, test coverage
  - **Dependencies:** x402 paid routes foundation (PR #7100); multi-chain payments review item
  - **Estimated Effort (1-5):** 3
- **Recommended Priority:** **P3** (promote to P2 if tied to a committed launch date)
- **Specific Actionable Next Steps:**
  1. Define acceptance criteria: supported chains, pricing denomination, conversion rules, refunds, replay protection.
  2. Implement token method(s) behind feature flags; add integration tests using devnets.
  3. Document operator setup and plugin developer guide for paid routes.
- **Potential Assignees:** `odilitime`, `NubsCarson`

---

## Highest-Priority Focus (Top 5–10 to address immediately)
1. **P0:** PR **#6613** “virus” package — close/reject or quarantine; add policy guardrails.
2. **P0:** Issue **#7108** — integrate checkpoint branch (29 commits) via sliced merges + CI gates.
3. **P1:** **Milady Play Store link broken** — create GH issue, fix official install links + add link-checking.
4. **P1:** **Auth consent flow rebuild** (pending review) — ship reliable onboarding/auth with contract tests.
5. **P1:** Cloud monetization PRs **#473/#474** — org credit debiting correctness + auditability.
6. **P1:** **Multi-chain A2A payments integration** (pending review) — review with threat model + replay/chain tests.
7. **P1:** **v3 release readiness** — establish ship checklist, freeze window, and required green test suite.
8. **P2:** **HTN documentation/verification** — remove architecture ambiguity; publish current-state + roadmap docs.

## Patterns / Themes Indicating Deeper Architectural Risk
- **Security boundary ambiguity around “agents that can act”**: multiple surfaces (shell execution, payments, automation triggers) demand explicit safety models, not ad-hoc deny-lists.
- **Release pressure + branch drift**: “checkpoint” integration (#7108) suggests high parallelism without sufficient incremental landing, increasing regression risk near v3.
- **Monetization/auth are becoming core-path**: billing/org credits, consent flows, and payments are now critical infrastructure; they need first-class testing and invariants.
- **UX reliability signals**: broken public install links and auth status confusion (class of issue addressed by PR #7094) show that small UX correctness bugs can severely impact trust.

## Process Improvements (to prevent repeats)
1. **Add a security intake gate for PRs** touching: persistence, shell execution, payment flows, credential storage, connector auth. Require explicit threat model notes.
2. **Mandate “PR-to-issue linkage” for release-critical work** and require ship-checklist items to be traceable (avoid “pending review” without IDs).
3. **Adopt “sliced merge” policy for large branches**: enforce subsystem-scoped PRs with dedicated smoke tests to reduce checkpoint drift.
4. **Introduce contract tests for onboarding/auth/billing**: minimal end-to-end CI tests that catch the most damaging regressions early.
5. **Docs CI link checking for top user journeys**: distribution links (Play Store), install guides, and key product URLs validated on every docs change.