praxis/.ciagent/GRILL-v0.3.md

Praxis v0.3 CIAgent Plan — GRILL Verdict (Red-Team Review)

Reviewer: adversarial technology executive (red-team) Subject: v0.3 execution plan (Mastery Scoring + Competency Rubrics) — 2 phases, 15 slices, 70 tasks Stance: plan is unfeasible, over-scoped, and too costly until evidence forces otherwise Date: 2026-08-03 Binding status: This GRILL verdict must be cleared (MUSTs resolved, FIXs tracked) before EXECUTE is authorized. Artifacts reviewed: PLAN.md, PROJECT.md, REQUIREMENTS.md, RESEARCH.md (v0.3 section), ARCHITECTURE.md (v0.3 section), ROADMAP.md

---

Verdict Legend

• MUST — blocks execution until fixed. The plan cannot enter EXECUTE with this issue open.
• FIX — fix during execution, non-blocking. Tracked as a P1 condition in VERIFY.
• ACCEPT — proceed as-is. The evidence clears the challenge.

---

Axis 1 — Feasibility

Forcing question: Can this actually be built in 2 execution phases (70 tasks)? Is the scope realistic for one milestone, or is it 2 milestones pretending to be one?

Challenge: The v0.3 scope spans seven independent subsystems (rubric/mastery engine, IRT, scenario library + ≥6 authored scenarios, 6-week path engine, W3C VC 2.0 issuer with Ed25519 + Status List, operator auth + argon2id + slowapi, Postgres-in-LXC + asyncpg, cohort dashboard + k-anonymity aggregation + React UI). This is not a milestone — it is a program. The PLAN.md phase-split rationale (lines 14-23) openly admits the scope "is too large for one execution phase" and splits into P1/P2, but both phases ship under the same v0.3 milestone tag (v0.1.6). The 70-task count is artificially compressed: SLICE-12 (VC issuer) is 6 tasks for a W3C VC 2.0 + Ed25519 + JCS + Bitstring Status List + public verification endpoint + key rotation — that is at minimum a 10-12 task slice on its own, and SLICE-13 (cohort aggregation with k-anonymity + nightly reconciliation + on-session-end hook) is similarly under-tasked at 4 tasks.

Evidence:

• PLAN.md:14-23 — "The v0.3 scope … is too large for one execution phase."
• PLAN.md:32, 334 — P1 = 38 tasks, P2 = 32 tasks, total 70 (excludes P3 review).
• REQUIREMENTS.md:20-66 — 11 functional REQ-IDs + 9 NFRs = 20 active requirements, the largest single-milestone REQ surface in the project's history (v0.1 was ~14, v0.2 was 16 deploy + 4 NFR).
• RESEARCH.md:769 (R-VC-01) — "No batteries-included Python VC lib → ~200 LOC custom code" — 200 LOC of custom crypto code is not a 6-task slice; it is a liability that demands more tests than the plan allocates (only 2 test tasks: TASK-12-05, TASK-12-06).
• SLICE-13 (PLAN.md:516-546) — 4 tasks for: on-session-end hook, k-anonymity suppression SQL, nightly reconciliation cron, and tests. The nightly reconciliation job alone (recompute all 7-day windows from raw events, correct drift, idempotent upsert) is a 2-3 task effort.

Binding verdict: FIX — The plan is feasible as a 2-phase program, but only if it is honestly re-labeled. The milestone should ship as v0.3 (P1 mastery core, v0.1.4) and v0.3.1 (P2 operator tier, v0.1.5), with the v0.3 milestone release (v0.1.6) being the merge of two separately-shipped, separately-verified patches. Do not pretend P1+P2 is one milestone release. Additionally, re-task SLICE-12 and SLICE-13: add 2 tasks each (one for VC Status List edge cases + key rotation drill, one for reconciliation idempotency + race-condition test). This is non-blocking — the wave structure survives — but the task counts must be honest before EXECUTE.

---

Axis 2 — Scope

Forcing question: Is REQ-DASH-01 (cohort dashboard + multi-tenant + auth) really v0.3, or was it correctly deferred in v0.1/v0.2 for a reason? Does D-031 (override D-007) open a Pandora's box?

