Adopt community-base project rows for cohort page project badges

[alexeygrigorev]

Goal

Use the released shared project-row owner on DTC's cohort page and delete the local badge implementation, preserving every existing visible result and feature. The owner's instruction is code simplification with no visible UI changes.

Normative references

• Course-platform specification: reuse policy, cohort ownership, curriculum presentations, route and learner-behavior preservation.
• Application boundaries.
• Coding standard.
• Development process and verification plan contract.
• Shared capability: Coursework: move CMP's per-project lifecycle presentation into the package community-base#312 (C5.2k), released from v0.5.13 onward.
• Read-only readiness evidence.

Scope and ownership

• Adopt community_base.coursework.project_rows.project_row for the existing DTC learner project badge context.
• Preserve the site's existing context attributes, including submitted state/time, score, badge text, Bootstrap badge class and DTC pill class. Keep the established four pill surfaces used by homework.
• Delete ProjectBadgeData, base_project_badge, peer_review_project_badge, completed_project_badge and submitted_project_badge after checking their consumers.
• Adopt an immutable released package tag containing C5.2k, with a matching lockfile and reviewed dependency consequences. v0.5.17 is the reviewed source candidate; it is not accepted merely because it is released.
• Preserve the existing homework pending-change presentation through the pin update. Both courses/templates/homework_steps/_stepper.html and courses/templates/homework/homework.html consume this state.
• Preserve package ownership of shared lifecycle/state rules. Any necessary DTC presentation adjustment must use a cohesive existing host boundary and avoid a parallel shared-state implementation.

The existing candidate is foreign uncommitted work on branch c5-project-lifecycle-adopt, worktree /data/agents/dtc-website/worktrees/c5-project-lifecycle-adopt, HEAD cfc21a90. Do not edit, reset, rebase or commit it until its owner explicitly transfers it. Use an independently owned worktree for new implementation. Shared main is read-only. Preserve frozen #439 work; it is not part of this issue.

Dependencies and delivery boundary

• Released capability: satisfied. v0.5.17 resolves to 7e75eae92fcabbb686c58d99b237e563b764bb13; DTC currently pins v0.5.10.
• Align development deployment validation with the reviewed Relay runtime contract #442 development recovery remains the integration prerequisite. No rebase, commit, merge, push or deployment of this dependent adoption before recovery is green. Read-only grooming and planning may proceed.
• Ownership transfer is required before using or modifying the prepared candidate.
• Normal engineer → independent tester → PM acceptance → original engineer commit → isolated integration → on-call stages remain required.
• A local/path/branch package source is not a deliverable. Do not reset a database or perform a course-model/route cutover as part of this issue.

Behavior to preserve

Current local DTC projects do not expose uses_pooled_review; source inspection therefore finds the v0.5.17 pooled policy inactive for this adoption. Do not introduce that attribute or enable pooled/self-paced assessment here.

Project state	No learner submission	Learner submission
Closed	Closed; wait pill	Closed; wait pill
Collecting submissions	Open; open pill	Submitted; live pill
Peer reviewing	Not submitted; wait pill	Review; open pill until required reviews are complete, then Review completed; live pill
Completed	Not submitted; wait pill	Passed (score); mint pill, or Failed (score); wait pill

Keep the exact existing Bootstrap classes and score values as well as the labels above. Required review counts exclude optional reviews. Preserve existing row ordering, learner scoping and submission selection.

Canonical routes remain those produced by the existing named URLs:

• cohort: /courses/<course_slug>/<cohort_identifier>.
• cohort_project: the cohort path followed by /project/<project_slug>.
• cohort_projects_eval: project path followed by /eval.
• cohort_project_results: project path followed by /results.
• cohort_homework_step: cohort path followed by /homework/<homework_slug>/<homework_step>.

Collecting projects link to submission, reviewing projects to evaluation, completed projects to results, and closed projects remain unlinked. Review deadlines display for submitted reviewing projects and completed projects; other rows retain submission deadlines. Preserve timestamps, timezone formatting, countdown markup and the completed note.

Checkbox status is a pin-adoption regression boundary: an accepted list ["2", "1"] and draft ["1", "2"] currently produce pending-change copy and the unsent-draft pill. Later package state normalization treats those selections as equivalent. Preserve DTC's current visible behavior at both render sites without altering stored answers or introducing another state machine.

Non-goals

No redesign, copy changes, new controls, package-template replacement, new routes, scoring changes, submission/review mutation changes, pooled/self-paced feature enablement, local model replacement or API contract changes. The released package may carry migrations; review and verify their compatibility without using this issue to adopt package course storage.

Acceptance criteria

