jobtrackingapp/docs/redesign/phase-9/rd21-remediation/REQUEST.md

Jobjakt — RD21 Critical Data-Loss Remediation

Phase 9 Blocking Defect · Root Cause, Repair and Requalification

Mission

Resolve the Phase 9 blocking defect RD21: acknowledged Career Profile and job edits can subsequently be lost.

This is a high-priority data-integrity defect.

The goal is to eliminate the root cause, prove that acknowledged changes are durably persisted, prevent stale writes from silently replacing newer data, and obtain sufficient regression evidence to reassess Phase 9 acceptance.

Work autonomously through safe investigation, implementation, testing, documentation, commits and remote pushes.

Do not start Phase 10, deploy production or implement unrelated features.

1. Confirm the baseline

The final Phase 9 state is:

• Branch: feature/phase9-full-qa
• Commit: 8e7e3f6387544e24082ebe2c107c0b868897959e
• Phase 9: NO-GO.
• Phase 10 readiness: NO-GO.
• Production: NO-GO.
• Working tree clean and remote verified at handoff.

Reported passing tests:

• Backend: 1,084.
• Frontend: 919.
• Browser: 362.
• Browser contracts: 23.
• AI sidecar: 56.
• Diagnostics: 18 + 3.

Read:

docs/redesign/phase-9/p9-07/FINAL_ACCEPTANCE.md

Locate all RD21 reproduction evidence, logs, issue records and related tests.

Inspect the exact reproduction rather than inferring the cause from the issue title.

2. Branching

Create a dedicated branch:

fix/rd21-acknowledged-edit-loss

Base it on the accepted Phase 9 development HEAD containing the commit above.

Do not branch from older production main.

Preserve the original Phase 9 acceptance report and its historical NO-GO decision.

Do not force-push or modify unrelated branches.

3. Reproduce and isolate RD21

Before implementing a fix:

1. Locate the exact known RD21 reproduction sequence.
2. Reproduce it in a controlled development environment.
3. Identify which Career Profile and job workflows are affected.
4. Capture request/response ordering and relevant revision information.
5. Determine when the application reports a successful save.
6. Verify what the database actually contains immediately afterward.
7. Verify what remains after refresh, navigation and a new session.
8. Distinguish frontend display inconsistencies from actual persisted data loss.

Determine whether the problem is caused by one mechanism affecting multiple workflows or separate defects.

Do not weaken the reproduction test or change its conditions simply to obtain a pass.

Use synthetic data.

4. Investigate the complete save lifecycle

Trace each affected workflow end-to-end:

User edit → Client draft/state → Save request → API validation → Authorization → Database transaction → Durable commit → Server response → Client acknowledgement → Subsequent reads.

Investigate potential causes, including:

• Stale frontend state.
• Overlapping requests.
• Autosave and explicit-save races.
• Debounced requests completing out of order.
• Optimistic UI acknowledgements.
• Lost or ignored request failures.
• Stale API responses overwriting newer client state.
• Concurrent updates.
• Missing revision/concurrency checks.
• Background refresh or cache invalidation.
• Navigation/unmount timing.
• Database transaction behaviour.
• Partial aggregate updates.
• Incorrect mapping between API DTOs and persisted entities.
• Shared abstractions affecting Career Profile and jobs.

These are investigation hypotheses, not assumed findings.

Find the actual root cause and support it with evidence.

5. Implement a durable fix

Requirements:

• A successful-save acknowledgement must correspond to confirmed successful persistence.
• Failed saves must not be presented as successful.
• The latest user-approved change must not be silently replaced by stale data.
• Concurrent updates must be handled predictably.
• Revision conflicts must be surfaced appropriately.
• Failed operations must retain recoverable user edits.
• Related fields must not be inadvertently cleared by partial updates.
• Correct user and tenant ownership must be preserved.
• Existing Career Profile canonical-data and CV-specific override rules must remain intact.
• Submitted/frozen documents must not be unintentionally modified.
• Job timelines and associations must remain consistent.

Prefer a focused correction to the existing save infrastructure.

If shared infrastructure is defective, fix the common cause rather than applying unrelated UI workarounds.

Do not add arbitrary delays or unbounded retries to hide a race condition.

Do not change save semantics without testing all affected consumers.

6. Regression tests

Create deterministic tests that reproduce the original RD21 failure before accepting the fix.

Include suitable coverage for:

• Career Profile edits.
• Job edits.
• Consecutive rapid edits.
• Overlapping saves.
• Delayed and out-of-order responses.
• Navigation immediately after save acknowledgement.
• Refresh after save.
• Logout/login or independent session.
• Failed network requests.
• Database transaction failures.
• Concurrent editing in two sessions.
• Conflict detection and recovery.
• Partial updates and unchanged fields.
• Cross-tenant isolation.
• Existing CV and document revision behaviour.

