Decision: Choose CMP system-evaluation, peer-assignment, score, and notification behavior

[alexeygrigorev]

Decision outcome

A named course-domain owner must choose ADOPT, DEFER, or REJECT independently for four behavior families introduced by immutable CMP series ending at 598c028fcd5cf30d4b1cdcae344bcc2193adc2c9:

1. staff-created system project evaluations;
2. learner-facing peer-review task visibility;
3. score/result readiness and visibility;
4. explicit peer-assignment and score notification actions.

#149 remains a blocked product-decision gate. It is not an engineering or source-sync issue. Unknown policy fails closed: keep the website pin and target overlays unchanged, do not copy/apply CMP bytes, and do not create implementation children until the owner responds.

Parent review: #148.

Correction to the 2026-08-27 packet

The earlier phrase “whether learners may submit the CMP system rubric” is inaccurate and is superseded by this body and the latest PM comment.

At the reviewed upstream commit, learners do not submit a system evaluation. The only upstream creation route is the compatibility API guarded by token_required plus require_staff_token. Its GET/POST resolves a non-volunteer submission inside the route's course/project, requires every rubric criterion, records created_by=request.user, and creates an idempotency-keyed evaluation. The product decision is whether authorized staff and/or a trusted service may create it and how it affects learners—not whether learners author it.

This correction does not approve the upstream staff-token authorization as the target management design. Any adopted target behavior must still use named capabilities, shared services, Studio and /api/v1/admin/ parity, object/cohort authorization, revision/idempotency, and redacted audit.

Evidence boundary

• Website remains pinned to CMP 98a235283904b4ef9ad29e196298540756cf1bcc; the requested series is unapplied.
• Review CMP upstream overlay drift at 598c028f #148 accepted only a fail-closed review. Its exact comparison identified substantive model/migration/API/scoring/render/notification behavior and target overlay conflicts; it did not approve product behavior or pin movement.
• The reviewed upstream families are commits 8146d463 (split processing from notifications), 80d67dfa (peer-review task visibility), 894696cf (system evaluation), and 83242da (score hiding).
• Current target migration numbering and overlays are authoritative. Upstream courses.0041 cannot replace the target's existing migration identity.
• Preserve public course signup totals without registration PII #133's aggregate-only registration seam and protected-source HUMAN gate remain untouched and require no data for this decision.

Owner response format

For each family, reply with exactly one disposition:

• ADOPT — approve the behavior for this release and answer every required policy field below. Adoption approves product semantics only; PM will later create/groom bounded implementation issues against current main.
• DEFER — preserve current target behavior, state why it is not in this release, name the condition or future decision that may reopen it, and leave all corresponding CMP bytes/overlays unapplied.
• REJECT — preserve current target behavior, state why this behavior is not part of the target product, and record it as an explicit source-sync exclusion rather than a later implementation promise.

“Adopt upstream,” “same as CMP,” silence, or a partial answer is not sufficient. Do not combine the four dispositions; each has an independent security, migration, UI, and delivery boundary.

Decision 1 — staff-created system project evaluations

Reviewed upstream behavior

• Only the staff-token compatibility GET/POST route creates/reads system evaluations; there is no learner-authoring route.
• POST requires feedback, an idempotency key, and one valid answer for every project review criterion. Exact replay returns the existing evaluation; a different payload with the same key conflicts.
• Each new evaluation is append-only in the reviewed API. Multiple system evaluations for one submission can exist and all of their criterion responses join submitted peer responses in criterion scoring; each response has equal input weight before the existing median/ceiling calculation.
• Creation immediately replaces stored criterion scores, recomputes total/pass state, and may update leaderboard/legacy Datamailer projections in the upstream implementation.
• Learner results may display system feedback and include system rubric votes. The staff compatibility GET exposes submission/account fields and peer/system evaluation details that require a separate target field/PII policy.

Required ADOPT answers

1. Actor: Which named target capability may create/view a system evaluation? Is a separately authenticated trusted service allowed, staff allowed, or both? No learner actor is implied. Define object/cohort scope and reauthentication/confirmation if required.
2. Weight and aggregation: Does each system response count equally with each submitted peer response, act only as a fallback when peer evidence is insufficient, override peers, or use another explicit weight? Define rounding, missing criteria, conflicting/multiple system evaluations, and leaderboard/pass effects.
3. Correction and history: Is an evaluation immutable append-only, revision-correctable, supersedable, or deletable? Define replay/conflict, reason, audit, rescoring, retention, actor deletion, legal deletion, and rollback behavior. State whether multiple active evaluations may contribute simultaneously.
4. Visibility: Which feedback, rubric answers, source label, actor class, timestamps, and score effects are visible to the learner, Studio, admin API, compatibility API, exports, and audits? Define masking and no-existence leakage.
5. Completion/readiness: Which project/submission states permit creation and when is the evaluation complete enough to affect score/results? Define missing, partial, stale, failed, superseded, and post-completion correction behavior.

A DEFER or REJECT response preserves current peer-only target scoring/results and excludes the model, migration, API, feedback, and aggregation changes together unless the owner explicitly adopts a smaller separately defined family later.

Decision 2 — peer-review task/assignment visibility

Reviewed upstream behavior

The upstream change does not prove that a learner has a concrete PeerReview assignment. It changes the current-assignment label/link by project state and the learner's own ordinary project submission:

• anonymous/no-user context sees the generic Peer review task during peer-reviewing and completed states;
• an authenticated user sees it only after having an ordinary submission for that project;
• it does not separately require current enrollment or query an assigned review row;
• completion keeps the task visible, so reassigned, removed, completed, or otherwise stale assignment state is not represented.

