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.

---

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.

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

---
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/**"
---

---
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/**"
---

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

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

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

---

Praxis — Persona Assessment (v0.4 Operator Tier)

Generated: v0.4 RESEARCH stage Project: Praxis (v0.4 — operator tier: cohort dashboard, auth, Postgres) Source: v0.4 RESEARCH-v0.4-operator-tier.md + v0.4 REQUIREMENTS.md (REQ-MT-01/02, REQ-AUTH-01, REQ-DASH-01, 4 NFRs) + actual pyproject.toml + client/package.json + server/ structure

v0.4 Persona Roster

Active personas (6)

The v0.4 milestone is operator-tier-backend + dashboard-frontend + security-crypto + Postgres-in-LXC. The frontend-engineer (reactivated in v0.3 anticipatory, now confirmed for v0.4 dashboard UI) and devops-engineer (deactivated in v0.3, reactivated for Postgres-in-LXC + backup + bootstrap script) are both active. The security-engineer is retained (VC key migration SQLite→Postgres + auth stack + Secure-cookie-TLS resolution). The data-engineer expands to the Postgres operator-tier schema + aggregation SQL. All 6 personas are active — the largest roster since v0.1.

---
name: lead-developer
active: true
phase_specific: false
reason: Coordinates task decomposition across Postgres/auth/cohort/dashboard/VC-migration domains. Resolves conflicts between backend (operator API + aggregation), security (auth + VC key migration), data (Postgres schema + k-anon), frontend (dashboard UI), and devops (Postgres service + CT bump + backup). Owns the docker-compose.yml Postgres service addition (spans data + backend + devops). Required for every milestone.
domain: coordination
frameworks: [pipecat, fastapi, postgres, docker]
constraints: [pragmatic, battle-tested defaults, hybrid-storage-no-cross-db-joins, k-anonymity-floor-10, no-raw-learner-pii-in-postgres, mastery-off-voice-path, aggregation-off-voice-path]
territory:
  - "docker-compose.yml"
  - ".env.example"
---

---
name: backend-engineer
active: true
phase_specific: false
reason: Owns the asyncpg pool wiring (app.state.pg_pool via lifespan — D-050), the operator API routes (server/operator/ — 8 endpoints per D-053/D-057), the cohort aggregation pipeline (server/cohort/ — on-session-end async hook + nightly reconciliation job per D-054), and the session_recorder.py extension to chain the aggregation hook after the mastery flow. Also owns the SPA fallback route in server/__main__.py (required for React Router /operator/* routes). The aggregation pipeline is the largest new backend territory in v0.4.
domain: backend
frameworks: [pipecat, pydantic, fastapi, uvicorn, asyncpg, aiosqlite]
constraints: [api-first, type-safe, mastery-off-voice-path, aggregation-off-voice-path, deterministic-scoring, latency-budget-aware, routes-before-static-mount, no-cross-db-joins, asyncpg-pool-on-app-state]
territory:
  - "**/server/**"
  - "**/server/operator/**"
  - "**/server/cohort/**"
  - "**/server/__main__.py"
  - "**/session_recorder.py"
---

---
name: frontend-engineer
active: true
phase_specific: false
reason: REACTIVATED (confirmed for v0.4 — was anticipatory in v0.3). Owns the React cohort dashboard UI (client/src/operator/ — D-044, REQ-DASH-01, D-053). Auth-gated /operator/* routes + 3 k-anonymized views (practice volume, mastery progression, failure patterns). Adds React Router (react-router-dom@^7 — NEW dep) for /operator/* routing. Renders read-only tables + inline SVG sparklines (zero-dep, ~50 LOC). Auth gate: GET /api/operator/me on mount → redirect to /operator/login if 401. Reuses v0.2 StaticFiles (same client/dist build — D-044). No separate SPA build.
domain: frontend
frameworks: [react, react-router-dom, 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, spa-fallback-for-operator-routes, inline-svg-sparklines-no-chart-lib]
territory:
  - "**/client/**"
  - "**/client/src/operator/**"
  - "**/client/src/App.tsx"
  - "**/client/package.json"
---