Tests must establish persisted database state, not merely successful API status codes or optimistic UI state.

Use controlled concurrency and deterministic synchronisation where possible, avoiding timing-dependent flaky assertions.

7. Database-provider verification

Run the relevant tests against the existing supported development provider.

Also verify MariaDB using an isolated disposable test instance if the environment supports it.

Do not claim MariaDB compatibility from SQLite-only evidence.

Do not access or mutate the production database.

If MariaDB cannot be exercised, record it as a specific outstanding qualification requirement.

8. Broader regression review

Investigate whether similar save patterns exist in:

• Dashboard preferences.
• Settings.
• CV Builder.
• Cover letters.
• Documents.
• Application timelines.
• Other editable user-owned records.

Do not assume they are affected.

Use code inspection and targeted tests to establish whether the RD21 root cause extends beyond the original affected workflows.

Fix directly related vulnerabilities to user-data integrity within this bounded remediation scope.

Record unrelated findings separately.

9. Verification

After fixing RD21:

• Run the original reproduction.
• Repeat it across multiple deterministic test cases.
• Run affected backend and frontend tests.
• Run applicable browser tests.
• Run provider and tenant-isolation checks.
• Run the complete regression suite.
• Run type checking, lint and build.
• Run applicable security checks.
• Reconcile the functionality preservation matrix.

Record exact commands, results, failures and limitations.

Do not conceal failures through skips or weakened assertions.

10. Phase 9 requalification

Once the fix is validated, reassess Phase 9 against the original acceptance requirements.

Distinguish:

A. RD21 resolved.

B. Phase 9 functional QA readiness.

C. Remaining manual accessibility/device checks.

D. Provider/database qualification.

E. Phase 10 readiness.

F. Production release readiness.

RD21 resolution must not automatically convert every outstanding PARTIAL or DEFERRED preservation item into PASS.

Treat the existing 56 PARTIAL groups and C11 DEFERRED according to their authoritative acceptance criteria.

Update findings only where new evidence justifies doing so.

Preserve the original Phase 9 NO-GO report and create a dated remediation/requalification addendum.

11. Documentation

Create an RD21 remediation directory using repository conventions, for example:

docs/redesign/phase-9/rd21-remediation/

Include:

• Original reproduction.
• Root-cause analysis.
• Affected workflows.
• Implemented fix.
• Concurrency/save semantics.
• Before/after regression evidence.
• Database verification.
• Full test results.
• Preservation impact.
• Remaining risks.
• Phase 9 acceptance addendum.
• Phase 10 handoff decision.

Document any recovery limitations for edits that may already have been lost. Do not claim historical data can be recovered without evidence.

12. Autonomous execution

Work autonomously through:

1. Baseline and reproduction.
2. Root-cause investigation.
3. Implementation.
4. Targeted regression tests.
5. Broad regression qualification.
6. Acceptance addendum and handoff.

Commit completed logical checkpoints.

Push to:

fix/rd21-acknowledged-edit-loss

Verify remote synchronisation and clean working tree.

Do not stop for routine low-risk decisions.

Escalate destructive operations, significant scope changes or mandatory external approvals.

13. Release boundaries

The live server remains production NO-GO.

Do not:

• Merge into main.
• Deploy production.
• Run production migrations.
• Restart live services.
• Modify live databases.
• Perform filesystem repairs.
• Change live Ollama models.
• Start Phase 10.
• Begin LinkedIn, FINN/NAV or new AI features.

The production filesystem, backup, restore, security and manual acceptance requirements remain independently gated.

14. Final acceptance

Report separate decisions:

RD21: RESOLVED / UNRESOLVED.

Phase 9: GO / CONDITIONAL GO / NO-GO.

Phase 10 readiness: GO / CONDITIONAL GO / NO-GO.

Production: GO / NO-GO.

Include:

• Exact root cause.
• Reproduction evidence.
• Code changes.
• New regression tests.
• Actual full test results.
• MariaDB qualification status.
• Remaining defects and risks.
• Preservation status.
• Branch name and final commit.
• Remote verification.
• Phase 10 recommendation.

Final instruction

Begin by reproducing RD21.

Fix the proven underlying cause, not the visible symptom.

Validate that an acknowledged edit remains durably saved after subsequent requests, navigation, refresh and independent-session reads.

Complete all safe remediation and requalification checkpoints autonomously.

Push validated work to the dedicated fix branch.

Do not merge to main or begin Phase 10 automatically.