Praxis CI
813bd586d6
v0.3 milestone merged to main. Mastery scoring + competency rubrics + verifiable credentials (formative-tier) shipped. 13/13 REQ-IDs covered. Next milestone: v0.4 (operator tier — cohort dashboard + auth + Postgres). ---ci--- project: praxis phase: 2 milestone: v0.3 status: complete milestone_complete: true milestone_merged_to_main: true ---/ci---
325 lines
18 KiB
Markdown
325 lines
18 KiB
Markdown
# 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. |