Challenge: REQ-DASH-01 was explicitly deferred in v0.1 (REQUIREMENTS.md:152, "later/deferred") and v0.2. ROADMAP.md:94 places the "Employer / program dashboard" at v0.8. The v0.3 plan pulls it forward three milestones with the justification that mastery scoring "needs" the operator view. But mastery scoring (REQ-MAST-01/02) and VC issuance (REQ-MAST-03) work without a cohort dashboard — the dashboard is an operator feature, not a learner feature. D-031 overrides D-007 (single-learner/no-auth) and introduces a hybrid SQLite+Postgres topology, operator auth, argon2id, slowapi, asyncpg, a second Docker service, k-anonymity aggregation, and a React operator UI — none of which is required for the learner-facing mastery gate to function. This is scope creep dressed as a dependency.

Evidence:

• ROADMAP.md:94 — "v0.8 | Employer / program dashboard" (original placement).
• PROJECT.md:129 (D-031) — "overrides D-007 for the cohort-dashboard surface" — confidence 0.75, the lowest-confidence decision that expands scope.
• REQUIREMENTS.md:44 (REQ-DASH-01) — "Forces multi-tenant + operator auth (D-031)" — the word "forces" is doing a lot of work. The mastery gate (REQ-MAST-02) does not depend on the dashboard.
• PLAN.md:18 — P1 "works standalone (learner can practice, score, progress) without the operator tier." — This is an admission that the operator tier is separable.
• PROJECT.md:147 (D-049) — failure-injection stays off, further confirming the learner-facing mastery layer is the real v0.3 deliverable.

Binding verdict: MUST — Split the milestone. Ship v0.3 = P1 only (mastery core + IRT + scenarios + paths + VC issuance, since VC issuance is triggered by the mastery gate and is learner-facing per D-048). Defer REQ-DASH-01 + REQ-AUTH-01 + REQ-MT-01/02 + REQ-NFR-DASH-01/02 + REQ-NFR-AUTH-01 + REQ-NFR-MT-01 to v0.4 (operator tier), restoring the original ROADMAP intent. D-031 does open a Pandora's box: every hybrid-DB system eventually faces the "which store is the source of truth?" question, and shipping it under a learner-milestone tag hides that risk. If the team insists on keeping the dashboard in v0.3, rebrand the milestone as "v0.3: Mastery + Operator Tier" and accept that this is a 2-milestone program — but the cleaner answer is to defer the dashboard.

---

Axis 3 — Cost

Forcing question: What is the maintenance cost of Postgres-in-LXC, asyncpg, argon2, pynacl, slowapi, and ~200 LOC custom VC code? Is R-VC-01 (custom VC code) a liability vs using a library?

Challenge: The v0.3 dependency surface grows by at least 5 new pip packages (asyncpg, argon2-cffi, slowapi, pynacl, canonicaljson, base58 — actually 6) plus a Postgres service. Each is a CVE vector, a version-pin maintenance burden, and a CI complexity adder. The ~200 LOC custom VC code (R-VC-01) is the most concerning: cryptographic code written by an AI agent is a liability regardless of test coverage. The W3C VC 2.0 + eddsa-jcs-2022 cryptosuite has subtle canonicalization edge cases (e.g., JSON number representation, key ordering, URI normalization) that unit-test round-trips do not catch — only interop tests against an independent verifier do, and the plan has zero interop tests.

Evidence:

• RESEARCH.md:769 (R-VC-01) — "~200 LOC custom code" — confidence 0.75. The mitigation is "unit-test signature/verify round-trip," which only proves the code is self-consistent, not that it is W3C-compliant.
• PLAN.md:504-513 (TASK-12-05, TASK-12-06) — VC tests are sign/verify round-trip, tamper detection, JCS determinism, status list, revocation, key rotation. No interop test against an external verifier (e.g., Verifiable Credential JS verifier, Digital Credentials Verifier).
• PROJECT.md:140 (D-042) — issuer key encrypted at rest with a root key from secrets. Key management is hand-rolled (init_issuer_key, encrypt, store, rotate). This is a security-engineer task, not a backend task, and the plan assigns it to security-engineer (good), but the rotation drill (D-042 "new key + old marked superseded") is not tested end-to-end except in TASK-12-06 which only checks "old VC still verifies against archived public key" — it does not test the operational rotation procedure (generate new key, archive old, re-sign new VCs, update verificationMethod URL).
• RESEARCH.md:772 (R-MT-01) — Postgres-in-LXC resource contention, confidence 0.65 — the lowest-confidence technical risk. Memory bump to 6GB is a guess, not a measurement.