• Existing project badge branches use the released shared owner; the five local definitions are removed and their consumer scan is recorded.
• Exact labels, Bootstrap classes, DTC pill classes, scores, submitted flags and submitted timestamps match the baseline for every state above, including submitted-closed and unsubmitted-review/completed rows.
• Reviews below, at and above the required threshold retain the same result; optional reviews do not advance that threshold.
• Existing project links, deadlines, countdowns, completed notes, row ordering and empty states are unchanged.
• Anonymous and authenticated behavior, cohort/user isolation, access denials and existing API behavior remain unchanged. Rendering does not mutate submissions, reviews or enrollment.
• Both homework status render sites retain baseline output for reordered checkbox selections, identical selections, changed selections, empty selections and no accepted submission. Other question/final-field edits, successful submission and rejected/stale writes retain existing draft-versus-accepted behavior.
• Pin and lock reference the same immutable released tag. Dependency, migration, mail/job registration and template/context consequences are reviewed; no unintended feature activation or visible change results.
• Query-count evidence shows no per-project query growth. Report application lines removed separately from tests and dependency changes.
• Changed code follows the coding standard; existing oversized functions/files do not grow.
• Baseline and adopted behavior evidence covers the changed contracts. The engineer records the exact frozen inputs and verification-plan digests; the independent tester recomputes the plan and completes every required component.
• Independent desktop/mobile screenshots show the actual cohort and homework states, with unchanged copy, layout and controls; no required screenshot or browser evidence remains pending.
• Tester passes, PM accepts and the resulting development deployment is green before this issue is considered done.

Verification scenarios

Django/integration:

• Use synthetic cohorts and learners to exercise the full project matrix, review thresholds, score/flag/timestamp context, exact destinations and deadline markup.
• Compare the checkbox/draft cases above on the baseline and adopted package, including both message and pill; prove stored accepted answers are unchanged.
• Preserve cohort/user isolation, anonymous output, empty projects and constant query behavior.
• Follow the generated verification plan for dependency-wide checks and migration compatibility; earlier local-link results are historical context only.

Browser:

• On desktop and mobile, inspect a cohort containing open, submitted, reviewing, review-completed, passed, failed and closed projects. Follow the existing submission/review/results links and verify destination/access behavior.
• Inspect homework Review and question pages with accepted answers, reordered saved checkbox selections and genuine edits. Check the status sentence and unsent-draft pill together, then submit and verify existing behavior.
• Exercise a rejected/stale save and the existing empty/anonymous states. Use the graph-selected browser tier; template changes require the process's full browser tier.

Evidence status at grooming

The readiness review inspected DTC origin/main=ddb898e737f68d43bd47fc4f89d357fe32386fb6, the untouched prepared candidate and v0.5.17. It found source-level project-row compatibility and 38 net runtime lines removed in that candidate, plus 100 new test lines. No tests were executed for the readiness review or this grooming. All acceptance boxes remain unchecked.

[alexeygrigorev]

Read-only adoption readiness evidence

Reviewed DTC origin/main=ddb898e737f68d43bd47fc4f89d357fe32386fb6, the untouched prepared candidate at cfc21a90, and released community-base v0.5.17=7e75eae92fcabbb686c58d99b237e563b764bb13.

The tag dependency is now satisfied. Source inspection finds that the candidate's use of project_row preserves current DTC badge text/classes, score and submission timestamps. DTC's Project has no uses_pooled_review attribute, so the package's new pooled-mode policy is inactive. Existing site links, deadline rendering and countdown calculations remain site-owned. Runtime change is 38 net lines removed, separately from the candidate's 100 new test lines. This is source evidence, not an executed compatibility verdict.

A dependency bump alone is insufficient for the owner's no-visible-UI-change instruction. All released versions with project_rows (v0.5.13 through v0.5.17) include an earlier checkbox-normalization change: accepted answers ["2", "1"] versus draft ["1", "2"] had pending changes in v0.5.10 but not v0.5.17. This affects both courses/templates/homework_steps/_stepper.html and the unsent-draft pill in courses/templates/homework/homework.html.

For PM grooming: consider the existing Assignment.context construction as the bounded presentation seam for preserving that DTC message contract, with the shared state calculator continuing to own submission/draft state. This is an unimplemented proposal requiring review and behavior evidence, not permission to fork the state machine. The relevant view/context paths do not overlap the frozen #439 answer-check changes.

The prepared project test does not yet cover both review thresholds, submitted-closed, unsubmitted-review/completed, anonymous access, badge CSS, links and deadlines. Pin adoption needs focused baseline/adopted checkbox render evidence, updated lock/seals, and the normal independent verification/PM gates. Preserve the existing candidate until ownership transfer; #442 development recovery remains the integration prerequisite.

No local files, environments, dependencies or databases were changed; no tests, rebase, commit, push or deployment ran for this review. PM grooming remains outstanding.

[alexeygrigorev]

Grooming Complete

Rewrote the issue as a behavior-preserving shared project-row adoption, including the released-tag/lock requirement, complete project-state matrix, both DTC checkbox status render sites, exact existing routes, ownership boundaries, dependency consequences and independent verification/browser scenarios. Removed needs grooming; labels are courses, integration, P1, enhancement.

The prepared candidate remains foreign WIP. #442 recovery remains the integration prerequisite, and frozen #439 is excluded. The shared state owner must remain authoritative; the issue specifies observable preservation rather than prescribing a shim or a copied state machine.

Source inspection supports current DTC project-row compatibility with v0.5.17 and identifies the earlier checkbox pending-message difference across the pin update. These are inspection findings, not executed acceptance proof. No local files, environments or databases changed; no tests, commit, push, merge or deployment ran. All acceptance criteria remain unchecked. Handoff: assign the engineer only when the prerequisite and ownership boundaries permit implementation.