# Known Issues & Future Work

All fixable issues from the original report have been resolved. The remaining
items require either architectural changes, new features, or deep investigation
of the Go language server binary.

---

## 🔴 Blockers (Require Deep Investigation)

### 1. LS Go LLM Client Ignores System TLS Trust Store

**File:** `docs/mitm-interception-status.md`

The LS binary's Go HTTP client for LLM API calls uses a custom `tls.Config` that
does **not** trust system CAs or honor `SSL_CERT_FILE`. Our MITM proxy can route
traffic but not decrypt it.

**Investigation status:** All practical approaches have been tried and failed:

- iptables REDIRECT → redirect loop + broke all HTTPS traffic
- DNS redirect → same TLS trust failure
- LD_PRELOAD → Go doesn't use libc for syscalls
- SSLKEYLOGFILE → Go doesn't support it

**Remaining options (untried):**

- Binary patching Go TLS verification (fragile, breaks on updates)
- Full standalone LS control (see issue #2)
- eBPF/ptrace syscall interception (complex)
- Network namespace isolation (complex setup)

**Confidence: <30%** — all easy paths exhausted. Requires reverse engineering the Go binary's TLS setup.

**See:** `docs/mitm-interception-status.md` for full analysis

---

### 2. Standalone LS Cascades Silently Fail

**File:** `docs/standalone-ls-todo.md`

Standalone LS (outside Antigravity) accepts `StartCascade` RPCs without error
but cascade never progresses. No output.

**Suspected blockers:**

- Missing auth context (OAuth token propagation)
- Different Unleash feature flags between main and standalone instances
- Missing initialization steps (`LoadCodeAssist`, `OnboardUser`)
- Missing extension server callbacks (`WriteCascadeEdit`, `ExecuteCommand`)

**Confidence: <30%** — too many unknowns. Needs systematic debugging with the standalone LS.

**See:** `docs/standalone-ls-todo.md` for investigation plan

---

## Medium (Architecture / Future Work)

### 3. Cascade Correlation Is Heuristic

**File:** `src/mitm/intercept.rs` — `extract_cascade_hint()`

The MITM proxy matches intercepted API traffic to cascade IDs heuristically:

- HTTP/1.1 path: scans JSON body for `metadata.user_id` or `workspace_id`
- gRPC/H2 path: recursively searches proto fields for UUID strings

If neither method finds a match, usage is stored under `_latest` but never
consumed (since `take_usage()` requires exact cascade ID match).

**Confidence: <50%** — can't test without working MITM interception (blocked by issue #1). The heuristic is reasonable but unverified against real traffic.

---

### 4. Request Modification Not Implemented

**File:** `src/mitm/proxy.rs` — `modify_requests: bool`

The `MitmConfig.modify_requests` flag is plumbed through the entire call chain
but hardcoded to `false`. No modification logic exists. This is intentional
scaffolding for future use.

**Status:** Not a bug — reserved for potential request mutation features.

---

### 5. Polling-Based Cascade Updates vs Streaming RPC

**File:** `src/api/polling.rs`

We poll `GetCascadeTrajectorySteps` on a timer. The LS has a
`StreamCascadeReactiveUpdates` streaming gRPC method that pushes updates
in real-time. Polling works but adds latency.

**Status:** Functional but suboptimal. Switching to streaming requires
implementing a gRPC streaming client with reconnection handling. Not blocking.

---

## 🟢 Low

### 6. No Integration Tests for MITM Module

Unit tests cover protobuf decoding and intercept parsing (17 tests pass), but
no integration tests for:

- TLS interception end-to-end with the generated CA
- Full HTTP/1.1 request/response cycle through the proxy
- gRPC (HTTP/2) request/response cycle through `h2_handler`
- Store recording and retrieval under concurrency

**Status:** The MITM can't intercept real traffic anyway (blocked by issue #1),
so integration tests would be somewhat hypothetical. Worth adding when the TLS
blocker is resolved.