Files
jobtrackingapp/docs/redesign/phase-9/rd21-remediation/PLAN.md
T

6.2 KiB

RD21 remediation plan

Spec: 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.