Airgapped plugin

[tgutu]

Purpose

This PR converts Continue into a strictly air-gapped, deterministic local-LLM deployment suitable for constrained or regulated environments.

The focus is not feature expansion, but risk reduction, operational determinism, and explicit architectural trade-offs aligned with the technical assessment.

---

What Changed (High-Level)

1. Enforced Air-Gap

• Removed cloud providers, authentication flows, and external service dependencies
• Ensured no runtime network resolution or fallback behavior
• Local Ollama is the sole inference backend

2. Deterministic Runtime Behavior

• Eliminated runtime model seeding
• Baked models directly into container images
• Avoided writable model volumes to preserve mmap compatibility where possible

3. Memory & Stability Controls

• Documented and constrained mmap behavior on macOS Docker
• Accepted predictable OOM failure over silent degradation
• Prioritized clean process exit and failure containment

4. Operational Transparency

• Classified known console noise (VS Code, npm, Copilot) as non-issues
• Explicitly documented platform limitations instead of masking them
• Added operational and test documentation grounded in observed behavior

---

What This PR Is Not

• Not a production hardening pass
• Not a performance optimization exercise
• Not a feature-parity implementation with hosted Continue

These were consciously rejected to preserve clarity, determinism, and assessment focus.

---

Supporting Documentation

• OPERATIONAL.md — deployment model, trade-offs, rejected approaches
• TEST_REPORT.md — real execution-based test cases and failure analysis

Both documents are written to be reviewable without running the system.

Anticipated Reviewer Questions

Why bake models into the image instead of seeding?

Runtime seeding introduces:

• Non-deterministic startup
• Volume-backed filesystem layers that degrade mmap
• Hidden network and write dependencies

Baking models trades image size for predictability and correctness, which is appropriate for air-gapped constraints.

---

Why not force mmap everywhere?

On macOS Docker, mmap behavior depends on the host filesystem abstraction.
Forcing mmap can degrade stability without guarantees.

This PR documents the limitation and selects safe fallback behavior over undefined behavior.

---

Why are there console warnings?

Warnings originate from:

• VS Code internals
• npm deprecations
• Other extensions (e.g. Copilot)

They are explicitly classified as non-defects and do not affect runtime correctness.

---

Why remove providers instead of feature-flagging them?

Feature flags still allow:

• Accidental activation
• Dead code paths
• Configuration drift

Complete removal provides stronger guarantees and a smaller attack surface.

---

Why are some tests skipped or absent?

Risk in this system is primarily:

• Integration
• Runtime behavior
• Deployment correctness

The test report focuses on observed failures and operational risks, not synthetic unit coverage.

[tgutu]

👋 Reviewer Guide

If you only have a few minutes, here’s the recommended review path:

1️⃣ Start with OPERATIONAL.md

• Explains architecture, deployment model, and explicit trade-offs
• Includes a “Rejected Approaches” appendix to show judgment, not just implementation

2️⃣ Then skim TEST_REPORT.md

• Test cases are derived from real execution, not hypotheticals
• Focuses on failure containment and air-gap integrity

3️⃣ Code Review Guidance

• Changes are intentionally broad because air-gapping is cross-cutting
• Look for absence of cloud paths rather than new abstractions
• Preference is given to deterministic behavior over configurability

ℹ️ Console noise and npm warnings are documented and out-of-scope unless they affect correctness.

Happy to clarify any design decisions — most trade-offs are already documented explicitly.