87 lines
6.2 KiB
Markdown
87 lines
6.2 KiB
Markdown
# 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.
|