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.