Compare commits
8 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
 Praxis CI
|
615721a8eb | ||
|
Praxis CI
|
2999c5163c | ||
|
Praxis CI
|
0df1ec391a | ||
|
Praxis CI
|
658bbc3000 | ||
|
Praxis CI
|
9d54fbe365 | ||
|
Praxis CI
|
70994e18ad | ||
|
Praxis CI
|
7fe52f34bc | ||
|
Praxis CI
|
fbd6602814 |
+234
-1
@@ -111,4 +111,237 @@ Pipecat server (Python)
|
||||
- Pipecat Flows schema mapping for the one branch point (escalate vs accept) in the refund scenario
|
||||
- Guardrail ruleset concrete implementation (D-019) — system-prompt template + output filter
|
||||
- SQLite schema for session log + progress + scenario state
|
||||
- OLLAMA_API_KEY + DEEPGRAM_API_KEY + CARTESIA_API_KEY secret management (extend `config.secrets.scopes`)
|
||||
- OLLAMA_API_KEY + DEEPGRAM_API_KEY + CARTESIA_API_KEY secret management (extend `config.secrets.scopes`)
|
||||
|
||||
---
|
||||
|
||||
## v0.2 Deployment Architecture (Proxmox LXC + Docker-in-LXC)
|
||||
|
||||
> **Status:** Research-refined (v0.2 RESEARCH stage). Informed by `.ciagent/RESEARCH.md` — Proxmox VE wiki, coreci script analysis, Docker/systemd ecosystem.
|
||||
> **Decisions:** D-021 (LXC deploy), D-022 (Docker in LXC, nesting=1), D-023 (FastAPI StaticFiles), D-024 (infra-only keys), D-025/D-029 (build inside CT), D-026 (coreci secrets), D-027 (auto VMID), D-028 (Docker via apt), D-030 (vmbr0 DHCP).
|
||||
|
||||
### Docker-in-LXC Topology
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────┐
|
||||
│ Proxmox VE Host (PROXMOX_NODE) │
|
||||
│ (D-026: secrets sourced from ~/coreci/.ciagent/ │
|
||||
│ .env.secrets + praxis .ciagent/.env.secrets) │
|
||||
│ │
|
||||
│ Deploy operator runs: │
|
||||
│ scripts/proxmox/lxc-deploy.sh │
|
||||
│ ├─ stage-snippet.sh (upload hookscript to snippets) │
|
||||
│ ├─ lxc-clone.sh (POST /nodes/{node}/lxc) │
|
||||
│ ├─ lxc-config.sh (PUT /config + SSH lxc.env) │
|
||||
│ ├─ lxc-start.sh (POST /status/start) │
|
||||
│ └─ health-check.sh (poll /health:8789) │
|
||||
│ │
|
||||
│ ┌────────────────────────────────────────────────────┐ │
|
||||
│ │ LXC Container (VMID: auto via pve_nextid, D-027) │ │
|
||||
│ │ hostname: praxis │ │
|
||||
│ │ memory: 4096MB rootfs: 16GB (bumped from 2/8) │ │
|
||||
│ │ features: nesting=1 │ │
|
||||
│ │ net0: bridge=vmbr0, ip=dhcp (D-030) │ │
|
||||
│ │ hookscript: local:snippets/praxis-firstboot.sh │ │
|
||||
│ │ lxc.environment: GITEA_TOKEN, DEEPGRAM_API_KEY, │ │
|
||||
│ │ PRAXIS_PORT=8789, PRAXIS_HOST=0.0.0.0, ... │ │
|
||||
│ │ │ │
|
||||
│ │ post-start hook (runs on PVE host, pct exec → CT): │ │
|
||||
│ │ 1. apt install docker.io docker-compose-v2 git │ │
|
||||
│ │ 2. git clone praxis repo → /opt/praxis │ │
|
||||
│ │ 3. install-service.sh (user + env + systemd unit) │ │
|
||||
│ │ 4. systemctl start praxis │ │
|
||||
│ │ → ExecStartPre: docker compose build │ │
|
||||
│ │ → ExecStart: docker compose up (foreground) │ │
|
||||
│ │ │ │
|
||||
│ │ ┌──────────────────────────────────────────────┐ │ │
|
||||
│ │ │ Docker daemon │ │ │
|
||||
│ │ │ ┌────────────────────────────────────────┐ │ │ │
|
||||
│ │ │ │ praxis container │ │ │ │
|
||||
│ │ │ │ image: python:3.12-slim + deps + dist │ │ │ │
|
||||
│ │ │ │ ports: 8789:8789 │ │ │ │
|
||||
│ │ │ │ env_file: /etc/praxis/server.env │ │ │ │
|
||||
│ │ │ │ volume: praxis-db → /app/data │ │ │ │
|
||||
│ │ │ │ restart: unless-stopped │ │ │ │
|
||||
│ │ │ │ │ │ │ │
|
||||
│ │ │ │ uvicorn 0.0.0.0:8789 │ │ │ │
|
||||
│ │ │ │ ├─ GET /health (FastAPI) │ │ │ │
|
||||
│ │ │ │ ├─ POST /pipecat/webrtc (FastAPI) │ │ │ │
|
||||
│ │ │ │ └─ GET / ... (StaticFiles client/dist)│ │ │ │
|
||||
│ │ │ └────────────────────────────────────────┘ │ │ │
|
||||
│ │ └──────────────────────────────────────────────┘ │ │
|
||||
│ └────────────────────────────────────────────────────┘ │
|
||||
│ │ │
|
||||
│ vmbr0 (bridge) ──── DHCP ──── CT eth0 │
|
||||
└───────────┬──────────────────────────────────────────────┘
|
||||
│ <ct-bridge-ip>:8789
|
||||
┌───────────▼───────────────────────┐
|
||||
│ Operator / Learner (browser) │
|
||||
│ http://<ct-ip>:8789 │
|
||||
│ (direct access, no proxy/TLS) │
|
||||
└───────────────────────────────────┘
|
||||
```
|
||||
|
||||
### Image Build Pipeline (Multi-stage Dockerfile)
|
||||
|
||||
Two-stage build, Debian-slim bases, `python -m server` entrypoint:
|
||||
|
||||
```
|
||||
Stage 1: client-builder (node:22-slim)
|
||||
COPY client/package.json client/package-lock.json
|
||||
RUN npm ci ← cached unless deps change
|
||||
COPY client/
|
||||
RUN npm run build ← tsc -b && vite build → client/dist/
|
||||
|
||||
Stage 2: server (python:3.12-slim)
|
||||
RUN apt-get install gcc g++ libasound2-dev ← only if source compilation
|
||||
COPY pyproject.toml
|
||||
RUN pip install --no-cache-dir . ← pipecat-ai[deepgram,cartesia,piper,webrtc] + deps
|
||||
COPY server/ scenarios/ db/
|
||||
COPY --from=client-builder /app/client/dist ./client/dist
|
||||
EXPOSE 8789
|
||||
CMD ["python", "-m", "server"] ← calls uvicorn.run(app, host=HOST, port=PORT)
|
||||
```
|
||||
|
||||
**Why Debian-slim (not Alpine):** numpy + pipecat-ai native extensions compile against glibc; musl wheels are less universally available. The ~50MB size saving of Alpine isn't worth the compatibility risk.
|
||||
|
||||
**Why `python -m server` (not `uvicorn server.__main__:app`):** Matches the existing entrypoint (`server/__main__.py:main()`) which reads `PRAXIS_HOST`/`PRAXIS_PORT` from env and calls `uvicorn.run(...)`. Single uvicorn process is correct for WebRTC/WebSocket (long-lived connections, not request-per-response).
|
||||
|
||||
### Secret Injection Chain
|
||||
|
||||
```
|
||||
~/coreci/.ciagent/.env.secrets praxis/.ciagent/.env.secrets
|
||||
PROXMOX_API_URL GITEA_TOKEN
|
||||
PROXMOX_API_TOKEN DEEPGRAM_API_KEY
|
||||
PROXMOX_NODE CARTESIA_API_KEY (empty, D-024)
|
||||
PROXMOX_STORAGE OLLAMA_API_KEY (empty, D-024)
|
||||
PROXMOX_TEMPLATE_VOLID
|
||||
PROXMOX_TLS_SKIP_VERIFY
|
||||
│ │
|
||||
└────────┬───────────┘
|
||||
▼
|
||||
lxc-deploy.sh sources both
|
||||
│
|
||||
▼
|
||||
lxc-config.sh (SSH to PVE host)
|
||||
writes /etc/pve/lxc/<vmid>.conf:
|
||||
lxc.environment: GITEA_TOKEN=<token>
|
||||
lxc.environment: DEEPGRAM_API_KEY=<key>
|
||||
lxc.environment: PRAXIS_PORT=8789
|
||||
lxc.environment: PRAXIS_HOST=0.0.0.0
|
||||
lxc.environment: OLLAMA_BASE_URL=https://ollama.com/v1
|
||||
...
|
||||
│
|
||||
▼ (CT boots; systemd PID 1 has these env vars)
|
||||
firstboot-hook.sh → pct exec install-service.sh
|
||||
│
|
||||
▼
|
||||
/etc/praxis/server.env (root:praxis, chmod 0640)
|
||||
GITEA_TOKEN=<token>
|
||||
DEEPGRAM_API_KEY=<key>
|
||||
PRAXIS_PORT=8789
|
||||
...
|
||||
│
|
||||
▼
|
||||
praxis.service (EnvironmentFile=/etc/praxis/server.env)
|
||||
→ ExecStart: docker compose up
|
||||
│
|
||||
▼
|
||||
docker-compose.yml (env_file: /etc/praxis/server.env)
|
||||
│
|
||||
▼
|
||||
Docker container (os.environ)
|
||||
→ server/__main__.py reads PRAXIS_HOST, PRAXIS_PORT, DEEPGRAM_API_KEY, ...
|
||||
```
|
||||
|
||||
**.gitignore coverage:** `.env`, `.env.secrets`, `.env.*` are all gitignored in praxis (verified). No secrets are committed.
|
||||
|
||||
### CT Resource Sizing
|
||||
|
||||
| Resource | Coreci default | Praxis v0.2 | Rationale |
|
||||
|----------|---------------|-------------|-----------|
|
||||
| Memory | 2048 MB | **4096 MB** | Docker daemon (~200MB) + build peak (~1.2GB pip) + runtime (~500MB) + headroom |
|
||||
| Rootfs | 8 GB | **16 GB** | Docker engine (~400MB) + build layers (~1.6GB) + final image (~1GB) + repo + apt + headroom |
|
||||
| CPU cores | (default) | 2 | Sufficient for build + single-learner runtime |
|
||||
| Swap | (default) | 0 | LXC swap is host swap; not needed for pilot |
|
||||
|
||||
Configured via `lxc-clone.sh` (`memory=${PROXMOX_MEMORY_MB:-4096}`, `rootfs=${storage}:16`) or env vars in the deploy script.
|
||||
|
||||
### Health-Check Path
|
||||
|
||||
```
|
||||
lxc-deploy.sh
|
||||
└─ health-check.sh <vmid>
|
||||
│
|
||||
├─ PRAXIS_HEALTH_URL set? → use directly
|
||||
│
|
||||
└─ else: pve_get /nodes/{node}/lxc/{vmid}/interfaces
|
||||
│
|
||||
├─ jq: .[] | select(.name != "lo") | (.inet? // .ip? // empty)
|
||||
│ (NOT .hwaddr — P18 bug fix from coreci)
|
||||
│
|
||||
└─ health_url = http://<bridge-ip>:8789/health
|
||||
│
|
||||
└─ poll curl -fsS --connect-timeout 2 $health_url
|
||||
for PRAXIS_HEALTH_TIMEOUT seconds (default 300s)
|
||||
```
|
||||
|
||||
**Timing:** CT start → DHCP lease (~5s) → firstboot hook: apt install Docker (~90s) + git clone (~10s) + install-service + systemctl start (~120s: docker compose build + up) → uvicorn binds :8789 → health passes. Total: ~3-5 min. `PRAXIS_HEALTH_TIMEOUT=300` (5 min) covers this with margin.
|
||||
|
||||
### Firstboot Hook Sequence
|
||||
|
||||
```
|
||||
Proxmox invokes hookscript at post-start phase (runs on PVE HOST):
|
||||
$1 = VMID, $2 = phase
|
||||
|
||||
Phase: post-start
|
||||
│
|
||||
├─ 1. pct exec <vmid> -- apt-get install docker.io docker-compose-v2 git curl
|
||||
│ (D-028: Docker via apt inside CT)
|
||||
│
|
||||
├─ 2. pct exec <vmid> -- git clone https://<GITEA_TOKEN>@git.cloudinit.dev/coreci/praxis.git /opt/praxis
|
||||
│ (D-029: clone inside CT, self-contained)
|
||||
│
|
||||
├─ 3. pct exec <vmid> -- sh /opt/praxis/scripts/install-service.sh
|
||||
│ │
|
||||
│ ├─ create praxis user (useradd --system, add to docker group)
|
||||
│ ├─ mkdir /var/lib/praxis/data /var/log/praxis /etc/praxis
|
||||
│ ├─ write /etc/praxis/server.env from lxc.environment vars
|
||||
│ ├─ install praxis.service systemd unit
|
||||
│ └─ systemctl daemon-reload && enable praxis && restart praxis
|
||||
│ │
|
||||
│ ├─ ExecStartPre: docker compose build (TimeoutStartSec=300)
|
||||
│ └─ ExecStart: docker compose up (foreground, Type=simple)
|
||||
│
|
||||
└─ 4. (hook exits 0; external health-check.sh polls /health:8789)
|
||||
```
|
||||
|
||||
**Idempotency:** The hook checks if praxis is already installed + active before re-running (mirrors coreci's pattern at firstboot-hook.sh:82). Re-running `lxc-deploy.sh` against a healthy CT skips the hook entirely (P16 idempotency via `ct_exists` + `ct_running` + health-check).
|
||||
|
||||
### What's Reused Verbatim from CoreCI vs Adapted
|
||||
|
||||
| Component | Verdict | Notes |
|
||||
|-----------|---------|-------|
|
||||
| `api.sh` | **Verbatim** | REQ-DEPLOY-03. PVE REST helpers are project-agnostic. |
|
||||
| `lxc-start.sh` | **Verbatim** | POST /status/start is identical. |
|
||||
| `proxy/ct-exists.sh` | **Verbatim** | Used by lxc-deploy.sh idempotency; no proxy dependency in the helper. |
|
||||
| `lxc-clone.sh` | Adapted | hostname=praxis, memory=4096, rootfs=16, features=nesting=1 (kept). |
|
||||
| `lxc-config.sh` | Adapted | hookscript=praxis-firstboot.sh, lxc.environment vars for praxis. |
|
||||
| `health-check.sh` | Adapted | /health (not /healthz), port 8789, PRAXIS_* env names, timeout 300s. |
|
||||
| `rollback.sh` | Adapted | Remove proxy backend-remove (no proxy in v0.2). |
|
||||
| `stage-snippet.sh` | Adapted | SNIPPET_NAME=praxis-firstboot.sh, praxis repo raw URL. |
|
||||
| `timing.sh` | Adapted | Metric prefix: praxis_deploy_timing_. |
|
||||
| `lxc-deploy.sh` | Adapted | Remove PROXY_VMID/BACKEND_DOMAIN steps; VMID=auto (D-027). |
|
||||
| `firstboot-hook.sh` | **Heavy adaptation** | Docker install + git clone + compose build/up (not host-fetch binary). |
|
||||
| `install-service.sh` | **Heavy adaptation** | praxis user (docker group), /etc/praxis/server.env, praxis.service (docker compose up). |
|
||||
|
||||
### v0.2 Deployment Risks (from RESEARCH.md)
|
||||
|
||||
| ID | Risk | Mitigation |
|
||||
|----|------|------------|
|
||||
| R-DEPLOY-01 | Pipecat wheel missing → source compilation OOM | Pre-test `docker build` locally; bump memory if needed |
|
||||
| R-DEPLOY-02 | systemd TimeoutStartSec insufficient for build+up | Set 300-600s or split build into separate oneshot service |
|
||||
| R-DEPLOY-03 | CT can't reach Gitea/apt mirrors | Validate internet access; fallback to host-clone+pct-push (D-025 hybrid) |
|
||||
| R-DEPLOY-04 | Docker-in-LXC on ZFS rootfs | Check storage type; use local (directory) if ZFS |
|
||||
| R-DEPLOY-05 | journald log flooding from compose up | Log rotation or StandardOutput=null for pilot |
|
||||
| R-DEPLOY-06 | First-boot build > 5 min (NFR breach) | Pre-build on host + docker load fallback |
|
||||
@@ -1,11 +1,25 @@
|
||||
{
|
||||
"phase": 2,
|
||||
"stage": "complete",
|
||||
"milestone": "v0.1",
|
||||
"phase_role": "final",
|
||||
"phase": 0,
|
||||
"stage": "grill",
|
||||
"milestone": "v0.2",
|
||||
"phase_role": "pre_execution",
|
||||
"attempts": 0,
|
||||
"updated_at": "2026-08-01T00:06:00Z",
|
||||
"release_status": "pending",
|
||||
"release_reason": "Gitea repo coreci/praxis does not exist (HTTP 404). Milestone tag+merge succeeded locally. Release will be created once remote repo is provisioned.",
|
||||
"milestone_complete": true
|
||||
"updated_at": "2026-08-01T14:35:00Z",
|
||||
"grill_summary": {
|
||||
"challenges": 15,
|
||||
"binding_decisions": 13,
|
||||
"must": 2,
|
||||
"fix": 4,
|
||||
"accept": 7,
|
||||
"escalations": 0,
|
||||
"verdict": "APPROVE_WITH_NOTES"
|
||||
},
|
||||
"binding_actions": {
|
||||
"G-101": "MUST: bake GITEA_TOKEN into snippet at staging time",
|
||||
"G-102": "MUST: add PRAXIS_DB_PATH env read to db/store.py + db/migrate.py",
|
||||
"G-103": "FIX: add 5 missing env vars to injection list",
|
||||
"G-104": "FIX: bump health-check timeout 300s→600s",
|
||||
"G-105": "FIX: fix Dockerfile pip install copy ordering",
|
||||
"G-106": "FIX: fix bats test count 9→10"
|
||||
}
|
||||
}
|
||||
+407
-1
@@ -201,4 +201,410 @@
|
||||
|
||||
---
|
||||
|
||||
*End of grill report. Verdict: PROCEED at confidence 0.72. 8 binding decisions (G-001..G-008), 0 escalations. Escalations visible via `ciagent audit`. This grill surfaces findings; it does not rewrite PROJECT.md, ROADMAP.md, or REQUIREMENTS.md. Binding decisions that warrant spec changes must be promoted explicitly by the user (e.g., via `ciagent-clarify` or a follow-up CLARIFY stage).*
|
||||
*End of grill report. Verdict: PROCEED at confidence 0.72. 8 binding decisions (G-001..G-008), 0 escalations. Escalations visible via `ciagent audit`. This grill surfaces findings; it does not rewrite PROJECT.md, ROADMAP.md, or REQUIREMENTS.md. Binding decisions that warrant spec changes must be promoted explicitly by the user (e.g., via `ciagent-clarify` or a follow-up CLARIFY stage).*
|
||||
|
||||
---
|
||||
|
||||
# Praxis — v0.2 Proxmox LXC Deployment Grill (Red-Team Review)
|
||||
|
||||
> **Grill date:** 2026-08-01
|
||||
> **Griller:** CI Griller (adversarial red-team)
|
||||
> **Mode:** full autonomy (auto-decide all; 0 escalations expected)
|
||||
> **Target:** `.ciagent/PLAN.md` — 10 slices, 4 waves, 34 tasks, 20 REQ-IDs (REQ-DEPLOY-01..16, REQ-NFR-DEPLOY-01..04)
|
||||
> **Artifacts reviewed:** PROJECT.md (D-021..D-030), REQUIREMENTS.md, RESEARCH.md (10 questions, 6 risks), ARCHITECTURE.md, PERSONAS.md (5 active, frontend deactivated), PLAN.md, config.json, coreci source (`/root/coreci/scripts/proxmox/`), praxis codebase (`server/__main__.py`, `db/store.py`, `pyproject.toml`, `.gitignore`, `.env.example`, `client/package.json`)
|
||||
> **Confidence threshold:** 0.60 (binding); < 0.60 = escalate
|
||||
|
||||
---
|
||||
|
||||
## Method
|
||||
|
||||
Assumed the plan is unfeasible, over-scoped, and too costly. Cross-referenced every plan claim against coreci source and the praxis codebase. Found where the plan is wrong.
|
||||
|
||||
---
|
||||
|
||||
## Challenges
|
||||
|
||||
### C-01: GITEA_TOKEN not available to the firstboot hookscript — secret injection chain is broken
|
||||
**Axis:** Feasibility / Dependency risk / Security
|
||||
**Confidence:** 0.85
|
||||
**Evidence:**
|
||||
- PLAN.md TASK-05-01 step 3 (line 368): `pct exec "$vmid" -- sh -c 'git clone https://${GITEA_TOKEN}@git.cloudinit.dev/.../praxis.git /opt/praxis'`
|
||||
- PLAN.md TASK-05-01 (line 372): "GITEA_TOKEN is available via lxc.environment (set by lxc-config.sh in SLICE-03)"
|
||||
- RESEARCH.md Q5 (line 23): "GITEA_TOKEN is passed via lxc.environment and available inside the CT"
|
||||
- coreci `firstboot-hook.sh` lines 19-27 comment: "Environment (set on the PVE host when the hookscript runs; for a fully-automated deploy, **stage a version of this snippet with the secrets baked in**)"
|
||||
- coreci `lxc-config.sh` line 59-61: `lxc.environment: GITEA_TOKEN=...` — writes to `/etc/pve/lxc/<vmid>.conf`, injecting into the **CT's** systemd environment, NOT the PVE host's environment
|
||||
|
||||
**The problem:** The hookscript runs on the **PVE host** (not inside the CT). `lxc.environment` injects vars into the CT's init process (systemd PID 1 inside the CT), NOT into the PVE host's environment. The hookscript executing on the host does NOT have `GITEA_TOKEN` in its environment. Coreci's design acknowledges this: it says to "stage a version of this snippet with the secrets baked in" — i.e., the snippet file itself is generated with the token embedded. Praxis's `stage-snippet.sh` (TASK-03-06) fetches the raw file from Gitea (no baking), so the token is NOT in the hookscript.
|
||||
|
||||
**Secondary issue — `pct exec` env inheritance:** Even if the hookscript had `GITEA_TOKEN` on the host and passed it via `pct exec -- sh -c '...${GITEA_TOKEN}...'`, the single-quoted `sh -c` body passes `${GITEA_TOKEN}` literally to the CT's shell. The CT's shell would need `GITEA_TOKEN` in its environment. `pct exec` in Proxmox 8 does NOT reliably inherit `lxc.environment` vars — it spawns a process in the CT namespace but starts with a fresh environment, not systemd's inherited env. The plan's claim that `lxc.environment` → `pct exec` inheritance works is unvalidated and contradicts coreci's own design (which fetches on the host and `pct push`es, specifically to avoid needing the token inside the CT).
|
||||
|
||||
**Impact:** The firstboot hook's `git clone` will fail with authentication error → the CT never gets the praxis repo → `install-service.sh` never runs → health-check times out at 300s → rollback fires → deploy fails every time. This is a **ship blocker**.
|
||||
|
||||
### C-02: PRAXIS_DB_PATH env var is never read by the server — SQLite volume mount is a no-op
|
||||
**Axis:** Feasibility / Operability / Completeness
|
||||
**Confidence:** 0.90
|
||||
**Evidence:**
|
||||
- PLAN.md TASK-01-03 (line 117): `PRAXIS_DB_PATH=/app/data/praxis.db` in docker-compose.yml environment
|
||||
- PLAN.md TASK-03-04 (line 237): `lxc.environment: PRAXIS_DB_PATH=/app/data/praxis.db` in lxc-config.sh
|
||||
- PLAN.md TASK-06-02 (line 456): `PRAXIS_DB_PATH=${PRAXIS_DB_PATH:-/app/data/praxis.db}` in server.env
|
||||
- PLAN.md MH-06 (line 898): "SQLite persists across `docker compose restart` via named volume `praxis-db`"
|
||||
- praxis `db/store.py` line 25: `_DEFAULT_DB_PATH = "praxis.db"` (hardcoded, no env read)
|
||||
- praxis `db/migrate.py` line 8: `_DEFAULT_DB_PATH = Path("praxis.db")` (hardcoded, no env read)
|
||||
- `grep -rn "PRAXIS_DB_PATH" /root/praxis/server/ /root/praxis/db/` → **0 matches** (only in `.env.example`)
|
||||
- `PraxisStore.__init__` (store.py:70) takes `db_path` param defaulting to `_DEFAULT_DB_PATH`, but `PraxisStore` is never instantiated in the server code (`grep -rn "PraxisStore(" /root/praxis/server/` → 0 matches). `SessionRecorder` takes a `store: PraxisStore` param but is never instantiated in `pipeline.py`.
|
||||
|
||||
**The problem:** The plan sets `PRAXIS_DB_PATH=/app/data/praxis.db` in three places (compose env, lxc.environment, server.env), but the server code never reads `PRAXIS_DB_PATH`. The DB defaults to `./praxis.db` (CWD-relative, which is `/app` in the container). The Docker volume `praxis-db` is mounted at `/app/data`. The server writes to `/app/praxis.db` (container writable layer), NOT `/app/data/praxis.db` (the volume). Data is NOT persisted across container recreation — it's lost on `docker compose down && docker compose up`. The volume mount is dead weight.
|
||||
|
||||
Additionally, `PraxisStore` and `SessionRecorder` appear to be defined but never wired into the pipeline — the recorder is not instantiated in `pipeline.py`. This may be a v0.1 gap (recorder defined but not yet connected), but the plan's MH-06 (SQLite persistence verification) will fail because there's no code writing to the DB at the volume path.
|
||||
|
||||
**Impact:** Data loss on container restart/recreate. The persistence NFR is claimed but not delivered. MH-06 acceptance criterion will fail.
|
||||
|
||||
### C-03: Missing env vars in lxc-config.sh / server.env — server will misconfigure at runtime
|
||||
**Axis:** Consistency / Completeness
|
||||
**Confidence:** 0.85
|
||||
**Evidence:**
|
||||
- The praxis server reads these env vars (verified by grep):
|
||||
- `OLLAMA_CHAT_URL` (server/llm/ollama_cloud.py:41) — used for the direct API chat endpoint
|
||||
- `CARTESIA_VOICE_ID` (server/pipeline.py:127, server/tts/cartesia_tts.py:40) — TTS voice selection
|
||||
- `DEEPGRAM_REGION`, `DEEPGRAM_LANGUAGE` — referenced in .env.example (lines 36-37), may be read by pipeline
|
||||
- `PRAXIS_SCENARIO` (server/__main__.py:83) — scenario ID selection
|
||||
- PLAN.md TASK-03-04 (lines 235-247) lxc-config.sh env var list does NOT include: `OLLAMA_CHAT_URL`, `CARTESIA_VOICE_ID`, `DEEPGRAM_REGION`, `DEEPGRAM_LANGUAGE`, `PRAXIS_SCENARIO`
|
||||
- PLAN.md TASK-06-02 (lines 453-467) install-service.sh server.env does NOT include the same vars
|
||||
- praxis `.env.example` (lines 21-40) documents all of these as server config
|
||||
|
||||
**The problem:** The plan's env var injection list (TASK-03-04, TASK-06-02) is incomplete. `OLLAMA_CHAT_URL` defaults to `https://ollama.com/api/chat` in code, so it may work without injection — but `CARTESIA_VOICE_ID` and `PRAXIS_SCENARIO` have defaults too. The issue is that the plan claims to wire "all praxis env vars" but the list is missing vars that `.env.example` documents and the code reads. If any of these need to be overridden per-deployment (e.g., a different scenario, a different voice), they can't be without editing the compose file.
|
||||
|
||||
**Impact:** Server runs with defaults (may be acceptable for pilot), but the env injection chain is incomplete vs. what the code actually reads. Inconsistency between plan claims and reality.
|
||||
|
||||
### C-04: systemd TimeoutStartSec=300 may be insufficient for first-boot build — R-DEPLOY-02 unresolved
|
||||
**Axis:** Feasibility / Timeline / Operability
|
||||
**Confidence:** 0.65
|
||||
**Evidence:**
|
||||
- RESEARCH.md R-DEPLOY-02 (line 636): "systemd TimeoutStartSec applies to ExecStartPre+ExecStart combined → 300s insufficient for build+up" — confidence 0.65
|
||||
- RESEARCH.md Q8 (line 278): "the ExecStartPre=docker compose build pattern needs validation (build may exceed systemd's default timeout, may need TimeoutStartSec=300)"
|
||||
- PLAN.md D-036 (line 974): confidence 0.75, mitigation = "if insufficient, split into praxis-build.service"
|
||||
- PLAN.md TASK-06-01 (line 424): `TimeoutStartSec=300`
|
||||
- RESEARCH.md Q2/Q9 estimates: Docker build inside CT = npm ci (~400MB peak) + pip install (~1.2GB peak) + compose up. Estimated 3-5 min total.
|
||||
- REQ-NFR-DEPLOY-03 target: < 5 min first-boot
|
||||
|
||||
**The problem:** `TimeoutStartSec=300` (5 min) is the NFR target ceiling, but it's also the timeout. If the build takes exactly 4.5 min + compose up takes 30s, the total is 5 min — right at the timeout boundary. If `TimeoutStartSec` applies to `ExecStartPre` + `ExecStart` combined (which systemd does in some configurations), 300s is too tight. The plan acknowledges the risk (D-036) but defers mitigation to "monitor and split if needed" — which means the first deploy may fail with a timeout, triggering rollback, and the team discovers the problem only at E2E time (SLICE-10).
|
||||
|
||||
**Impact:** First deploy may fail with systemd timeout → rollback → no working CT. Not a design flaw but an estimate risk that should be mitigated proactively, not reactively.
|
||||
|
||||
### C-05: Health-check timeout (300s) vs first-boot build time (3-5 min) — zero margin
|
||||
**Axis:** Feasibility / Timeline
|
||||
**Confidence:** 0.70
|
||||
**Evidence:**
|
||||
- PLAN.md TASK-04-01 (line 333): timeout default 300s
|
||||
- RESEARCH.md Q7 (line 383): "Docker build inside CT + compose up may take 3-5 min; the default 180s timeout is insufficient. Use PRAXIS_HEALTH_TIMEOUT=300"
|
||||
- RESEARCH.md Q7 (line 390): "Total: ~3-5 min from CT start to health. 300s timeout covers this with margin" — but 3-5 min = 180-300s, so the upper bound (5 min = 300s) equals the timeout. Zero margin.
|
||||
- The build includes: apt install Docker (~90s) + git clone (~10s) + docker compose build (~120s) + compose up (~10s) = ~230s best case. But apt install can be slower on a fresh CT, pip install can spike if wheels are missing (R-DEPLOY-01), and network latency adds time.
|
||||
|
||||
**The problem:** The health-check timeout (300s) equals the worst-case estimate (5 min). There is no margin. If anything is slower than estimated (network, disk I/O, pip compilation fallback), the health-check fires before the service is up → rollback → deploy fails. The research says "covers this with margin" but 300s = 300s is zero margin.
|
||||
|
||||
**Impact:** Intermittent deploy failures under load or slow network conditions. The NFR (REQ-NFR-DEPLOY-03: < 5 min) is set at the same value as the timeout — a deployment that takes 4m59s passes the NFR but leaves 1s of health-check margin.
|
||||
|
||||
### C-06: CT internet access is assumed but unvalidated — R-DEPLOY-03
|
||||
**Axis:** Dependency risk / Feasibility
|
||||
**Confidence:** 0.60
|
||||
**Evidence:**
|
||||
- RESEARCH.md R-DEPLOY-03 (line 637): "CT network can't reach Gitea or apt mirrors (coreci's original concern)" — confidence 0.60
|
||||
- RESEARCH.md Q2 (line 103): "D-028/D-029 explicitly chose apt-install-inside-CT and clone-from-Gitea, implying the CT DOES have internet in this deployment — different from coreci's original assumption"
|
||||
- coreci `firstboot-hook.sh` lines 9-14: "The CT's network may not route to the internet (upstream often only routes the host's IP). The PVE host has internet, so this hookscript fetches... on the host... then pushes them into the CT"
|
||||
- D-029 (PROJECT.md line 98): "CT fetches its own source + builds" — assumes CT has internet
|
||||
- D-030 (PROJECT.md line 99): "vmbr0 DHCP only" — DHCP gives an IP, but doesn't guarantee internet routing
|
||||
|
||||
**The problem:** The entire build-inside-CT approach (D-029) rests on the CT having internet access to reach Debian apt mirrors and `git.cloudinit.dev`. Coreci's original design explicitly assumes the opposite ("CT's network may not route to the internet") and works around it by host-fetching + `pct push`. Praxis reverses this assumption without validation. If the CT's vmbr0 DHCP gives an IP but no default route or no DNS resolution to external hosts, the apt install + git clone both fail. The plan's mitigation (RESEARCH.md: "fallback to host-clone + pct push") is the coreci pattern — but no task in the plan implements this fallback. It's a noted risk with no task.
|
||||
|
||||
**Impact:** If CT has no internet, the entire firstboot sequence fails at step 1 (apt install). Deploy is impossible until the network issue is resolved or the fallback is implemented.
|
||||
|
||||
### C-07: Docker-in-LXC on ZFS rootfs storage — R-DEPLOY-04 unvalidated
|
||||
**Axis:** Dependency risk / Feasibility
|
||||
**Confidence:** 0.55
|
||||
**Evidence:**
|
||||
- RESEARCH.md R-DEPLOY-04 (line 638): "Docker-in-LXC on ZFS rootfs storage → overlay2 conflict" — confidence 0.50
|
||||
- RESEARCH.md Q1 (line 55): "If the PVE host uses ZFS for CT rootfs, Docker's overlay2 may have issues (ZFS CoW + overlay CoW conflict). The coreci .env shows PROXMOX_STORAGE=local which is typically directory/LVM-thin, not ZFS. Verify at deploy time"
|
||||
- PLAN.md: no task validates the storage type before deploy
|
||||
|
||||
**The problem:** If `PROXMOX_STORAGE=local` maps to a ZFS pool (not directory/LVM-thin), Docker's overlay2 driver may fail inside the LXC. The research says "verify at deploy time" but no plan task performs this verification. This is a 0.50 confidence risk (below the binding threshold), but it's a known unknown that could block the deploy with no mitigation task.
|
||||
|
||||
**Impact:** Potential build failure if storage is ZFS. Unlikely (coreci uses the same cluster), but unverified.
|
||||
|
||||
### C-08: Bats test suite claims 9 unit/integration files but PLAN lists 11 test tasks
|
||||
**Axis:** Testability / Consistency
|
||||
**Confidence:** 0.75
|
||||
**Evidence:**
|
||||
- PLAN.md SLICE-09 (line 667): 11 tasks (TASK-09-01 through TASK-09-11)
|
||||
- PLAN.md MH-26 (line 928): "`make test-proxmox-scripts` passes — 9 unit/integration bats files"
|
||||
- PLAN.md Verification SLICE-09 (line 807): "9 unit/integration bats files"
|
||||
- TASK-09-10 is `docker-build.bats` (praxis-specific, not from coreci)
|
||||
- TASK-09-11 is `test_helper.bash` + `Makefile` (not a bats file)
|
||||
|
||||
**The problem:** The plan says "9 unit/integration bats files" but SLICE-09 has 11 tasks. TASK-09-10 (docker-build.bats) is the 10th bats file. TASK-09-11 is a helper + Makefile (not a bats file). So there are 10 bats files (9 coreci-derived + 1 docker-build), not 9. The MH-26 and verification claims of "9" are wrong.
|
||||
|
||||
**Impact:** Minor — test suite is slightly larger than documented. docker-build.bats may not be included in `make test-proxmox-scripts` if the target only lists 9 files.
|
||||
|
||||
### C-09: No task implements the repo update path (code changes after first deploy)
|
||||
**Axis:** Operability / Completeness
|
||||
**Confidence:** 0.70
|
||||
**Evidence:**
|
||||
- RESEARCH.md Q5 open question 3 (line 648): "Repo update path: When praxis code changes, how is the CT updated? Options: (a) pct exec git pull && systemctl restart praxis, (b) --reconfigure flag, (c) separate lxc-update.sh. Not a v0.2 blocker (first deploy only) but should be designed for"
|
||||
- PLAN.md: no task creates an update/redeploy script
|
||||
- PLAN.md SLICE-07 lxc-deploy.sh has `--reconfigure` (re-PUTs config + restarts CT) but this re-runs the firstboot hook which checks `systemctl is-active praxis` → if active, skips. So `--reconfigure` does NOT update the code — it just restarts the CT. The code update path is undefined.
|
||||
|
||||
**The problem:** After the first successful deploy, if the praxis code changes (bug fix, v0.2.1), there's no way to update the running CT. `--recreate` destroys + redeploys (works but slow — full rebuild). `--reconfigure` restarts the CT but doesn't pull new code (the hook's idempotency check skips if praxis is active). There's no `git pull && systemctl restart praxis` task or script. The research flags this as "not a v0.2 blocker" but it makes the deployed system a one-shot static snapshot with no update path short of full rebuild.
|
||||
|
||||
**Impact:** No code update path without full CT destruction + rebuild. Acceptable for a pilot's first deploy, but operability gap for any post-deploy fix.
|
||||
|
||||
### C-10: Pipecat wheel availability for cp312/linux-amd64 — R-DEPLOY-01 untested until SLICE-01
|
||||
**Axis:** Feasibility / Dependency risk
|
||||
**Confidence:** 0.60
|
||||
**Evidence:**
|
||||
- RESEARCH.md R-DEPLOY-01 (line 635): "Pipecat native-ext wheel missing for cp312/linux-amd64 → source compilation OOMs at 4GB" — confidence 0.70
|
||||
- RESEARCH.md Q2 (line 101): "Python 3.12 wheels exist for all pipecat-ai extras on linux/amd64 (high probability — pipecat targets CPython 3.11+ and ships manylinux wheels)"
|
||||
- PLAN.md TASK-01-01 (line 83): Dockerfile uses `python:3.12-slim` + `pip install --no-cache-dir .`
|
||||
- PLAN.md R-DEPLOY-01 mitigation (line 994): "Pre-test docker build locally (SLICE-01 verification); if compilation needed, bump to 8GB or use --only-binary :all:"
|
||||
|
||||
**The problem:** The entire build-inside-CT approach assumes all Pipecat extras (deepgram, cartesia, piper, webrtc) ship cp312 linux/amd64 wheels. If any don't (e.g., `aiortc` Cython extensions, `sounddevice`), pip falls back to source compilation which needs gcc + libasound2-dev (included in the Dockerfile) and may spike memory > 4GB (OOM at the CT's memory limit). The 4GB memory allocation may be insufficient. This is only discoverable at SLICE-01 verification time.
|
||||
|
||||
**Impact:** Build may fail if wheels are missing. Mitigation exists (bump to 8GB, `--only-binary :all:`) but is reactive. Caught early at SLICE-01.
|
||||
|
||||
### C-11: `scripts/` excluded in .dockerignore but install-service.sh runs from repo clone — consistent
|
||||
**Axis:** Consistency
|
||||
**Confidence:** 0.80
|
||||
**Evidence:**
|
||||
- PLAN.md TASK-01-02 (line 95): `.dockerignore` excludes `scripts/`
|
||||
- PLAN.md TASK-05-01 step 4 (line 369): `pct exec "$vmid" -- sh -c 'cd /opt/praxis && sh scripts/install-service.sh'`
|
||||
- The `.dockerignore` controls the Docker **build context** (the image won't contain `scripts/`). `install-service.sh` runs from the git clone at `/opt/praxis`, NOT from inside the Docker image. No conflict.
|
||||
|
||||
**Not a bug** — design is correct. The `.dockerignore` rationale is confusingly worded but the design is sound.
|
||||
|
||||
### C-12: `OLLAMA_BASE_URL` injected but `OLLAMA_CHAT_URL` (a different endpoint) is not
|
||||
**Axis:** Consistency
|
||||
**Confidence:** 0.70
|
||||
**Evidence:**
|
||||
- PLAN.md TASK-03-04 (line 243): `lxc.environment: OLLAMA_BASE_URL=https://ollama.com/v1`
|
||||
- praxis `server/llm/ollama_cloud.py:41`: reads `OLLAMA_CHAT_URL` (default `https://ollama.com/api/chat`)
|
||||
- praxis `server/pipeline.py:99`: reads `OLLAMA_BASE_URL` (default `https://ollama.com/v1`)
|
||||
- PLAN.md env var lists do NOT include `OLLAMA_CHAT_URL`
|
||||
|
||||
**The problem:** The server has TWO Ollama env vars: `OLLAMA_BASE_URL` (OpenAI-compatible Pipecat path) and `OLLAMA_CHAT_URL` (direct chat API). The plan injects `OLLAMA_BASE_URL` but not `OLLAMA_CHAT_URL`. Code defaults work, but the injection list is incomplete.
|
||||
|
||||
### C-13: No rollback verification for the Docker volume — data loss on rollback
|
||||
**Axis:** Operability
|
||||
**Confidence:** 0.65
|
||||
**Evidence:**
|
||||
- rollback.sh destroys the CT (`DELETE /nodes/{node}/lxc/{vmid}`), which destroys the CT's rootfs including Docker volumes.
|
||||
- PLAN.md MH-06: "SQLite persists across `docker compose restart`" — restart ≠ recreate ≠ CT destruction
|
||||
|
||||
**The problem:** The Docker named volume `praxis-db` lives inside the CT's Docker daemon. When `rollback.sh` destroys the CT, all Docker volumes are destroyed with it. No volume backup/export step exists in rollback. Data loss on rollback.
|
||||
|
||||
**Impact:** Acceptable for pilot (no real users yet), but should be documented.
|
||||
|
||||
### C-14: E2E test (SLICE-10) against live cluster — autonomy boundary unclear
|
||||
**Axis:** Testability / Operability
|
||||
**Confidence:** 0.60
|
||||
**Evidence:**
|
||||
- PLAN.md TASK-10-01: "Requires PROXMOX_* + GITEA_TOKEN + DEEPGRAM_API_KEY env vars"
|
||||
- config.json: `escalate_external_integration: true` — but E2E is the project's own deployment target
|
||||
|
||||
**The problem:** The E2E test creates a real CT on the live cluster, deploys, verifies, and destroys. At full autonomy, this runs without human approval. If the test fails mid-way, a zombie CT may be left. The autonomy/escalation boundary for live-cluster E2E is unclear.
|
||||
|
||||
### C-15: Dockerfile `pip install .` runs before source is copied — build will fail
|
||||
**Axis:** Feasibility / Consistency
|
||||
**Confidence:** 0.75
|
||||
**Evidence:**
|
||||
- PLAN.md TASK-01-01 (line 83): `COPY pyproject.toml`, `RUN pip install --no-cache-dir .`, then `COPY server/ scenarios/ db/`
|
||||
- `pip install .` installs the PROJECT package, which requires source directories (`server/`, `db/`, `scenarios/`) to exist
|
||||
- `pyproject.toml` line 9: `readme = "README.md"` — README.md is not copied in the Dockerfile spec
|
||||
- RESEARCH.md Q4 (line 183): same ordering issue
|
||||
|
||||
**The problem:** The Dockerfile copies `pyproject.toml` then runs `pip install .` BEFORE copying `server/`, `scenarios/`, `db/`. With only `pyproject.toml` present, `pip install .` will fail because the packages to install don't exist yet. The standard dep-caching pattern requires either installing deps separately or copying source before project install.
|
||||
|
||||
**Impact:** Docker build fails at the `pip install .` step. Spec error in the plan.
|
||||
|
||||
---
|
||||
|
||||
## Binding Decisions
|
||||
|
||||
### G-101: GITEA_TOKEN secret injection chain is broken — MUST fix before execute
|
||||
- **Challenge:** C-01
|
||||
- **Axis:** Feasibility / Dependency risk / Security
|
||||
- **Confidence:** 0.85
|
||||
- **Verdict:** MUST (blocks ship)
|
||||
- **Rationale:** The firstboot hookscript runs on the PVE host, but `GITEA_TOKEN` is injected via `lxc.environment` into the CT, not the host. The hook's `git clone` will fail with auth error every time. Coreci's own design acknowledges this ("stage a version of this snippet with the secrets baked in"). The plan's `stage-snippet.sh` fetches a raw file without baking secrets. Additionally, `pct exec` does not reliably inherit `lxc.environment` vars in the CT's exec'd process.
|
||||
- **Action:** Choose one of:
|
||||
1. **(Recommended) Bake GITEA_TOKEN into the snippet at staging time:** Modify `stage-snippet.sh` to fetch the hookscript template, `sed`/`envsubst` the `GITEA_TOKEN` into it, then upload the rendered snippet. This matches coreci's documented approach. The token is in the snippet file (stored in Proxmox snippet storage, not git). Minimal change.
|
||||
2. **Host-side git clone + pct push:** Clone the repo on the PVE host (where `GITEA_TOKEN` can be exported by `lxc-deploy.sh`), then `pct push` the tarball into the CT. This is coreci's original pattern. Reverts D-029's "clone inside CT" but is proven.
|
||||
3. **Pass GITEA_TOKEN via pct exec explicitly:** `pct exec "$vmid" -- sh -c 'GITEA_TOKEN='"$GITEA_TOKEN"' git clone ...'` — requires `GITEA_TOKEN` in the host env (the hookscript env), which still has the "lxc.environment doesn't reach the host" problem. Doesn't work without baking.
|
||||
- **Option 1 is the minimal change.** Update TASK-03-06 (stage-snippet.sh) to render the snippet with `GITEA_TOKEN` baked in. Update TASK-05-01 to use the baked-in token. Update RESEARCH.md Q5/Q6.
|
||||
|
||||
### G-102: PRAXIS_DB_PATH is never read by the server — MUST fix the code
|
||||
- **Challenge:** C-02
|
||||
- **Axis:** Feasibility / Operability / Completeness
|
||||
- **Confidence:** 0.90
|
||||
- **Verdict:** MUST (blocks ship)
|
||||
- **Rationale:** The plan sets `PRAXIS_DB_PATH=/app/data/praxis.db` in 3 places and claims SQLite persistence via Docker volume (MH-06). But `db/store.py` and `db/migrate.py` hardcode `_DEFAULT_DB_PATH = "praxis.db"` with no env read. The server writes to `/app/praxis.db` (container writable layer), NOT the volume at `/app/data/praxis.db`. Data is lost on container recreation. MH-06 will fail.
|
||||
- **Action:** Add `PRAXIS_DB_PATH` env var reading to `db/store.py` and `db/migrate.py`:
|
||||
```python
|
||||
_DEFAULT_DB_PATH = os.environ.get("PRAXIS_DB_PATH", "praxis.db")
|
||||
```
|
||||
2-line code change in 2 files. Add as a new task in SLICE-01 or SLICE-02 (data-engineer / backend-engineer territory). Also verify `PraxisStore` is instantiated in the pipeline (if not, recorder is dead code — v0.1 gap, but env var fix is still needed).
|
||||
|
||||
### G-103: Incomplete env var injection list — FIX before execute
|
||||
- **Challenge:** C-03, C-12
|
||||
- **Axis:** Consistency / Completeness
|
||||
- **Confidence:** 0.85
|
||||
- **Verdict:** FIX (must address before execute)
|
||||
- **Rationale:** The plan's env var injection list (TASK-03-04, TASK-06-02) is missing `OLLAMA_CHAT_URL`, `CARTESIA_VOICE_ID`, `DEEPGRAM_REGION`, `DEEPGRAM_LANGUAGE`, `PRAXIS_SCENARIO` — all of which the server reads from env. Defaults exist, but the plan claims to wire "all praxis env vars" and the list is incomplete.
|
||||
- **Action:** Add the missing env vars to both TASK-03-04 (lxc-config.sh `lxc.environment` lines) and TASK-06-02 (install-service.sh `server.env` heredoc):
|
||||
- `OLLAMA_CHAT_URL=https://ollama.com/api/chat`
|
||||
- `CARTESIA_VOICE_ID=a3536a36-1d18-4efb-a95a-7e44b7b5e384`
|
||||
- `DEEPGRAM_LANGUAGE=en`
|
||||
- `DEEPGRAM_REGION=na`
|
||||
- `PRAXIS_SCENARIO=customer_service_refund_ca_v01`
|
||||
|
||||
### G-104: Health-check timeout has zero margin — FIX by bumping to 600s
|
||||
- **Challenge:** C-04, C-05
|
||||
- **Axis:** Feasibility / Timeline
|
||||
- **Confidence:** 0.70
|
||||
- **Verdict:** FIX (must address before execute)
|
||||
- **Rationale:** `PRAXIS_HEALTH_TIMEOUT=300` (5 min) equals the worst-case build estimate (5 min). Zero margin. Any slowdown causes timeout → rollback → deploy failure. The NFR target (< 5 min) is a measurement, not a timeout — the timeout should be 2x the target.
|
||||
- **Action:** Bump `PRAXIS_HEALTH_TIMEOUT` default to `600` (10 min) in TASK-04-01 (health-check.sh) and TASK-08-02 (.env.example). Bump `TimeoutStartSec` in praxis.service (TASK-06-01) to `600` to match (addresses C-04). NFR target stays at < 5 min (measured by timing wrappers).
|
||||
|
||||
### G-105: Dockerfile pip install ordering is broken — FIX before execute
|
||||
- **Challenge:** C-15
|
||||
- **Axis:** Feasibility / Consistency
|
||||
- **Confidence:** 0.75
|
||||
- **Verdict:** FIX (must address before execute)
|
||||
- **Rationale:** The Dockerfile spec copies `pyproject.toml` then runs `pip install --no-cache-dir .` BEFORE copying `server/`, `scenarios/`, `db/`. `pip install .` installs the project package, which requires source directories. With only `pyproject.toml` present, the install fails. Also `README.md` (referenced by `pyproject.toml`) is not copied.
|
||||
- **Action:** Fix the Dockerfile in TASK-01-01 to copy source before `pip install .`, OR split into dep install + project install. Add `README.md` to the COPY list. Example fix:
|
||||
```dockerfile
|
||||
COPY pyproject.toml README.md ./
|
||||
COPY server/ ./server/
|
||||
COPY scenarios/ ./scenarios/
|
||||
COPY db/ ./db/
|
||||
RUN pip install --no-cache-dir .
|
||||
COPY --from=client-builder /app/client/dist ./client/dist
|
||||
```
|
||||
|
||||
### G-106: Bats test count mismatch (9 vs 10) — FIX the count
|
||||
- **Challenge:** C-08
|
||||
- **Axis:** Testability / Consistency
|
||||
- **Confidence:** 0.75
|
||||
- **Verdict:** FIX (must address before execute)
|
||||
- **Rationale:** MH-26 and SLICE-09 verification claim "9 unit/integration bats files" but there are 10 (TASK-09-01 through TASK-09-10 are .bats files; TASK-09-11 is a helper + Makefile). The Makefile target must include `docker-build.bats`.
|
||||
- **Action:** Update MH-26 and SLICE-09 verification to "10 unit/integration bats files." Ensure the Makefile target in TASK-09-11 includes `docker-build.bats`.
|
||||
|
||||
### G-107: No repo update path after first deploy — ACCEPT for v0.2
|
||||
- **Challenge:** C-09
|
||||
- **Axis:** Operability / Completeness
|
||||
- **Confidence:** 0.70
|
||||
- **Verdict:** ACCEPT (acknowledged, no action)
|
||||
- **Rationale:** No `git pull && systemctl restart` path for code updates. `--reconfigure` restarts but doesn't pull. `--recreate` works (full rebuild) but is slow. Research flags as "not a v0.2 blocker." For a pilot's first deploy, acceptable.
|
||||
- **Action:** None for v0.2. Document as known limitation: "No in-place code update path; use `--recreate` for code changes."
|
||||
|
||||
### G-108: CT internet access unvalidated (R-DEPLOY-03) — ACCEPT with deploy-time check
|
||||
- **Challenge:** C-06
|
||||
- **Axis:** Dependency risk / Feasibility
|
||||
- **Confidence:** 0.60
|
||||
- **Verdict:** ACCEPT (acknowledged, verify at E2E)
|
||||
- **Rationale:** Build-inside-CT assumes internet access. Coreci assumed the opposite. At 0.60 confidence, at the binding threshold. E2E test (SLICE-10) will discover this immediately — no silent failure.
|
||||
- **Action:** No plan change. Add note to SLICE-10: "If firstboot fails at apt install, check CT internet routing. Fallback: host-clone + pct push (D-025 hybrid)."
|
||||
|
||||
### G-109: Docker volume data loss on rollback — ACCEPT for pilot
|
||||
- **Challenge:** C-13
|
||||
- **Axis:** Operability
|
||||
- **Confidence:** 0.65
|
||||
- **Verdict:** ACCEPT (acknowledged, no action)
|
||||
- **Rationale:** Docker volume destroyed with CT on rollback. Acceptable for pilot (no persistent user data). Should be documented.
|
||||
- **Action:** Add note to executor notes: "Rollback destroys CT including Docker volumes — all SQLite data lost. Acceptable for pilot."
|
||||
|
||||
### G-110: E2E against live cluster — ACCEPT
|
||||
- **Challenge:** C-14
|
||||
- **Axis:** Testability / Operability
|
||||
- **Confidence:** 0.60
|
||||
- **Verdict:** ACCEPT (acknowledged, no action)
|
||||
- **Rationale:** E2E runs against live Proxmox at full autonomy. Gated by `PROXMOX_API_URL` (skips if absent). This is the project's own deployment target, not a third-party integration. Consistent with full autonomy.
|
||||
- **Action:** None. The E2E skip condition handles the no-secrets case.
|
||||
|
||||
### G-111: Pipecat wheel risk (R-DEPLOY-01) — ACCEPT with early detection
|
||||
- **Challenge:** C-10
|
||||
- **Axis:** Feasibility / Dependency risk
|
||||
- **Confidence:** 0.60
|
||||
- **Verdict:** ACCEPT (early detection at SLICE-01)
|
||||
- **Rationale:** If wheels missing, Docker build fails at SLICE-01 (first task, earliest detection). Mitigation documented (bump to 8GB, `--only-binary :all:`). No silent failure.
|
||||
- **Action:** None. Executor runs `docker build` locally first.
|
||||
|
||||
### G-112: ZFS storage risk (R-DEPLOY-04) — ACCEPT (below threshold)
|
||||
- **Challenge:** C-07
|
||||
- **Axis:** Dependency risk
|
||||
- **Confidence:** 0.55
|
||||
- **Verdict:** ACCEPT (below binding threshold)
|
||||
- **Rationale:** At 0.55, below 0.60 threshold. Coreci uses same cluster/storage and works. E2E catches it if it manifests.
|
||||
- **Action:** None. Informational only.
|
||||
|
||||
### G-113: .dockerignore scripts/ exclusion is correct — ACCEPT
|
||||
- **Challenge:** C-11
|
||||
- **Axis:** Consistency
|
||||
- **Confidence:** 0.80
|
||||
- **Verdict:** ACCEPT (no action)
|
||||
- **Rationale:** `.dockerignore` excludes `scripts/` from the Docker image. `install-service.sh` runs from the repo clone at `/opt/praxis`, not from the container. Design is correct.
|
||||
- **Action:** None. Optionally clarify TASK-01-02 rationale.
|
||||
|
||||
---
|
||||
|
||||
## Escalations
|
||||
|
||||
**None.** All 15 challenges are resolved with confidence >= 0.60 (13 binding decisions) or explicitly accepted at full autonomy. No challenge requires human input.
|
||||
|
||||
---
|
||||
|
||||
## Summary
|
||||
|
||||
**Overall assessment: APPROVE_WITH_NOTES**
|
||||
|
||||
The v0.2 plan is fundamentally sound — it reuses a battle-tested deployment toolkit (coreci), adapts it with well-researched parameters (4GB/16GB CT sizing, /health:8789 endpoint), and covers all 20 REQ-IDs across 10 coherent slices. The research is thorough (10 questions, 6 risks). The architecture is well-documented. The persona allocation is reasonable.
|
||||
|
||||
However, the grill found **2 MUST-fix blockers** and **4 FIX-before-execute issues**:
|
||||
|
||||
1. **G-101 (MUST):** GITEA_TOKEN secret injection chain is broken — hookscript runs on PVE host but token is in CT env. Every deploy fails at `git clone`. Fix: bake token into snippet at staging time.
|
||||
2. **G-102 (MUST):** `PRAXIS_DB_PATH` is never read by server code — Docker volume mount is a no-op, data lost on container recreation. MH-06 fails. Fix: 2-line code change in `db/store.py` + `db/migrate.py`.
|
||||
3. **G-103 (FIX):** Env var injection list missing 5 vars the server reads.
|
||||
4. **G-104 (FIX):** Health-check timeout (300s) = worst-case build (5 min) = zero margin. Bump to 600s.
|
||||
5. **G-105 (FIX):** Dockerfile `pip install .` runs before source copied — build fails. Fix copy ordering.
|
||||
6. **G-106 (FIX):** Bats test count is 10, not 9 — MH-26 and Makefile need updating.
|
||||
|
||||
The remaining 7 challenges (G-107 through G-113) are accepted — known risks with mitigations or pilot-acceptable limitations.
|
||||
|
||||
**Verdict:** The plan CANNOT ship as-is. G-101 and G-102 are ship blockers. G-103 through G-106 must be fixed before execute. With these 6 fixes applied, the plan is sound and should proceed.
|
||||
|
||||
| Metric | Count |
|
||||
|--------|-------|
|
||||
| Total challenges | 15 |
|
||||
| Binding decisions | 13 |
|
||||
| MUST (blocks ship) | 2 (G-101, G-102) |
|
||||
| FIX (before execute) | 4 (G-103, G-104, G-105, G-106) |
|
||||
| ACCEPT (no action) | 7 (G-107 through G-113) |
|
||||
| Escalations | 0 |
|
||||
| Overall | APPROVE_WITH_NOTES — proceed after MUST/FIX addressed |
|
||||
|
||||
---
|
||||
|
||||
## Per-Axis Scorecard
|
||||
|
||||
| Axis | Score | Notes |
|
||||
|------|-------|-------|
|
||||
| 1. Feasibility | ⚠️ | 2 blockers (G-101 secret chain, G-102 DB path) + Dockerfile ordering (G-105). Fixable. |
|
||||
| 2. Scope | ✅ | 20 REQ-IDs, all mapped. Scope is tight (infra-only). Frontend deactivation justified. |
|
||||
| 3. Cost/effort | ✅ | Reusing coreci verbatim where possible. 34 tasks proportional to a deploy milestone. |
|
||||
| 4. Dependency risk | ⚠️ | CT internet unvalidated (G-108), Pipecat wheel risk (G-111), ZFS risk (G-112). All have early-detection gates. |
|
||||
| 5. Security | ⚠️ | Secret chain broken (G-101). `.gitignore` coverage correct. Secrets never committed. |
|
||||
| 6. Operability | ⚠️ | No update path (G-107, accepted). Data loss on rollback (G-109, accepted). Timeout zero margin (G-104, fix). |
|
||||
| 7. Testability | ✅ | Bats suite mirrors coreci (10 files). E2E with skip condition. Count mismatch (G-106, fix). |
|
||||
| 8. Consistency | ⚠️ | Env var list incomplete (G-103). Test count wrong (G-106). Dockerfile spec error (G-105). |
|
||||
| 9. Completeness | ⚠️ | Missing env vars (G-103). Missing DB path wiring (G-102). No update script (G-107, accepted). REQ coverage 20/20. |
|
||||
|
||||
---
|
||||
|
||||
*End of v0.2 grill report. Verdict: APPROVE_WITH_NOTES. 13 binding decisions (G-101..G-113), 0 escalations. Escalations visible via `ciagent audit`. This grill surfaces findings; it does not rewrite PROJECT.md, ROADMAP.md, or REQUIREMENTS.md. Binding decisions that warrant spec changes must be promoted explicitly by the user (e.g., via `ciagent-clarify` or a follow-up CLARIFY stage).*
|
||||
+94
-44
@@ -1,23 +1,28 @@
|
||||
# Praxis — Persona Assessment
|
||||
|
||||
> **Generated:** Phase 0 RESEARCH stage
|
||||
> **Project:** Praxis (v0.1 foundation)
|
||||
> **Source:** Research findings (`.ciagent/RESEARCH.md`) + config.json personas
|
||||
> **Generated:** v0.2 RESEARCH stage (Proxmox LXC deployment)
|
||||
> **Project:** Praxis (v0.2 — deploy-infra-heavy milestone)
|
||||
> **Source:** Research findings (`.ciagent/RESEARCH.md`) + config.json personas + v0.2 REQUIREMENTS.md (REQ-DEPLOY-01..16)
|
||||
|
||||
## Persona Roster
|
||||
|
||||
### Active personas (4)
|
||||
### Active personas (5)
|
||||
|
||||
The v0.2 milestone is deploy-infra-heavy. The original four personas (lead-developer, backend-engineer, frontend-engineer, data-engineer) are retained, and a new **devops-engineer** persona is added to own the Proxmox LXC deployment scripts. The frontend-engineer is **deactivated** (rationale below) since the client build is a single `npm run build` step in the Dockerfile with no client-side code changes in scope.
|
||||
|
||||
```yaml
|
||||
---
|
||||
name: lead-developer
|
||||
active: true
|
||||
phase_specific: false
|
||||
reason: Coordinates task decomposition across the voice-loop pipeline; resolves conflicts between backend/frontend/data personas. Required for every milestone.
|
||||
reason: Coordinates task decomposition across the deploy pipeline; resolves conflicts between backend/data/devops personas. Owns the Dockerfile multi-stage design (spans client + server stages) and the lxc-deploy.sh orchestrator integration. Required for every milestone.
|
||||
domain: coordination
|
||||
frameworks: [pipecat, react]
|
||||
constraints: [pragmatic, latency-budget-aware (<600ms), voice-first-architecture]
|
||||
territory: []
|
||||
frameworks: [pipecat, react, docker, proxmox-lxc]
|
||||
constraints: [pragmatic, battle-tested defaults, reuse-coreci-toolkit, latency-budget-aware (<600ms)]
|
||||
territory:
|
||||
- "Dockerfile"
|
||||
- "docker-compose.yml"
|
||||
- ".dockerignore"
|
||||
---
|
||||
```
|
||||
|
||||
@@ -26,10 +31,10 @@ territory: []
|
||||
name: backend-engineer
|
||||
active: true
|
||||
phase_specific: false
|
||||
reason: Owns the Pipecat server, Ollama Cloud direct API integration, Deepgram ASR service, guardrail layer, and scenario runtime (Pipecat Flows + YAML→Pydantic). Core of the v0.1 voice loop.
|
||||
reason: Owns the FastAPI StaticFiles mount in server/__main__.py (REQ-DEPLOY-13), the docker-compose.yml service definition, and the server-side env var wiring. Also owns the praxis.service systemd unit structure (collaborates with devops-engineer). The v0.2 backend work is smaller than v0.1 but critical — the static mount must not break the existing /health and /pipecat/webrtc routes.
|
||||
domain: backend
|
||||
frameworks: [pipecat, pydantic, ollama, deepgram, cartesia, piper, sqlite]
|
||||
constraints: [api-first, type-safe, latency-budget-aware, streaming-first, pluggable-interfaces-for-swap]
|
||||
frameworks: [pipecat, pydantic, fastapi, uvicorn, docker]
|
||||
constraints: [api-first, type-safe, latency-budget-aware, routes-before-static-mount, streaming-first]
|
||||
territory:
|
||||
- "**/server/**"
|
||||
- "**/pipecat/**"
|
||||
@@ -46,11 +51,11 @@ territory:
|
||||
```yaml
|
||||
---
|
||||
name: frontend-engineer
|
||||
active: true
|
||||
phase_specific: false
|
||||
reason: Owns the React + WebRTC client via Pipecat client SDK — audio capture/playback, interruptibility UI, session display, debrief rendering. Voice-first UI constraints differ from typical web frontend.
|
||||
active: false
|
||||
phase_specific: true
|
||||
reason: DEACTIVATED for v0.2. The v0.2 client work is a single `npm run build` step in the Dockerfile's Node stage (REQ-DEPLOY-01) — no client-side code changes, no new components, no UI work. The client/dist is built and served as static files. Reactivating would add a persona with no territory to own. The lead-developer owns the Dockerfile Node stage (the only client-touching artifact in v0.2). Will reactivate in v0.3+ when client features return.
|
||||
domain: frontend
|
||||
frameworks: [react, pipecat-client-sdk, webrtc]
|
||||
frameworks: [react, pipecat-client-sdk, webrtc, vite]
|
||||
constraints: [component-first, voice-first-ui, minimal-client-javascript, webRTC-audio-pipeline]
|
||||
territory:
|
||||
- "**/client/**"
|
||||
@@ -65,10 +70,10 @@ territory:
|
||||
name: data-engineer
|
||||
active: true
|
||||
phase_specific: false
|
||||
reason: Owns SQLite schema (praxis.db), session-log migrations, scenario YAML→Pydantic schema definitions, and learner-state access layer. v0.1 data surface is small but schema-first discipline is still required.
|
||||
reason: Owns the SQLite volume mount in docker-compose.yml (REQ-DEPLOY-02) and the PRAXIS_DB_PATH env var wiring so the server writes praxis.db to the Docker volume (/app/data/praxis.db) rather than a container-local path. Small surface but critical for data persistence across container restarts. Also owns the db/migrations and db/schema.sql if any v0.2 schema changes are needed (none expected — v0.2 is infra-only).
|
||||
domain: data
|
||||
frameworks: [sqlite, pydantic, pydantic-ai]
|
||||
constraints: [schema-first, type-safe, migration-driven, single-learner-no-auth]
|
||||
frameworks: [sqlite, pydantic, aiosqlite, docker-volumes]
|
||||
constraints: [schema-first, type-safe, migration-driven, single-learner-no-auth, volume-persistence]
|
||||
territory:
|
||||
- "**/migrations/**"
|
||||
- "**/schema/**"
|
||||
@@ -78,18 +83,42 @@ territory:
|
||||
---
|
||||
```
|
||||
|
||||
### Deactivated personas (0)
|
||||
```yaml
|
||||
---
|
||||
name: devops-engineer
|
||||
active: true
|
||||
phase_specific: true
|
||||
reason: NEW persona for v0.2. Owns the entire scripts/proxmox/ deployment toolkit (10 scripts adapted from coreci) + scripts/install-service.sh + the praxis.service systemd unit + the .env.example deployment vars + the bats test suite. This is the largest territory in v0.2 (~12 scripts + systemd unit + tests). Created as a phase-specific persona because v0.2 is deploy-infra-heavy and none of the existing personas cover shell/Proxmox/systemd territory. Will be deactivated in v0.3 (mastery scoring — no deploy scripts) unless deploy hardening work continues.
|
||||
domain: devops
|
||||
frameworks: [proxmox-ve-api, lxc, docker, systemd, bash, bats, gitea]
|
||||
constraints: [reuse-coreci-verbatim-where-possible, idempotent-deploy, rollback-on-failure, secrets-never-committed, posix-sh-compatible]
|
||||
territory:
|
||||
- "scripts/proxmox/**"
|
||||
- "scripts/install-service.sh"
|
||||
- "scripts/proxmox/praxis.service"
|
||||
- "scripts/proxmox/test/**"
|
||||
- ".env.example"
|
||||
---
|
||||
```
|
||||
|
||||
No default personas are deactivated for v0.1. All four default personas have relevant territory.
|
||||
### Deactivated personas (1)
|
||||
|
||||
### Custom personas (proposed for later milestones — NOT v0.1)
|
||||
The **frontend-engineer** is deactivated for v0.2. Rationale:
|
||||
- v0.2 scope is infrastructure-only (D-021): Docker image, Proxmox LXC deploy, health-check, secret wiring.
|
||||
- The only client-touching artifact is the Dockerfile's Node stage: `COPY client/ && npm run build`. This is a 4-line build step, not frontend engineering.
|
||||
- No client-side code changes, no new components, no UI work, no React Router, no WebRTC pipeline changes.
|
||||
- Reactivating frontend-engineer would add a persona with no meaningful territory to own (the lead-developer owns the Dockerfile, which includes the Node stage).
|
||||
|
||||
The frontend-engineer will reactivate in v0.3+ when client features return (mastery dashboard, multi-scenario UI, etc.).
|
||||
|
||||
### Custom personas (proposed for later milestones — NOT v0.2)
|
||||
|
||||
```yaml
|
||||
---
|
||||
name: voice-engineer
|
||||
active: false
|
||||
phase_specific: false
|
||||
reason: PROPOSED for v0.2+ when latency tuning, accent modeling, and multi-voice personas become central. v0.1 uses Pipecat's built-in voice pipeline (Silero VAD + Deepgram + Cartesia/Piper), so a dedicated voice-engineer is not warranted yet.
|
||||
reason: PROPOSED for v0.3+ when latency tuning, accent modeling, and multi-voice personas become central. v0.1/v0.2 use Pipecat's built-in voice pipeline (Silero VAD + Deepgram + Cartesia/Piper), so a dedicated voice-engineer is not warranted yet.
|
||||
domain: voice
|
||||
frameworks: [webrtc, silero-vad, audio-codecs]
|
||||
constraints: [sub-600ms-latency, accent-robustness, audio-quality-vs-latency-tradeoff]
|
||||
@@ -102,7 +131,7 @@ territory: []
|
||||
name: ml-engineer
|
||||
active: false
|
||||
phase_specific: false
|
||||
reason: PROPOSED for v0.3+ when fine-tuning Ollama models on Canadian English / role-play data becomes relevant. v0.1 uses off-the-shelf cloud models — no ML training in scope.
|
||||
reason: PROPOSED for v0.4+ when fine-tuning Ollama models on Canadian English / role-play data becomes relevant. v0.1/v0.2 use off-the-shelf cloud models — no ML training in scope.
|
||||
domain: ml
|
||||
frameworks: [ollama, pytorch, axolotl]
|
||||
constraints: [open-weights, cost-bounded-fine-tuning]
|
||||
@@ -110,38 +139,59 @@ territory: []
|
||||
---
|
||||
```
|
||||
|
||||
## Framework Alignment (overrides from config.json defaults)
|
||||
## Framework Alignment (v0.2 overrides)
|
||||
|
||||
The default config.json personas had empty `frameworks[]`. Research identified the actual v0.1 stack, so frameworks are now populated above:
|
||||
The v0.2 milestone adds deployment frameworks to the persona skill sets:
|
||||
|
||||
| Persona | Frameworks (research-aligned) |
|
||||
|---------|-------------------------------|
|
||||
| lead-developer | pipecat, react |
|
||||
| backend-engineer | pipecat, pydantic, ollama, deepgram, cartesia, piper, sqlite |
|
||||
| frontend-engineer | react, pipecat-client-sdk, webrtc |
|
||||
| data-engineer | sqlite, pydantic, pydantic-ai |
|
||||
| Persona | Frameworks (v0.2 research-aligned) |
|
||||
|---------|-------------------------------------|
|
||||
| lead-developer | pipecat, react, **docker**, **proxmox-lxc** |
|
||||
| backend-engineer | pipecat, pydantic, **fastapi**, **uvicorn**, **docker** |
|
||||
| frontend-engineer | react, pipecat-client-sdk, webrtc, vite (DEACTIVATED) |
|
||||
| data-engineer | sqlite, pydantic, aiosqlite, **docker-volumes** |
|
||||
| devops-engineer | **proxmox-ve-api**, **lxc**, **docker**, **systemd**, **bash**, **bats**, **gitea** |
|
||||
|
||||
## Territory Alignment
|
||||
|
||||
Default config.json territory globs were generic (`**/server/**`, `**/client/**`, etc.). Research refined them to match the v0.1 Pipecat-based architecture — see `territory:` fields above. Notable additions:
|
||||
- backend-engineer now owns `**/pipecat/**`, `**/scenarios/**`, `**/guardrails/**`, `**/llm/**`, `**/asr/**`, `**/tts/**` (voice-loop service boundaries)
|
||||
- data-engineer now owns `**/scenarios/*.yaml` (scenario schema authorship)
|
||||
v0.2 introduces a new territory category: `scripts/proxmox/**` and deployment artifacts. The devops-engineer owns this exclusively. Key territory boundaries:
|
||||
|
||||
- **Dockerfile** → lead-developer (spans client + server stages; no single persona owns both)
|
||||
- **docker-compose.yml** → lead-developer (spans server service + data volume; collaborates with backend + data)
|
||||
- **server/__main__.py** (StaticFiles mount) → backend-engineer
|
||||
- **scripts/proxmox/** → devops-engineer (exclusive)
|
||||
- **scripts/install-service.sh** → devops-engineer
|
||||
- **praxis.service** (systemd unit) → devops-engineer (with backend-engineer consultation on ExecStart)
|
||||
- **db/ volume mount in docker-compose.yml** → data-engineer (with lead-developer on the compose file)
|
||||
- **.env.example** → devops-engineer (documents PROXMOX_* + PRAXIS_* deployment vars)
|
||||
- **client/** → frontend-engineer (DEACTIVATED — no changes in v0.2)
|
||||
|
||||
## Constraint Alignment
|
||||
|
||||
Default config.json constraints were generic. Research added project-specific constraints:
|
||||
- All personas: `latency-budget-aware (<600ms)` — the binding v0.1 NFR
|
||||
- backend-engineer: `streaming-first`, `pluggable-interfaces-for-swap` (D-014/D-019/D-020 require swappable TTS/LLM/guardrail layers)
|
||||
- frontend-engineer: `voice-first-ui`, `webRTC-audio-pipeline`, `minimal-client-javascript`
|
||||
- data-engineer: `single-learner-no-auth` (D-007)
|
||||
v0.2 adds project-specific constraints:
|
||||
|
||||
- **All personas:** `reuse-coreci-toolkit` — the coreci proxmox scripts are battle-tested; adapt, don't rewrite.
|
||||
- **lead-developer:** `reuse-coreci-verbatim-where-possible` — api.sh, lxc-start.sh, ct-exists.sh are verbatim (REQ-DEPLOY-03/08).
|
||||
- **backend-engineer:** `routes-before-static-mount` — API routes (/health, /pipecat/webrtc) MUST be registered before the StaticFiles mount at `/` (D-023, RESEARCH.md Q3).
|
||||
- **data-engineer:** `volume-persistence` — SQLite must write to a Docker volume, not the container's writable layer (REQ-DEPLOY-02).
|
||||
- **devops-engineer:** `idempotent-deploy`, `rollback-on-failure`, `secrets-never-committed`, `posix-sh-compatible` — coreci's deploy NFRs (REQ-NFR-DEPLOY-01/02/04) + the scripts use `#!/bin/sh` (POSIX, not bash-specific).
|
||||
|
||||
## Phase-Specific Personas
|
||||
|
||||
None for v0.1. No personas are created for a specific phase and removed after — the four active personas span the whole milestone. The proposed `voice-engineer` and `ml-engineer` are for later milestones, not phase-specific.
|
||||
Two personas are **phase-specific** for v0.2:
|
||||
|
||||
## Notes for EXECUTE stage
|
||||
1. **devops-engineer** — `phase_specific: true`. Created for v0.2 (deploy-infra-heavy). Will be deactivated in v0.3 (mastery scoring — no new deploy scripts) unless deploy hardening/proxy/TLS work continues. This is the largest territory in v0.2.
|
||||
|
||||
2. **frontend-engineer** — `phase_specific: true` (deactivated). The frontend-engineer is normally active but is deactivated specifically for v0.2 because the milestone has no client-side work. This is a phase-specific deactivation, not a permanent removal.
|
||||
|
||||
## Notes for PLAN/EXECUTE stage
|
||||
|
||||
- Territory enforcement mode: `warn` (per config.json `personas.territory_enforcement`)
|
||||
- The backend-engineer owns the majority of v0.1 task surface (Pipecat server + all service integrations)
|
||||
- The frontend-engineer's surface is smaller but has the R2/R4 latency risk (WebRTC audio pipeline + TTS playback)
|
||||
- The data-engineer's surface is the smallest (one SQLite schema + one YAML scenario) but is on the critical path (scenario definition blocks scenario runtime)
|
||||
- The **devops-engineer owns the majority of v0.2 task surface** (~12 scripts + systemd unit + tests). This is the inverse of v0.1 where backend-engineer owned the majority.
|
||||
- The **backend-engineer's v0.2 surface is small but critical**: the StaticFiles mount in server/__main__.py must not break existing routes. This is a ~5-line change with high blast radius.
|
||||
- The **data-engineer's v0.2 surface is the smallest**: one volume mount line in docker-compose.yml + one env var (PRAXIS_DB_PATH). But it's on the critical path (data persistence).
|
||||
- The **lead-developer** owns the Dockerfile and docker-compose.yml because these span multiple persona territories (client + server + data). This prevents territory disputes.
|
||||
- Cross-persona collaboration points:
|
||||
- devops-engineer (praxis.service) ↔ backend-engineer (ExecStart command)
|
||||
- data-engineer (volume in compose) ↔ lead-developer (compose file owner)
|
||||
- devops-engineer (install-service.sh env file) ↔ backend-engineer (server env var consumption)
|
||||
- The config.json `personas` array does NOT include the devops-engineer — it will need to be added to config.json at PLAN/EXECUTE time, OR the devops-engineer is an emergent persona defined only in PERSONAS.md. The territory enforcement (warn mode) will pick up the territory globs from PERSONAS.md regardless of config.json.
|
||||
+964
-256
File diff suppressed because it is too large
Load Diff
+27
-18
@@ -1,7 +1,7 @@
|
||||
# Praxis — Voice-first AI Apprenticeship Platform
|
||||
|
||||
**Milestone:** v0.1 (foundation)
|
||||
**Status:** complete
|
||||
**Milestone:** v0.2 (Proxmox LXC deployment)
|
||||
**Status:** in-progress
|
||||
**Autonomy:** full
|
||||
|
||||
## Vision
|
||||
@@ -14,25 +14,24 @@ Praxis is a voice-first, AI-tutored skill platform for learners in resource-cons
|
||||
|
||||
Build a voice-first AI apprenticeship platform where learners engage in spoken role-play scenarios with AI tutors, receive coaching debriefs, and progress via mastery gates — working on low-cost phones over constrained bandwidth.
|
||||
|
||||
## v0.1 Scope (Foundation)
|
||||
## v0.2 Scope (Proxmox LXC Deployment)
|
||||
|
||||
v0.1 establishes the minimal viable voice loop on which all later capabilities build. v1.0 is reserved for a working, tested product; v0.1 is the foundation milestone.
|
||||
v0.2 deploys praxis into a Proxmox LXC container, reusing and adapting the battle-tested deployment toolkit from `~/coreci/scripts/proxmox/`. The v0.1 voice loop becomes deployable infrastructure — a Docker image runs the Python/Pipecat server (serving the React client as static files) inside an LXC container on the operator's Proxmox cluster.
|
||||
|
||||
**v0.1 in scope:**
|
||||
- Phase 0: pre-execution (specify, clarify, research, plan, grill)
|
||||
- Phase 1: minimal viable voice loop — one persona, one branching scenario, ASR + TTS round-trip (<600ms target), single learner state, Ollama-hosted LLM foundation
|
||||
**v0.2 in scope:**
|
||||
- Docker image (multi-stage: Node builds `client/dist`, Python runs `server` + serves dist via FastAPI StaticFiles)
|
||||
- `scripts/proxmox/` adapted from coreci (api.sh, lxc-deploy, lxc-clone, lxc-config, lxc-start, health-check, rollback, stage-snippet, firstboot-hook, timing)
|
||||
- `scripts/install-service.sh` (systemd unit for `docker compose up`)
|
||||
- Secret wiring: PROXMOX_* sourced from coreci's `.env.secrets`; GITEA_TOKEN + DEEPGRAM_API_KEY from praxis's secrets
|
||||
- Health-check adapted for `/health` :8789 (praxis's endpoint, not coreci's `/healthz` :18080)
|
||||
- E2E deploy verification against the live Proxmox cluster
|
||||
|
||||
**v0.1 out of scope (deferred to later milestones):**
|
||||
- Mastery scoring, competency rubrics, verifiable credentials
|
||||
- Multi-language support (launch: Canadian English; French-Canadian noted for later)
|
||||
- Employer / program dashboard
|
||||
- Live Assist on-the-job companion mode
|
||||
- WhatsApp / SMS bot, USSD fallback
|
||||
- Drill Mode, Review Mode
|
||||
- Open scenario authoring marketplace
|
||||
- B2B SaaS
|
||||
- Voice cloning of real individuals
|
||||
- Early childhood education, medical procedures (permanently out of scope per PRD §11.6)
|
||||
**v0.2 out of scope (deferred):**
|
||||
- Mastery scoring, competency rubrics (deferred to v0.3)
|
||||
- CARTESIA_API_KEY / OLLAMA_API_KEY provisioning (infrastructure-only; server degrades gracefully per v0.1 design)
|
||||
- Traefik proxy / public TLS (pilot = direct bridge IP access)
|
||||
- Multi-environment (dev/staging/prod) — single pilot CT
|
||||
- vmbr1 private network (pilot uses vmbr0 DHCP)
|
||||
|
||||
## Product Principles (non-negotiable)
|
||||
|
||||
@@ -88,6 +87,16 @@ v0.1 establishes the minimal viable voice loop on which all later capabilities b
|
||||
| D-018 | Scenario format = **YAML DSL → Pydantic → Pipecat Flows** | Research-verified: YAML is human-authorable + diffable + supports comments (critical for learning-designer rationale per C-7); Pydantic gives typed runtime; Pipecat Flows consumes the schema for branching. JSON is wire format only. | 0.85 | JSON DSL (no comments), code-authored (couples authoring to engineering) |
|
||||
| D-019 | v0.1 guardrail layer = **pluggable interface** with Customer Service ruleset implementation | Research: v0.1 is low-risk (Customer Service) but architecture must support pluggable guardrails for later high-risk domains (health/electrical). Ruleset: no legal/financial/medical advice, no real-company employee impersonation, stay-in-role, session-start disclaimer audio, no PII beyond hardcoded profile. | 0.80 | No guardrails (violates C-6), hardcoded non-pluggable rules (blocks future domains) |
|
||||
| D-020 | LLM access = **Ollama Cloud direct API** (`https://ollama.com/api/chat` + `OLLAMA_API_KEY`) — no local daemon | Research-verified: `:cloud` tags are real Ollama hosted-inference on NVIDIA cloud partners. Direct API eliminates local-daemon deployment dependency. `gemma4:cloud` (256K ctx) → role-play fast path; `deepseek-v4-flash:cloud` (1M ctx, no-think mode) → debrief. Self-host `gemma4:e4b` is the post-pilot cost-reduction path. | 0.85 | Local Ollama daemon proxy mode (adds deployment dependency) |
|
||||
| D-021 | v0.2 scope = **Proxmox LXC deployment** (replaces roadmap's mastery-scoring v0.2) | User-directed: deploy praxis into an LXC container hosted on Proxmox, reusing `~/coreci/scripts/proxmox/` methods. Mastery scoring deferred to v0.3. | 0.95 | v0.2 = mastery scoring (original roadmap), v0.2 = LXC deploy + mastery (too large) |
|
||||
| D-022 | Artifact = **Docker image in LXC** (nesting=1) | User-directed. Isolates Python/Pipecat deps; coreci's clone script already sets `features=nesting=1`. Avoids venv/pip first-boot fragility (Pipecat has many native deps). Multi-stage build: Node stage produces `client/dist`, Python stage runs the server. | 0.85 | Clone repo + venv + pip (fragile first-boot), sdist tarball (needs build/release step) |
|
||||
| D-023 | Client serving = **FastAPI serves `client/dist` as StaticFiles** | User-directed. Single port (8789), simplest pilot — no nginx/caddy. The Docker image bundles the pre-built dist. | 0.90 | Separate static server (nginx/caddy — more moving parts), client out of scope |
|
||||
| D-024 | Voice-service keys = **infrastructure-only** for v0.2 | User-directed. Server starts and `/health` passes even without CARTESIA/OLLAMA keys (v0.1 graceful degradation). Keys provisioned in a later milestone. Only GITEA_TOKEN + DEEPGRAM_API_KEY are in `.env.secrets`. | 0.90 | Provision all keys in v0.2 (premature — deploy infra first) |
|
||||
| D-025 | Image distribution = **host-build → `pct push` tarball** (research decision, see RESEARCH.md) | The LXC CT may not route to the internet (coreci pattern: host-fetch → pct push). Build the Docker image on the PVE host (Docker available on Proxmox host) and `docker save | pct exec -- docker load`, or `pct push` a tarball. Avoids needing a container registry. | 0.75 | Gitea container registry (requires registry setup), Docker Hub (external dependency) |
|
||||
| D-026 | Proxmox secrets sourced from **`~/coreci/.ciagent/.env.secrets`** | Same Proxmox cluster, same operator. PROXMOX_API_URL/TOKEN/NODE/STORAGE/TEMPLATE_VOLID already provisioned there. Praxis's `.env.secrets` adds GITEA_TOKEN + DEEPGRAM_API_KEY. The deploy script sources both. | 0.90 | Duplicate proxmox secrets in praxis (drift risk) |
|
||||
| D-027 | VMID = **`auto`** (fresh allocation via `pve_nextid`) | CLARIFY auto-decide (full autonomy). Don't reuse coreci's fixed PROXMOX_LXC_VMID — praxis gets its own CT on the same cluster. | 0.95 | Reuse coreci's VMID (collision), hardcode a new fixed VMID (manual allocation) |
|
||||
| D-028 | Docker installed **inside the CT** via apt (CT has network via vmbr0 DHCP) | CLARIFY auto-decide. Avoids needing Docker on the PVE host. The debian-12 template + nesting=1 supports Docker-in-LXC. firstboot hook runs `pct exec` to install `docker.io` + `docker-compose-v2`. | 0.90 | Docker on PVE host (extra host dependency), pre-baked template (custom template maintenance) |
|
||||
| D-029 | Image built **inside the CT** (clone repo from Gitea, `docker build`, `docker compose up`) | CLARIFY auto-decide. Self-contained — CT fetches its own source + builds. No image transfer needed. Slower first-boot (~3-5 min for build) but simpler and reproducible. | 0.80 | Build on PVE host + pct push tarball (host Docker dependency), pre-built image from registry (external dependency) |
|
||||
| D-030 | CT network = **vmbr0 DHCP only** (pilot, no vmbr1, no Traefik proxy) | CLARIFY auto-decide. v0.2 is infrastructure-only pilot. Direct bridge IP access for health-check. Proxy/TLS deferred to a later milestone. | 0.90 | vmbr1 + Traefik proxy (over-scoped for pilot) |
|
||||
|
||||
### Confidence updates from research
|
||||
|
||||
|
||||
@@ -1,9 +1,9 @@
|
||||
# Praxis — Requirements
|
||||
|
||||
**Milestone:** v0.1 (foundation)
|
||||
**Status:** complete
|
||||
**Milestone:** v0.2 (Proxmox LXC deployment)
|
||||
**Status:** in-progress
|
||||
|
||||
Formal requirements with REQ-IDs. Scoped to v0.1 unless noted. Later-milestone requirements are marked `deferred`.
|
||||
Formal requirements with REQ-IDs. Scoped to the active milestone unless noted. Later-milestone requirements are marked `deferred`. v0.1 requirements (complete) are retained for reference.
|
||||
|
||||
## Functional Requirements
|
||||
|
||||
@@ -121,6 +121,36 @@ Formal requirements with REQ-IDs. Scoped to v0.1 unless noted. Later-milestone r
|
||||
- C-7 Scenarios authored by domain experts + learning designers; AI generates variations only
|
||||
- C-8 Latency budget < 600ms end-to-end
|
||||
|
||||
## Deployment (v0.2 — Proxmox LXC)
|
||||
|
||||
| REQ-ID | Requirement | Priority | Phase | Status |
|
||||
|--------|-------------|----------|-------|--------|
|
||||
| REQ-DEPLOY-01 | Multi-stage Dockerfile: Node stage builds `client/dist` via `npm run build`, Python stage runs the Pipecat server and serves `client/dist` via FastAPI StaticFiles (D-022, D-023) | must | P1 | pending |
|
||||
| REQ-DEPLOY-02 | `docker-compose.yml` defining the praxis service with volume for SQLite DB (`praxis.db`), env injection, port mapping (8789), restart policy | must | P1 | pending |
|
||||
| REQ-DEPLOY-03 | Port `scripts/proxmox/api.sh` from coreci verbatim (PVE REST helpers: pve_curl, pve_poll, pve_nextid, pve_get, pve_env, pve_lxc_env_args) | must | P1 | pending |
|
||||
| REQ-DEPLOY-04 | Port `scripts/proxmox/lxc-clone.sh` adapted for praxis (hostname=praxis, port 8789, features=nesting=1 for Docker-in-LXC) | must | P1 | pending |
|
||||
| REQ-DEPLOY-05 | Port `scripts/proxmox/lxc-config.sh` adapted: hookscript snippet, lxc.environment injects GITEA_TOKEN + DEEPGRAM_API_KEY + voice-service env vars (empty if unprovisioned), PRAXIS_PORT=8789 | must | P1 | pending |
|
||||
| REQ-DEPLOY-06 | Port `scripts/proxmox/firstboot-hook.sh` adapted: host-builds Docker image (or loads pre-built), `pct exec` runs `docker compose up -d` inside the CT, health-checks `/health` :8789 | must | P1 | pending |
|
||||
| REQ-DEPLOY-07 | Port `scripts/proxmox/health-check.sh` adapted for praxis: polls `http://<bridge-ip>:8789/health` (not coreci's `/healthz` :18080) | must | P1 | pending |
|
||||
| REQ-DEPLOY-08 | Port `scripts/proxmox/{lxc-start,rollback,stage-snippet,timing}.sh` from coreci (adapted for praxis snippet name) | must | P1 | pending |
|
||||
| REQ-DEPLOY-09 | Port `scripts/proxmox/lxc-deploy.sh` orchestrator: clone → config → start → health-check → rollback-on-failure, with idempotency (--recreate/--reconfigure) | must | P1 | pending |
|
||||
| REQ-DEPLOY-10 | `scripts/install-service.sh` adapted: creates praxis user, data/log dirs, env file, systemd unit (`praxis.service`) that runs `docker compose up -d`, health-checks `/health` :8789 | must | P1 | pending |
|
||||
| REQ-DEPLOY-11 | `scripts/proxmox/praxis.service` systemd unit running `docker compose up -d` with `Restart=on-failure` | must | P1 | pending |
|
||||
| REQ-DEPLOY-12 | Secret wiring: extend `config.json` secrets.scopes with proxmox + voice scopes; source PROXMOX_* from `~/coreci/.ciagent/.env.secrets` | must | P1 | pending |
|
||||
| REQ-DEPLOY-13 | FastAPI `server/__main__.py` mounts `client/dist` as StaticFiles at `/` (serving the React client from the same port as the API) | must | P1 | pending |
|
||||
| REQ-DEPLOY-14 | `.env.example` updated with PROXMOX_* + deployment env vars (documented, not secret) | must | P1 | pending |
|
||||
| REQ-DEPLOY-15 | E2E deploy verification: `scripts/proxmox/test/` bats tests (mirroring coreci's test structure) + health-check + smoke against live CT | must | P1 | pending |
|
||||
| REQ-DEPLOY-16 | `.dockerignore` excluding `node_modules`, `.git`, `__pycache__`, `.pytest_cache`, `client/dist` (rebuilt in image), `.ciagent/.env*` (secrets) | must | P1 | pending |
|
||||
|
||||
## Non-Functional Requirements (v0.2)
|
||||
|
||||
| REQ-ID | Requirement | Target | Phase | Status |
|
||||
|--------|-------------|--------|-------|--------|
|
||||
| REQ-NFR-DEPLOY-01 | Deploy idempotency — re-running `lxc-deploy.sh` against a healthy CT is a no-op; unhealthy CT requires explicit `--recreate`/`--reconfigure` | must | P1 | pending |
|
||||
| REQ-NFR-DEPLOY-02 | Deploy rollback — any stage failure (clone/config/start/health) triggers `rollback.sh` (stop + destroy the partial CT) | must | P1 | pending |
|
||||
| REQ-NFR-DEPLOY-03 | First-boot install time | < 5 min (Docker image load + compose up + health) | P1 | pending |
|
||||
| REQ-NFR-DEPLOY-04 | Secrets never committed to git (`.ciagent/.env*` in `.gitignore`, secrets injected via `lxc.environment` at runtime) | must | P1 | pending |
|
||||
|
||||
## Out of Scope (v0.1)
|
||||
|
||||
- Mastery scoring, competency rubrics, verifiable credentials
|
||||
|
||||
+546
-328
@@ -1,431 +1,649 @@
|
||||
# Praxis — Research Findings (v0.1 Foundation)
|
||||
# Praxis — Research Findings (v0.2 Proxmox LXC Deployment)
|
||||
|
||||
> **Phase:** 0 (pre-execution / research)
|
||||
> **Branch:** `phase/00-pre-execution`
|
||||
> **Phase:** v0.2 research (Proxmox LXC deployment)
|
||||
> **Branch:** research/v0.2-proxmox-lxc-deploy
|
||||
> **Status:** research complete — pending orchestrator review
|
||||
> **Date:** 2026-08-01
|
||||
> **Method:** web-verified vendor catalogs, GitHub repo metadata, and official docs. Where a claim could not be verified online, it is marked with an explicit confidence score.
|
||||
> **Method:** Proxmox VE official wiki, coreci script source analysis (`/root/coreci/scripts/proxmox/`), praxis codebase inspection, Docker/systemd ecosystem knowledge. Web-verified where possible; domain-knowledge claims carry explicit confidence scores.
|
||||
|
||||
This document grounds the v0.1 architecture and Phase 1 plan in ecosystem evidence. It addresses the 10 research scope items and concludes with an architecture diff and a risks/unknowns list for the PLAN stage.
|
||||
This document grounds the v0.2 deployment architecture in ecosystem evidence. It addresses the 10 research questions and concludes with an architecture diff and risks/unknowns list for the PLAN stage.
|
||||
|
||||
---
|
||||
|
||||
## Summary of Findings (Executive 1-Pager)
|
||||
|
||||
1. **D-003 VERIFIED — both Ollama model IDs are real and current.** `gemma4:cloud` and `deepseek-v4-flash:cloud` both exist in the Ollama catalog as official cloud-hosted tags. `:cloud` is a real Ollama concept: Ollama-hosted inference on NVIDIA cloud partners (US/Europe/Singapore), callable via a local `ollama run` proxy OR directly at `https://ollama.com/api/chat` with an `OLLAMA_API_KEY`. This is the highest-confidence finding and unblocks the LLM foundation. Raise D-003 confidence from 0.75 → 0.95.
|
||||
1. **Docker-in-LXC is well-supported on Proxmox 8 with `nesting=1`.** The Proxmox wiki explicitly documents `nesting` as the feature that "exposes procfs and sysfs to allow nested containers" and notes "systemd also uses this to isolate services." Debian 12 standard template + `docker.io` apt package works out of the box. overlay2 storage driver functions inside LXC with nesting enabled. cgroups v2 (Debian 12 default) is supported by Docker 20.10+. The main gotcha is iptables — Docker manages NAT rules in the CT's network namespace, which works because `net0=bridge=vmbr0,ip=dhcp` gives the CT its own netns. No `keyctl` or AppArmor adjustments needed for the standard unprivileged+nesting path on Proxmox 8. (Confidence: 0.85)
|
||||
|
||||
2. **Recommended ASR: Deepgram Nova-3 streaming (cloud).** Streaming-native, ~300ms partial-transcript latency (sub-200ms for first partial with endpointing), best-in-class accuracy on accented English, Canada data-residency available, pay-as-you-go. Fallback/alternative: Groq-hosted Whisper (lower cost, higher latency) or whisper.cpp self-hosted (zero cost, but breaks the <600ms budget on CPU).
|
||||
2. **Build-inside-CT needs a resource bump.** The coreci default (2GB memory, 8GB rootfs) is too tight for `docker build` with Pipecat's native-extension deps (numpy, aiohttp, pipecat-ai[webrtc]). Recommend **4GB memory, 16GB rootfs**. `docker-compose-v2` is available in Debian 12 Bookworm repos as an apt package. (Confidence: 0.80)
|
||||
|
||||
3. **Recommended TTS: Cartesia Sonic (cloud) primary, Piper (self-hosted) as open-weights fallback.** Cartesia Sonic is #1 on the Artificial Analysis Speech Arena leaderboard, purpose-built for voice agents with state-space-model architecture, ~120ms first-audio, streaming-native. Piper1-gpl is the open-weights self-hosted fallback for the post-pilot ≤$3/learner target. ElevenLabs is the quality benchmark but higher latency/cost.
|
||||
3. **FastAPI StaticFiles with `html=True` is the correct pattern — no SPA fallback needed.** The praxis client uses a single-view state machine (start → live → debrief) with NO React Router. `app.mount("/", StaticFiles(directory="client/dist", html=True))` serves index.html at `/` and static assets at their paths. API routes (`/health`, `/pipecat/webrtc`) registered BEFORE the mount take precedence. (Confidence: 0.95)
|
||||
|
||||
4. **Recommended client framework: Web (React + WebRTC) via Pipecat's official client SDK.** Pipecat ships React/React Native/Swift/Kotlin/C++ client SDKs and WebSocket + WebRTC transports. A React + WebRTC web client is the fastest v0.1 iteration path, needs no app-store distribution, and upgrades trivially to React Native for later Android targets. A Python CLI harness is a viable secondary dev-integration test path but not the v0.1 deliverable.
|
||||
4. **Multi-stage Dockerfile: Node 22-slim → Python 3.12-slim, run via `python -m server`.** Node stage builds `client/dist` with cached `npm ci`. Python stage installs deps from `pyproject.toml`, copies `client/dist` from the Node stage, copies `server/` + `scenarios/` + `db/`. Final CMD: `python -m server` (matches existing entrypoint, calls uvicorn internally with HOST/PORT env). Debian-based slim (not Alpine) avoids musl+native-ext pain. (Confidence: 0.90)
|
||||
|
||||
5. **Recommended streaming transport: WebRTC** for bidirectional audio + control; **WebSocket** as the fallback for token-streaming-only dev mode. WebRTC gives sub-50ms audio transport with UDP, adaptive bitrate, and is the transport Pipecat's production examples use. SSE/raw HTTP are rejected (unidirectional or too high overhead).
|
||||
5. **firstboot-hook: install Docker → clone repo → build + compose up.** The hook runs on the PVE host (post-start phase) and uses `pct exec` to run commands inside the CT. Sequence: (a) `pct exec` apt-install docker.io + docker-compose-v2, (b) `pct exec` git clone from Gitea using GITEA_TOKEN, (c) `pct exec` docker build + docker compose up, (d) external health-check.sh polls /health:8789. Clone-inside-CT (not host-clone+pct-push) matches D-029's self-contained rationale. (Confidence: 0.85)
|
||||
|
||||
6. **D-007 CONFIRMED: SQLite is the correct v0.1 learner state store.** Single-learner, no auth, no concurrency, schema needs (session log, progress, scenario state) fit SQLite trivially. No evidence favors DuckDB/LiteDB/JSON for this scale. Raise D-007 confidence from 0.80 → 0.90.
|
||||
6. **Secret injection chain: lxc.environment → /etc/praxis/server.env → docker-compose env_file → container.** Validated. `lxc-config.sh` SSH step writes `lxc.environment: KEY=VAL` lines to `/etc/pve/lxc/<vmid>.conf`. CT boots → systemd has these env vars. `install-service.sh` reads them and writes `/etc/praxis/server.env`. `docker-compose.yml` references `env_file: /etc/praxis/server.env`. praxis `.gitignore` covers `.env`, `.env.secrets`, `.env.*` — secrets are gitignored. ✅ (Confidence: 0.90)
|
||||
|
||||
7. **Recommended scenario format: YAML DSL** authored by domain experts (C-7), loaded into a typed Python schema (Pydantic). YAML is human-authorable, diffable in git, supports comments (critical for learning-designer rationale), and parses to the branching model. JSON is the runtime wire format. Code-authored is rejected for v0.1 (couples authoring to engineering).
|
||||
7. **Health-check: bump timeout to 300s for Docker build inside CT.** Coreci's `health-check.sh` queries PVE `/interfaces` for the bridge IP — works for vmbr0 DHCP CTs. The `/health:8789` endpoint (not `/healthz:18080`) is the praxis target. Docker build + compose up may take 3-5 min; the default 180s timeout is insufficient. Use `PRAXIS_HEALTH_TIMEOUT=300`. (Confidence: 0.90)
|
||||
|
||||
8. **Prior art scan:** Second Nature (closest analog — AI role-play sales/support training with coaching debriefs, used by Oracle/Zoom/GoHealth, reduces ramp time 34%), Speak (language learning, voice-first consumer), Cartesia/Retell/Vapi (voice-agent infra, not learning), Duolingo voice features (limited). Key lesson: Second Nature validates the Praxis thesis (role-play + coaching works) but is B2B/enterprise/desktop — Praxis's wedge is mobile-first, voice-primary, low-bandwidth, B2C-apprentice.
|
||||
8. **Systemd unit: `Type=simple` with `docker compose up` (foreground, no -d).** `docker compose up -d` is fire-and-forget → `Type=oneshot` loses container lifecycle tracking. The correct systemd+Docker pattern: `ExecStart=docker compose up` (foreground, streams logs), `ExecStop=docker compose down`, `Restart=on-failure`. systemd tracks the compose process; compose's `restart: unless-stopped` policy is a second layer. (Confidence: 0.85)
|
||||
|
||||
9. **Recommended orchestration: Pipecat.** 13.8k stars, actively maintained (11k+ commits), Python, integrates Deepgram + Cartesia/Piper + Ollama natively, has VAD, interruptibility, "Pipecat Flows" for structured branching conversations, and client SDKs for all target platforms. Vocode is stale (last updated Nov 2024). Custom orchestration is rejected for v0.1 (rebuilds solved problems).
|
||||
9. **CT resource sizing: 4GB memory, 16GB rootfs.** Docker engine (~300MB) + build layers + final image (~1-1.5GB) + apt cache + repo clone. 8GB rootfs is tight; 16GB gives headroom. Build happens on rootfs (not tmpfs — tmpfs would consume already-tight memory). (Confidence: 0.80)
|
||||
|
||||
10. **Safety baseline (v0.1 Customer Service):** Minimal but present. (a) System-prompt guardrails (no legal/financial/medical advice, no impersonation of a real company employee, stay in scenario role), (b) output filter on debrief text, (c) session-start disclaimer audio ("This is an AI practice session"), (d) no PII collection beyond a hardcoded learner profile. The architecture must support a pluggable guardrail layer for later high-risk domains (health/electrical).
|
||||
10. **Testing strategy: mirror coreci's bats structure.** Unit-testable (mocked API, no live Proxmox): api.sh helpers, lxc-clone.sh, lxc-config.sh, lxc-start.sh, health-check.sh, rollback.sh, timing.sh. E2E (live cluster): lxc-deploy.sh full sequence, idempotency, health against live CT. Praxis ports the bats tests with adapted assertions (hostname=praxis, port=8789, /health endpoint). (Confidence: 0.90)
|
||||
|
||||
---
|
||||
|
||||
## Ollama Catalog Verification (D-003)
|
||||
## Q1: Docker-in-LXC on Proxmox (2025-2026 Best Practice)
|
||||
|
||||
**Source:** Ollama official library (https://ollama.com/library/gemma4, https://ollama.com/library/deepseek-v4-flash), Ollama Cloud docs (https://docs.ollama.com/cloud), Ollama pricing (https://ollama.com/pricing). Verified 2026-08-01.
|
||||
**Sources:** Proxmox VE wiki — Linux Container page (https://pve.proxmox.com/wiki/Linux_Container, fetched 2026-08-01), coreci `lxc-clone.sh` (sets `features=nesting=1`), Docker documentation (cgroups v2 support, overlay2 driver).
|
||||
|
||||
### Finding: Both exact model IDs exist and are current
|
||||
### Finding: nesting=1 is sufficient; Debian 12 + docker.io works
|
||||
|
||||
| Model ID (as specified in D-003) | Exists? | Status | Context Window | Modalities | Tag details |
|
||||
|---|---|---|---|---|---|
|
||||
| `gemma4:cloud` | ✅ YES | Current (updated ~1 month ago) | 256K | Text, Image | "Low Usage" tier — cloud-hosted, Ollama-managed |
|
||||
| `deepseek-v4-flash:cloud` | ✅ YES | Current (updated 7 hours ago as of fetch) | 1M | Text | "Medium Usage" tier — cloud-hosted, Ollama-managed |
|
||||
The Proxmox wiki documents the `nesting` feature as: "expose procfs and sysfs to allow nested containers. Note that systemd also uses this to isolate services." This is the single required flag for Docker-in-LXC.
|
||||
|
||||
Additional verified tags available:
|
||||
- `gemma4`: also has `e2b`, `e4b` (edge, with **native audio modality** — CoVoST/FLEURS benchmarks present), `12b`, `26b` (MoE 4B active), `31b` (dense), `31b-cloud`.
|
||||
- `deepseek-v4-flash`: only `cloud` and `0731-cloud` tags (it is a cloud-only release — 284B MoE / 13B active, too large for self-host on pilot hardware).
|
||||
**What works out of the box:**
|
||||
- **overlay2 storage driver**: Docker detects it's running inside a container (LXC) and uses overlay2. With `nesting=1`, the kernel's overlay filesystem is accessible. No `fuse-overlayfs` needed (that's for rootless Docker only).
|
||||
- **cgroups v2**: Debian 12 Bookworm uses cgroups v2 by default. Proxmox VE 8 supports cgroups v2. Docker 20.10+ (and the `docker.io` package in Debian 12, which is Docker 24.x+) fully supports cgroups v2. The `nesting=1` feature ensures the CT has access to the cgroup hierarchy.
|
||||
- **iptables/NAT**: Docker creates NAT rules for container port mapping. This works in LXC because `net0=bridge=vmbr0,ip=dhcp` gives the CT its own network namespace where Docker can manage iptables without affecting the host.
|
||||
- **Bridge networking**: Docker's default bridge network inside the LXC works — containers get IPs on Docker's internal bridge, and port mapping (`ports: "8789:8789"`) forwards from the CT's eth0 to the Docker container.
|
||||
|
||||
### Is `:cloud` a real Ollama concept?
|
||||
**Known gotchas (none blocking for praxis v0.2):**
|
||||
1. **`keyctl` syscall**: Blocked in unprivileged LXC by default. Some Docker operations (registry auth with keyring) may warn. In practice, `docker build` + `docker compose up` without registry auth is unaffected. If `docker login` is needed later, `lxc.cap.drop` adjustment may be required. **Not a v0.2 concern** (no registry; build from local source).
|
||||
2. **AppArmor**: The unprivileged CT has an AppArmor profile. Docker-in-LXC sometimes hits AppArmor denials for specific mount operations. Proxmox 8's default profile handles the common cases. If issues arise, `lxc.apparmor.profile:unconfined` is the escape hatch (less secure, but functional). **Not expected for v0.2.**
|
||||
3. **Live migration**: Docker-in-LXC breaks Proxmox live migration (the Docker daemon state doesn't migrate cleanly). **Not a v0.2 concern** (single-node pilot, no HA).
|
||||
4. **Storage driver on ZFS**: If the PVE host uses ZFS for CT rootfs, Docker's overlay2 may have issues (ZFS CoW + overlay CoW conflict). The coreci `.env` shows `PROXMOX_STORAGE=local` which is typically directory/LVM-thin, not ZFS. **Verify at deploy time** but not expected to block.
|
||||
|
||||
**Yes.** Per Ollama Cloud docs: `:cloud` tags are models that "run without a powerful GPU" — they are "automatically offloaded to Ollama's cloud service." Ollama collaborates with NVIDIA Cloud Providers (NCPs), hosts primarily in the US with Europe/Singapore routing, and enforces no-logging/no-training/zero-data-retention. Two access modes:
|
||||
1. **Local proxy:** `ollama run gemma4:cloud` — local Ollama daemon forwards to cloud (requires `ollama signin`).
|
||||
2. **Direct API:** `https://ollama.com/api/chat` with `Authorization: Bearer $OLLAMA_API_KEY` — no local Ollama install needed. This is the mode v0.1 should use (server-side, no local daemon dependency).
|
||||
**Verdict:** `features=nesting=1` (already set by coreci's `lxc-clone.sh` line 46) is sufficient. `docker.io` from Debian 12 repos works. No additional LXC features or capabilities needed for the v0.2 pilot.
|
||||
|
||||
### Pricing implications (informs D-012 cost logging)
|
||||
**Confidence: 0.85** — well-established pattern in the Proxmox community; edge cases exist (ZFS, keyctl, AppArmor) but none apply to the v0.2 pilot configuration.
|
||||
|
||||
Ollama uses a usage-tier model (small/light = level 1 → extra heavy = level 4), not per-token pricing, on Free/Pro($20)/Max($100) plans. `gemma4:cloud` = "Low Usage"; `deepseek-v4-flash:cloud` = "Medium Usage". For a v0.1 Canada pilot (low volume, no enforced ceiling per D-012), a Pro plan likely covers development. **Risk:** usage-tier pricing is not unit-economics-friendly at scale; post-pilot, self-hosting `gemma4:e4b` (edge, audio-capable, 9.6GB) on partner hardware becomes the ≤$3/learner path. Architecture must keep the model-call layer swappable.
|
||||
|
||||
### Native audio modality discovery (notable)
|
||||
|
||||
`gemma4:e2b` and `gemma4:e4b` support **Text, Image, Audio** input (audio encoder ~300M params; CoVoST 35.54, FLEURS 0.08). This means a future architecture could use gemma4 edge models for Ollama-hosted ASR — but for v0.1, dedicated ASR (Deepgram) is lower-latency and more accent-robust. Log this as a future-cost-reduction option.
|
||||
|
||||
### Recommendation
|
||||
|
||||
- **Adopt `gemma4:cloud` and `deepseek-v4-flash:cloud` exactly as specified in D-003.** No rename needed.
|
||||
- **Use direct API mode** (`https://ollama.com/api/chat` + `OLLAMA_API_KEY`) for v0.1 — eliminates the local-Ollama-daemon deployment dependency.
|
||||
- **Map roles:** `gemma4:cloud` (256K ctx, fast) → persona/role-play turns + fast path; `deepseek-v4-flash:cloud` (1M ctx, reasoning modes: no-think/think/max-think) → coaching debrief + scenario-branch decisions. Use **no-think mode** for debrief to keep latency down; reserve think/max-think for offline analysis.
|
||||
- **Confidence update:** D-003 0.75 → **0.95**.
|
||||
**Assumptions logged:**
|
||||
- PVE host is Proxmox VE 8.x (not 7.x) — coreci targets the same cluster, which is confirmed by the autoscaling `.env` showing a real node hostname.
|
||||
- CT rootfs storage is `local` (directory or LVM-thin), not ZFS — based on `PROXMOX_STORAGE=local` in coreci's env.
|
||||
|
||||
---
|
||||
|
||||
## ASR Recommendation
|
||||
## Q2: Image Build-Inside-CT vs Host-Build — Resource Validation
|
||||
|
||||
### Options compared
|
||||
**Sources:** praxis `pyproject.toml` (deps), praxis `client/package.json` (client deps), coreci `lxc-clone.sh` (default `rootfs=${storage}:8`, `memory=2048`).
|
||||
|
||||
| Option | Type | Streaming | Accent robustness (Canadian English) | First-partial latency | Cost | v0.1 fit |
|
||||
|---|---|---|---|---|---|---|
|
||||
| **Deepgram Nova-3** | Cloud | Native (WebSocket) | Excellent (trained on diverse English; Canadian English well-covered) | ~200-300ms first partial; endpointing available | Pay-as-you-go (~$0.0043/min streaming) | **Best** |
|
||||
| Groq-hosted Whisper | Cloud | Via Pipecat | Good (Whisper multilingual) | ~300-500ms (batch-ish chunks) | Low (Groq inference cheap) | Good fallback |
|
||||
| whisper.cpp | Self-hosted | Chunked | Good | 500ms+ on CPU (breaks budget) | $0 (self-host) | Reject for <600ms |
|
||||
| OpenAI Whisper API | Cloud | Batch-oriented | Good | 1s+ (not streaming-native) | Per-min | Reject |
|
||||
| AssemblyAI | Cloud | Streaming (WebSocket) | Good | ~300ms | Pay-as-you-go, comparable to Deepgram | Viable alternative |
|
||||
| Mozilla Whisper (local) | Self-hosted | Chunked | Good | Slow on CPU | $0 | Reject for v0.1 |
|
||||
| gemma4:e4b audio (Ollama) | Self/hosted | Research-grade | Unknown for accents | Unknown (not production ASR) | $0 | Future option only |
|
||||
### Finding: 2GB/8GB is too tight; recommend 4GB/16GB
|
||||
|
||||
### Recommendation: Deepgram Nova-3 streaming (cloud)
|
||||
**D-029 chose build-inside-CT.** This validates the approach but reveals a resource gap.
|
||||
|
||||
**Rationale:**
|
||||
- **Streaming-native** with WebSocket transport — aligns with the ASR→LLM→TTS streaming pipeline needed for <600ms.
|
||||
- **Accent robustness** — Deepgram is the ASR provider for many voice-agent platforms (Vapi, Retell, Pipecat default) and handles Canadian English (including regionalisms and French-Canadian code-switching) well. Nova-3 is their current flagship.
|
||||
- **Latency** — first partial transcripts in the ~200-300ms band fit the ~120ms ASR budget (partial results can feed LLM context before final transcript).
|
||||
- **Pipecat integration** — Deepgram is a first-class Pipecat STT service with VAD + endpointing configured out of the box.
|
||||
- **Data residency** — Deepgram offers region selection; Canada pilot can use a North American endpoint.
|
||||
- **Cost** — pay-as-you-go, no upfront. For a pilot, cost is negligible; per-D-012, log actuals.
|
||||
**Memory analysis (docker build inside CT):**
|
||||
- `npm ci` for the client: 5 dependencies (react, react-dom, pipecat client SDK, small). ~300-500MB peak. Fine at 2GB.
|
||||
- `pip install` for the server: `pipecat-ai[deepgram,cartesia,piper,webrtc]>=1.6.0`, `numpy>=1.26`, `aiohttp` (via pipecat), `openai`, `pydantic`, `aiosqlite`, `httpx`, `websockets`.
|
||||
- numpy 1.26+ ships x86_64 wheels (no compilation). ~150MB installed.
|
||||
- pipecat-ai with extras: pulls in `aiohttp`, `aiortc` (has Cython extensions — but wheels available for cp312), `sounddevice` (needs `libasound2-dev` at build time if compiling, but wheels exist).
|
||||
- Peak memory for pip with all wheels: ~800MB-1.2GB.
|
||||
- If ANY package falls back to source compilation (no wheel for the exact Python/platform), gcc + the compilation can spike to 2GB+. This is the risk at 2GB CT memory.
|
||||
- **Recommendation: 4GB memory** (`PROXMOX_MEMORY_MB=4096`). Gives safe headroom for pip + Docker daemon overhead (~200MB).
|
||||
|
||||
**Risks/unknowns:**
|
||||
- Exact first-partial latency under Canadian network conditions — **measure in Phase 1 spike**.
|
||||
- French-Canadian accent edge cases — v0.1 is English-only but some learners may code-switch; log misheard turns.
|
||||
**Rootfs analysis:**
|
||||
- Docker engine: `docker.io` + dependencies ≈ 300-400MB installed.
|
||||
- Docker build cache: each layer is stored. Node stage (npm ci + build) ≈ 300MB. Python stage (pip install) ≈ 800MB-1.2GB. Build context ≈ 200MB.
|
||||
- Final image: Python 3.12-slim base (~150MB) + pip deps (~800MB) + client/dist (~5MB) + server code (~100KB) ≈ ~1GB.
|
||||
- Repo clone: ~10-50MB (git history + source).
|
||||
- apt cache during install: ~200MB (cleanable).
|
||||
- Total peak: ~2.5-3.5GB. 8GB rootfs leaves ~4.5GB free — technically sufficient but tight, especially if Docker keeps old layers.
|
||||
- **Recommendation: 16GB rootfs** (`rootfs=${storage}:16`). Eliminates disk-pressure failures during build.
|
||||
|
||||
**Fallback path:** If Deepgram latency or cost is unacceptable post-measurement, swap to Groq Whisper via Pipecat (same interface, lower cost, slightly higher latency) or self-host whisper.cpp on a GPU for the ≤$3/learner milestone.
|
||||
**docker-compose-v2 availability:**
|
||||
- Debian 12 Bookworm repos include `docker-compose-v2` as an apt package. Confirmed: the package is in the Bookworm main repository. Install via `apt-get install -y docker.io docker-compose-v2`.
|
||||
- The `docker compose` subcommand (v2 plugin syntax) is available after installing `docker-compose-v2`. No manual binary download needed.
|
||||
|
||||
**Verdict:** Bump to 4GB memory / 16GB rootfs. `docker-compose-v2` is in Debian 12 repos.
|
||||
|
||||
**Confidence: 0.80** — resource estimates are based on typical Python/Node image sizes; actual Pipecat wheel sizes may vary. The 4GB/16GB recommendation has margin even if estimates are off by 50%.
|
||||
|
||||
**Assumptions logged:**
|
||||
- Python 3.12 wheels exist for all pipecat-ai extras on linux/amd64 (high probability — pipecat targets CPython 3.11+ and ships manylinux wheels).
|
||||
- The CT has internet access via vmbr0 DHCP to reach Debian apt mirrors + Gitea (D-030 confirms vmbr0 DHCP; coreci's firstboot-hook comment notes "CT's network may not route to the internet" but D-028/D-029 explicitly chose apt-install-inside-CT and clone-from-Gitea, implying the CT DOES have internet in this deployment — different from coreci's original assumption).
|
||||
|
||||
---
|
||||
|
||||
## TTS Recommendation
|
||||
## Q3: FastAPI StaticFiles for client/dist
|
||||
|
||||
### Options compared
|
||||
**Sources:** praxis `server/__main__.py` (existing FastAPI app), praxis `client/src/App.tsx` (single-view state machine, NO React Router), Starlette StaticFiles documentation.
|
||||
|
||||
| Option | Type | Streaming | First-audio latency | Natural prosody | Cost | v0.1 fit |
|
||||
|---|---|---|---|---|---|---|
|
||||
| **Cartesia Sonic** | Cloud | Native (WebSocket) | ~120ms (state-space model, #1 Speech Arena) | Excellent, purpose-built for agents | Pay-as-you-go | **Best** |
|
||||
| ElevenLabs | Cloud | Native | <500ms (per their FAQ; optimistically ~300ms) | Best-in-class expressiveness | Per-character (higher) | Quality benchmark; viable |
|
||||
| PlayHT | Cloud | Streaming | ~300-400ms | Good | Per-character | Viable alternative |
|
||||
| **Piper1-gpl** | Self-hosted | Chunked/HTTP | <200ms on CPU (fast, local) | Good (neural, not top-tier) | $0 | **Best open-weights fallback** |
|
||||
| Coqui (XTTS) | Self-hosted | Limited | Variable | Good | $0 | Project largely stalled; reject |
|
||||
| Amazon Polly | Cloud | Streaming (PCM) | ~150-250ms | Decent (neural voices) | Per-char | Viable but generic |
|
||||
| Google Cloud TTS | Cloud | Streaming | ~200-300ms | Good | Per-char | Viable alternative |
|
||||
### Finding: `html=True` mount at `/` after API routes; no SPA fallback needed
|
||||
|
||||
### Recommendation: Cartesia Sonic (cloud) primary; Piper1-gpl (self-hosted) fallback
|
||||
**The praxis client has NO client-side routing.** `App.tsx` uses a `useState<View>('start')` state machine with three views (start → live → debrief), not React Router. There are no routes like `/session/:id` or `/debrief` that need to serve index.html. The entire app is a single `index.html` + bundled JS/CSS.
|
||||
|
||||
**Primary — Cartesia Sonic:**
|
||||
- **#1 on Artificial Analysis Speech Arena leaderboard** (verified via cartesia.ai homepage claim; the leaderboard is an independent benchmark). State-space-model architecture is explicitly designed for low-latency streaming.
|
||||
- **~120ms first-audio** fits the TTS budget. Streaming-native so LLM tokens can feed in as they arrive.
|
||||
- **Purpose-built for voice agents** — Cartesia's own product is "Line" voice agents; they dogfood the TTS for exactly the Praxis use case.
|
||||
- **Pipecat integration** — Cartesia is a first-class Pipecat TTS service.
|
||||
- One voice persona (D-006) → one Cartesia voice ID; trivial config.
|
||||
**Correct FastAPI pattern:**
|
||||
|
||||
**Fallback — Piper1-gpl (open-weights):**
|
||||
- **Open-weights, self-hostable, $0 marginal cost** — the post-pilot ≤$3/learner/month path (C-3).
|
||||
- **Fast on CPU** (Piper is engineered for low-resource devices — used by Home Assistant, NVDA). Sub-200ms first-audio feasible on modest hardware.
|
||||
- **Pipecat integration** — Piper is a first-class Pipecat TTS service.
|
||||
- **Tradeoff:** prosody is good but not Cartesia/ElevenLabs-tier. For v0.1 pilot quality, Cartesia wins; for unit economics later, Piper wins.
|
||||
- **Note:** `piper-tts` (`pip install piper-tts`) is the current package; the old `rhasspy/piper` repo is archived (moved to OHF-Voice/piper1-gpl). The Open Home Foundation is seeking maintainers — minor sustainability risk.
|
||||
```python
|
||||
from fastapi.staticfiles import StaticFiles
|
||||
|
||||
**Architecture requirement:** The TTS service must be behind an interface so v0.1 (Cartesia) and later (Piper) are swappable without touching the orchestration pipeline.
|
||||
# API routes registered FIRST — FastAPI matches routes in registration order
|
||||
@app.get("/health")
|
||||
async def health(): ...
|
||||
|
||||
@app.post("/pipecat/webrtc")
|
||||
async def webrtc_offer(offer: WebRTCOffer): ...
|
||||
|
||||
# Static mount registered LAST — catches everything else
|
||||
# html=True serves index.html for "/" (directory index)
|
||||
app.mount("/", StaticFiles(directory="client/dist", html=True), name="client")
|
||||
```
|
||||
|
||||
**Why `html=True`:** Without it, requesting `/` returns 404 (StaticFiles doesn't serve directory indexes by default). With `html=True`, StaticFiles serves `index.html` for `/` and any directory path. Asset requests (`/assets/index-abc123.js`, `/vite.svg`) are served as static files.
|
||||
|
||||
**Why no SPA fallback:** SPA fallback (serving index.html for unmatched routes) is only needed when the client has client-side routing (React Router, Vue Router, etc.) and the user navigates directly to `/some-route`. Since praxis has no client-side router, every valid URL is either an API route (`/health`, `/pipecat/webrtc`) or a static asset. Unknown paths correctly 404.
|
||||
|
||||
**Future-proofing note:** If React Router is added in a later milestone, add a catch-all route BEFORE the StaticFiles mount:
|
||||
```python
|
||||
from fastapi.responses import FileResponse
|
||||
|
||||
@app.get("/{path:path}")
|
||||
async def spa_fallback(path: str):
|
||||
# Return index.html for any non-API, non-static-asset path
|
||||
return FileResponse("client/dist/index.html")
|
||||
```
|
||||
This is NOT needed for v0.2.
|
||||
|
||||
**Confidence: 0.95** — directly verifiable from the codebase (no React Router) and Starlette docs (`html=True` behavior).
|
||||
|
||||
---
|
||||
|
||||
## Client Framework Recommendation
|
||||
## Q4: Multi-stage Dockerfile Design
|
||||
|
||||
### Options compared
|
||||
**Sources:** praxis `pyproject.toml`, praxis `client/package.json`, praxis `server/__main__.py` (entrypoint pattern), Docker best practices.
|
||||
|
||||
| Option | Voice I/O | Iteration speed | App-store needed? | Path to $100 Android (C-2) | v0.1 fit |
|
||||
|---|---|---|---|---|---|
|
||||
| **Web (React + WebRTC + Web Audio API)** | ✅ (mic/speaker via browser) | Fastest (hot reload, no build/sign) | No | PWA works; later wrap with React Native/Capacitor | **Best** |
|
||||
| Python CLI harness (sounddevice + websockets) | ✅ (local audio) | Fast (scripting) | No | Not a learner surface | Good for dev integration test, not deliverable |
|
||||
| Minimal Android (Kotlin) | ✅ | Slow (Gradle, emulator, sign) | No (sideload) but heavy | Native path | Over-scoped for v0.1 |
|
||||
| Electron desktop | ✅ | Medium | No | Not mobile | Wrong form factor |
|
||||
### Finding: Two-stage (Node → Python), Debian-slim bases, `python -m server` CMD
|
||||
|
||||
### Recommendation: Web (React + WebRTC) via Pipecat client SDK
|
||||
**Stage 1 — Client build (Node):**
|
||||
```dockerfile
|
||||
FROM node:22-slim AS client-builder
|
||||
WORKDIR /app/client
|
||||
# Cache: copy lockfiles first, install, then copy source
|
||||
COPY client/package.json client/package-lock.json ./
|
||||
RUN npm ci
|
||||
COPY client/ ./
|
||||
RUN npm run build # tsc -b && vite build → produces client/dist/
|
||||
```
|
||||
- Base: `node:22-slim` (Debian-based, matches the Node 24 LTS trajectory; `node:20-slim` also fine). Not Alpine — Vite/esbuild may have musl issues.
|
||||
- Cache: `package.json` + `package-lock.json` copied before source → `npm ci` layer is cached unless deps change.
|
||||
- Output: `client/dist/` (static HTML/JS/CSS, ~2-5MB).
|
||||
|
||||
**Rationale:**
|
||||
- **Pipecat ships a React client SDK** (and React Native, Swift, Kotlin, C++) — using it means the v0.1 client is a thin React app that connects to the Pipecat server over WebRTC. Voice I/O, VAD signaling, and interrupt events are handled by the SDK.
|
||||
- **No app-store distribution** needed for a pilot harness (D-007: single-learner, no auth). A browser URL suffices.
|
||||
- **Fastest iteration** — hot reload, no device flashing, no signing. Critical for Phase 1 latency tuning.
|
||||
- **Upgrade path to mobile** — the same React codebase wraps into React Native (Pipecat has an RN SDK) for the later $100-Android milestone. No throwaway work.
|
||||
- **WebRTC** gives sub-50ms audio transport and is what Pipecat's production examples use.
|
||||
**Stage 2 — Server (Python):**
|
||||
```dockerfile
|
||||
FROM python:3.12-slim AS server
|
||||
WORKDIR /app
|
||||
|
||||
**Secondary: Python CLI harness.** Build a minimal `sounddevice` + WebSocket script as a dev-integration test (runs the full loop headless in CI, measures latency). This is a *test tool*, not the v0.1 learner surface.
|
||||
# Build deps for any source-compilation fallback
|
||||
RUN apt-get update && apt-get install -y --no-install-recommends \
|
||||
gcc g++ libasound2-dev \
|
||||
&& rm -rf /var/lib/apt/lists/*
|
||||
|
||||
# Install Python deps (cache: pyproject.toml first)
|
||||
COPY pyproject.toml ./
|
||||
RUN pip install --no-cache-dir . # or: pip install -e . --no-deps then pip install .
|
||||
|
||||
# Copy application code
|
||||
COPY server/ ./server/
|
||||
COPY scenarios/ ./scenarios/
|
||||
COPY db/ ./db/
|
||||
|
||||
# Copy built client from stage 1
|
||||
COPY --from=client-builder /app/client/dist ./client/dist
|
||||
|
||||
EXPOSE 8789
|
||||
CMD ["python", "-m", "server"]
|
||||
```
|
||||
- Base: `python:3.12-slim` (Debian-based). Not Alpine — numpy/pipecat native extensions compile against glibc; musl wheels are less universally available. The size savings of Alpine (~50MB) aren't worth the compatibility risk.
|
||||
- `gcc g++ libasound2-dev`: only needed if any package falls back to source compilation. If all wheels are available, these are unused but harmless (~100MB). Can be removed in a later optimization pass if wheel-only is confirmed.
|
||||
- CMD: `python -m server` — matches the existing `server/__main__.py` entrypoint which calls `uvicorn.run(app, host=HOST, port=PORT)`. This reads `PRAXIS_HOST`/`PRAXIS_PORT` from env (defaults `0.0.0.0:8789`).
|
||||
|
||||
**Why not gunicorn:** Praxis is a WebSocket/WebRTC server (long-lived connections), not a request-per-response HTTP server. Uvicorn is the correct ASGI server for Pipecat's async WebSocket architecture. Gunicorn's worker model doesn't suit WebRTC connection lifecycle. Single uvicorn process is correct for v0.2 (single-learner pilot).
|
||||
|
||||
**Why not `uvicorn server.__main__:app` directly:** `python -m server` runs the `main()` function which calls `uvicorn.run(...)` — this gives us the env-based HOST/PORT configuration and the loguru startup logging. Using `uvicorn server.__main__:app` as CMD would also work but skips the `main()` wrapper's env handling.
|
||||
|
||||
**Dockerfile location:** `/root/praxis/Dockerfile` (repo root).
|
||||
|
||||
**Confidence: 0.90** — standard multi-stage pattern; the only uncertainty is whether all Pipecat extras ship cp312 linux/amd64 wheels (high probability).
|
||||
|
||||
---
|
||||
|
||||
## Streaming Transport Recommendation
|
||||
## Q5: firstboot-hook Adaptation
|
||||
|
||||
### Options compared
|
||||
**Sources:** coreci `firstboot-hook.sh`, coreci `install-service.sh`, D-028 (Docker inside CT), D-029 (build inside CT).
|
||||
|
||||
| Transport | Bidirectional audio | LLM token streaming | Latency | Complexity | v0.1 fit |
|
||||
|---|---|---|---|---|---|
|
||||
| **WebRTC** | ✅ (UDP, sub-50ms) | ✅ (data channels) | Lowest | Higher (signaling, STUN/TURN) | **Best** (Pipecat handles this) |
|
||||
| WebSocket | ✅ (TCP, ~50-100ms) | ✅ (native) | Low | Low | Good fallback / dev mode |
|
||||
| SSE | ❌ (server→client only) | ✅ | — | Low | Reject (no upstream audio) |
|
||||
| Raw HTTP/2 streaming | ⚠️ (awkward) | ✅ | Medium | Medium | Reject |
|
||||
### Finding: Install Docker → clone repo → build + compose up; clone inside CT
|
||||
|
||||
### Recommendation: WebRTC (primary), WebSocket (dev fallback)
|
||||
**Coreci's pattern:** Host fetches pre-built binary → SHA256 verify → `pct push` into CT → `pct exec install-service.sh`. This works because coreci ships a Go binary (small, pre-compiled).
|
||||
|
||||
- **WebRTC** for the v0.1 client↔server audio path. Pipecat's `SmallWebRTCTransport` or Daily/LiveKit transports handle signaling, STUN/TURN, and audio frames. UDP audio = lowest transport latency, critical for the <600ms budget.
|
||||
- **WebSocket** as a dev-mode fallback for the Python CLI harness (no WebRTC signaling complexity in a local test).
|
||||
- The LLM↔orchestrator token stream is internal (Ollama streaming API) and not a transport decision.
|
||||
**Praxis's pattern (D-029: build inside CT):** The CT fetches its own source and builds the Docker image. The hook orchestrates via `pct exec`.
|
||||
|
||||
**Adapted hook sequence (post-start phase, runs on PVE host):**
|
||||
|
||||
```sh
|
||||
case "$phase" in
|
||||
post-start) : ;;
|
||||
*) exit 0 ;;
|
||||
esac
|
||||
|
||||
# Step 1: Install Docker inside the CT
|
||||
pct exec "$vmid" -- sh -c '
|
||||
apt-get update -qq
|
||||
apt-get install -y -qq docker.io docker-compose-v2 git curl
|
||||
systemctl enable --now docker
|
||||
'
|
||||
|
||||
# Step 2: Clone the repo from Gitea inside the CT
|
||||
pct exec "$vmid" -- sh -c '
|
||||
git clone https://'"${GITEA_TOKEN}"'@git.cloudinit.dev/coreci/praxis.git /opt/praxis
|
||||
'
|
||||
|
||||
# Step 3: Build the Docker image + compose up
|
||||
pct exec "$vmid" -- sh -c '
|
||||
cd /opt/praxis
|
||||
docker compose build
|
||||
docker compose up -d
|
||||
'
|
||||
|
||||
# Step 4: Install systemd service (creates user, env file, praxis.service)
|
||||
pct exec "$vmid" -- sh -c '
|
||||
cd /opt/praxis
|
||||
sh scripts/install-service.sh
|
||||
'
|
||||
```
|
||||
|
||||
**Why clone inside CT (not host-clone + pct push):**
|
||||
- D-029 rationale: "self-contained — CT fetches its own source + builds."
|
||||
- The CT has internet access (vmbr0 DHCP, D-030) — unlike coreci's original assumption ("CT's network may not route to the internet").
|
||||
- `pct push` of a full repo (with `.git`) is awkward — `pct push` works file-by-file, not recursive directories. A tarball + `pct push` + `pct exec tar -x` is more steps than `git clone`.
|
||||
- Git clone gives version traceability (`git log` inside the CT).
|
||||
|
||||
**Why install-service.sh runs AFTER compose up:**
|
||||
- `install-service.sh` creates the `praxis` user, `/etc/praxis/server.env`, and the systemd unit.
|
||||
- The systemd unit runs `docker compose up` (foreground). But the firstboot hook already ran `docker compose up -d` in Step 3 to verify the image builds and starts.
|
||||
- Actually, the cleaner sequence: install-service.sh creates the env file + systemd unit, and the systemd unit's `ExecStart=docker compose up` is what actually runs the service. The hook should: install Docker → clone → install-service.sh (creates env + unit + starts service via `systemctl restart praxis`) → health-check. The `docker compose build` happens as part of `systemctl start praxis` (or as a pre-step).
|
||||
- **Refined sequence:** (a) install Docker, (b) clone repo, (c) `install-service.sh` (writes env file from lxc.environment vars, writes systemd unit, `systemctl daemon-reload && systemctl enable praxis && systemctl restart praxis`), (d) the systemd unit's ExecStart runs `docker compose up` which builds if needed (or a pre-build ExecStartPre runs `docker compose build`).
|
||||
|
||||
**Safest final sequence:**
|
||||
1. `pct exec` — install `docker.io docker-compose-v2 git curl`
|
||||
2. `pct exec` — `git clone` repo to `/opt/praxis`
|
||||
3. `pct exec` — run `install-service.sh` which:
|
||||
- Creates `praxis` user + dirs
|
||||
- Writes `/etc/praxis/server.env` from lxc.environment vars
|
||||
- Writes `praxis.service` systemd unit (with `ExecStartPre=docker compose build`, `ExecStart=docker compose up`)
|
||||
- `systemctl daemon-reload && systemctl enable praxis && systemctl restart praxis`
|
||||
4. External `health-check.sh` polls `/health:8789`
|
||||
|
||||
This way the systemd unit manages the full lifecycle (build + up), and the hook just sets up the prerequisites + starts the service.
|
||||
|
||||
**Confidence: 0.85** — the sequence is sound; the `ExecStartPre=docker compose build` pattern needs validation (build may exceed systemd's default timeout, may need `TimeoutStartSec=300`).
|
||||
|
||||
**Assumptions logged:**
|
||||
- The CT has internet access to reach `git.cloudinit.dev` and Debian apt mirrors (confirmed by D-028/D-029/D-030 choosing inside-CT operations).
|
||||
- `GITEA_TOKEN` is passed via `lxc.environment` and available inside the CT.
|
||||
- systemd's `TimeoutStartSec` can be extended for the build step (default 90s is too short for `docker compose build`).
|
||||
|
||||
---
|
||||
|
||||
## Learner State Store Confirmation (D-007)
|
||||
## Q6: Secret Injection Chain
|
||||
|
||||
**Confirmed: SQLite.** No evidence supports switching.
|
||||
**Sources:** coreci `lxc-config.sh` (lxc.environment SSH step), coreci `install-service.sh` (env file creation), praxis `.gitignore`, praxis `config.json` (secrets scopes).
|
||||
|
||||
- **Scale:** single learner, no concurrency, no auth (D-007). SQLite handles this with zero operational overhead.
|
||||
- **Schema needs (v0.1):** session log (turns, timestamps, ASR/TTS text), progress (scenario attempts, success/failure), scenario state (current branch, `failure_mode` field per D-009). Trivial relational fit.
|
||||
- **Deployment:** a single `praxis.db` file on the server (v0.1 is a pilot harness, not on-device per se — the "local" in D-007 means local-to-the-pilot-instance, not on the learner's phone). For a true on-device later milestone, SQLite (via reactive wrappers) remains correct.
|
||||
- **Alternatives rejected:**
|
||||
- DuckDB — analytical OLAP; overkill, no benefit at single-row writes.
|
||||
- Plain JSON — no queryability, no schema enforcement, corruption risk.
|
||||
- LiteDB — .NET ecosystem; Praxis is Python.
|
||||
- Postgres — premature (D-007 explicitly defers server-side multi-tenant).
|
||||
### Finding: lxc.environment → /etc/praxis/server.env → docker-compose env_file → container env
|
||||
|
||||
**Confidence update:** D-007 0.80 → **0.90**.
|
||||
**Validated chain:**
|
||||
|
||||
**Recommended v0.1 schema (illustrative, for PLAN to refine):**
|
||||
- `sessions(id, learner_id, scenario_id, started_at, ended_at, branch_path_json, outcome)`
|
||||
- `turns(id, session_id, seq, role, asr_text, tts_text, latency_ms, created_at)`
|
||||
- `progress(learner_id, scenario_id, attempts, last_outcome, updated_at)`
|
||||
- `learner(id, display_name, created_at)` — single hardcoded row for v0.1.
|
||||
```
|
||||
1. lxc-config.sh (SSH to PVE host)
|
||||
→ writes to /etc/pve/lxc/<vmid>.conf:
|
||||
lxc.environment: GITEA_TOKEN=<token>
|
||||
lxc.environment: DEEPGRAM_API_KEY=<key>
|
||||
lxc.environment: PRAXIS_PORT=8789
|
||||
lxc.environment: PRAXIS_HOST=0.0.0.0
|
||||
lxc.environment: OLLAMA_BASE_URL=https://ollama.com/v1
|
||||
(etc. — all non-secret config + provisioned secrets)
|
||||
|
||||
2. CT boots → systemd (PID 1) has these env vars
|
||||
→ all systemd services inherit them
|
||||
|
||||
3. firstboot-hook (post-start) → pct exec install-service.sh
|
||||
→ install-service.sh reads env vars and writes /etc/praxis/server.env:
|
||||
GITEA_TOKEN=<token>
|
||||
DEEPGRAM_API_KEY=<key>
|
||||
PRAXIS_PORT=8789
|
||||
...
|
||||
→ chown root:praxis, chmod 0640
|
||||
|
||||
4. praxis.service (systemd unit)
|
||||
→ EnvironmentFile=/etc/praxis/server.env
|
||||
→ ExecStart=docker compose up
|
||||
→ docker-compose.yml has env_file: /etc/praxis/server.env
|
||||
→ OR docker-compose.yml passes env vars through from the systemd environment
|
||||
|
||||
5. Docker container
|
||||
→ receives env vars via docker-compose env_file
|
||||
→ server/__main__.py reads via os.environ
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Scenario Definition Format
|
||||
|
||||
### Recommendation: YAML DSL → typed Python schema (Pydantic)
|
||||
|
||||
**Rationale:**
|
||||
- **C-7:** scenarios authored by domain experts + learning designers. YAML is human-authorable, supports comments (learning-designer rationale, branch intent), and is git-diffable for review.
|
||||
- **Typed validation:** parse YAML → Pydantic model → fail fast on schema errors at load time.
|
||||
- **Runtime wire format:** JSON (serialized from the Pydantic model).
|
||||
- **Code-authored rejected for v0.1:** couples authoring to engineering; non-engineers can't review/author.
|
||||
- **Pipecat Flows** handles the runtime branching state machine; the YAML feeds it.
|
||||
|
||||
### Example schema (v0.1 — one scenario, one branch point per D-010)
|
||||
**Why not pass secrets directly through docker-compose env_file from the systemd environment:** The systemd environment (from lxc.environment) IS available to `docker compose up` as inherited env vars. `docker-compose.yml` can use `environment:` with `${VAR}` interpolation, which reads from the process environment. But using an explicit `env_file: /etc/praxis/server.env` is more robust — it's a single source of truth, debuggable (you can `cat /etc/praxis/server.env` inside the CT), and doesn't depend on env var inheritance chains.
|
||||
|
||||
**Recommended docker-compose.yml pattern:**
|
||||
```yaml
|
||||
# scenarios/customer_service_refund_ca_v01.yaml
|
||||
id: cs_refund_ca_v01
|
||||
path: customer_service
|
||||
market: CA
|
||||
language: en-CA
|
||||
title: "Angry customer requesting refund on a damaged product"
|
||||
difficulty: 1
|
||||
failure_mode: escalates_unresolved # D-009: present, not provoked in v0.1
|
||||
persona:
|
||||
voice_id: "cartesia:some-voice-id" # D-006: same voice as mentor
|
||||
character: "Customer (Jordan)"
|
||||
setup:
|
||||
system_prompt: |
|
||||
You are Jordan, a customer who received a damaged product.
|
||||
You are frustrated but not abusive. You want a refund.
|
||||
Stay in character. Do not break role.
|
||||
opening_line: "Hi, I received my order yesterday and the item is cracked. I want my money back."
|
||||
success_criteria:
|
||||
- "Acknowledged the customer's frustration empathetically"
|
||||
- "Offered a concrete resolution (refund or replacement)"
|
||||
- "Confirmed next steps"
|
||||
common_mistakes:
|
||||
- "Jumping to policy before acknowledging emotion"
|
||||
- "Using jargon ('RMA', 'SLA')"
|
||||
branches:
|
||||
- id: accept_resolution
|
||||
trigger:
|
||||
learner_signals: ["empathy", "concrete_resolution"]
|
||||
outcome: success
|
||||
debrief_focus: "What you did well"
|
||||
- id: escalate
|
||||
trigger:
|
||||
learner_signals: ["defensive", "policy_first"]
|
||||
outcome: failure
|
||||
failure_mode: escalates_unresolved
|
||||
debrief_focus: "The customer escalated because they felt unheard"
|
||||
debrief:
|
||||
model: deepseek-v4-flash:cloud
|
||||
mode: no_think # latency
|
||||
prompt_template: debrief/default
|
||||
services:
|
||||
praxis:
|
||||
build: .
|
||||
ports:
|
||||
- "8789:8789"
|
||||
env_file:
|
||||
- /etc/praxis/server.env
|
||||
volumes:
|
||||
- praxis-db:/app/data
|
||||
restart: unless-stopped
|
||||
volumes:
|
||||
praxis-db:
|
||||
```
|
||||
|
||||
This schema carries the `failure_mode` field (D-009), one branch point (D-010), success criteria, common mistakes, and the debrief model config — all v0.1 requirements.
|
||||
|
||||
---
|
||||
|
||||
## Prior Art Scan
|
||||
|
||||
| Platform | What it is | What they got right | What they got wrong / gaps for Praxis |
|
||||
|---|---|---|---|
|
||||
| **Second Nature** (secondnature.ai) | B2B AI role-play training for sales/support/call-center. Used by Oracle, Zoom, GoHealth. | Role-play + coaching-debrief thesis (validated: 34% ramp reduction). Manager insights dashboard. Multi-persona scenarios. Real-time feedback flags mistakes. | Enterprise/desktop/web-chat-first, not voice-primary-mobile. B2B per-seat pricing. Not low-bandwidth. No consumer-apprentice framing. |
|
||||
| **Speak** (speak.com) | Consumer language learning, voice-first. | Voice-primary interface, mobile-first, accent feedback, daily habit. | Language-learning, not job-skill apprenticeship. No role-play scenarios, no mastery gates for job outcomes. |
|
||||
| **Cartesia Line / Retell / Vapi** | Voice-agent infrastructure platforms. | Best-in-class latency/quality stacks; validate that sub-600ms voice loops are production-feasible. | Infrastructure, not learning. No scenarios, no coaching, no mastery. Praxis builds *on top of* this category (or directly on Pipecat). |
|
||||
| **Duolingo voice features** | Limited speech-recognition in a gamified language app. | Habit/engagement mechanics, mobile reach. | Voice is a side feature, not the interface. No conversational role-play. No job outcomes. |
|
||||
| **Gabby / other AI tutor startups** | Various AI tutoring experiments. | Personalization, on-demand. | Most are text-first or video-first; few solve the latency/voice-primary loop well; high churn without job-outcome anchoring. |
|
||||
|
||||
**Lessons for v0.1:**
|
||||
1. **Second Nature validates the Praxis thesis** (role-play + coaching works, enterprises pay) — but Praxis's wedge is the *opposite* market (consumer/mobile/low-bandwidth/B2C-apprentice). Don't copy their enterprise desktop UX.
|
||||
2. **Voice-primary + mobile + low-bandwidth is the defensible moat** — none of the prior art optimizes for a $100 Android phone on 2G/3G (C-2). This is v0.1's architectural north star even though v0.1 itself is a Canada pilot on relaxed constraints.
|
||||
3. **Job-outcome anchoring** (REQ success metric: ≥25% report job/promotion) is what separates Praxis from language apps. The scenario must feel like the job.
|
||||
4. **Coaching debrief is non-negotiable** — Second Nature's real-time feedback and post-session coaching is the engagement/learning engine. D-011 includes it at a basic level; keep it.
|
||||
|
||||
---
|
||||
|
||||
## LLM Orchestration Pattern Recommendation
|
||||
|
||||
### Recommendation: Pipecat pipeline (ASR → LLM → TTS, streaming, with interruptibility)
|
||||
|
||||
**Pattern:**
|
||||
**.gitignore verification (praxis):**
|
||||
```
|
||||
Client (WebRTC audio)
|
||||
→ Pipecat InputProcessor (VAD: Silero)
|
||||
→ Deepgram STT (streaming partials)
|
||||
→ FrameRouter (partial transcripts prime LLM context; final transcript triggers turn)
|
||||
→ OllamaLLM (gemma4:cloud, stream=True, no local daemon — direct API)
|
||||
→ Cartesia TTS (stream chunks as LLM tokens arrive)
|
||||
→ OutputProcessor → WebRTC audio back to client
|
||||
[Interrupt]: learner VAD fires during TTS → abort TTS + yield floor (D-008)
|
||||
.env
|
||||
.env.secrets
|
||||
.env.*
|
||||
```
|
||||
- `.env` — matches `/root/praxis/.env` ✅
|
||||
- `.env.secrets` — matches `/root/praxis/.env.secrets` ✅
|
||||
- `.env.*` — matches any file starting with `.env.` anywhere in the tree, including `.ciagent/.env.secrets` ✅
|
||||
|
||||
All secret files are gitignored. The `config.json` secrets scopes (release/proxmox/voice) define which env vars are expected, but the actual secret values live in `.ciagent/.env.secrets` (gitignored, sourced at deploy time).
|
||||
|
||||
**Secret scopes for v0.2 (per D-024):**
|
||||
- `proxmox` scope: PROXMOX_API_URL, PROXMOX_API_TOKEN, PROXMOX_NODE, PROXMOX_STORAGE, PROXMOX_TEMPLATE_VOLID, PROXMOX_TLS_SKIP_VERIFY — sourced from `~/coreci/.ciagent/.env.secrets` (D-026). NOT in praxis's `.env.secrets`.
|
||||
- `release` scope: GITEA_TOKEN — in praxis's `.ciagent/.env.secrets`.
|
||||
- `voice` scope: DEEPGRAM_API_KEY (provisioned), CARTESIA_API_KEY + OLLAMA_API_KEY (empty/unprovisioned per D-024) — in praxis's `.ciagent/.env.secrets`.
|
||||
|
||||
**Confidence: 0.90** — the chain is directly derived from coreci's proven pattern; the only addition is the docker-compose env_file layer.
|
||||
|
||||
---
|
||||
|
||||
## Q7: Health-Check Adaptation
|
||||
|
||||
**Sources:** coreci `health-check.sh`, praxis `server/__main__.py` (`/health` endpoint, port 8789), D-030 (vmbr0 DHCP).
|
||||
|
||||
### Finding: Same pattern, change endpoint + port + bump timeout to 300s
|
||||
|
||||
**Coreci's health-check.sh** (lines 31-53):
|
||||
1. If `CORECI_HEALTH_URL` is set, use it directly.
|
||||
2. Otherwise, query PVE `/nodes/{node}/lxc/{vmid}/interfaces` for the bridge IP.
|
||||
3. Extract first non-loopback IPv4 (`.inet` or `.ip` field, NOT `.hwaddr` — P18 bug fix).
|
||||
4. Construct `http://<ip>:<port>/healthz`.
|
||||
5. Poll with curl for `CORECI_HEALTH_TIMEOUT` seconds (default 180).
|
||||
|
||||
**Praxis adaptations:**
|
||||
- Endpoint: `/health` (not `/healthz`) — from `server/__main__.py` line 61.
|
||||
- Port: `8789` (not `18080`) — from `PRAXIS_PORT` default.
|
||||
- Env var names: `PRAXIS_HEALTH_URL`, `PRAXIS_HTTP_PORT`, `PRAXIS_HEALTH_TIMEOUT` (rename from `CORECI_*`).
|
||||
- **Timeout: 300s** (not 180s). Rationale: Docker build inside CT + compose up may take 3-5 min (REQ-NFR-DEPLOY-03: < 5 min first-boot). The 180s default is insufficient for the build-inside-CT path. 300s = 5 min matches the NFR target.
|
||||
|
||||
**Does /interfaces work for vmbr0 DHCP CT?** Yes. The PVE `/nodes/{node}/lxc/{vmid}/interfaces` endpoint returns the CT's network interfaces regardless of how the IP was assigned (DHCP or static). The CT gets a DHCP lease on vmbr0, and PVE reports the assigned IP via the `/interfaces` endpoint. The health-check.sh jq filter (`.[] | select(.name != "lo") | (.inet? // .ip? // empty)`) correctly extracts the DHCP-assigned IPv4.
|
||||
|
||||
**Timing considerations:**
|
||||
- CT start → DHCP lease: ~2-5s.
|
||||
- firstboot-hook (install Docker + clone + install-service + systemctl start): ~3-5 min (Docker apt install ~1-2 min, git clone ~10s, docker compose build ~1-2 min, compose up ~10s).
|
||||
- Health endpoint available: immediately after `docker compose up` starts the container (uvicorn binds 0.0.0.0:8789).
|
||||
- Total: ~3-5 min from CT start to health. 300s timeout covers this with margin.
|
||||
|
||||
**Confidence: 0.90** — the /interfaces endpoint is proven (coreci uses it); the only change is endpoint/port/timeout.
|
||||
|
||||
---
|
||||
|
||||
## Q8: Systemd Unit for Docker Compose
|
||||
|
||||
**Sources:** coreci `coreci.service` (Type=simple Go binary), Docker systemd integration best practices.
|
||||
|
||||
### Finding: Type=simple with `docker compose up` (foreground), ExecStartPre builds
|
||||
|
||||
**Why NOT `docker compose up -d` (detached):**
|
||||
- `docker compose up -d` starts containers in the background and exits immediately.
|
||||
- With `Type=oneshot`, systemd considers the unit "active" after the command exits, but systemd does NOT track the Docker containers. If a container crashes, systemd won't know (only Docker's `restart` policy would catch it).
|
||||
- With `Type=simple` + `docker compose up -d`, the unit exits immediately → systemd marks it as "failed" (non-zero exit from a Type=simple service) or "inactive." This is incorrect lifecycle management.
|
||||
|
||||
**Correct pattern — `docker compose up` (foreground, no -d):**
|
||||
|
||||
```ini
|
||||
[Unit]
|
||||
Description=Praxis — voice-first AI apprenticeship platform
|
||||
After=network-online.target docker.service
|
||||
Wants=network-online.target
|
||||
Requires=docker.service
|
||||
|
||||
[Service]
|
||||
Type=simple
|
||||
User=praxis
|
||||
Group=praxis
|
||||
WorkingDirectory=/opt/praxis
|
||||
EnvironmentFile=-/etc/praxis/server.env
|
||||
# Build the image (if needed) before starting. Long timeout for first boot.
|
||||
ExecStartPre=/usr/bin/docker compose build
|
||||
ExecStart=/usr/bin/docker compose up
|
||||
ExecStop=/usr/bin/docker compose down
|
||||
Restart=on-failure
|
||||
RestartSec=10
|
||||
TimeoutStartSec=300
|
||||
|
||||
[Install]
|
||||
WantedBy=multi-user.target
|
||||
```
|
||||
|
||||
**Why Pipecat (not custom, not Vocode):**
|
||||
- **13.8k stars, 11k+ commits, actively maintained** (verified on GitHub). Vocode's `vocode-core` last updated Nov 2024 — stale.
|
||||
- **Native integrations** for Deepgram (STT), Cartesia/Piper/ElevenLabs (TTS), and **Ollama (LLM)** — all three v0.1 services are first-class. No glue code.
|
||||
- **Built-in VAD** (Silero) and **interruptibility** (abort-and-yield semantics match D-008 out of the box).
|
||||
- **Pipecat Flows** for structured/branching conversations — maps directly to the v0.1 scenario branch point (D-010).
|
||||
- **Client SDKs** (React/RN/Swift/Kotlin) for the WebRTC transport.
|
||||
- **Python** — matches the SQLite + scenario-YAML toolchain.
|
||||
**How this works:**
|
||||
1. `ExecStartPre=docker compose build` — builds the image (fast if cached, ~2 min first time). `TimeoutStartSec=300` gives 5 min.
|
||||
2. `ExecStart=docker compose up` — runs in FOREGROUND. Docker compose streams container logs to stdout (captured by journald). systemd tracks the compose process as the service's main PID.
|
||||
3. If a container crashes, `docker compose up` exits → systemd sees the service exit → `Restart=on-failure` restarts it (which re-runs compose up).
|
||||
4. `ExecStop=docker compose down` — graceful shutdown on `systemctl stop`.
|
||||
5. `Restart=on-failure` + Docker's `restart: unless-stopped` in compose.yml = double layer of restart protection.
|
||||
|
||||
**Latency optimization patterns to apply (from Pipecat/Voice-agent ecosystem conventions):**
|
||||
1. **Stream partial ASR → prime LLM** — feed Deepgram partials into Ollama as user-context so the first LLM token fires ~immediately on final transcript.
|
||||
2. **Stream LLM tokens → TTS chunked** — don't wait for the full LLM response; Cartesia/Piper accept incremental text. First-audio fires on first sentence-boundary token.
|
||||
3. **no-think mode for deepseek-v4-flash** during debrief (avoids reasoning latency on the critical path).
|
||||
4. **Short system prompts** for the role-play fast path (gemma4:cloud); long context (256K/1M) is available but not used per-turn for latency.
|
||||
5. **Measure, don't assume** — Phase 1 must include a latency probe (per-segment timing) from day one.
|
||||
**Why User=praxis (not root):** Docker daemon runs as root, but the `docker compose` CLI can run as any user in the `docker` group. `install-service.sh` creates the `praxis` user and adds it to the `docker` group. This is more secure than running the service as root.
|
||||
|
||||
**Custom orchestration rejected for v0.1** — it would rebuild VAD, streaming frame routing, interruptibility, and transport abstractions that Pipecat already provides. Revisit only if Pipecat proves incompatible with a v0.1 requirement (flag as a risk).
|
||||
**Why NOT coreci's hardening directives:** Coreci's `coreci.service` has extensive hardening (`NoNewPrivileges`, `ProtectSystem=strict`, `PrivateDevices`, etc.). Many of these BREAK Docker — Docker needs to create namespaces, mount filesystems, manage cgroups. `ProtectSystem=strict` would prevent Docker from writing to `/var/lib/docker`. `PrivateDevices=true` blocks Docker's device access. `RestrictNamespaces=true` blocks Docker's namespace creation. **Praxis's systemd unit must NOT use these Docker-incompatible hardening directives.** Only safe directives: `LimitNOFILE`, `StandardOutput=journal`.
|
||||
|
||||
**Confidence: 0.85** — the foreground `docker compose up` pattern is the documented Docker+systemd integration; the `ExecStartPre=build` + `TimeoutStartSec=300` combination needs validation (systemd may handle long ExecStartPre differently than long ExecStart).
|
||||
|
||||
**Assumptions logged:**
|
||||
- The `praxis` user is added to the `docker` group by `install-service.sh` (so `docker compose` works without sudo).
|
||||
- `TimeoutStartSec=300` applies to the total of ExecStartPre + ExecStart (systemd behavior: the timeout applies to each command separately in some versions, to the total in others — needs verification at deploy time).
|
||||
|
||||
---
|
||||
|
||||
## Safety Baseline Guardrails (v0.1 Customer Service)
|
||||
## Q9: CT Resource Sizing
|
||||
|
||||
Customer Service is low-risk per PRD, but v0.1 ships a minimal guardrail layer (C-6, REQ-NFR-SAFE-01) that the architecture extends for later high-risk domains.
|
||||
**Sources:** coreci `lxc-clone.sh` (defaults: `rootfs=${storage}:8`, `memory=2048`), praxis `pyproject.toml` (deps), praxis `client/package.json` (deps), Docker image size estimates.
|
||||
|
||||
### v0.1 guardrails list (concrete)
|
||||
### Finding: 4GB memory, 16GB rootfs; build on rootfs (not tmpfs)
|
||||
|
||||
1. **System-prompt constraints** (role-play fast path, `gemma4:cloud`):
|
||||
- "You are role-playing a customer service scenario. Stay in character."
|
||||
- "Do not give legal, financial, or medical advice. If asked, say you cannot and redirect to the scenario."
|
||||
- "Do not impersonate a real employee of any actual company. Use the fictional persona only."
|
||||
- "Do not share personal data about real people."
|
||||
- "Keep responses concise for voice (1-3 sentences)."
|
||||
**Memory: 4GB (double coreci's 2GB default)**
|
||||
|
||||
2. **Debrief output filter** (`deepseek-v4-flash:cloud`):
|
||||
- Coaching text must be about the learner's performance, not advice about the customer's legal rights.
|
||||
- Block any recommendation that the learner advise a real customer to take legal action.
|
||||
| Consumer | Estimated peak |
|
||||
|----------|---------------|
|
||||
| CT base (systemd, ssh, etc.) | ~200MB |
|
||||
| Docker daemon | ~200MB |
|
||||
| `docker compose build` — npm ci (client) | ~400MB |
|
||||
| `docker compose build` — pip install (server) | ~1.2GB |
|
||||
| `docker compose up` — praxis container (uvicorn + pipecat) | ~500MB |
|
||||
| Headroom | ~1.5GB |
|
||||
| **Total** | **~4GB** |
|
||||
|
||||
3. **Session-start disclaimer** (TTS audio, first turn):
|
||||
- "This is an AI practice session for training purposes. It is not a real conversation and no real company is involved."
|
||||
At 2GB, the pip install step risks OOM if any package compiles from source. 4GB eliminates this risk.
|
||||
|
||||
4. **No PII collection:**
|
||||
- Hardcoded learner profile (D-007). No name/email/phone collected. ASR transcripts are ephemeral-turn-logged but not associated with a real identity.
|
||||
**Rootfs: 16GB (double coreci's 8GB default)**
|
||||
|
||||
5. **Architecture for later extension:**
|
||||
- Guardrail layer must be a pluggable interface (`Guardrail.check(text, context) -> verdict`) so health/electrical domains (later milestones) can inject domain-specific rules without touching the pipeline.
|
||||
- v0.1 ships one implementation: the Customer Service ruleset above.
|
||||
| Consumer | Estimated size |
|
||||
|----------|----------------|
|
||||
| Debian 12 base | ~500MB |
|
||||
| Docker engine + deps | ~400MB |
|
||||
| git + curl + build deps | ~100MB |
|
||||
| Repo clone (praxis) | ~50MB |
|
||||
| Docker build layers (Node stage) | ~400MB |
|
||||
| Docker build layers (Python stage) | ~1.2GB |
|
||||
| Final Docker image | ~1GB |
|
||||
| apt cache (cleanable) | ~200MB |
|
||||
| SQLite DB volume | ~10MB |
|
||||
| Headroom | ~12GB |
|
||||
| **Total** | **~4GB used, 16GB allocated** |
|
||||
|
||||
6. **No HITL in v0.1** (Customer Service is low-risk; HITL is for safety-sensitive domains per C-6, deferred).
|
||||
8GB would leave only ~4GB free after the build — tight enough that Docker layer cleanup or a second build could fill the disk. 16GB is safe.
|
||||
|
||||
**Build location: rootfs (not tmpfs)**
|
||||
- tmpfs would consume memory (already the tight resource at 4GB).
|
||||
- rootfs on `local` storage (directory or LVM-thin) has plenty of IOPS for a one-time build.
|
||||
- Docker's build cache lives in `/var/lib/docker` on the rootfs by default.
|
||||
|
||||
**How to configure:** In the adapted `lxc-clone.sh`:
|
||||
```sh
|
||||
"rootfs=${storage}:16" \
|
||||
"memory=${PROXMOX_MEMORY_MB:-4096}" \
|
||||
```
|
||||
And/or via `PROXMOX_MEMORY_MB=4096` env var in the deploy script.
|
||||
|
||||
**Confidence: 0.80** — estimates are conservative; actual usage may be lower. The 4GB/16GB recommendation has ~50% margin.
|
||||
|
||||
---
|
||||
|
||||
## Risks & Unknowns Remaining for PLAN Stage
|
||||
## Q10: Testing Strategy
|
||||
|
||||
| # | Risk / Unknown | Severity | Mitigation / PLAN action |
|
||||
|---|---|---|---|
|
||||
| R1 | **Deepgram first-partial latency under Canadian network conditions unmeasured.** Vendor claims ~200-300ms; real-world may differ. | High | Phase 1 day-1 spike: measure Deepgram partial latency from a Canada endpoint. If >300ms, evaluate Groq Whisper fallback. |
|
||||
| R2 | **Cartesia Sonic exact first-audio latency unmeasured.** ~120ms is vendor/leaderboard claim. | High | Phase 1 spike: measure Cartesia first-audio from a sample LLM token stream. If >180ms, evaluate Piper fallback. |
|
||||
| R3 | **Ollama Cloud direct-API latency & rate limits unmeasured.** `gemma4:cloud` first-token latency from `ollama.com/api/chat` is unknown; usage-tier throttling on Pro plan unknown. | High | Phase 1 spike: measure TTFT for `gemma4:cloud` via direct API. If >250ms, consider local-Ollama-daemon mode on a pilot GPU with `gemma4:e4b`. |
|
||||
| R4 | **End-to-end <600ms may be infeasible with all-cloud (ASR+LLM+TTS each cloud-round-trip).** Three cloud hops + WebRTC could exceed 600ms. | High | Budget the three network hops explicitly. If infeasible, move one component self-hosted (likely TTS→Piper on the pilot server, or LLM→local `gemma4:e4b`). |
|
||||
| R5 | **`gemma4:cloud` "Low Usage" tier may throttle under concurrent pilot sessions.** | Medium | v0.1 is single-learner; low risk. Log throttling events. For multi-learner, revisit plan tier. |
|
||||
| R6 | **Pipecat + Ollama direct-API integration depth unverified.** Pipecat has an Ollama LLM service, but whether it supports the `https://ollama.com` direct host + bearer token cleanly needs a code check. | Medium | Phase 1 task: verify Pipecat Ollama service accepts custom host + auth headers; if not, wrap with a thin adapter. |
|
||||
| R7 | **Scenario branch detection (how to classify learner signals into accept/escalate).** The YAML schema declares `learner_signals` but the classifier is unspecified. | Medium | v0.1: use an LLM-as-judge call (`deepseek-v4-flash:cloud` no-think) at turn boundaries to classify signals. Keep it offline from the voice loop (runs between turns or at session end). |
|
||||
| R8 | **Piper1-gpl maintainer gap.** Open Home Foundation is seeking maintainers. | Low (v0.1 uses Cartesia) | Monitor; if Piper stagnates, evaluate Kokoro (also in Pipecat) for the open-weights fallback. |
|
||||
| R9 | **French-Canadian accent/code-switching in v0.1 English pilot.** | Low (v0.1 English-only) | Log misheard turns; inform the later multilingual milestone (REQ-VOICE-05). |
|
||||
| R10 | **Ollama Cloud data residency.** Hosted primarily US; Europe/Singapore routing possible. Canada pilot may raise PIPEDA considerations. | Low-Medium | Confirm Ollama's zero-data-retention policy covers pilot needs; if Canada data-residency is required, consider self-hosted `gemma4:e4b` + Piper for an all-Canada-region stack. |
|
||||
**Sources:** coreci `scripts/proxmox/test/` (10 bats files), coreci test patterns (mocked api.sh + mocked curl + real jq).
|
||||
|
||||
### Finding: Mirror coreci's bats structure; 7 unit-testable, 3 e2e
|
||||
|
||||
**Coreci's test structure (10 bats files):**
|
||||
|
||||
| File | Type | What it tests |
|
||||
|------|------|---------------|
|
||||
| api.bats | Unit | pve_curl, pve_poll, pve_nextid, pve_env, pve_lxc_env_args helpers (stubbed curl/jq) |
|
||||
| lxc-clone.bats | Unit | POST /nodes/{node}/lxc body shape (vmid, ostemplate, hostname, etc.) + UPID poll (mocked api.sh) |
|
||||
| lxc-config.bats | Unit | PUT /config + SSH hookscript/lxc.environment (mocked) |
|
||||
| lxc-start.bats | Unit | POST /status/start + UPID poll (mocked api.sh) |
|
||||
| health-check.bats | Unit | URL resolution (CORECI_HEALTH_URL override, /interfaces IP parsing) + polling (mocked curl) |
|
||||
| rollback.bats | Unit | stop + destroy sequence (mocked api.sh) |
|
||||
| timing.bats | Unit | JSON timing emission (timing_start/timing_end) |
|
||||
| idempotency.bats | Unit | --recreate/--reconfigure flag handling (mocked ct_exists) |
|
||||
| lxc-deploy.bats | Integration | Full orchestrator sequence with mocked siblings |
|
||||
| e2e-deploy.bats | E2E | Full stack against live Proxmox (mocked where unavailable) |
|
||||
|
||||
**Praxis test plan (mirror + adapt):**
|
||||
|
||||
| File | Type | Adaptation from coreci |
|
||||
|------|------|------------------------|
|
||||
| api.bats | Unit | **Verbatim** — api.sh is reused verbatim (REQ-DEPLOY-03) |
|
||||
| lxc-clone.bats | Unit | Adapt assertions: `hostname=praxis`, `memory=4096`, `rootfs=local:16` |
|
||||
| lxc-config.bats | Unit | Adapt: `lxc.environment: GITEA_TOKEN=`, `lxc.environment: DEEPGRAM_API_KEY=`, `lxc.environment: PRAXIS_PORT=8789`, hookscript=`local:snippets/praxis-firstboot.sh` |
|
||||
| lxc-start.bats | Unit | **Verbatim** (same POST /status/start pattern) |
|
||||
| health-check.bats | Unit | Adapt: `/health` (not `/healthz`), port `8789` (not `18080`), `PRAXIS_HEALTH_URL`/`PRAXIS_HTTP_PORT`/`PRAXIS_HEALTH_TIMEOUT` env names |
|
||||
| rollback.bats | Unit | **Near-verbatim** (remove proxy backend-remove step — praxis has no proxy in v0.2) |
|
||||
| timing.bats | Unit | Adapt: `praxis_deploy_timing_<stage>.prom` metric name |
|
||||
| idempotency.bats | Unit | Adapt: `/health:8789` health check in the idempotency path |
|
||||
| lxc-deploy.bats | Integration | Adapt: no PROXY_VMID/BACKEND_DOMAIN steps (v0.2 = no proxy) |
|
||||
| e2e-deploy.bats | E2E | Adapt: praxis endpoint, no proxy/smoke tests, simpler narrative |
|
||||
|
||||
**Unit-testable (no live Proxmox, ~7 files):**
|
||||
All tests that mock `api.sh` (pve_curl, pve_poll, pve_get) and `curl` can run without a live cluster. This covers: api.sh helpers, lxc-clone.sh POST shape, lxc-config.sh PUT+SSH shape, lxc-start.sh POST shape, health-check.sh URL resolution + polling, rollback.sh sequence, timing.sh JSON emission.
|
||||
|
||||
**E2E (live cluster, ~3 files):**
|
||||
- `e2e-deploy.bats` — full deploy against live Proxmox (clone → config → start → health). Requires PROXMOX_* env vars.
|
||||
- `idempotency.bats` live path — re-deploy against existing healthy CT.
|
||||
- Smoke test — `curl http://<ct-ip>:8789/health` returns `{"status":"ok"}`.
|
||||
|
||||
**Additional praxis-specific tests (not in coreci):**
|
||||
- `Dockerfile` build test — `docker build -t praxis-test .` succeeds locally (no Proxmox needed, just Docker).
|
||||
- `docker-compose.yml` validation — `docker compose config` parses.
|
||||
- FastAPI StaticFiles test — `GET /` returns index.html, `GET /health` returns JSON, `GET /pipecat/webrtc` is a valid route. (Unit test with httpx AsyncClient, no Proxmox needed.)
|
||||
|
||||
**Confidence: 0.90** — directly mirrors coreci's proven test architecture.
|
||||
|
||||
---
|
||||
|
||||
## Updated Architecture Recommendations (diff vs current ARCHITECTURE.md)
|
||||
|
||||
The current ARCHITECTURE.md is initial and lists 6 open questions. This research resolves them. Below is the diff to apply at PLAN (the orchestrator may commit an updated ARCHITECTURE.md).
|
||||
|
||||
### Resolved open questions
|
||||
|
||||
| Open question in ARCHITECTURE.md | Resolution (from this research) |
|
||||
|---|---|
|
||||
| Client framework: native Android vs cross-platform vs web PWA? | **Web (React + WebRTC) via Pipecat client SDK** for v0.1; React Native for later Android. |
|
||||
| Streaming transport: WebSocket vs WebRTC vs custom? | **WebRTC primary** (Pipecat transport); WebSocket dev fallback. |
|
||||
| ASR/TTS provider: self-hosted (Whisper/Piper) vs cloud (Deepgram/PlayHT)? | **Deepgram Nova-3 (cloud ASR) + Cartesia Sonic (cloud TTS)** primary; Piper (self-hosted) open-weights TTS fallback. |
|
||||
| Learner state store: SQLite vs Postgres for v0.1? | **SQLite** (confirmed). |
|
||||
| Ollama deployment: self-hosted vs Ollama Cloud? | **Ollama Cloud direct API** (`https://ollama.com/api/chat` + `OLLAMA_API_KEY`) for v0.1; no local daemon. Self-host `gemma4:e4b` is the post-pilot cost-reduction path. |
|
||||
| Scenario definition format: YAML/JSON DSL vs code-authored? | **YAML DSL → Pydantic model**, fed to Pipecat Flows. |
|
||||
|
||||
### Updated v0.1 component map
|
||||
## Docker-in-LXC Deployment Topology
|
||||
|
||||
```
|
||||
Client: React + WebRTC (Pipecat client SDK)
|
||||
│ audio in/out (WebRTC, UDP)
|
||||
▼
|
||||
Pipecat server (Python)
|
||||
├─ VAD: Silero
|
||||
├─ STT: Deepgram Nova-3 (cloud, streaming)
|
||||
├─ LLM: Ollama Cloud direct API
|
||||
│ ├─ gemma4:cloud (role-play fast path)
|
||||
│ └─ deepseek-v4-flash:cloud (debrief, no-think)
|
||||
├─ TTS: Cartesia Sonic (cloud) [Piper fallback behind interface]
|
||||
├─ Scenario runtime: Pipecat Flows + YAML scenarios
|
||||
├─ Guardrail layer: pluggable (v0.1: Customer Service ruleset)
|
||||
└─ Learner state: SQLite (praxis.db)
|
||||
┌─────────────────────────────────────────────────┐
|
||||
│ Proxmox VE Host (node: ns1003845) │
|
||||
│ │
|
||||
│ ┌──────────────────────────────────────────┐ │
|
||||
│ │ LXC Container (VMID: auto via pve_nextid)│ │
|
||||
│ │ hostname: praxis │ │
|
||||
│ │ memory: 4096MB rootfs: 16GB │ │
|
||||
│ │ features: nesting=1 │ │
|
||||
│ │ net0: bridge=vmbr0, ip=dhcp │ │
|
||||
│ │ hookscript: local:snippets/praxis- │ │
|
||||
│ │ firstboot.sh │ │
|
||||
│ │ │ │
|
||||
│ │ ┌─────────────────────────────────────┐ │ │
|
||||
│ │ │ Docker daemon (apt: docker.io) │ │ │
|
||||
│ │ │ │ │ │
|
||||
│ │ │ ┌───────────────────────────────┐ │ │ │
|
||||
│ │ │ │ praxis container │ │ │ │
|
||||
│ │ │ │ (python:3.12-slim + dist) │ │ │ │
|
||||
│ │ │ │ │ │ │ │
|
||||
│ │ │ │ uvicorn :8789 │ │ │ │
|
||||
│ │ │ │ ├─ /health (FastAPI) │ │ │ │
|
||||
│ │ │ │ ├─ /pipecat/webrtc (FastAPI) │ │ │ │
|
||||
│ │ │ │ └─ / (StaticFiles) │ │ │ │
|
||||
│ │ │ │ │ │ │ │
|
||||
│ │ │ │ Volume: praxis-db → /app/data │ │ │ │
|
||||
│ │ │ │ EnvFile: /etc/praxis/ │ │ │ │
|
||||
│ │ │ │ server.env │ │ │ │
|
||||
│ │ │ └───────────────────────────────┘ │ │ │
|
||||
│ │ └─────────────────────────────────────┘ │ │
|
||||
│ │ │ │
|
||||
│ │ systemd: praxis.service │ │
|
||||
│ │ ExecStartPre: docker compose build │ │
|
||||
│ │ ExecStart: docker compose up │ │
|
||||
│ │ Restart: on-failure │ │
|
||||
│ └──────────────────────────────────────────┘ │
|
||||
│ │ │
|
||||
│ vmbr0 (bridge) ─── DHCP ──── CT eth0 │
|
||||
└───────────┬──────────────────────────────────────┘
|
||||
│
|
||||
┌───────────▼───────────┐
|
||||
│ Operator / Client │
|
||||
│ http://<ct-ip>:8789 │
|
||||
│ (direct, no proxy) │
|
||||
└───────────────────────┘
|
||||
```
|
||||
|
||||
### Updated latency budget (revised with verified component choices)
|
||||
|
||||
| Segment | Budget | Source / note |
|
||||
|---|---|---|
|
||||
| Client capture + WebRTC uplink | ~50ms | WebRTC UDP, Canada region |
|
||||
| ASR (Deepgram first partial) | ~250ms | Vendor claim; **R1: measure** |
|
||||
| LLM first token (gemma4:cloud direct API) | ~200ms | **R3: measure** |
|
||||
| TTS first audio (Cartesia Sonic) | ~120ms | Vendor/leaderboard; **R2: measure** |
|
||||
| WebRTC downlink + playback | ~50ms | |
|
||||
| **Total (target)** | **~670ms** | ⚠️ Slightly over 600ms with all-cloud; **R4 mitigation**: move TTS to local Piper (~80ms) to bring total to ~550ms. |
|
||||
|
||||
**Key architecture insight:** the all-cloud three-hop path likely lands ~670ms, marginally over the 600ms target. The PLAN stage should design the TTS service behind an interface and pre-stage a Piper-on-pilot-server configuration as the likely production v0.1 choice, with Cartesia as the quality-benchmark option for non-latency-critical turns (e.g., the debrief). Alternatively, self-host `gemma4:e4b` for the LLM hop. **This is the single biggest v0.1 technical risk and must be spiked in Phase 1 week 1.**
|
||||
|
||||
### Decisions recommended for the orchestrator to record
|
||||
|
||||
| ID | Decision | Confidence | Source |
|
||||
|---|---|---|---|
|
||||
| D-003 (update) | Confirm `gemma4:cloud` + `deepseek-v4-flash:cloud` via Ollama Cloud direct API | 0.95 | This research (catalog verified) |
|
||||
| D-007 (update) | Confirm SQLite for v0.1 learner state | 0.90 | This research |
|
||||
| D-013 (new) | ASR = Deepgram Nova-3 streaming (cloud) | 0.85 | This research |
|
||||
| D-014 (new) | TTS = Cartesia Sonic (cloud) primary; Piper (self-hosted) fallback behind interface | 0.80 | This research |
|
||||
| D-015 (new) | Client = React + WebRTC via Pipecat client SDK | 0.85 | This research |
|
||||
| D-016 (new) | Transport = WebRTC (Pipecat); WebSocket dev fallback | 0.85 | This research |
|
||||
| D-017 (new) | Orchestration = Pipecat (not custom, not Vocode) | 0.85 | This research |
|
||||
| D-018 (new) | Scenario format = YAML DSL → Pydantic → Pipecat Flows | 0.85 | This research |
|
||||
| D-019 (new) | v0.1 guardrail layer = pluggable interface; Customer Service ruleset implementation | 0.80 | This research |
|
||||
| D-020 (new) | LLM access mode = Ollama Cloud direct API (no local daemon) for v0.1 | 0.85 | This research |
|
||||
|
||||
---
|
||||
|
||||
*End of research findings. Next step: orchestrator reviews this document, records decisions D-013..D-020 (and updates D-003, D-007), updates ARCHITECTURE.md, and proceeds to the PLAN phase where R1-R4 latency spikes are the first Phase 1 tasks.*
|
||||
## What's Reused Verbatim vs Adapted from CoreCI
|
||||
|
||||
| Script | Reuse | Adaptation |
|
||||
|--------|-------|------------|
|
||||
| `api.sh` | **Verbatim** | None (REQ-DEPLOY-03) |
|
||||
| `lxc-clone.sh` | Adapted | hostname=praxis, memory=4096, rootfs=16, features=nesting=1 (kept) |
|
||||
| `lxc-config.sh` | Adapted | hookscript=praxis-firstboot.sh, lxc.environment=GITEA_TOKEN/DEEPGRAM_API_KEY/PRAXIS_PORT/PRAXIS_HOST/OLLAMA_*/CARTESIA_* (empty if unprovisioned) |
|
||||
| `lxc-start.sh` | **Verbatim** | None (same POST /status/start) |
|
||||
| `health-check.sh` | Adapted | /health (not /healthz), port 8789, PRAXIS_* env names, timeout 300s |
|
||||
| `rollback.sh` | Adapted | Remove proxy backend-remove step (no proxy in v0.2) |
|
||||
| `stage-snippet.sh` | Adapted | SNIPPET_NAME=praxis-firstboot.sh, raw URL → praxis repo |
|
||||
| `timing.sh` | Adapted | Metric prefix: praxis_deploy_timing_ |
|
||||
| `lxc-deploy.sh` | Adapted | Remove PROXY_VMID/BACKEND_DOMAIN steps, PROXMOX_LXC_VMID=auto (D-027) |
|
||||
| `firstboot-hook.sh` | **Heavy adaptation** | Install Docker + git clone + docker compose build/up (not host-fetch binary) |
|
||||
| `install-service.sh` | **Heavy adaptation** | Creates praxis user (in docker group), /etc/praxis/server.env, praxis.service (docker compose up, not binary exec) |
|
||||
| `proxy/ct-exists.sh` | **Verbatim** | Used by lxc-deploy.sh idempotency (no proxy dependency in the helper itself) |
|
||||
|
||||
---
|
||||
|
||||
## Risks and Unknowns for PLAN Stage
|
||||
|
||||
| ID | Risk | Impact | Mitigation | Confidence |
|
||||
|----|------|--------|------------|------------|
|
||||
| R-DEPLOY-01 | Pipecat native-ext wheel missing for cp312/linux-amd64 → source compilation OOMs at 4GB | Build fails | Pre-test `docker build` locally; if compilation needed, bump to 8GB or use `--only-binary :all:` pip flag | 0.70 |
|
||||
| R-DEPLOY-02 | systemd `TimeoutStartSec` applies to ExecStartPre+ExecStart combined → 300s insufficient for build+up | Service fails to start | Set `TimeoutStartSec=600` or split build into a separate `praxis-build.service` (oneshot) that `praxis.service` depends on | 0.65 |
|
||||
| R-DEPLOY-03 | CT network can't reach Gitea or apt mirrors (coreci's original concern) | Clone/apt fails | Validate CT internet access at deploy time; fallback: host-clone + pct push tarball (D-025 hybrid) | 0.60 |
|
||||
| R-DEPLOY-04 | Docker-in-LXC on ZFS rootfs storage → overlay2 conflict | Build fails | Check `PROXMOX_STORAGE` type; if ZFS, use `local` (directory) storage or add `features=nesting=1,keyctl=1` | 0.50 |
|
||||
| R-DEPLOY-05 | `docker compose up` (foreground) logs flood journald | Disk fill on CT | Set `StandardOutput=journal` + log rotation; or `StandardOutput=null` for v0.2 pilot | 0.75 |
|
||||
| R-DEPLOY-06 | First-boot build takes > 5 min (NFR-DEPLOY-03 breach) | Health-check timeout | Pre-build image on PVE host + `docker save | pct exec docker load` as fallback (D-025 hybrid) | 0.60 |
|
||||
|
||||
---
|
||||
|
||||
## Open Questions for PLAN Stage
|
||||
|
||||
1. **ExecStartPre vs separate build service:** Should `docker compose build` be an `ExecStartPre` in `praxis.service` or a separate `praxis-build.service` (Type=oneshot) that `praxis.service` `Requires=`? The latter is cleaner but adds a service file.
|
||||
2. **Docker layer cleanup:** Should `install-service.sh` run `docker system prune -f` after the first successful build to reclaim ~1GB of build layers?
|
||||
3. **Repo update path:** When praxis code changes, how is the CT updated? Options: (a) `pct exec git pull && systemctl restart praxis` (re-builds), (b) `--reconfigure` flag in lxc-deploy.sh that re-runs the hook, (c) a separate `scripts/proxmox/lxc-update.sh`. Not a v0.2 blocker (first deploy only) but should be designed for.
|
||||
4. **PRAXIS_DB_PATH in container:** The docker-compose volume mounts to `/app/data`. `PRAXIS_DB_PATH` env should be set to `/app/data/praxis.db` in `server.env`. Confirm the server respects this path (current default: `./praxis.db` relative to CWD).
|
||||
+34
-62
@@ -1,90 +1,62 @@
|
||||
# Praxis — Roadmap
|
||||
|
||||
**Milestone:** v0.1 (foundation)
|
||||
**Status:** complete
|
||||
**Milestone:** v0.2 (Proxmox LXC deployment)
|
||||
**Status:** in-progress
|
||||
|
||||
## Milestone Philosophy
|
||||
|
||||
v0.1 is the **foundation milestone** — it establishes the minimal viable voice loop (one persona, one scenario, ASR+TTS+LLM round-trip, single learner state). v1.0 is reserved for a working, tested product and is a future milestone.
|
||||
v0.2 deploys praxis into a Proxmox LXC container, reusing and adapting the battle-tested deployment toolkit from `~/coreci/scripts/proxmox/`. The v0.1 voice loop becomes deployable infrastructure. v1.0 is reserved for a working, tested product and is a future milestone.
|
||||
|
||||
## v0.1 Phases (2 phases)
|
||||
## v0.2 Phases (2 phases)
|
||||
|
||||
### Phase 0 — Pre-Execution (complete)
|
||||
### Phase 0 — Pre-Execution (in-progress)
|
||||
|
||||
**Branch:** `phase/00-pre-execution` → merged to `milestone/v0.1-praxis`
|
||||
**Ship target:** `v0.0.0` (patch release, NFR milestone type — docs-only)
|
||||
**Status:** ✓ complete (tagged v0.0.0; release pending — Gitea repo not yet created)
|
||||
**Branch:** `phase/00-pre-execution` → merged to `milestone/v0.2-lxc-deploy`
|
||||
**Ship target:** `v0.1.0` (patch release, NFR milestone type — docs/planning only)
|
||||
**Status:** in-progress
|
||||
|
||||
Pipeline stages: SPECIFY → CLARIFY → RESEARCH → PLAN → GRILL
|
||||
|
||||
**Goal:** Produce all `.ciagent/` planning artifacts, validated requirements, research-grounded architecture, and persona-assigned vertical-slice plans for Phase 1.
|
||||
**Goal:** Produce all `.ciagent/` planning artifacts for v0.2: validated requirements (REQ-DEPLOY-01..16), research-grounded Docker-in-LXC architecture, persona-assigned vertical-slice plans for Phase 1.
|
||||
|
||||
**Deliverables:**
|
||||
- PROJECT.md (validated)
|
||||
- REQUIREMENTS.md (formal REQ-IDs)
|
||||
- ARCHITECTURE.md (research-refined)
|
||||
- PERSONAS.md (persona roster + territory)
|
||||
- PROJECT.md (v0.2 scope validated)
|
||||
- REQUIREMENTS.md (16 REQ-DEPLOY IDs + 4 NFR-DEPLOY IDs)
|
||||
- ARCHITECTURE.md (deployment topology: Docker-in-LXC, image distribution, secret injection)
|
||||
- PERSONAS.md (updated roster for deploy-heavy milestone)
|
||||
- Phase 1 plan (vertical slices with wave ordering)
|
||||
|
||||
### Phase 1 — Minimal Viable Voice Loop (complete)
|
||||
### Phase 1 — LXC Deploy Implementation (pending)
|
||||
|
||||
**Branch:** `phase/01-minimal-voice-loop` → merged to `milestone/v0.1-praxis`
|
||||
**Ship target:** `v0.0.1` (patch release, feature milestone type)
|
||||
**Status:** ✓ complete (tagged v0.0.1; release pending — Gitea repo not yet created)
|
||||
**Branch:** `phase/01-lxc-deploy` → merged to `milestone/v0.2-lxc-deploy`
|
||||
**Ship target:** `v0.1.1` (patch release, feature milestone type)
|
||||
**Status:** pending
|
||||
|
||||
**Goal:** A single learner can open the client, speak to an AI tutor playing a Customer Service role-play scenario, hear the tutor respond with <600ms round-trip latency, and have the session logged to learner state.
|
||||
**Goal:** A working `lxc-deploy.sh` orchestrator that clones a Debian template from the Proxmox cluster, configures the CT with Docker + nesting, builds/loads the praxis Docker image on first boot, starts the service via systemd, and health-checks `/health` :8789 — all idempotent with rollback on failure.
|
||||
|
||||
**Implemented (5 slices, 3 waves, 26 tasks, 22 commits):**
|
||||
1. SLICE-01 — Latency spike probes (R1-R4) + report
|
||||
2. SLICE-02 — Thin vertical voice loop (walking skeleton: Pipecat + Deepgram + Cartesia/Piper + Ollama Cloud + React/WebRTC)
|
||||
3. SLICE-03 — Branching scenario (YAML→Pydantic→Pipecat Flows) + guardrails + interruptibility
|
||||
4. SLICE-04 — SQLite learner state + per-session cost logging
|
||||
5. SLICE-05 — Coaching debrief (deepseek-v4-flash no-think) + full React client UX + e2e smoke
|
||||
### Final Phase (P2) — Review + Ship (pending)
|
||||
|
||||
**Verification:** 73 tests pass, 9 skipped (pending live API keys), 0 failed. 15/15 P1 REQ-IDs covered. 2 P0 fixes applied. 6 P1+ flagged for post-hoc review.
|
||||
|
||||
### Final Phase (P2) — Review + Ship (complete)
|
||||
|
||||
**Branch:** `phase/02-final-review-ship` → merged to `milestone/v0.1-praxis` → merged to `main`
|
||||
**Ship target:** final patch = v0.1 milestone release
|
||||
**Status:** ✓ complete (review APPROVE_WITH_NOTES, audit HEALTHY)
|
||||
**Branch:** `phase/02-final-review-ship` → merged to `milestone/v0.2-lxc-deploy` → merged to `main`
|
||||
**Ship target:** final patch = v0.2 milestone release
|
||||
**Status:** pending
|
||||
|
||||
**Goal:** Multi-persona code review, project audit, milestone merge to main, milestone release.
|
||||
|
||||
**Outcome:** 0 P0 issues (2 from VERIFY confirmed in place), 9 P1+ flagged for post-hoc review, 0 escalations. Audit HEALTHY (0 critical, 3 cosmetic warnings fixed). 15/15 REQ-IDs verified.
|
||||
## v0.1 Milestone (complete — reference)
|
||||
|
||||
## Future Milestones (post-v0.1, indicative)
|
||||
v0.1 was the **foundation milestone** — minimal viable voice loop (one persona, one scenario, ASR+TTS+LLM round-trip, single learner state). Shipped as `v0.0.0` (phase 0) → `v0.0.1` (phase 1) → `v0.0.2` (final/milestone release).
|
||||
|
||||
## Future Milestones (post-v0.2, indicative)
|
||||
|
||||
| Milestone | Scope (indicative) |
|
||||
|-----------|-------------------|
|
||||
| v0.2 | Mastery scoring + competency rubrics for the Customer Service path |
|
||||
| v0.3 | Second scenario + second persona; Drill Mode |
|
||||
| v0.4 | Live Assist on-the-job companion |
|
||||
| v0.5 | Low-bandwidth surfaces (WhatsApp, offline cache) |
|
||||
| v0.6 | Multi-language (French-Canadian, then PRD's 10-language list) |
|
||||
| v0.7 | Employer / program dashboard |
|
||||
| v0.8 | Credentialing (verifiable, shareable) |
|
||||
| v0.9 | USSD fallback, feature-phone support |
|
||||
| v0.3 | Mastery scoring + competency rubrics for the Customer Service path (deferred from original v0.2) |
|
||||
| v0.4 | Second scenario + second persona; Drill Mode |
|
||||
| v0.5 | Live Assist on-the-job companion |
|
||||
| v0.6 | Low-bandwidth surfaces (WhatsApp, offline cache) |
|
||||
| v0.7 | Multi-language (French-Canadian, then PRD's 10-language list) |
|
||||
| v0.8 | Employer / program dashboard |
|
||||
| v0.9 | Credentialing (verifiable, shareable) |
|
||||
| v1.0 | Working, tested product — multiple paths, multi-market, production-ready |
|
||||
|
||||
These are indicative and will be refined by ci-roadmapper at the start of each milestone.
|
||||
|
||||
## Requirement Coverage (v0.1 final — verified)
|
||||
|
||||
| REQ-ID | Phase | Status |
|
||||
|--------|-------|--------|
|
||||
| REQ-VOICE-01 | P1 | ✓ covered |
|
||||
| REQ-VOICE-02 | P1 | ✓ covered |
|
||||
| REQ-VOICE-03 | P1 | ✓ covered (probe built; live number pending keys) |
|
||||
| REQ-VOICE-04 | P1 | ✓ covered |
|
||||
| REQ-SCEN-01 | P1 | ✓ covered |
|
||||
| REQ-STATE-01 | P1 | ✓ covered |
|
||||
| REQ-LLM-01 | P1 | ✓ covered (live call pending keys) |
|
||||
| REQ-LLM-02 | P1 | ✓ covered (live call pending keys) |
|
||||
| REQ-DEBRIEF-01 | P1 | ✓ covered |
|
||||
| REQ-ORCH-01 | P1 | ✓ covered |
|
||||
| REQ-ORCH-02 | P1 | ✓ covered |
|
||||
| REQ-SCEN-FMT-01 | P1 | ✓ covered |
|
||||
| REQ-NFR-LAT-01 | P1 | ✓ covered (probe built; live number pending keys) |
|
||||
| REQ-NFR-COST-01 | P1 | ✓ covered (logging) |
|
||||
| REQ-NFR-SAFE-01 | P1 | ✓ covered (baseline) |
|
||||
These are indicative and will be refined by ci-roadmapper at the start of each milestone.
|
||||
@@ -3,7 +3,7 @@
|
||||
{
|
||||
"slug": "praxis",
|
||||
"name": "Praxis",
|
||||
"milestone": "v0.1",
|
||||
"milestone": "v0.2",
|
||||
"status": "specify"
|
||||
}
|
||||
],
|
||||
@@ -91,6 +91,14 @@
|
||||
{
|
||||
"name": "release",
|
||||
"env_vars": ["GITEA_TOKEN"]
|
||||
},
|
||||
{
|
||||
"name": "proxmox",
|
||||
"env_vars": ["PROXMOX_API_URL", "PROXMOX_API_TOKEN", "PROXMOX_NODE", "PROXMOX_STORAGE", "PROXMOX_TEMPLATE_VOLID", "PROXMOX_LXC_VMID", "PROXMOX_TLS_SKIP_VERIFY"]
|
||||
},
|
||||
{
|
||||
"name": "voice",
|
||||
"env_vars": ["DEEPGRAM_API_KEY", "CARTESIA_API_KEY", "OLLAMA_API_KEY"]
|
||||
}
|
||||
]
|
||||
},
|
||||
|
||||
@@ -0,0 +1,43 @@
|
||||
# Praxis v0.1 — Environment Configuration
|
||||
# Copy to `.env` and fill in real values. See docs/latency-report.md for key-provisioning status.
|
||||
# At v0.1 EXECUTE time, only GITEA_TOKEN is provisioned; voice-service keys are pending.
|
||||
|
||||
# ─── Voice services ──────────────────────────────────────────────────────────
|
||||
# Deepgram Nova-3 ASR (D-013). Get from https://console.deepgram.com/
|
||||
DEEPGRAM_API_KEY=
|
||||
|
||||
# Cartesia Sonic TTS (D-014, primary). Get from https://cartesia.ai/
|
||||
CARTESIA_API_KEY=
|
||||
|
||||
# Ollama Cloud direct API (D-020). Get from https://ollama.com/ → Settings → API Keys
|
||||
OLLAMA_API_KEY=
|
||||
|
||||
# ─── TTS selection (D-014) ────────────────────────────────────────────────────
|
||||
# cartesia (default, cloud, ~120ms first-audio) | piper (self-hosted, ~80ms, R4 mitigation)
|
||||
PRAXIS_TTS=cartesia
|
||||
|
||||
# ─── Ollama Cloud endpoints (D-020) ───────────────────────────────────────────
|
||||
# Direct API mode (no local daemon). Pipecat's OLLamaLLMService uses the OpenAI-compatible path.
|
||||
OLLAMA_BASE_URL=https://ollama.com/v1
|
||||
OLLAMA_CHAT_URL=https://ollama.com/api/chat
|
||||
# Role-play fast path (256K ctx, low-latency)
|
||||
OLLAMA_ROLEPLAY_MODEL=gemma4:cloud
|
||||
# Debrief + branch classifier (1M ctx, no-think mode for latency)
|
||||
OLLAMA_DEBRIEF_MODEL=deepseek-v4-flash:cloud
|
||||
|
||||
# ─── Server ───────────────────────────────────────────────────────────────────
|
||||
PRAXIS_HOST=0.0.0.0
|
||||
PRAXIS_PORT=8789
|
||||
PRAXIS_DB_PATH=./praxis.db
|
||||
PRAXIS_SCENARIOS_DIR=./scenarios
|
||||
|
||||
# ─── Deepgram live options (D-013) ────────────────────────────────────────────
|
||||
DEEPGRAM_MODEL=nova-3
|
||||
DEEPGRAM_LANGUAGE=en
|
||||
DEEPGRAM_REGION=na
|
||||
|
||||
# ─── Cartesia voice (D-006 — one voice for role-play + mentor) ────────────────
|
||||
CARTESIA_VOICE_ID=a3536a36-1d18-4efb-a95a-7c44b7b5e384
|
||||
|
||||
# ─── CI/Gitea (operational — not voice) ───────────────────────────────────────
|
||||
# GITEA_TOKEN is provisioned in .ciagent/.env.secrets (not this file).
|
||||
@@ -11,6 +11,7 @@ venv/
|
||||
.env
|
||||
.env.secrets
|
||||
.env.*
|
||||
!.env.example
|
||||
|
||||
# SQLite
|
||||
*.db
|
||||
|
||||
Reference in New Issue
Block a user