---
name: data-engineer
active: true
phase_specific: false
reason: EXPANDED territory for v0.4. Owns the Postgres operator-tier schema (operators, issued_credentials, mastery_gate_events, cohort_aggregates, issuer_keys — D-040, refined by D-050..D-053), the db/pg_migrations/ migration runner (mirrors the existing db/migrate.py pattern), the db/pg_store.py (asyncpg-backed Postgres store), the IssuerKeyStore protocol/ABC (D-051 migration — both PraxisStore and PgStore implement it), and the k-anonymity suppression SQL (D-034 — write-time COUNT(DISTINCT learner_ref) >= 10 check). The hybrid SQLite+Postgres storage pattern (D-031) is the data-engineer's architectural concern — no cross-DB joins, opaque learner_ref. The cohort_aggregates table is a plain table (NOT partitioned — v0.4 scale; partitioning deferred post-pilot per RESEARCH-v0.4 §1.7).
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, write-time-suppression, plain-table-no-partitions-v0.4, gen-random-uuid-no-extension]
territory:
  - "**/db/**"
  - "**/db/migrations/**"
  - "**/db/pg_migrations/**"
  - "**/db/schema.sql"
  - "**/db/pg_schema.sql"
  - "**/db/pg_store.py"
  - "**/db/pg_migrate.py"
---

