cesnimda/jobtrackingapp
1
0
Fork 0
Code Issues Pull Requests Actions 4 Packages Projects Releases Wiki Activity

docs(rd21): record reproduced data loss and remediation scope

Browse Source
This commit is contained in:
cesnimda
2026-10-23 07:56:04 +02:00
parent 8e7e3f6387
commit 8f2cad67f7
4 changed files with 507 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/redesign/phase-9/rd21-remediation/PLAN.md
+86
View File
@@ -0,0 +1,86 @@
# RD21 remediation plan
Spec: [REQUEST.md](REQUEST.md). Baseline: `8e7e3f6387544e24082ebe2c107c0b868897959e`.
## Global constraints
Keep historical Phase 9 evidence unchanged. Use synthetic local databases, existing providers,
EF concurrency tokens and existing client error handling. No production actions, main merge,
new dependencies, silent stale-write retries or historical recovery claims.
The reproduced failure is persisted full-snapshot replacement without a caller precondition.
Career Profile additionally commits canonical state before its Identity projection. The repair
must compare the revision the editor actually read and atomically guard the eventual database
write. Missing preconditions fail closed. Schema format `profile.version` is not a revision.
## Task 1: Career backend and persistence tests
Own CareerProfileService, CareerProfileController, ProfileCvController partials, and dedicated
RD21 Career tests. Enumerate canonical import/parse/review/restore callers before changing them.
Add deterministic RED tests before implementation. Require expected canonical revision on
editor replacement, restore, parse and reviewed import acceptance. Return a persistence revision
with the coherent source snapshot/diff. Guard EF updates with existing CareerProfile.Version;
serialize competing first saves using the existing unique owner constraint plus safe conflict
translation. Keep children, history, legacy projection and import application metadata in one
transaction. Failed Identity/DB updates roll back everything. No failed operation can be saved
later through a dirty tracker. Preserve read-only public loads, tenant filters, stable IDs,
CV inheritance and frozen outputs. Test independent contexts, stale restore, first saves,
transaction rollback, and canonical/projection consistency. Notify coordinator of shared
DbContext configuration required; do not edit DbContext or migrations (Task 2 owns those).
## Task 2: Job revision infrastructure and consumers
Own JobApplication model, DbContext, migrations, generic job PUT/DTO and affected job writers,
API client and job UI callers, plus dedicated job regression tests. First write a failing
SQLite persistence test reproducing stale acknowledged job replacement. Add an application
managed integer revision; advance it for every tracked JobApplication mutation, including
background/legacy writers, with EF atomic original-revision comparison. Generic full-snapshot
PUT requires the caller revision. Preserve 204 compatibility while returning the committed
revision in a response header for sequential callers. All production snapshot callers carry
the revision of their actual source; never fetch a new revision to bless an old snapshot.
Surface conflicts and retain drafts. Inspect cover letter, package drafts, timeline and other
overlapping writes; guard directly related destructive stale replacements and document distinct
unrelated findings. Preserve company ownership validation, opportunity dual writes and events.
Generate migration only against local development infrastructure; test upgrade and rollback
without touching real user data. Integrate Task 1's Career concurrency configuration here.
## Task 3: Frontend Career consumers and deterministic UI tests
After Task 1 contract is known, update Career editor/import/restore/parse call sites and test
fixtures. Hold the source revision with the draft. Disable overlapping conflicting actions or
serialize accepted saves without losing edits made during the request. Out-of-order reads and
responses cannot replace newer local edits. A rejected/failed save retains the editable draft;
recovery requires deliberate reload/review, never blind automatic overwrite. Add focused tests
for conflict/network failure, in-flight editing, and delayed response handling.
## Task 4: Integration, qualification and delivery
Run unchanged historical characterization and separate stronger browser safety tests: exact
original ordering, immediate independent database read, refresh, navigation, new authenticated
session, rapid saves, concurrent requests and recoverable rejection. Run targeted native/Jest
tests before full backend, frontend, browser, contract, sidecar, diagnostics, type/lint/build
gates. Serialize build/browser lanes and freeze source identity for final evidence. Probe local
MariaDB/disposable Docker availability without external calls or production mutations; record
unavailable qualifications honestly. Review tenant/security regressions and preservation matrix.
Obtain independent code review, fix actionable findings, write dated acceptance addendum with
separate RD21/Phase 9/Phase 10/production decisions and exact non-overlapping totals. Commit
logical checkpoints, push the dedicated branch and verify remote SHA and clean status.
## Preflight and rulings
| Tasks | Shared interface / consistency check | Ruling |
| --- | --- | --- |
| 1 / 2 | Career.Version EF configuration belongs to DbContext | Task 1 specifies; Task 2 edits shared file and generates migration. |
| 1 / 3 | Career DTO and import precondition | Task 3 waits for explicit contract; no guessed auto-refresh fallback. |
| 2 / 3 | Shared API client | Task 2 owns job methods; Task 3 edits only Career page/tests unless coordinated. |
| 1 / 4 | Service tests vs HTTP contract | Both persisted state and fail-closed HTTP behavior required. |
| 2 / 4 | Legacy 204 and revision advancement | Keep status, expose committed revision; characterize unchanged old test separately. |
| 3 / 4 | UI optimism vs acknowledged persistence | Acknowledgement only after successful response; draft retention independently tested. |
| 1 | Existing internal test setup callers | Update callers explicitly; no production blind-save overload. |
| 2 | All tracked writers vs partial endpoints | Token prevents overlapping server writes; caller preconditions required for stale snapshot replacements. |
| 3 | Draft revision vs server response ordering | Never attach a later revision to an older draft automatically. |
| 4 | Broad suites vs bounded provider/manual evidence | Preserve 56 PARTIAL/C11 DEFERRED until their actual criteria pass. |
Ruling: use the user-requested dedicated branch in the existing clean checkout. Extra worktree
creation and routine approval pauses are unnecessary; autonomous execution and pushes are
explicitly authorized in REQUEST.md.