Required ADOPT answers

1. Anonymous: Should signed-out visitors see a generic peer-review task/link, only non-actionable phase copy, or nothing?
2. Eligibility source: For an authenticated learner, is visibility based on own project submission, an actual current PeerReview assignment, either, or another explicit rule? Volunteer-only rows must be addressed separately.
3. Enrollment and identity: Must the learner have an active enrollment in the exact cohort? Define staff/view-as and inactive/removed enrollment behavior without revealing assignment existence.
4. Cohort/project boundary: Require exact Course/Cohort/Project ownership and define behavior for same slugs across cohorts, hidden/cancelled cohorts, closed projects, and legacy routes.
5. Stale lifecycle: Define visibility before assignment, after completion/submission, after reassignment/removal, after project completion, and on missing/ambiguous/stale state. State which destination is safe in every state.

A DEFER or REJECT response retains current target course-page assignment presentation and excludes the upstream learner-visibility change.

Decision 3 — score/result readiness and visibility

Reviewed upstream behavior

The reviewed HTML change treats a submission as “evaluated” after any submitted peer evaluation or any system evaluation. Until then it hides outcome/criteria/components/submission/feedback sections behind No evaluation is available for this submission yet. The source change does not by itself define consistent readiness for compatibility APIs, future /api/v1/, Studio, exports, leaderboards/statistics, cached projections, or already-stored historical scores. Existing fallback scoring may already have stored values before an evaluation exists.

Required ADOPT answers

1. Readiness predicate: Is one submitted peer evaluation sufficient? Must the configured peer-review count, every rubric criterion, a system evaluation, scoring completion, or another explicit condition be satisfied? Define volunteer/system inputs and partial criteria.
2. Learner HTML: Before readiness, which outcome, total/components, criterion votes, submission facts, feedback, pass/fail, and navigation remain visible? Define empty/error copy and whether a learner can distinguish missing from failed/stale processing.
3. API/Studio/export: Apply the same readiness rule explicitly to public/learner APIs, compatibility API, /api/v1/admin/, Studio, CSV/data exports, and staff diagnostics, with exact staff override/masking rules.
4. Leaderboard/statistics: Decide whether unready scores are excluded, marked pending, or included but hidden; define aggregates, ranking, certificates, completion, and notification eligibility.
5. History/correction: Define legacy stored scores without evaluation rows, later evaluation/regrade, stale projections, rollback, and correction visibility. No historical score may silently become zero, failed, or disappear without an approved migration/reconciliation rule.

A DEFER or REJECT response retains current target score/result visibility and excludes upstream score-hiding behavior; it does not authorize misleading placeholder scores.

Decision 4 — explicit peer-assignment and score notifications

Reviewed upstream behavior

Upstream removes notification sends from assignment/scoring actions and adds separate staff POST actions. The peer notification action is offered in peer-reviewing state; the score action in completed state. The reviewed code can be invoked repeatedly and calls copied Datamailer synchronously; project state alone gates the action, and the exact already-notified/audience-delta semantics are not a product contract.

Required ADOPT answers

1. Actor and trigger: Which named capability may trigger each action, from Studio and /api/v1/admin/ parity? Define project/assignment/scoring/readiness state, confirmation, reason, reauthentication, and audit.
2. Audience: For peer assignment, are recipients only learners with a current unresolved assignment, all ordinary submitters, or another exact set? For scores, define ready/passed/failed/withdrawn/inactive recipients. Require exact cohort/project scope and suppression/preferences.
3. Repeat semantics: Is a second action a no-op, delta-only delivery, explicit resend, or new version? Define idempotency key, changed assignments/rescores, per-recipient result, partial failure, cancellation, and manual-resend authorization.
4. Delivery status: Define accepted versus delivered, retryable versus ambiguous, expiry/retention, redacted Studio/API status, and what happens when Relay is unavailable. Ambiguous acknowledgement never becomes automatic duplicate send.
5. Purpose contract: Confirm the approved Decision: Confirm the MVP transactional email purpose catalog #22 purpose IDs, audience, sender/reply-to, Relay template/version/context, and retention for peer-assignment and score communication, or explicitly defer the purpose.

Even if ADOPT is chosen, implementation remains owned by #48/#49/#50: one website business intent plus durable job commits atomically, only a leased post-commit job contacts Relay, and there is no direct Datamailer/SES, synchronous provider call, dual sender, or local canonical renderer.

Cross-family requirements for any ADOPT

• Exact cohort/project/submission identity and authorized-queryset boundaries; no cross-cohort/account fallback or existence leak.
• Shared courses services used by learner HTML, Studio, admin API, compatibility adapters, exports, and jobs as applicable.
• Target-native UUID/revision/idempotency/capability/audit rules; an upstream staff token alone is insufficient management authorization.
• Fresh/upgrade/replay/SQLite/PostgreSQL migration plan that preserves target migration identities and historical results.
• Private/no-store/noindex learner and management responses, field minimization/redaction, CSRF-safe HTML mutations, OpenAPI parity, safe empty/stale/error states, and inspected desktop/mobile screenshots for changed render surfaces.
• Exact current-main overlay reconciliation and one immutable CMP source SHA after—not before—the product decisions and bounded implementation acceptance.

Dependencies and blocked state