Binding verdict: MUST — Two conditions before EXECUTE:

1. Add a VC interop test (TASK-12-07): verify a Praxis-issued VC against at least one external W3C VC verifier (e.g., the digitalbazaar/vc-verifier or a JS @digitalcredentials/vc verifier). Round-trip self-verification is insufficient for cryptographic claims. Without this, R-VC-01 is an unmitigated liability.
2. Add a key-rotation operational test (TASK-12-08): end-to-end drill — issue N VCs with key A, rotate to key B, issue M VCs with key B, verify all N+M VCs still verify (N against archived key A, M against active key B), revoke one of each, verify revocation. This is the one crypto procedure that, if broken, silently invalidates every credential ever issued.

The Postgres/argon2/slowapi maintenance cost is ACCEPT — these are well-maintained, widely-used libraries. The liability is concentrated in the custom VC code.

---

Axis 4 — Technical Risk

Forcing question: R-MAST-01 (N=3 thin for credential), R-AUTH-01 (Secure cookie + no TLS), R-MAST-02 (LLM hallucinated quotes), R-IRT-01 (cold start) — which are MUST-FIX before execution vs ACCEPT?

Challenge: The plan treats all four as "Open Questions Deferred to EXECUTE" (PLAN.md:687-693). That is insufficient. R-MAST-01 is a credibility risk: if the VC is labeled as a mastery credential and employers treat it as high-stakes, N=3 with G≈0.5-0.6 is defensible only if the credential is explicitly labeled formative. R-AUTH-01 is a security risk: relaxing the Secure cookie flag for a no-TLS pilot means session cookies travel in cleartext — if the operator bridge IP is on a shared network (vmbr0 DHCP), any host on the bridge can sniff the operator session. R-MAST-02 is the highest-confidence mitigation (fuzzy-match quotes), but the plan's fallback ("empty evidence + log warning") means a session could silently score as a zero with no learner-visible signal. R-IRT-01 is benign (cold-start fallback to fixed difficulty).

Evidence:

• RESEARCH.md:766 (R-MAST-01) — confidence 0.62, below the 0.70 decision threshold. Mitigation: "Label v0.3 VC as formative." This label is not in the PLAN.md VC payload (TASK-12-02) or the REQ-MAST-03 requirement text.
• RESEARCH.md:771 (R-AUTH-01) — "Secure cookie flag fails without TLS." PLAN.md:450 resolves this with PRAXIS_COOKIE_SECURE=false env default. This ships a known-insecure default.
• PLAN.md:154 (TASK-03-01) — "on final failure, fall back to empty evidence + log warning." Empty evidence → rule scorer has no signals → every criterion scores level 1 (fail) → scenario fails → learner sees a failed session with no explanation. This is a UX and fairness bug.
• RESEARCH.md:774 (R-IRT-01) — mitigation confidence 0.75, "fall back to scenario.difficulty until ≥5 observations." ACCEPT.

Binding verdict: MUST — Three conditions:

