# 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. ```yaml --- 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" --- ``` ```yaml --- 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/**" --- ``` ```yaml --- 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/**" --- ``` ```yaml --- 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" --- ``` ```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) ```yaml --- 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: [] --- ``` ```yaml --- 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. --- # Praxis — Persona Assessment (v0.3 Mastery Scoring) > **Generated:** v0.3 RESEARCH stage > **Project:** Praxis (v0.3 — mastery scoring + competency rubrics + VC + cohort dashboard) > **Source:** v0.3 RESEARCH.md + v0.3 REQUIREMENTS.md (REQ-MAST-01/02/03, REQ-SCEN-02/03/04, REQ-PATH-02, REQ-DASH-01, REQ-AUTH-01, REQ-MT-01/02) ## v0.3 Persona Roster ### Active personas (5) The v0.3 milestone is **mastery-backend + operator-frontend + security-heavy**. The frontend-engineer **reactivates** (cohort dashboard UI — D-044). A new **security-engineer** persona is added (VC crypto + auth — D-033/D-041/D-042). The devops-engineer from v0.2 is **deactivated** (no new deploy scripts in v0.3 — the Postgres-in-LXC addition is owned by backend-engineer + data-engineer since it's a docker-compose service addition, not a deploy-script change). The data-engineer expands territory to cover the Postgres operator-tier schema. ```yaml --- name: lead-developer active: true phase_specific: false reason: Coordinates task decomposition across mastery/rubric/IRT/VC/auth/cohort/dashboard domains. Resolves conflicts between backend (mastery engine), security (VC + auth), data (Postgres + SQLite hybrid), and frontend (dashboard UI). Owns the docker-compose.yml Postgres service addition (spans data + backend). Required for every milestone. domain: coordination frameworks: [pipecat, fastapi, postgres, docker] constraints: [pragmatic, battle-tested defaults, mastery-off-voice-path, hybrid-storage-no-cross-db-joins, k-anonymity-floor-10] territory: - "docker-compose.yml" - ".env.example" --- ``` ```yaml --- name: backend-engineer active: true phase_specific: false reason: Owns the majority of v0.3 server-side logic: rubric engine (server/mastery/), IRT engine, scenario library, path engine, cohort aggregation pipeline, operator API routes, Postgres asyncpg pool wiring, session_recorder.py extension for rubric/IRT hooks. The mastery scoring flow (off the voice path) is the largest single territory in v0.3. domain: backend frameworks: [pipecat, pydantic, fastapi, uvicorn, asyncpg, aiosqlite] constraints: [api-first, type-safe, mastery-off-voice-path, deterministic-scoring, latency-budget-aware, routes-before-static-mount, no-cross-db-joins] territory: - "**/server/**" - "**/mastery/**" - "**/scenarios/**" - "**/paths/**" - "**/cohort/**" - "**/operator/**" - "**/db/**" --- ``` ```yaml --- name: frontend-engineer active: true phase_specific: false reason: REACTIVATED for v0.3. Owns the cohort dashboard UI (React /operator/* route — D-044, REQ-DASH-01). Auth-gated React route + k-anonymized cohort views (practice, mastery progression, failure patterns). Reuses v0.2 StaticFiles + same client/dist build. No new build pipeline. First client-side feature work since v0.1. domain: frontend frameworks: [react, pipecat-client-sdk, webrtc, vite, fastapi-staticfiles] constraints: [component-first, auth-gated-operator-routes, k-anonymity-display-suppressed-cells, no-raw-learner-pii-in-ui] territory: - "**/client/**" - "**/client/src/operator/**" --- ``` ```yaml --- name: data-engineer active: true phase_specific: false reason: EXPANDED territory for v0.3. Owns the Postgres operator-tier schema (operators, issued_credentials, mastery_gate_events, cohort_aggregates, issuer_keys — D-040), the db/pg_migrations/ migration runner, the SQLite v0.3 additions (learner_ability, mastery_progress tables — D-046), and the k-anonymity suppression queries (D-034). The hybrid SQLite+Postgres storage pattern (D-031) is the data-engineer's architectural concern — no cross-DB joins, opaque learner_ref. domain: data frameworks: [sqlite, postgres16, aiosqlite, asyncpg, alembic-style-migrations] constraints: [schema-first, type-safe, migration-driven, no-cross-db-joins, k-anonymity-floor-10, opaque-learner-ref, weekly-partitions-cohort-aggregates] territory: - "**/db/**" - "**/db/migrations/**" - "**/db/pg_migrations/**" - "**/db/schema.sql" - "**/db/pg_schema.sql" --- ``` ```yaml --- name: security-engineer active: true phase_specific: true reason: NEW persona for v0.3. Owns the VC issuer (server/vc/ — Ed25519 signing, JCS canonicalization, Bitstring Status List, verification endpoint — D-033/D-042/D-043) and the operator auth stack (server/auth/ — argon2id, session cookies, rate limiting — D-041). VC crypto + auth are security-critical and outside the default four personas' expertise. Created as phase-specific because v0.3 is the first security-crypto-heavy milestone; may persist into v0.9 (credentialing) but deactivate in between. domain: security frameworks: [pynacl, canonicaljson, base58, argon2-cffi, starlette-sessionmiddleware, slowapi] constraints: [eddsa-jcs-2022-cryptosuite, no-plaintext-keys-in-git, issuer-key-encrypted-at-rest, argon2id-passwords, secure-cookies-require-tls-R-AUTH-01, public-verification-no-pii] territory: - "**/server/vc/**" - "**/server/auth/**" - "**/vc/**" - "**/auth/**" --- ``` ### Deactivated personas (1) ```yaml --- name: devops-engineer active: false phase_specific: true reason: DEACTIVATED for v0.3. No new Proxmox/deploy scripts in v0.3 — the v0.2 LXC deployment carries forward unchanged. The Postgres-in-LXC addition (D-040) is a docker-compose service addition owned by lead-developer (compose file) + data-engineer (schema) + backend-engineer (asyncpg wiring), not a deploy-script change. Will reactivate if v0.3 adds deploy hardening (Traefik/TLS) or if a CT memory bump requires lxc-config changes. domain: devops frameworks: [proxmox-lxc, docker, systemd, bash] constraints: [idempotent-deploy, rollback-on-failure, battle-tested-coreci-toolkit] territory: [] --- ``` ## v0.3 Notes for PLAN/EXECUTE - Territory enforcement mode: `warn` (per config.json `personas.territory_enforcement`) - The **backend-engineer owns the majority of v0.3 task surface** (mastery engine + IRT + library + paths + cohort aggregation + operator API + Postgres wiring). This is the largest backend surface since v0.1. - The **security-engineer's v0.3 surface is the most security-critical**: VC issuer keys + operator auth. Any P0/P1 finding here blocks ship. - The **frontend-engineer reactivates** after v0.2 deactivation — the cohort dashboard is the first client-side feature since v0.1. - The **data-engineer's v0.3 surface spans two stores** (SQLite v0.3 tables + Postgres operator tier) — the hybrid pattern (D-031) is the architectural concern. - Cross-persona collaboration points: - backend-engineer (mastery_gate_event write) ↔ data-engineer (Postgres schema) ↔ security-engineer (VC issuance on gate-open) - frontend-engineer (dashboard UI) ↔ backend-engineer (operator API) ↔ data-engineer (k-anonymity queries) - security-engineer (issuer key) ↔ data-engineer (issuer_keys table, encrypted-at-rest) - The security-engineer is NOT in config.json `personas` — emergent persona defined in PERSONAS.md (same pattern as v0.2 devops-engineer). Territory enforcement (warn mode) picks up globs from PERSONAS.md. - R-AUTH-01 (Secure cookie + no-TLS) is a security-engineer + lead-developer collaboration point for PLAN.