• Hard blocker: the named course-domain owner response to all four families. Until then Decision: Choose CMP system-evaluation, peer-assignment, score, and notification behavior #149 remains blocked and unassigned.
• Review CMP upstream overlay drift at 598c028f #148 supplies immutable review evidence only; refresh it against then-current main after the decision.
• Rename the copied cadmin package to Studio Courses without changing behavior #116 owns the Studio Courses namespace/target overlays; Add controlled upstream synchronization from CMP main #145 owns the controlled sync boundary.
• Preserve public course signup totals without registration PII #133's registration-count seam/HUMAN gate remains independent and untouched.
• Manage Relay-owned versioned transactional templates in Studio #48/Build the durable Relay delivery intent and status lifecycle #49/Wire approved messages through Relay and retire Datamailer #50 are implementation dependencies only for an adopted notification/delivery family. Closed Decision: Confirm the MVP transactional email purpose catalog #22 supplies purpose-policy authority but the owner must identify the exact approved or deferred purposes in the response.
• Complete Studio production identity, role, audit export, and high-risk controls #32/Complete production admin API identity and credential lifecycle controls #33 and the course capability issues govern later target-native management authorization. They do not answer these product choices.

Non-goals while blocked

• No engineering, issue splitting, model/migration/API/UI implementation, source copy, checksum refresh, pin movement, sync --apply, or adoption manifest rewrite.
• No inference of approval from CMP, Review CMP upstream overlay drift at 598c028f #148, the copied platform, current target behavior, Relay authority, or technical feasibility.
• No production/protected data, Preserve public course signup totals without registration PII #133 source, provider credential/call, real email, Datamailer/SES fallback, or external Relay mutation.
• No decision about unrelated project submission, peer assignment algorithm, scoring redesign, registration, curriculum, events, content, SEO, or infrastructure.

Decision acceptance

• A named owner records ADOPT/DEFER/REJECT separately for all four families.
• Every ADOPT answer completes all required fields above; every DEFER/REJECT records rationale and preserved current behavior.
• PM confirms the response is internally consistent across actor, cohort/privacy, scoring/readiness, export/history, and delivery boundaries.
• Only after that confirmation does PM create/groom the smallest implementation follow-ups and refresh Review CMP upstream overlay drift at 598c028f #148/current-main source-overlay evidence.

Exact next action

Course-domain owner: reply using the four numbered decision sections. PM then records the selected contract and, only for adopted families, splits/grooms implementation work. Until that response, keep #149 blocked for engineering and CMP apply.

[alexeygrigorev]

PM grooming — BLOCKED pending course-domain decision

Verdict: BLOCKED; not ready for engineering. The source change is a real product/integration change, not a checksum refresh. No course-domain owner decision approving (or rejecting) these behaviors is recorded, so I am not inventing one. Keep the source pin at 98a235283904b4ef9ad29e196298540756cf1bcc, do not copy source bytes, and do not run --apply.

Evidence boundary

• Review CMP upstream overlay drift at 598c028f #148 reviewed the immutable CMP request 598c028fcd5cf30d4b1cdcae344bcc2193adc2c9, source tree a37115e63382a317730e2c6fe5d8ef7a27ac17be, against pinned tree 22a4a9944f353bce1f7779c52cf3ec0fa56a7f32.
• Scheduled run 31745422903 / artifact 9198777578 is status=blocked, applied=false: 31 allowlisted changes, 6 excluded changes, 18 copy entries, 13 overlay conflicts, and 0 fatal errors. Report SHA-256 is 6bde1087fe5f7b988f6d8290559ea3028502b94ec0a915be8f8fd8d855584a35.
• The exact-SHA dry-run in Review CMP upstream overlay drift at 598c028f #148 has the same result and is fail-closed. Its report SHA-256 is 7f4e13dccbf01122df298b340cb897904a418b25bd8b63b8476724aaa2196b44; no source pin or target bytes were applied.
• The current Review CMP upstream overlay drift at 598c028f #148 review record binds all 13 target overlays, retains their target bytes, and links each separate_issue disposition to this issue: overlay-review-598c028f.json. Review CMP upstream overlay drift at 598c028f #148 remains the evidence/ownership boundary; Decision: Choose CMP system-evaluation, peer-assignment, score, and notification behavior #149 is the product decision and possible implementation follow-up.

The requested source is the series 8146d463 (separate project processing from notifications), 80d67dfa (show eligible peer-review assignments), 894696cf (system-project-evaluation fallback), and 83242da (hide scores until a project is evaluated). In aggregate it changes 37 source paths / 1,981 lines, including:

• persistent SystemProjectEvaluation and SystemEvaluationCriteriaResponse models plus migration courses/migrations/0041_system_project_evaluations.py, scoring aggregation, result feedback, and score-visibility changes;
• staff-token GET/POST compatibility API, OpenAPI schemas/routes, idempotent rubric submission, and submission/project data exposure;
• Studio Courses notification controls/routes for peer-review assignments and score delivery, while removing notification sends from assignment/scoring actions;
• learner-facing visibility of eligible peer-review assignments;
• 13 target-owned overlay conflicts listed and checksum-bound by Review CMP upstream overlay drift at 598c028f #148; 18 non-overlay allowlisted copies; and 6 non-allowlisted metadata/agent/deployment changes that remain excluded.

Normative constraints

This review follows the #145 CMP runbook and the current adoption/specification authorities. The adopted platform is a literal copy with explicit target overlays; changed overlays fail closed until reviewed. The #116 decision keeps the logical namespace Studio → Courses. The #133 course registration aggregate is technically accepted but still has its authorized protected-source [HUMAN] gate open; #149 must not consume, change, or claim that gate.

