praxis/.ciagent/PERSONAS.md

Praxis — Persona Assessment

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 (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.

---
name: lead-developer
active: true
phase_specific: false
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, docker, proxmox-lxc]
constraints: [pragmatic, battle-tested defaults, reuse-coreci-toolkit, latency-budget-aware (<600ms)]
territory:
  - "Dockerfile"
  - "docker-compose.yml"
  - ".dockerignore"
---

---
name: backend-engineer
active: true
phase_specific: false
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, fastapi, uvicorn, docker]
constraints: [api-first, type-safe, latency-budget-aware, routes-before-static-mount, streaming-first]
territory:
  - "**/server/**"
  - "**/pipecat/**"
  - "**/services/**"
  - "**/scenarios/**"
  - "**/guardrails/**"
  - "**/db/**"
  - "**/llm/**"
  - "**/asr/**"
  - "**/tts/**"
---

---
name: frontend-engineer
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, vite]
constraints: [component-first, voice-first-ui, minimal-client-javascript, webRTC-audio-pipeline]
territory:
  - "**/client/**"
  - "**/ui/**"
  - "**/components/**"
  - "**/web/**"
---

---
name: data-engineer
active: true
phase_specific: false
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, aiosqlite, docker-volumes]
constraints: [schema-first, type-safe, migration-driven, single-learner-no-auth, volume-persistence]
territory:
  - "**/migrations/**"
  - "**/schema/**"
  - "**/models/**"
  - "**/db/**"
  - "**/scenarios/*.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"
---

Deactivated personas (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)

---
name: voice-engineer
active: false
phase_specific: false
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]
territory: []
---

---
name: ml-engineer
active: false
phase_specific: false
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]
territory: []
---

Framework Alignment (v0.2 overrides)

The v0.2 milestone adds deployment frameworks to the persona skill sets:

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

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

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

Two personas are phase-specific for v0.2:

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 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.