📌Remaining Issues

Maintainability items deferred to a later phase (CM-3 / CM-5) and the Low group.

Source: REMAINING_ISSUES.md. The CM / Low groups are all maintainability (architecture) items, not bugs or security, positioned to be tackled in a later phase together with the reviewers. The exception is the “required gate for Rhodium productization” below (a porting item).

Required gate for Rhodium productization (porting)

⚠️RDS / Arrowfone 32-bit → 64-bit port (required)

RDS (7.3 MiB) and Arrowfone (7.1 MiB) are armhf (32-bit) binaries with a MariaDB dependency. The target environment is Raspberry Pi OS Bookworm 64-bit (aarch64), so they do not run as-is.

Options: (a) rebuild for 64-bit (requires source) / (b) keep them 32-bit via an armhf compatibility layer (multiarch) / (c) reimplement the functionality.

Not needed for the MVP (landline only, no smartphone app) — bridge / voice-edge have zero dependency on RDS / RTS / Arrowfone (proven by code search, 2026-07-16). This gate becomes mandatory once we move to the Rhodium product form that includes smartphone extensions (Arrowfone).

Ownership: Namzak Labs (Chris) — review and porting scope. Related: goes together with the 8 GB SD-card capacity check (OS + Asterisk 22 + Aegis + RTS + RDS + Arrowfone combined).

Status: not started — a required gate for Rhodium productization. Scale estimate: weeks to a few months (64-bit rebuild plus re-tuning every app; CV’s estimate).

Design refactors (later phase)

🧱

CM-3: the service layer depends on fastapi.HTTPException

Split out into domain exceptions and translate at the API layer. Wide blast radius (~8 routers + MCP strict_fallback + 27 tests).

🧩

CM-5: business logic leaking into adapters/routers

Can be split into extracting the Scorer (CM-5a, medium) and consolidating CallLog state transitions (CM-5b, large).

ℹ️Why not now

These are not production blockers; starting them requires a full-suite regression (about 4 minutes a run) and cross-cutting follow-through, so the plan is to agree on the blast radius first and handle them in a dedicated refactor pass.

The Low group (updated 2026-07-14)

Low-1: inconsistent HTTP 503/502 responses (realtime_session) — ✅ fixed (platform #75; unified as 502 = upstream / 503 = our side)
Low-2: a broad except Exception swallowing errors — deliberately deferred. The wide catches are intentional fail-safe design (shadow recording, ledger writeback, etc.); mechanically switching to explicit types risks breaking call handling, so this stays parked as a design item that needs per-site intent review.
Low-3: the source of the monitoring health/alert-level backend enum — ✅ fixed (platform #76; health/alert/stage values consolidated into one enum module, behavior unchanged)
Low-4: forgetting to set runtime_env skips the weak-JWT-secret check — ✅ fixed (platform #74; a two-stage guard independent of runtime_env)

✅Resolved items are on another page

Critical-1 / H-1–H-5 / CM-1, 2, 4, 6 / PM-1, 2, 4 / n+101 / C-2(b) are all fixed. See “Reviews & Findings” and “PR Timeline” for details.