The course specs already preserve peer review, scoring, results, statistics, and communications, but they do not approve these new system-evaluation, assignment-visibility, score-hiding, or explicit-send semantics. Specs 04/06/07/09/10 require course/cohort isolation, capability/object authorization, CSRF, revision/idempotency controls, safe errors/redaction, migration rehearsal, and desktop/mobile verification. #106 and #124 make Relay the sole new website sender: business mutation plus one logical delivery intent commit first, a durable job contacts Relay after commit, and new website code must not send through Datamailer or SES. Any unresolved purpose/sender policy remains fail closed.

Required owner decision before engineering

A course-domain owner must explicitly answer, in an issue comment or linked decision record:

1. System evaluations: Are machine/instructor evaluations a supported release behavior? Who may create them (named staff capability, trusted service, or both)? Must every criterion be answered? Are feedback, rubric answers, score aggregation, replay, correction, and deletion/retention semantics approved?
2. Peer-review assignment visibility: Should eligible learners see assignments on course pages, under which cohort/project/privacy conditions, and what must remain hidden until assignment/submission state permits it?
3. Score visibility: Is hiding scores/results until any peer or system evaluation intentional? Define learner, staff, API, and incomplete/error behavior; unknown or stale evaluation state must not become a misleading score.
4. Notifications: Are separate explicit peer-review and score notification actions desired? Define who may trigger them, confirmation and repeat behavior, audience/purpose/template, Relay delivery status, and whether a failed send is retryable without duplicate delivery.

No “owner approved” conclusion is inferred from the upstream commit, #133, #145, #148, #106, or #124. If the owner defers or rejects a family, #149 records that disposition and leaves the corresponding overlays/source changes unapplied.

Bounded implementation scope after a decision

• Produce a machine-readable contract under _docs/adoption/course-platform/ mapping all 37 changed source paths (31 allowlisted, 6 excluded) and behavior families to adopt, defer/exclude, or a separately tracked issue. Preserve Review CMP upstream overlay drift at 598c028f #148’s exact source/tree/report and all 13 overlay checksums; no silent copy.
• For adopted behavior, copy non-overlaid CMP bytes literally where compatible, retain studio_courses and other target-owned overlays, and use shared application services consumed by public views, Studio, API, and jobs. Do not reimplement a second course workflow or add model exports without their owning implementation.
• For system evaluations, define portable migration/upgrade/replay behavior, uniqueness/idempotency, complete-rubric validation, scoring/leaderboard effects, actor authorization, result visibility, redacted audit, and fail-closed error states. Preserve course/cohort isolation and migration history.
• For notification actions, separate the business transition from sending; route Studio/API mutations through the owning service and capability registry. Commit the business change and one logical intent atomically, enqueue a durable post-commit Relay job, use stable idempotency, and expose retry/ambiguous/error states without direct Datamailer/SES calls.
• For learner-facing assignment/score changes, preserve privacy/no-store/noindex, safe incomplete/error behavior, accessibility, existing route compatibility, and exact target-owned visual language.
• Treat source compatibility API paths as an explicit contract decision; any new management capability must also satisfy the /api/v1/admin/ parity, OpenAPI, permission, revision, idempotency, and audit requirements rather than relying only on a staff-token shortcut.

Non-goals

• No CMP source checkout mutation, source-repository change, automatic synchronization, --apply, source-pin movement, commit, push, or pull request in this issue.
• No protected/production database, registration export, PII, AWS/Relay secret, provider request, or real email. Do not bypass Preserve public course signup totals without registration PII #133’s human gate.
• No redesign of Course → Cohort, registration aggregates, unrelated events/content/SEO/infrastructure, or the accepted Rename the copied cadmin package to Studio Courses without changing behavior #116 namespace decision.
• No direct SES or new Datamailer sends, dual-sender fallback, synchronous network call inside a business transaction, or provider-accepted-as-delivered assumption.
• No second course UI, unscoped staff endpoint, learner/attendee export, or weakening of existing security/privacy boundaries.

Acceptance criteria (after unblocking)

• Course-domain owner decision explicitly records adopt/defer/reject for system evaluations, assignment visibility, score hiding, and notification actions; unknown policy remains fail closed.
• The reviewed contract maps all 37 changed source paths, the 13 Review CMP upstream overlay drift at 598c028f #148 overlays, exact source commit/tree and report identities, target checksums, rationale, reviewer, and follow-up issue for every deferred/separate behavior.
• No behavior is adopted without its decision. Adopted bytes remain literal where possible, preserve the studio_courses/target overlays and Preserve public course signup totals without registration PII #133 registration seam, and introduce no second workflow or silent migration rewrite.
• System-evaluation models/services/migration/API contract (if adopted) proves exact authorization, complete rubric validation, idempotent create/replay/conflict, transactional rescore/leaderboard effects, cohort isolation, redacted audit, safe errors, and fresh/upgrade/SQLite migration coverage.
• Peer-review assignment visibility and score-hiding semantics (if adopted) have explicit learner/staff/API/privacy/error contracts, existing compatibility-route coverage, and no accidental score or submission disclosure.
• Notification actions (if adopted) have explicit Studio/API parity, CSRF/capability/object checks, confirmation, stable idempotency, one logical intent, durable after-commit Relay delivery, retry/ambiguity handling, redacted status/audit, and no Datamailer/SES call.
• OpenAPI, capability/management parity, focused unit/Django/API/privacy tests, copied CMP characterization tests, and migration/portability checks pass; no protected or source-derived private data appears in code, fixtures, logs, screenshots, or artifacts.
• Affected learner and Studio surfaces pass desktop/mobile browser/accessibility checks with inspected screenshots; unchanged documentation/manifest-only review evidence remains screenshot not_applicable.
• Adoption verification and migration drift checks pass. A later source-pin/apply issue, after all adopted overlays are implemented and independently tested, must produce exact-SHA dry-run ready/no_change with zero conflicts/fatal errors before any --apply.
• Engineer, independent tester, and PM reports include exact base/head, plan/report digests, command counts, render evidence, and protected-data/apply boundaries under _docs/PROCESS.md.