---
name: security-engineer
active: true
phase_specific: true
reason: RETAINED from v0.3. Owns the VC issuer key migration (D-051 — SQLite→Postgres, v0.3 public key archived as superseded, fresh v0.4 keypair, encrypted at rest) and the operator auth stack (D-041, D-056, D-057 — argon2id passwords, signed stateless cookies via Starlette SessionMiddleware, slowapi 5/min rate limit, server-side auth enforcement on every /api/operator/* request). The Secure-cookie-TLS tension (R-AUTH-01) is the security-engineer's v0.4 collaboration point with lead-developer — resolution is config-driven PRAXIS_COOKIE_SECURE (default true; false for HTTP pilot with logged WARNING). The VC key migration is high-severity risk R-VC-MIG-01 — archiving the v0.3 public key before activating the new key is security-critical. argon2-cffi PasswordHasher defaults (t=3, m=64MiB, p=4) exceed OWASP minimums (verified 2026-08-04).
domain: security
frameworks: [pynacl, canonicaljson, base58, argon2-cffi, starlette-sessionmiddleware, slowapi, itsdangerous]
constraints: [eddsa-jcs-2022-cryptosuite, no-plaintext-keys-in-git, issuer-key-encrypted-at-rest, argon2id-passwords-owasp-minimums, config-driven-secure-cookie, superseded-not-revoked, server-side-auth-enforcement, public-verification-no-pii]
territory:
  - "**/server/vc/**"
  - "**/server/auth/**"
  - "**/vc/**"
  - "**/auth/**"
---

---
name: devops-engineer
active: true
phase_specific: true
reason: REACTIVATED for v0.4 (was deactivated in v0.3 — no deploy scripts). v0.4 adds Postgres as a second Docker service in the existing LXC CT (D-040), which is devops territory: the docker-compose Postgres service definition + praxis-net bridge network + pgdata/pgbackups named volumes + pg_isready healthcheck + CT memory bump (4GB→6GB) + host-side cron for nightly pg_dump backup (D-055) + the scripts/create-operator.py bootstrap CLI (D-052) + .env.example operator vars (PRAXIS_PG_PASSWORD, PRAXIS_COOKIE_SECRET, PRAXIS_BOOTSTRAP_OPERATOR_USER/PASS, PRAXIS_VC_ISSUER_KEY). The Postgres-in-LXC addition is NOT just a docker-compose service addition (as v0.3 assumed) — it involves CT resource bump (lxc-config.sh memory change), backup cron setup, and the bootstrap script. Will deactivate again in v0.5 unless deploy hardening continues.
domain: devops
frameworks: [proxmox-ve-api, lxc, docker, systemd, bash, bats, gitea, pg_dump, cron]
constraints: [idempotent-deploy, rollback-on-failure, secrets-never-committed, posix-sh-compatible, pg-dump-backup-retention-7d, host-side-cron-decoupled-from-app, ct-memory-bump-6gb]
territory:
  - "scripts/proxmox/**"
  - "scripts/install-service.sh"
  - "scripts/create-operator.py"
  - "scripts/proxmox/praxis.service"
  - "scripts/proxmox/test/**"
  - ".env.example"
---

Deactivated personas (0)

All 6 personas are active for v0.4. No deactivations.

Proposed personas (not v0.4)

---
name: voice-engineer
active: false
phase_specific: false
reason: PROPOSED for v0.5+ (Live Assist) when latency tuning, accent modeling, and multi-voice personas become central. v0.4 uses Pipecat's built-in voice pipeline (Silero VAD + Deepgram + Cartesia/Piper), so a dedicated voice-engineer is not warranted.
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.6+ when fine-tuning Ollama models on Canadian English / role-play data becomes relevant. v0.4 uses 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.4 — from actual pyproject.toml + client/package.json)

Persona	Frameworks (v0.4 research-aligned)	New in v0.4	Source
lead-developer	pipecat, fastapi, postgres, docker	—	pyproject.toml + docker-compose.yml
backend-engineer	pipecat, pydantic, fastapi, uvicorn, asyncpg, aiosqlite	asyncpg	pyproject.toml
frontend-engineer	react, react-router-dom, pipecat-client-sdk, webrtc, vite, fastapi-staticfiles	react-router-dom	client/package.json
data-engineer	sqlite, postgres16, aiosqlite, asyncpg, alembic-style-migrations	postgres16, asyncpg	pyproject.toml + db/migrate.py
security-engineer	pynacl, canonicaljson, base58, argon2-cffi, starlette-sessionmiddleware, slowapi, itsdangerous	argon2-cffi, slowapi	pyproject.toml + RESEARCH-v0.4
devops-engineer	proxmox-ve-api, lxc, docker, systemd, bash, bats, gitea, pg_dump, cron	pg_dump, cron	scripts/proxmox/ + docker-compose.yml

Territory Alignment (v0.4 — from actual server/ structure)

The actual server/ structure: asr/, tts/, llm/, guardrails/, scenarios/, mastery/, paths/, vc/, services/, pipeline.py, session_recorder.py, __main__.py, cost.py, debrief.py, latency.py, interruptibility.py. v0.4 adds: server/operator/ (operator API), server/auth/ (auth middleware), server/cohort/ (aggregation pipeline), db/pg_store.py, db/pg_migrate.py, db/pg_migrations/, db/pg_schema.sql, scripts/create-operator.py, client/src/operator/.

Key territory boundaries:

• docker-compose.yml → lead-developer (spans praxis + postgres services + networks + volumes; collaborates with data + devops)
• server/__main__.py (SPA fallback) → backend-engineer (the catch-all route before StaticFiles mount — D-044 SPA fallback)
• server/operator/ → backend-engineer (operator API routes)
• server/auth/ → security-engineer (auth middleware, argon2, cookies, rate limit)
• server/cohort/ → backend-engineer (aggregation pipeline — hook + nightly job)
• server/vc/issuer_keys.py → security-engineer (IssuerKeyStore protocol refactor — D-051)
• db/pg_store.py + db/pg_schema.sql + db/pg_migrations/ → data-engineer (Postgres store + schema + migrations)
• scripts/create-operator.py → devops-engineer (operator bootstrap CLI — D-052)
• scripts/proxmox/ → devops-engineer (CT memory bump if lxc-config.sh changes)
• client/src/operator/ → frontend-engineer (dashboard UI)
• client/src/App.tsx → frontend-engineer (React Router wrapper + SPA fallback integration)
• client/package.json → frontend-engineer (react-router-dom addition)
• .env.example → devops-engineer (operator vars: PRAXIS_PG_PASSWORD, PRAXIS_COOKIE_SECRET, PRAXIS_BOOTSTRAP_OPERATOR_USER/PASS, PRAXIS_VC_ISSUER_KEY)

Constraint Alignment (v0.4-specific)

• All personas: hybrid-storage-no-cross-db-joins (D-031), k-anonymity-floor-10 (D-034), no-raw-learner-pii-in-postgres (D-031).
• lead-developer: aggregation-off-voice-path (D-054 — async fire-and-forget, must not block session-end response).
• backend-engineer: mastery-off-voice-path (C-8 carry-forward), aggregation-off-voice-path (D-054), asyncpg-pool-on-app-state (D-050 — pool created in lifespan, not per-request), routes-before-static-mount (carry-forward + SPA fallback catch-all before StaticFiles).
• frontend-engineer: auth-gated-operator-routes (D-057), k-anonymity-display-suppressed-cells (D-034 — render "— (<10 learners)" for suppressed cells), no-raw-learner-pii-in-ui (D-031), spa-fallback-for-operator-routes (new — React Router needs index.html fallback), inline-svg-sparklines-no-chart-lib (RESEARCH-v0.4 §4.3 — zero-dep sparklines).
• data-engineer: no-cross-db-joins (D-031), opaque-learner-ref (D-031 — learner_ref is opaque string, not FK), write-time-suppression (D-034 — cell suppression at write time, not read time), plain-table-no-partitions-v0.4 (RESEARCH-v0.4 §1.7 — partitioning deferred post-pilot), gen-random-uuid-no-extension (PG16 core, no pgcrypto).
• security-engineer: argon2id-passwords-owasp-minimums (D-041 + OWASP — PasswordHasher defaults exceed minimums), config-driven-secure-cookie (R-AUTH-01 resolution — PRAXIS_COOKIE_SECURE env var), issuer-key-encrypted-at-rest (D-042 — nacl.SecretBox with PRAXIS_VC_ISSUER_KEY root key), superseded-not-revoked (D-051 — v0.3 public key archived as superseded, not revoked), server-side-auth-enforcement (D-057 — server checks cookie on every /api/operator/* request, React guard is UX only), public-verification-no-pii (D-043 carry-forward).
• devops-engineer: idempotent-deploy (carry-forward), secrets-never-committed (carry-forward), pg-dump-backup-retention-7d (D-055 — %u day-of-week rolling 7-file), host-side-cron-decoupled-from-app (RESEARCH-v0.4 §1.5 — backup runs even if praxis is down), ct-memory-bump-6gb (REQ-NFR-MT-01 — 4GB→6GB).

Phase-Specific Personas

Two personas are phase-specific for v0.4:

1. security-engineer — phase_specific: true. Retained from v0.3 (was new in v0.3 for VC crypto). May persist into v0.9 (credentialing) but deactivate in between if no security-crypto work. The VC key migration + auth stack are the v0.4 security-critical surfaces.

2. devops-engineer — phase_specific: true. Reactivated from v0.2 (was deactivated in v0.3). v0.4 is Postgres-in-LXC heavy (docker-compose service + CT bump + backup + bootstrap). Will deactivate again in v0.5 unless deploy hardening continues.

v0.4 Notes for PLAN/EXECUTE

• Territory enforcement mode: warn (per config.json personas.territory_enforcement)
• The backend-engineer owns the largest v0.4 task surface: asyncpg pool + operator API (8 endpoints) + aggregation pipeline (hook + nightly job) + session_recorder extension + SPA fallback. This is the largest backend surface since v0.3.
• The frontend-engineer reactivates for confirmed dashboard work (v0.3 was anticipatory; v0.4 is the real dashboard implementation). React Router addition + SPA fallback + 3 k-anonymized views + inline SVG sparklines.
• The security-engineer's v0.4 surface is high-severity: VC key migration (R-VC-MIG-01 — archiving v0.3 public key is security-critical) + auth stack (R-AUTH-01 — Secure cookie + no-TLS resolution).
• The data-engineer's v0.4 surface spans two stores (SQLite v0.3 + Postgres v0.4) + the IssuerKeyStore protocol (D-051 migration bridge).
• The devops-engineer's v0.4 surface is smaller than v0.2 but critical: docker-compose Postgres service + CT memory bump + backup cron + bootstrap script.
• Cross-persona collaboration points:
  • backend-engineer (aggregation hook in session_recorder) ↔ data-engineer (cohort_aggregates schema + suppression SQL) ↔ security-engineer (learner_ref is opaque, no PII)
  • frontend-engineer (dashboard UI) ↔ backend-engineer (operator API endpoints) ↔ data-engineer (k-anonymity queries)
  • security-engineer (IssuerKeyStore protocol) ↔ data-engineer (PgStore implements it) — D-051 migration
  • security-engineer (auth middleware) ↔ backend-engineer (operator API router dependencies) — D-057
  • devops-engineer (docker-compose Postgres) ↔ lead-developer (compose file owner) ↔ data-engineer (pgdata volume + schema)
  • devops-engineer (create-operator.py) ↔ security-engineer (argon2id hashing) — D-052
• The security-engineer and devops-engineer are NOT in config.json personas — emergent personas defined in PERSONAS.md (same pattern as v0.2/v0.3). 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 GRILL-v0.4 (config-driven flag resolution must be grill-approved).
• R-VC-MIG-01 (VC key migration) is a security-engineer + data-engineer collaboration point (archive v0.3 public key before activating new key).

---

Praxis — Persona Assessment (v0.5 Live Assist)

Generated: v0.5 RESEARCH stage Project: Praxis (v0.5 — Live Assist: on-the-job voice companion, wake-word, guardrails, cohort aggregation extension) Source: v0.5 RESEARCH-v0.5-live-assist.md + v0.5 REQUIREMENTS.md (REQ-ASSIST-01/02/03, REQ-NFR-ASSIST-01..04) + actual server/ structure + db/ structure

v0.5 Persona Roster

Active personas (5)

The v0.5 milestone is voice-pipeline-heavy (wake-word + assist mode + latency tuning) + safety-critical guardrails + cohort aggregation extension. The voice-engineer reactivates (proposed at line 458 for v0.5+ — now confirmed). The devops-engineer deactivates (no deploy changes — v0.4 LXC carries forward). The frontend-engineer deactivates provisionally (assist UI is minimal — ~100-150 LOC, below the reactivation threshold; reactivate if the assist control surface exceeds ~200 LOC). The security-engineer and data-engineer are retained (guardrails + aggregation).

---
name: lead-developer
active: true
phase_specific: false
reason: Coordinates across assist pipeline (voice-engineer), guardrails (security-engineer), context-binding + session API (backend-engineer), and aggregation extension (data-engineer). Owns the build_assist_pipeline() design decision (mode param vs separate builder) and the warm-WebRTC-connection lifecycle (D-067). Owns the C-8 latency tension for assist (R-ASSIST-02 — the binding-constraint risk). Required for every milestone.
domain: coordination
frameworks: [pipecat, fastapi, sqlite, postgres, webrtc, docker]
constraints: [pragmatic, latency-budget-aware, hybrid-storage-no-cross-db-joins, k-anonymity-floor-10, assist-does-not-affect-mastery, warm-webrtc-per-shift]
territory:
  - "docker-compose.yml"
  - ".env.example"
---

---
name: voice-engineer
active: true
phase_specific: true
reason: REACTIVATED for v0.5 (proposed at PERSONAS.md line 458 for v0.5+). Owns the wake-word client (Picovoice Porcupine Android foreground service — D-058, D-064), the assist audio pipeline (warm WebRTC connection per shift — D-067, wake-word → first-audio latency — R-ASSIST-03), latency tuning (the C-8 <600ms assist budget — R-ASSIST-02, Domain 3), the in-loop guardrail processor (post-LLM frame processor — D-060 layer 2), and the build_assist_pipeline() (reuses v0.1 services, swaps the system prompt + adds the guardrail processor). This is the largest new territory in v0.5: the assist voice loop is a new mode alongside the practice scenario loop. Will deactivate in v0.6 unless voice work continues (accent modeling, multi-voice personas, multi-learner concurrency).
domain: voice
frameworks: [porcupine-android, webrtc, silero-vad, pipecat, audio-codecs, piper-tts, cartesia-tts, deepgram-nova3, ollama-cloud]
constraints: [sub-600ms-latency-assist, warm-webrtc-per-shift, foreground-service-background-mic, wake-word-detection-latency, piper-tts-for-assist, lean-assist-system-prompt-150-tokens, in-loop-guardrail-processor]
territory:
  - "**/server/pipeline.py"
  - "**/server/assist/pipeline.py"
  - "**/server/asr/**"
  - "**/server/tts/**"
  - "**/server/latency.py"
  - "**/server/guardrails/live_assist.py"
  - "**/client/wake-word/**"
  - "**/client/assist-service/**"
---

---
name: backend-engineer
active: true
phase_specific: false
reason: RETAINED from v0.4. Owns the assist context-binding endpoints (load path week + scenario tag + learner theta from SQLite into the assist prompt — D-059), the assist session API (POST /api/assist/shift/start + /end — D-062, D-069), the SessionRecorder extension (session_type field, assist turn logging, _build_session_outcome assist branch), and the cohort hook extension for session_type='assist' (D-062). Collaborates with security-engineer on the LiveAssistGuardrail ruleset (backend owns the in-loop processor integration; security owns the regex patterns + safety logic). The assist session API + context-binding is the largest backend territory in v0.5.
domain: backend
frameworks: [pipecat, pydantic, fastapi, uvicorn, aiosqlite, asyncpg]
constraints: [api-first, type-safe, mastery-off-voice-path, aggregation-off-voice-path, latency-budget-aware, no-cross-db-joins, assist-does-not-update-mastery, schedule-mastery-false-for-assist]
territory:
  - "**/server/**"
  - "**/server/assist/**"
  - "**/server/guardrails/**"
  - "**/server/cohort/**"
  - "**/server/session_recorder.py"
  - "**/db/migrations/**"
---

---
name: data-engineer
active: true
phase_specific: false
reason: RETAINED from v0.4. Owns the assist aggregation integration into the v0.4 cohort pipeline (new assist metrics in cohort_aggregates — no schema change, new metric strings: assist_shifts_count, assist_turns_count, assist_avg_turns_per_shift, assist_active_learners_count, assist_guardrail_block_rate — D-062), the turns-table guardrail_verdict field migration (SQLite, additive — D-060 layer 3), and the assist session_type field in the sessions table. Also owns the k-anonymity suppression extension for assist metrics (assist_active_learners_count distinct-count, ≥10 threshold). Smaller v0.5 surface than v0.4 but on the critical path for operator visibility into assist usage + guardrail safety signals.
domain: data
frameworks: [sqlite, postgres16, aiosqlite, asyncpg]
constraints: [schema-first, migration-driven, no-cross-db-joins, k-anonymity-floor-10, opaque-learner-ref, write-time-suppression, assist-metrics-no-schema-change]
territory:
  - "**/db/**"
  - "**/db/migrations/**"
  - "**/server/cohort/aggregator.py"
---

---
name: security-engineer
active: true
phase_specific: true
reason: RETAINED from v0.4. Owns the LiveAssistGuardrail enforcement (REQ-ASSIST-03 — the most safety-critical requirement in v0.5: the AI is in the learner's ear during real customer interactions). The 3-layer guardrail (D-060, REFINED by D-068) is the security-engineer's v0.5 surface: (1) prompt rules (coaching-mode system prompt — ask guiding questions, never give the answer, never claim false authority), (2) output filter patterns (direct-answer vs coaching-question regex — DIRECT_SCRIPT_RE, IMPERATIVE_RE, FALSE_AUTHORITY_RE, IMPERSONATION_RE, COACHING_QUESTION_RE + one retry + canned fallback), (3) audit logging (turns table guardrail_verdict + cohort aggregation guardrail_block_rate safety signal for operators). Also owns the privacy/consent disclosure surface (R-ASSIST-08 — foreground-service notification + learner-facing "Assist is on — those around you may be recorded by your mic" disclosure — D-070). REQ-ASSIST-03 blocks ship if the guardrail is not robust.
domain: security
frameworks: [pynacl, canonicaljson, base58, regex, llm-guardrail-patterns, argon2-cffi, starlette-sessionmiddleware]
constraints: [coaches-not-does, no-direct-answer-patterns, no-false-authority, no-impersonation, audit-all-assist-turns, guardrail-block-rate-operator-visible, consent-disclosure-required, output-filter-false-negative-mitigation-defense-in-depth]
territory:
  - "**/server/guardrails/live_assist.py"
  - "**/server/guardrails/**"
  - "**/server/vc/**"  # retained from v0.4 (no v0.5 change expected)
  - "**/server/auth/**"  # retained from v0.4 (no v0.5 change expected)
---

Deactivated personas (2)

---
name: devops-engineer
active: false
phase_specific: true
reason: DEACTIVATED for v0.5. No deploy changes — v0.4's LXC + Docker-in-LXC + Postgres + backup cron carries forward unchanged. The assist foreground service is a client-side concern (voice-engineer territory), not a deploy/infra change. No new Docker services, no CT resource bump, no new backup scripts, no new deploy scripts. Will reactivate in v0.6+ if deploy hardening (TLS, multi-instance for assist concurrency, autoscaling) or a CT bump is needed.
domain: devops
frameworks: [proxmox-lxc, docker, systemd, bash, pg_dump, cron]
constraints: [idempotent-deploy, rollback-on-failure, secrets-never-committed]
territory: []
---

---
name: frontend-engineer
active: false
phase_specific: true
reason: DEACTIVATED for v0.5 (PROVISIONAL). v0.5 assist mode is invoked by wake-word (audio) — the UI surface is minimal: a "Start Shift" / "End Shift" toggle + a context-declaration screen (path week + scenario tag selector). Estimated ~100-150 LOC of React — below the reactivation threshold (~200 LOC). This is small enough that the voice-engineer (client/wake-word + client/assist-service) can own the minimal control surface alongside the audio pipeline, OR the backend-engineer can add a minimal React route. No full frontend surface (no new dashboard, no complex components, no chart library). Will reactivate in v0.6+ if a richer assist control surface (shift history, guardrail-block review, assist coaching-quality dashboard) is needed. NOTE FOR ORCHESTRATOR: if the assist control surface (start/stop shift + context declaration + shift history) is judged non-trivial (>200 LOC of React), reactivate frontend-engineer. Current estimate: ~100-150 LOC.
domain: frontend
frameworks: [react, react-router-dom, pipecat-client-sdk, webrtc, vite]
constraints: [component-first, voice-first-ui, minimal-client-javascript, assist-control-surface-minimal]
territory: []
---

v0.5 Notes for PLAN/EXECUTE

• Territory enforcement mode: warn (per config.json personas.territory_enforcement)
• The voice-engineer owns the largest v0.5 task surface: wake-word client (Porcupine Android foreground service), assist pipeline (build_assist_pipeline + in-loop guardrail processor), warm WebRTC lifecycle, latency tuning (the C-8 <600ms assist budget is the binding-constraint risk — R-ASSIST-02), and the minimal assist control surface. This is the first voice-engineer activation (proposed since v0.2 PERSONAS line 458).
• The security-engineer's v0.5 surface is the most safety-critical: REQ-ASSIST-03 (coaches not does, never lies to real customers). The 3-layer guardrail (D-060, D-068) blocks ship if not robust. R-ASSIST-07 (output filter false negatives) is the residual risk — mitigated by defense-in-depth (prompt + regex + audit) + a post-v0.5 LLM-as-judge.
• The backend-engineer's v0.5 surface: assist session API + context-binding + SessionRecorder extension + cohort hook extension. Solid mid-size surface.
• The data-engineer's v0.5 surface is the smallest but on the operator-visibility critical path: assist metrics (no schema change, new metric strings) + guardrail_verdict migration.
• Cross-persona collaboration points:
  • voice-engineer (in-loop guardrail processor) ↔ security-engineer (LiveAssistGuardrail regex + safety logic) — D-060/D-068
  • voice-engineer (assist pipeline) ↔ backend-engineer (assist session API + context-binding) — D-059/D-061
  • backend-engineer (session_outcome session_type) ↔ data-engineer (aggregator _aggregate_assist branch) — D-062
  • security-engineer (guardrail_verdict audit) ↔ data-engineer (guardrail_block_rate cohort metric) — D-060 layer 3 + D-062
  • lead-developer (C-8 latency tension) ↔ voice-engineer (latency tuning) — R-ASSIST-02
• The voice-engineer is NOT in config.json personas — emergent persona defined in PERSONAS.md (same pattern as v0.2 devops-engineer, v0.3/v0.4 security-engineer). Territory enforcement (warn mode) picks up globs from PERSONAS.md.
• R-ASSIST-01 (Picovoice MAU pricing) is a lead-developer + voice-engineer collaboration point (decide: built-in wake word for v0.5, custom post-pilot, or Vosk fallback).
• R-ASSIST-02 (C-8 <600ms at risk) is a lead-developer + voice-engineer collaboration point for GRILL-v0.5 (relax C-8 for assist or push hardening to v0.6).
• R-ASSIST-08 (privacy/consent) is a security-engineer + lead-developer collaboration point (legal review of Canada consent law for ambient recording — flag for orchestrator).
• Client architecture flag (RESEARCH §7 Q1): v0.5 may require a client upgrade from React-Web (v0.1, D-015) to React-Native or a separate native Android assist app, because background wake-word needs an Android foreground service (which React-Web can't provide). Alternative: defer wake-word to v0.6 and ship v0.5 assist as tap-to-talk only. This is a scope decision for the orchestrator.