Keep project submission status persisted after failed validation

[alexeygrigorev]

Parent scope: #56 (preserved cohort project behavior)

User outcome

When a learner's first project submission is rejected by validation, the page must not claim
that a submission was saved. The learner sees the validation errors, the entered form remains
available for correction, and the status stays explicitly Not submitted until a submission is
actually persisted. A persisted submission continues to show Submitted with its saved time and
the update action.

This is a narrow target-native correctness slice. It does not complete #56 or change project
validation, scoring, peer review, or cohort migration behavior.

Scope

• Expose an explicit persisted-submission boolean from the project-page context rather than using
  the truthiness of a temporary validation object.
• Use that boolean consistently for the status badge, saved-status text, update/remove affordances,
  and the save/update button label.
• Preserve the existing invalid-submission form values and validation errors.
• Refresh the adoption manifest for every candidate-owned copied file whose bytes change.

Non-goals

• No change to project URL validation or network safety rules.
• No change to persisted submission data, scoring, peer assignment, or notifications.
• No completion claim for the broader Preserve cohort projects, peer assignment/review, voting, and scoring #56 project/peer-review contract.

Acceptance criteria

• A rejected first submission with no persisted row renders Not submitted and Status: Not
  saved yet, with no saved timestamp or update/remove action.
• The rejected form retains the learner's entered values and validation errors so it can be
  corrected and resubmitted.
• A persisted submission renders Submitted, its saved timestamp, and Update submission.
• Desktop and mobile project pages remain readable and have no horizontal overflow in both
  states.
• Focused Django, core/CI, quality, and browser evidence passes on a current-main candidate;
  the adoption manifest agrees with the changed copied files.

Dependencies

Uses the existing copied project behavior from #30. The later Course → Cohort work in #51/#56
must preserve this explicit persisted-state contract.

Existing evidence to reattach

The preserved candidate in .tmp/project-submission-status-current-20260827 was implemented
before this issue was formally groomed. It is not accepted automatically; it may be reused only
after the normal current-main engineer/tester/PM lifecycle is recorded against this issue.

[alexeygrigorev]

Preserved candidate evidence attachment — issue #229

The following candidate was found in an unfinished isolated workspace and is being attached to
this newly groomed issue for lifecycle traceability. The implementation predates this issue's
formal intake; that process defect is recorded rather than treated as waived.

• Engineer workspace: .tmp/project-submission-status-current-20260827
• Independent tester workspace: .tmp/project-submission-status-tester-current-20260827
• Base: d24808c374b7deb220cb57e365760382ad66d06b
• Candidate patch SHA-256: 07c250d0e699d6b7fe04e2043a95b5643ccb642c4edac78ab2ae13b0384e5372
• Candidate: five staged paths, uncommitted

Independent verification reported:

• 23 focused Django/adoption tests passed;
• 931 core tests and 607 CI tests passed;
• Ruff, mypy, migrations, Django, database-portability, security, deployment, links, SEO, and
  terminology checks passed;
• 2 desktop/mobile browser scenarios passed, with four screenshots manually inspected; and
• no candidate file was reported by the existing formatter-baseline failure.

The screenshots show the two required persisted states: an invalid first submission remains
Not submitted / Status: Not saved yet with Save submission, while a persisted row shows
Submitted, its saved time, and Update submission. Both states remain readable at mobile
width without horizontal overflow.

This evidence is candidate-specific. It does not by itself authorize commit, merge, push,
deployment, or production data access, and it does not complete parent issue #56.

[alexeygrigorev]

PM acceptance — issue #229 (bounded slice, 2026-08-27)

Disposition: ACCEPTED for the target-native persisted-submission status fix; #229 remains OPEN.

I reviewed the newly groomed scope, the preserved engineer/tester evidence, the current-main
candidate diff, the four desktop/mobile captures, and the backlog audit that identified the
failed-first-submission regression. The candidate meets the bounded user outcome:

• a rejected first submission does not masquerade as a saved submission;
• the page retains the correction form and validation errors while showing Not submitted and
  Status: Not saved yet;
• a real persisted submission continues to show Submitted, its saved timestamp, and the
  update/remove affordances; and
• the state distinction is readable and contained on desktop and mobile without changing project
  validation or scoring behavior.

The attached independent evidence reports 23 focused tests, 931 core tests, 607 CI tests, the
quality/security/migration checks, and two passing browser scenarios with four inspected captures.
The exact staged patch is 07c250d0e699d6b7fe04e2043a95b5643ccb642c4edac78ab2ae13b0384e5372 on
current main d24808c.

This acceptance is bounded and explicitly retrospective: the candidate existed before formal
issue intake, so the process deviation is recorded above. It is not acceptance of #56, a release
approval, or permission to access production data. The full repository baseline still has the
known homepage/formatter gates, and the candidate remains staged and uncommitted. No commit,
merge, push, deployment, or production change was authorized by this comment.

[alexeygrigorev]

Shipped candidate — 2026-08-27

The PM-accepted candidate was committed and pushed to main as 5d660eb:

Fix project submission status after validation

It includes the exact accepted five-path patch (07c250d0e699d6b7fe04e2043a95b5643ccb642c4edac78ab2ae13b0384e5372). The issue-specific tester and PM evidence remains the acceptance basis. The issue stays open for the post-push/on-call gate and does not expand the scope to parent issue #56.