Dependencies and unblock path

• Hard blocker: explicit course-domain owner decision above; none is currently recorded.
• Review CMP upstream overlay drift at 598c028f #148 review record and exact report evidence; its 13 conflicts remain blocked until this decision is implemented or explicitly deferred.
• Add controlled upstream synchronization from CMP main #145 adoption verifier/runbook and clean immutable CMP source checkout.
• Rename the copied cadmin package to Studio Courses without changing behavior #116 target namespace/compatibility overlay ownership.
• Preserve public course signup totals without registration PII #133 accepted aggregate contract plus its still-open [HUMAN] protected-source gate; no protected data is needed for Decision: Choose CMP system-evaluation, peer-assignment, score, and notification behavior #149.
• Integrate Relay for website email and retire Datamailer #106/Reconcile normative email specifications to Relay ownership #124 Relay ownership and after-commit delivery contract; purpose/sender decisions that remain unresolved must be linked and fail closed.

Once the owner decision is recorded, PM can revise this comment to READY FOR ENGINEERING with the selected behavior families, exact implementation boundary, and any split follow-up issues. Until then, do not assign an engineer or move the CMP pin.

[alexeygrigorev]

PM decision-gate audit — BLOCKED / not ready

Disposition: BLOCKED; not ready for engineering.

I reread the full #149 record and the complete #148 evidence/overlay-review thread, including the #148 PM clarification and final review-only acceptance. #148 is a fail-closed safety review, not product approval: the requested CMP commit 598c028fcd5cf30d4b1cdcae344bcc2193adc2c9 remains unapplied; the scheduled and exact-SHA reports are status=blocked, applied=false, with 13 overlay conflicts and no --apply. The upstream commit contains substantive system-evaluation, assignment-visibility, score-visibility, API, and notification behavior, not a checksum-only refresh.

The reviewed #149/#148 decision trail still contains no course-domain owner decision. Issue #22 is also still open; its latest purpose-catalog response explicitly says peer-review and score communications remain deferred and is not an owner acceptance. Relay ownership in #21/#124 establishes the delivery boundary only; it does not approve these product behaviors or their purposes.

Before engineering, one named course-domain owner must record adopt, defer, or reject for each family and answer these exact inputs:

1. System evaluations: Are machine/instructor evaluations supported in this release? Which named staff capability and/or trusted service may create, replay, correct, or delete them? Must every rubric criterion be answered? Approve feedback and rubric-response semantics, score aggregation/leaderboard/results effects, idempotent replay/conflict behavior, and deletion/retention rules.
2. Peer-review assignment visibility: Should an eligible learner see an assignment? Define the learner/staff/API visibility matrix and the cohort, project, enrollment, assignment, submission, and privacy conditions. State exactly what remains hidden until each state permits disclosure, including incomplete, unknown, or error states.
3. Score visibility: Is hiding scores/results until peer or system evaluation is complete intentional? Define when scores/results/feedback become visible to learners, staff, and APIs; how incomplete, stale, unknown, or failed evaluation state behaves; and whether leaderboard/statistics/result projections are affected.
4. Notifications: Are separate explicit peer-review-assignment and score-notification actions wanted? Define actor/capability, audience, trigger, template/version, sender/reply-to, purpose, retention, confirmation, repeat behavior, and idempotency. Define Relay status semantics (accepted versus delivered), retry versus ambiguous handling, manual resend, and the rule that a retry cannot duplicate delivery.

Until those inputs are recorded, unknown policy remains fail closed. Do not infer approval from the upstream commits, #148 evidence, #145 runbook, #21/#124 Relay decisions, or #133 technical acceptance. Keep the current source pin and target overlays unchanged; do not copy source bytes, run --apply, access the protected #133 source, or start engineering under #149.

[alexeygrigorev]

Lifecycle audit — 2026-08-22

Disposition: BLOCKED / not ready for engineering. #149 is not implemented or merged.

Evidence checked against origin/main 3909a48:

• No reachable commit, branch, or worktree is associated with Decision: Choose CMP system-evaluation, peer-assignment, score, and notification behavior #149. The issue-specific CMP identifiers and expected implementation symbols (598c028f, 8146d463, 80d67dfa, 894696cf, 83242da, SystemProjectEvaluation, and SystemEvaluationCriteriaResponse) are absent from the checked tree and all worktrees inspected.
• The issue thread contains exactly two role reports: PM grooming — BLOCKED and PM decision-gate audit — BLOCKED. Both explicitly say there is no course-domain decision and that Decision: Choose CMP system-evaluation, peer-assignment, score, and notification behavior #149 is not ready for engineering.
• There is no engineer handoff, independent tester report, focused test evidence/plan digest, screenshot evidence, or PM acceptance report. The issue remains OPEN.
• The governing specs require a recorded source/overlay decision before adoption (04, 06, 07, 09, 10); none of those implementation or verification gates has started for Decision: Choose CMP system-evaluation, peer-assignment, score, and notification behavior #149.

Dirty-worktree finding: the primary checkout is issue-216-engineer at 73f82d0, 7 commits ahead/16 behind origin/main, with 27 tracked/untracked changes. Its subjects and paths are podcast/projection, course-repository, and local course-fixture work, not #149. Other dirty worktrees are named for different issue lanes; none is an actionable #149 worktree. Preserve them; do not clean, merge, or reuse them for this issue.