1. R-MAST-01: Add credentialTier: "formative" (or equivalent) to the VC payload (TASK-12-02) and to the verification endpoint response (TASK-12-04). Update REQ-MAST-03 to require this label. Without it, the credential is misleading.
2. R-AUTH-01: Do not ship PRAXIS_COOKIE_SECURE=false as a default. Either (a) require TLS for the operator surface (add a Traefik sidecar or Caddy in front of /api/operator/*), or (b) bind the operator surface to 127.0.0.1 only (loopback) so cookies never traverse the bridge. A cleartext cookie on a shared bridge is a MUST-FIX.
3. R-MAST-02: Change the fallback in TASK-03-01 from "empty evidence + log warning" to "empty evidence → mark scenario as scoring_inconclusive → do not count toward gate, do not penalize learner, surface 'technical issue, please retry' in the debrief." A silent fail-to-zero is unacceptable.

R-IRT-01: ACCEPT — cold-start fallback is sound.

---

Axis 5 — Requirements Coverage

Forcing question: Does the plan actually cover all 20 REQ-IDs, or are some hand-waved? Check the coverage matrix in PLAN.md against REQUIREMENTS.md.

Challenge: The PLAN.md coverage matrix (lines 657-683) claims "20 REQ-IDs covered, 0 partial, 0 deferred." Let me audit the suspicious ones.

Evidence (audit):

REQ-ID	Claimed coverage	Actual coverage	Verdict
REQ-MAST-03	P2 SLICE-12 "VC issuer"	SLICE-12 implements issuance + verification + revocation. But REQ-MAST-03 says "Issued when a mastery gate opens" — the trigger is in P1 SLICE-07 (TASK-07-01, "path_engine.check_gate + advance_week") and the issuance is in P2 SLICE-12. The P1→P2 handoff for VC issuance is not in any task — who calls issuer.issue_credential() when the week-final gate opens? TASK-07-01 says "(6) record mastery_gate_event" but does NOT call the VC issuer (VC issuer is P2). D-048 says "issue VC if week-final gate" but the plan splits the gate-open (P1) from the issuance (P2). Gap: no task wires the P1 gate-open event to the P2 VC issuer.	FIX — add a task (either in SLICE-07 or SLICE-12) that defines the P1→P2 VC-issuance contract: a mastery_gate_events row with gate_opened_at is the trigger; P2's VC issuer polls/receives this event and issues.
REQ-NFR-MAST-02	P1+P2 SLICE-07, 09 "gate auditability (SQLite + Postgres)"	SLICE-07 records the event in SQLite; SLICE-09 defines the Postgres mastery_gate_events table; but no task mirrors the SQLite event to Postgres. The "mirror" is implied but not tasked.	FIX — TASK-13-01 (cohort aggregation hook) should explicitly mirror mastery_gate_events from SQLite to Postgres, or add a dedicated mirroring task.
REQ-SCEN-04	P1 SLICE-02, 06 "expert-authored format + AI variation hooks"	SLICE-02 adds generated_from and intent_hash fields (the hook). SLICE-06 authors expert scenarios. But no task implements the AI-variation review pipeline (_pending/ dir → expert review → library promotion). RESEARCH.md:758 describes it; PLAN.md does not task it.	ACCEPT — REQ-SCEN-04 says "AI-generated variations" with "expert review" — the hook is the schema field; the pipeline can be deferred. The plan is honest that AI variations are "in P2 or later" (SLICE-06 goal line 246).
REQ-NFR-DASH-02	P2 SLICE-13 "freshness ≤24h"	SLICE-13 has a nightly reconciliation job (TASK-13-03) at 02:00. If the on-session-end hook (TASK-13-01) fails or lags, freshness depends on the nightly job. ≤24h is satisfied if the nightly job runs. But there is no task for monitoring or alerting on job failure.	FIX — add a health check for the nightly job (log last-run timestamp, surface in operator dashboard or /health). Non-blocking.
REQ-NFR-VC-02	P2 SLICE-12 "revocation latency — within 1 sync of status list"	"1 sync" is undefined. Is it 1 sync of the status list blob? Is the status list in-memory or fetched on every verify? TASK-12-04 (verification endpoint) does not specify caching of the status list.	FIX — clarify in TASK-12-04: status list is fetched from Postgres on every verification (no cache), so revocation latency = next verify call. Non-blocking.

Binding verdict: FIX — The coverage matrix is mostly honest (18/20 fully covered), but the P1→P2 VC-issuance wiring gap (REQ-MAST-03) is a real hole — without a task that defines the trigger contract, the VC issuer will be built but never called. Add the wiring task. The other three FIXs are minor clarifications.

---

Axis 6 — Architecture

Forcing question: Is hybrid SQLite + Postgres (D-031) a maintainable pattern or a future migration nightmare? Is "no cross-DB joins" realistic for the cohort dashboard queries?

Challenge: Hybrid polyglot persistence is a known anti-pattern when the two stores hold related data and there is no canonical source of truth. Here, mastery_gate_events exists in both SQLite (P1, the learner's local record) and Postgres (P2, the operator audit log). Which is canonical? If they diverge (e.g., SQLite write succeeds, Postgres mirror fails due to pool exhaustion), the cohort dashboard shows stale data while the learner sees correct data — and there is no reconciliation except the nightly job (which recomputes from Postgres mastery_gate_events, not from SQLite). This means the nightly job recomputes from a possibly-incomplete Postgres copy. The "no cross-DB joins" rule is realistic only if the cohort dashboard never needs to join learner-local data (e.g., θ distribution by path) with operator data — but the dashboard's "progression" and "failure patterns" views implicitly need both the learner's session outcomes (SQLite) and the operator's aggregate view (Postgres). The plan resolves this by aggregating at session-end (writing the aggregate to Postgres), so the dashboard reads only Postgres — but this means the aggregate is a derived copy, and the "no cross-DB joins" rule is maintained by duplicating data, not by query-time joins. This is workable but fragile.

Evidence:

• ARCHITECTURE.md:356-379 — "The two stores never share a session and never join via cross-DB FKs (learner_ref is an opaque string in Postgres)." — the design is clean if the mirror is reliable.
• RESEARCH.md:746 — "No cross-DB joins via learner_ref — learner_ref is an opaque string, not a FK." — correct, but learner_ref is still a logical join key. If the SQLite learner is deleted and re-created, the Postgres learner_ref dangles.
• PLAN.md:528-529 (TASK-13-01) — "after P1's mastery hooks fire, call aggregator.upsert_aggregate(...)" — this is a synchronous call after the SQLite write, in the session-end path. If Postgres is down, does the session-end fail? The plan does not specify failure semantics.
• RESEARCH.md:748 — migration strategy: "SQLite volume untouched → learner path never regresses." Good, but the operator path regresses if Postgres is down.

Binding verdict: FIX — Three conditions:

1. Define failure semantics for the Postgres mirror (in TASK-13-01): if upsert_aggregate fails (Postgres down, pool exhausted), the learner session-end must still succeed (SQLite write is canonical for the learner). The aggregate failure is logged and reconciled by the nightly job. This makes SQLite the learner-canonical store and Postgres the operator-derived store — state this explicitly in ARCHITECTURE.md.
2. Make learner_ref a stable, opaque, non-reusable identifier (e.g., a UUID generated once and stored in SQLite, never reused). Add this to TASK-02-01 or a new task. Without it, the "no FK" rule is a leaky abstraction.
3. Add a Postgres-readiness guard to the operator API: if Postgres is down, /api/operator/cohort/* returns 503 (not 500 with a stack trace). Add to TASK-14-02.

The hybrid pattern is ACCEPT with these conditions — it is the correct pilot choice (don't migrate learner state to Postgres prematurely), but the failure semantics must be explicit.

---

Axis 7 — Testing

Forcing question: 70 tasks, but how many have tests? Is the test strategy (mocked LLM for evidence extraction, testcontainers for Postgres) viable, or are there untestable critical paths?

Challenge: Let me count test tasks across the plan.

Evidence (test task audit):

Slice	Tasks	Test tasks	Test ratio
SLICE-01	4	1 (TASK-01-04)	25%
SLICE-02	4	1 (TASK-02-04)	25%
SLICE-03	5	2 (TASK-03-04, 03-05)	40%
SLICE-04	4	2 (TASK-04-03, 04-04)	50%
SLICE-05	4	1 (TASK-05-04)	25%
SLICE-06	3	1 (TASK-06-03)	33%
SLICE-07	4	2 (TASK-07-03, 07-04)	50%
SLICE-08	3	3 (all test/verification)	100%
SLICE-09	4	1 (TASK-09-04)	25%
SLICE-10	3	0	0% — infra, acceptable
SLICE-11	5	2 (TASK-11-04, 11-05)	40%
SLICE-12	6	2 (TASK-12-05, 12-06)	33% — too low for crypto code
SLICE-13	4	1 (TASK-13-04)	25% — too low for k-anonymity
SLICE-14	4	1 (TASK-14-04)	25%
SLICE-15	4	1 (TASK-15-04)	25%
SLICE-16	3	3 (all integration/verification)	100%
Total	70	24	34%

Critical untestable paths:

1. LLM evidence extraction (TASK-03-01) — the plan mocks the LLM (good for unit tests), but there is no test that runs against the real LLM with a real transcript. A mocked LLM proves the scoring logic, not that the extraction prompt works. This is a fundamentally untestable in CI path — the only test is manual/staging.
2. k-anonymity suppression (TASK-13-02) — the test (TASK-13-04) checks "cell with 9 learners → suppressed, 10 → shown." But it does not test the differencing attack (comparing two adjacent windows to re-identify a learner who appears in one but not the other). RESEARCH.md:754 says "limit to pre-defined 2-D views to block differencing attacks" — but there is no test that the API enforces only pre-defined views (i.e., that an operator cannot request an arbitrary path × week × outcome 3-D view).
3. Nightly reconciliation (TASK-13-03) — no test for "reconciliation corrects drift." TASK-13-04 tests "reconciliation correctness" but not drift correction (insert a bad aggregate, run reconcile, verify it's fixed).
4. VC verification endpoint (TASK-12-04) — tested via TASK-12-06, but only with Praxis-issued VCs. No interop test (see Axis 3).

Binding verdict: FIX — Four conditions:

1. Add a real-LLM smoke test (in SLICE-08 or SLICE-16): run one session transcript through the actual deepseek-v4-flash:cloud evidence extractor and verify the output is valid JSON with fuzzy-matching quotes. This runs only in staging (requires OLLAMA_API_KEY), gated by an env flag. The mocked-LLM tests stay in CI.
2. Add a k-anonymity differencing-attack test (TASK-13-04 extension): verify that the cohort API rejects arbitrary 3-D view requests, and that two adjacent 7-day windows cannot re-identify a single learner appearing in only one.
3. Add a reconciliation drift-correction test (TASK-13-04 extension): insert a deliberately-wrong aggregate, run reconcile_cohort(), verify it's corrected.
4. Add the VC interop test (per Axis 3, MUST condition).

The mocked-LLM + testcontainers strategy is ACCEPT for CI. The gaps are in integration and security testing, not unit testing.

---

Axis 8 — Phase Split

Forcing question: Is P1/P2 the right split? Should VC issuance (P2 SLICE-12) be in P1 with mastery gates (P1 SLICE-07) since they trigger on the same event? Is the P1→P2 dependency clean?

Challenge: The plan splits VC issuance (P2) from mastery-gate-open (P1) even though D-048 says "issue VC if week-final gate." This means P1 ships (v0.1.4) with mastery gates that open but no credential is issued — the learner reaches mastery and gets... nothing portable. The VC issuer arrives in P2 (v0.1.5). This is a user-visible gap: a learner who completes the path in v0.1.4 has no credential. The plan's phase-split rationale (lines 14-23) says P1 "works standalone (learner can practice, score, progress) without the operator tier" — but VC issuance is not the operator tier; it is a learner-facing consequence of mastery (D-048). VC issuance should be in P1.

Conversely, the operator auth + Postgres + cohort dashboard is correctly P2 — those are operator-tier.

Evidence:

• PROJECT.md:146 (D-048) — "issue VC if week-final gate" — VC issuance is a mastery-gate consequence, not an operator feature.
• PLAN.md:18 — "P1 works standalone" — but "standalone" here silently drops the VC, which is a REQ-MAST-03 requirement.
• PLAN.md:663 (coverage matrix) — REQ-MAST-03 is listed as P2 SLICE-12. But REQ-MAST-03 is a mastery requirement, not an operator requirement.
• PLAN.md:282 (TASK-07-01) — P1 session-end hook does steps 1-6 but step 6 is "record mastery_gate_event" — no VC issuance call. The VC issuance is orphaned in P2 with no trigger from P1.

Binding verdict: MUST — Move SLICE-12 (VC issuer) to P1, after SLICE-07 (mastery gates), as a new Wave-4 slice in P1 (parallel with SLICE-08). This requires:

1. VC issuer needs issuer_keys storage — use SQLite for P1 (the issuer_keys table moves to SQLite for v0.3; Postgres takes over in v0.4 when the operator tier arrives). Or, if Postgres is required for VC, then Postgres must also move to P1 — which inflates P1 further and reinforces the Axis 2 verdict (split the milestone).
2. The cleaner resolution: defer VC issuance to v0.3.1 (P2) and accept that v0.1.4 (P1) ships mastery gates without credentials — but label this explicitly in the P1 ship notes ("VC issuance in v0.1.5"). Do not claim REQ-MAST-03 is covered in P1.

Either resolution is acceptable. The current plan — which implies VC issuance is triggered by P1's gate-open but tasks it in P2 with no wiring — is not acceptable. Pick one: (a) VC in P1 with SQLite-backed issuer keys, or (b) VC explicitly deferred to P2 with P1 shipping "mastery gates, no credential yet."

The P1→P2 dependency is otherwise clean (P2 reads P1's mastery_gate_events and session outcomes). ACCEPT on the dependency structure.

---

Axis 9 — Decisions

Forcing question: Are D-031..D-049 (12 clarify + 7 specify decisions) well-grounded, or are any below the 0.60 confidence threshold? Is D-049 (failure-injection stays off) a mistake given mastery scoring scores recovery from failure branches?

Challenge: Let me audit confidences against the 0.70 threshold (the project's apparent decision-acceptance floor).

Evidence (confidence audit of D-031..D-049):

ID	Confidence	Below 0.70?	Verdict
D-031	0.75	No	ACCEPT — but see Axis 2 (scope creep).
D-032	0.70	At threshold	ACCEPT — N=3 is formative-only per R-MAST-01.
D-033	0.70	At threshold	ACCEPT — W3C VC 2.0 is a stable standard.
D-034	0.70	At threshold	ACCEPT — k=10 is the conventional minimum.
D-035	0.70	At threshold	ACCEPT — 1PL/Rasch is the simplest IRT.
D-036	0.80	No	ACCEPT.
D-037	0.75	No	ACCEPT.
D-038	0.80	No	ACCEPT — deterministic scoring is the right call.
D-039	0.80	No	ACCEPT.
D-040	0.80	No	ACCEPT.
D-041	0.75	No	ACCEPT — but R-AUTH-01 (Secure cookie) is a MUST-FIX (Axis 4).
D-042	0.70	At threshold	ACCEPT — but key rotation drill is a MUST (Axis 3).
D-043	0.80	No	ACCEPT.
D-044	0.75	No	ACCEPT.
D-045	0.70	At threshold	ACCEPT — but failure semantics are a FIX (Axis 6).
D-046	0.80	No	ACCEPT — θ in SQLite is correct.
D-047	0.70	At threshold	ACCEPT — 6 scenarios is tight but defensible for formative.
D-048	0.75	No	ACCEPT — but the P1/P2 split breaks the trigger wiring (Axis 8).
D-049	0.80	No	See below.

D-049 (failure-injection stays off): The challenge is whether this is a mistake. The rubric (SLICE-01) has a "de-escalation" criterion (weight 0.20), and RESEARCH.md:718 says "de-escalation up-weights to ~0.40 if the escalate branch triggers." The escalate branch is a naturally-occurring failure branch in cs_refund_ca_v01 (D-010), not an AI-provoked failure. So mastery scoring does score recovery from a failure branch — the naturally-occurring one. D-049 keeps AI-provoked failure injection off, which is correct: the rubric's de-escalation criterion is exercised by the existing branch, and adding AI-provoked failures would couple mastery scoring to a new feature (scope creep). D-049 is well-grounded.

However, there is a subtle gap: the rubric weights are static in the YAML (empathy 0.35, resolution 0.30, de-escalation 0.20, professionalism 0.15 per TASK-01-01). RESEARCH says de-escalation "up-weights to ~0.40 if the escalate branch triggers" — but TASK-01-01 does not mention dynamic re-weighting based on branch outcome. Either the weights are static (and the "up-weight" is a future feature) or they are dynamic (and the plan is missing a task). This is a FIX — clarify in TASK-01-01 whether weights are static or branch-dependent. If static, update RESEARCH.md to note the up-weight is deferred.

Binding verdict: ACCEPT on all D-031..D-049 confidences (none below 0.60; the floor is 0.70, which is the project's threshold). FIX on the de-escalation weight ambiguity (static vs dynamic) in TASK-01-01. D-049 is ACCEPT — failure-injection stays off is the correct call; the naturally-occurring escalate branch exercises the de-escalation criterion.

---

Summary Table

#	Axis	Forcing question (short)	Verdict
1	Feasibility	2 phases / 70 tasks realistic?	FIX — re-label as 2-milestone program; re-task SLICE-12/13 (+2 tasks each)
2	Scope	REQ-DASH-01 really v0.3? D-031 Pandora's box?	MUST — split milestone; defer dashboard to v0.4 (or rebrand honestly)
3	Cost	Custom VC code liability? Maintenance burden?	MUST — add VC interop test + key-rotation operational test before EXECUTE
4	Technical risk	R-MAST-01/R-AUTH-01/R-MAST-02/R-IRT-01	MUST — label VC formative; fix Secure cookie; fix silent-fail-to-zero fallback
5	Requirements coverage	20 REQ-IDs fully covered?	FIX — wire P1→P2 VC-issuance trigger; mirror SQLite→Postgres gate events; minor NFR clarifications
6	Architecture	Hybrid SQLite+Postgres maintainable?	FIX — define Postgres-failure semantics; stabilize learner_ref; add 503 guard
7	Testing	Test strategy viable? Untestable paths?	FIX — add real-LLM smoke test, differencing-attack test, drift-correction test, VC interop test
8	Phase split	VC issuance in P2 but triggers on P1 event?	MUST — move VC to P1 (SQLite-backed) OR explicitly defer to P2 with honest labeling
9	Decisions	D-031..D-049 below 0.60? D-049 a mistake?	ACCEPT — all confidences ≥0.70; D-049 correct; FIX de-escalation weight ambiguity

---

Final Recommendation: GO-WITH-CONDITIONS

The v0.3 plan is not approved for EXECUTE as-is. It is a well-researched, well-structured plan that suffers from two structural flaws: (1) it is two milestones pretending to be one, and (2) it splits a learner-facing consequence (VC issuance) from its trigger (mastery gate) across a phase boundary without wiring.

MUST conditions (blocking — must be resolved in PLAN before EXECUTE):

1. Axis 2 — Split the milestone. Either (a) defer REQ-DASH-01 + operator tier to v0.4, shipping v0.3 = P1 + VC issuance only; or (b) rebrand v0.3 as a 2-milestone program (v0.3 + v0.3.1) with separate ship/verify cycles. Do not ship P1+P2 under one milestone tag.

2. Axis 3 — Add VC interop test + key-rotation operational test. Custom crypto code without interop verification is an unmitigated liability. Add TASK-12-07 (interop) and TASK-12-08 (rotation drill).

3. Axis 4 — Fix three technical risks. (a) Label VC as formative in payload + verification response + REQ-MAST-03 text. (b) Do not ship PRAXIS_COOKIE_SECURE=false as default — use TLS or loopback-binding for the operator surface. (c) Change evidence-extraction fallback from silent-fail-to-zero to scoring_inconclusive with learner-visible retry signal.

4. Axis 8 — Resolve the VC-issuance phase split. Either move SLICE-12 to P1 (with SQLite-backed issuer keys) or explicitly defer REQ-MAST-03 to P2 and label P1 as "mastery gates, no credential yet." The current plan's implicit wiring is a gap.

FIX conditions (non-blocking — tracked in VERIFY-P1/P2):

5. Axis 1 — Re-task SLICE-12 and SLICE-13. Add 2 tasks each to honestly reflect the effort (VC edge cases + rotation drill; reconciliation idempotency + race test).
6. Axis 5 — Wire the P1→P2 VC-issuance trigger (if VC stays in P2) and mirror SQLite→Postgres gate events explicitly in TASK-13-01.
7. Axis 6 — Define Postgres-failure semantics (SQLite is learner-canonical, Postgres is operator-derived); stabilize learner_ref as a non-reusable UUID; add 503 guard on operator API.
8. Axis 7 — Add four tests: real-LLM smoke (staging-gated), k-anonymity differencing-attack, reconciliation drift-correction, VC interop (already a MUST).
9. Axis 9 — Clarify de-escalation weight (static vs branch-dependent) in TASK-01-01.

ACCEPT items (proceed as-is):

• IRT 1PL/Rasch cold-start fallback (R-IRT-01).
• All decision confidences (D-031..D-049 ≥ 0.70, none below 0.60).
• D-049 (failure-injection stays off) — correct call.
• Mocked-LLM + testcontainers CI strategy.
• Hybrid SQLite+Postgres topology (with failure-semantics FIX).
• P1→P2 dependency structure (clean except for VC-issuance wiring).

Bottom line:

The plan is not unfeasible — the research is thorough, the architecture is sound, and the slice decomposition is reasonable. But it is over-scoped (two milestones in one tag) and under-tested in its highest-risk areas (custom crypto, k-anonymity, real-LLM extraction). Resolve the 4 MUST conditions, track the 5 FIX conditions, and this becomes a GO.