Exact next lifecycle action: a named course-domain owner must comment on #149 (or link a decision record) with adopt, defer, or reject for each of the four behavior families already listed in the PM gate: system evaluations, peer-review assignment visibility, score visibility, and notifications. Then the PM must revise #149 to READY FOR ENGINEERING with the selected scope and any follow-up issues. Only after that may an engineer start a fresh isolated worktree; tester and PM acceptance gates follow afterward. Until then, keep the source pin/overlays unchanged and do not copy source bytes or run --apply.

[alexeygrigorev]

PM status — BLOCKED / not ready for engineering

As of 2026-08-22, #149 is not implementable as currently groomed. This is a decision/grooming status, not acceptance or merge readiness.

Evidence

• Current origin/main is 35cb2e1, still pinned to CMP 98a2352. It has no system-evaluation models, migration, API route, or 598c028f feature symbols. The current implementation still scores from peer responses, uses the existing project-score path, and sends the existing Datamailer notifications from Studio action requests (scoring, Studio actions). That is not yet the required post-commit EmailDelivery/Relay path.
• The exact upstream comparison is 98a2352...598c028f: 37 changed paths, including system-evaluation persistence/API/scoring, learner assignment visibility, score hiding/results, and notification-action separation. The source migration is numbered 0041, while current target main already uses 0041 for #133’s registration-count seam; literal adoption therefore needs a target migration/upgrade/replay plan.
• Review CMP upstream overlay drift at 598c028f #148 was accepted only as a review-only, fail-closed overlay disposition; it was not product approval or source adoption (QA/PM record, PM acceptance). The accepted overlay-review-598c028f.json is absent from current origin/main, and the current ledger hashes differ from the candidate on Studio templates/tests. Re-audit/rebind the 13 overlay paths against current main before any sync or pin change.
• The prior Decision: Choose CMP system-evaluation, peer-assignment, score, and notification behavior #149 lifecycle reports still show only PM reports: no Decision: Choose CMP system-evaluation, peer-assignment, score, and notification behavior #149 engineer worktree, implementation, independent tester report, screenshots, or acceptance (grooming, decision-gate audit, lifecycle audit).

Open owner decisions and dependencies

1. A named course-domain owner must record adopt/defer/reject for each family: system-evaluation fallback; learner peer-review assignment visibility; score visibility/results/leaderboards; and explicit peer-review/score notification actions. For any adoption, record capability/actor, eligible audience and privacy conditions, complete-rubric and aggregation rules, feedback/source display, incomplete/stale/error behavior, replay/correction/deletion/retention, and idempotency/repeat-send behavior.
2. The Decision: Confirm the MVP transactional email purpose catalog #22 decision authority must resolve the purpose catalog for peer-review/score communications—or explicitly defer them—with owner, audience, trigger, Relay sender/reply-to, template/version/context, privacy/legal basis, retention, and retry/ambiguity rules. The latest Decision: Confirm the MVP transactional email purpose catalog #22 draft proposes deferral but is explicitly not owner acceptance (audit).
3. Notifications cannot be implemented against the current Datamailer calls. The Relay runtime/workflow dependencies remain open: Integrate Relay for transactional email and retire Datamailer #21’s website/Relay delivery lanes (Manage Relay-owned versioned transactional templates in Studio #48/Build the durable Relay delivery intent and status lifecycle #49 and Relay Bootstrap the runnable Django/uv foundation and engineering workflow #1–Epic: Preserve every URL, link, fragment, asset, and SEO contract #3), with capability gates Complete Studio production identity, role, audit export, and high-risk controls #32/Complete production admin API identity and credential lifecycle controls #33. Reconcile normative email specifications to Relay ownership #124 documents the boundary but supplies no runtime; Integrate Relay for transactional email and retire Datamailer #21’s latest audit still reports the purpose catalog and delivery contract open (audit).
4. Preserve Preserve public course signup totals without registration PII #133’s target-owned registration seam and open human gate; do not use protected data. Resolve the migration numbering and fresh/upgrade/replay/SQLite evidence around the existing 0041 before implementation. Rename the copied cadmin package to Studio Courses without changing behavior #116 and Add controlled upstream synchronization from CMP main #145 establish namespace/sync boundaries, but neither authorizes this feature or a pin/apply.

PM recommendation

Re-groom and split this before engineering. Keep #149 as the product decision/contract gate, then create separate implementation lanes for:

• system evaluation plus score visibility/aggregation/results;
• learner peer-review assignment visibility; and
• notification actions plus Relay EmailDelivery integration, only after Decision: Confirm the MVP transactional email purpose catalog #22/Integrate Relay for transactional email and retire Datamailer #21 are resolved.

Keep source-pin/overlay synchronization as a later, separately reviewed change. If a family is deferred, record the exclusion and rationale in #149 and the refreshed #148 overlay evidence.

Next owner/action

The named course-domain decision owner is next: comment on #149 with the four dispositions and the required behavior fields above. In parallel, the #22 email-policy owner must resolve peer-review/score purposes. After those decisions and a current-main #148 overlay re-audit, PM will re-groom #149 and bind the implementation follow-ups. Until then: no engineer assignment, source copy/apply, or pin movement.

[alexeygrigorev]

CMP drift audit — 2026-08-24

The CMP remote is now a9e7dbf8f370e7e43b86a24275f7d9548dfc6e94 (nine commits beyond the website pin 98a235283904b4ef9ad29e196298540756cf1bcc). The immutable comparison contains 40 changed paths: 34 allowlisted application paths and six excluded metadata/agent paths. The functional delta includes system-project-evaluation fallback, score visibility, peer-review assignment visibility, project-processing/notification separation, and the failed-submission status fix.

I ran the controlled #145 dry-run against that exact SHA from a clean website integration checkout. It failed closed with status=blocked, applied=false, zero copied/conflict paths, and fatal error missing or unsafe copied destination: courses/models/course.py. That destination is intentionally retired by the current course/model consolidation and is tolerated by the adoption verifier, but the sync command preflight does not yet handle it.

No source bytes, source pin, manifest, or target files were changed. The newer CMP behavior remains blocked behind #149's owner decisions and a follow-up sync-tool fix/re-audit; no --apply is authorized.

[alexeygrigorev]

Read-only lifecycle audit — 2026-08-24

Disposition: BLOCKED decision/review gate. This audit requires no source change; no implementation, pin movement, or CMP apply is authorized. If a behavior family is adopted, that is a later engineering lane.

Evidence:

• origin/main 1db4882 still pins CMP 98a2352. Its tree has none of SystemProjectEvaluation, SystemEvaluationCriteriaResponse, courses/system_project_evaluations.py, api/views/project_system_evaluations.py, or 0041_system_project_evaluations.py. Studio still calls the copied Datamailer peer-review/score senders (project actions), and email_app/models.py remains deferred; therefore 598c028f is substantive behavior plus the missing Relay/EmailDelivery boundary, not a checksum refresh.
• The immutable 98a2352 to 598c028f comparison is 37 paths (31 allowlisted, 6 excluded). The exact dry-run remains blocked, applied=false, with 18 copy entries, 13 overlay conflicts, and 0 fatal errors; the pin and target bytes are unchanged. Current GitHub workflow inventory has only CI and scheduled regression; the CMP drift workflow was retired in efda44d. The unmerged workflow on dirty issue-216-engineer is unrelated, and no Decision: Choose CMP system-evaluation, peer-assignment, score, and notification behavior #149 candidate worktree or implementation exists.
• Decision: Choose CMP system-evaluation, peer-assignment, score, and notification behavior #149 remains OPEN with only PM/audit reports: no course-domain owner decision, engineer handoff, independent tester evidence/screenshots, or PM acceptance. Specs 04, 05, 06, 09, 10, and #22 require explicit behavior/purpose decisions, shared services/Relay after commit, migration/API/Studio parity, and tester/PM gates; Decision: Confirm the MVP transactional email purpose catalog #22 remains OPEN/unaccepted.

Exact next process action: A named course-domain owner comments on #149 (or links a decision record) with adopt, defer, or reject for system evaluations, peer-review assignment visibility, score visibility, and notifications. The #22 owner must also resolve or explicitly defer peer-review/score email purposes. Then PM re-grooms #149 to READY FOR ENGINEERING with selected scope/follow-ups and refreshes the #148 overlay evidence against current origin/main; only then create a fresh isolated engineer worktree. Keep the source pin/overlays unchanged and do not run --apply.

[alexeygrigorev]

Backlog audit — 2026-08-24

GO/NO-GO/BLOCKED: BLOCKED. #149 is still an open P0 decision/review gate, not an engineering lane. No source, pin, migration, provider, deployment, or worktree state was changed by this audit.

Lifecycle and decision status

• Decision: Choose CMP system-evaluation, peer-assignment, score, and notification behavior #149 is OPEN, unassigned, labelled P0, courses, integration, testing, and data-migration; all 7 acceptance criteria remain unchecked.
• The issue has six comments, all PM/audit reports from alexeygrigorev; there is still no named course-domain owner decision, engineer handoff, independent tester report/screenshots, PM acceptance, commit, merge, or on-call report.
• This follows _docs/PROCESS.md: unknown product policy remains fail closed, and implementation cannot begin before the required decision and dependencies are resolved.

Website source and worktree evidence

• The audited remote and local ref both resolve to origin/main = 1db4882412553b8637f1d0d4e4d361735e6a683b.
• source-pin.json still pins CMP 98a235283904b4ef9ad29e196298540756cf1bcc.
• The current target tree has no SystemProjectEvaluation, SystemEvaluationCriteriaResponse, courses/system_project_evaluations.py, api/views/project_system_evaluations.py, or CMP 0041_system_project_evaluations.py. Its courses.0041 is already 0041_courseregistrationcountsourcerun_and_more.py, and the maintained migration graph reaches 0051.
• Current Studio Courses still imports the copied Datamailer peer-review/score senders and calls them inline after assignment/scoring in studio_courses/views/projects.py (assignment/scoring calls); there are no separate explicit notification action routes in the target tree.
• email_app/models.py remains the deferred placeholder. There is no website EmailDelivery, Relay client, callback/reconciliation consumer, or email handler on this head.
• No issue-149 branch/ref or worktree exists. The shared checkout is dirty on unrelated issue-216-engineer (73f82d0, 28 entries); the other registered worktrees are unrelated or dirty. The origin/main commit object above—not a dirty worktree—was used for the audit.

CMP source status

• The local CMP checkout is clean at 165d8ab3c5ff5861278d3307dc514dc6decd8d65, and CMP remote main resolves to the same SHA. It is 13 commits beyond the website pin.
• Requested commit 598c028f is an ancestor of current CMP main. The immutable 98a2352 -> 598c028f delta is 37 paths (31 allowlisted, 6 excluded; 1,981 additions / 38 deletions) and includes the feature commits 8146d46, 80d67df, 894696c, and 83242da: system-evaluation models/migration/API/rescoring/results, eligible peer-review visibility, score hiding, and separation of notification actions from assignment/scoring.
• Current CMP main has a later delta beyond 598c028f; any future sync must choose and review one exact immutable SHA rather than silently moving the pin.
• Review CMP upstream overlay drift at 598c028f #148 was correctly accepted as review-only: its exact-598 dry-run remained blocked/applied=false with 13 overlay conflicts and no authorization to apply. Its overlay review record is not present in current origin/main, so that evidence must be refreshed against the current target before any sync decision. A direct apply also cannot silently replace the target's existing courses.0041; the sync guard rejects existing migration replacement/target collisions (guard).

Authority and dependency status

The current authorities are still draft/owner-review documents. Spec 04 requires literal CMP adoption and preserves existing course workflows, but does not itself approve the new system-evaluation, assignment-visibility, score-hiding, or explicit-send semantics. Spec 05 lists course communication purposes but says unresolved purposes fail closed until #22 records owner/audience/sender/template/context/idempotency/version/retention decisions. Specs 06 and 07 require shared services, Studio/admin parity, capability/object checks, confirmation, audit/redaction, private responses, and no direct SES/Datamailer fallback. Specs 09/10 require fresh/upgrade/replay migration evidence, while verification strategy requires SQLite/service/contract/failure tests and independent desktop/mobile browser verification.

• #22 remains OPEN/unassigned with its 3 acceptance criteria unchecked; its latest owner-response is explicitly a draft, not acceptance. This blocks peer-review/score purpose activation.
• #21 remains OPEN; website Manage Relay-owned versioned transactional templates in Studio #48/Build the durable Relay delivery intent and status lifecycle #49/Wire approved messages through Relay and retire Datamailer #50 and Relay Bootstrap the runnable Django/uv foundation and engineering workflow #1/Epic: Establish the unified Django platform architecture #2/Epic: Preserve every URL, link, fragment, asset, and SEO contract #3 remain open/unimplemented. Reconcile normative email specifications to Relay ownership #124 is documentation/authority reconciliation only, and Integrate Relay for website email and retire Datamailer #106 is a superseded closed-not-planned duplicate. The Relay after-commit/idempotency/ambiguity boundary is an authority, not a runtime implementation.
• #133 remains open with its authorized protected-source HUMAN gate; Decision: Choose CMP system-evaluation, peer-assignment, score, and notification behavior #149 must preserve its registration aggregate seam and must not consume protected data. Decision: Approve privacy ownership, retention, and minors policy #23 privacy/retention ownership is also still open.

Exact next action

1. A named course-domain owner must comment on Decision: Choose CMP system-evaluation, peer-assignment, score, and notification behavior #149 or link a decision record with adopt, defer, or reject for each family: system evaluations; learner peer-review assignment visibility; score/result/leaderboard visibility; and explicit peer-review/score notification actions. The record must define actors/capabilities, cohort/project/privacy visibility, complete-rubric and scoring/replay/correction/deletion/retention rules, incomplete/stale/error behavior, notification audience/purpose/template/sender/reply-to, confirmation/repeat/idempotency semantics, and Relay accepted-versus-delivered/ retry/ambiguity handling.
2. In parallel, the Decision: Confirm the MVP transactional email purpose catalog #22 owner must approve or explicitly defer the peer-review/score purposes. Then PM must re-groom/split Decision: Choose CMP system-evaluation, peer-assignment, score, and notification behavior #149, refresh Review CMP upstream overlay drift at 598c028f #148's overlay evidence against current origin/main, choose the exact CMP SHA, and resolve the 0041 migration/source-sync contract.
3. Only after those gates pass should an isolated engineer worktree be created, followed by independent tester and PM gates. Keep the website pin/overlays unchanged; do not copy source bytes or run --apply.

Recommendation: BLOCKED / NO-GO for implementation, source-pin movement, and CMP apply.

[alexeygrigorev]

PM owner-decision packet — 2026-08-27

The previous #149 audit is stale on two dependencies: #22 and #23 are now closed, and #21
records Relay as the sole email renderer/transport with marketing/newsletter scope updated. The
underlying CMP delta still requires an explicit course-domain decision; no source bytes or source
pin should move until that decision is recorded.

Please choose adopt, defer with rationale, or reject independently for each behavior
family below:

1. System project evaluations: whether learners may submit the CMP system rubric, who can
   create/edit/score it, when results become visible, and how correction/replay/deletion/history
   behave.
2. Eligible peer-review assignment visibility: whether learners see the assignments eligible
   for them, with the exact Course/Cohort/Project/reviewer privacy boundary and safe empty/stale
   behavior.
3. Score/result visibility: whether scores are hidden until the relevant evaluation, and the
   exact effect on project results, leaderboards, exports, API/Studio, historical scores, and
   correction/regrade flows.
4. Explicit notification actions: whether peer-review assignment and score notifications are
   separate authorized actions rather than side effects of assignment/scoring, including the
   Relay purpose IDs, recipient/audience, confirmation/replay/idempotency, suppression, and
   accepted-versus-delivered/ambiguous behavior.

For every adopted family, confirm actor capabilities, same-Cohort/project isolation, no-existence
leakage, retention/deletion, migration compatibility, and the target-owned Studio/registration
overlays. For every deferred or rejected family, record the preserved current behavior and the
follow-up issue that owns it. The existing courses.0041 migration identity and target overlays
must remain intact; a checksum refresh cannot replace them.

After the owner response, PM can split #149 into bounded engineering slices and refresh the #148
overlay review against the current main plus one exact immutable CMP SHA. Until then, #149 is
blocked for implementation and CMP apply. No provider, migration, source-sync, or production
action is authorized by this packet.