283 lines
7.2 KiB
Plaintext
283 lines
7.2 KiB
Plaintext
# Jobjakt — Phase 10
|
|
## Final Redesign Cleanup, Technical Consolidation and Regression Acceptance
|
|
|
|
## Mission
|
|
|
|
Complete Phase 10, the final cleanup stage of the Jobjakt redesign.
|
|
|
|
Remove obsolete code, consolidate superseded UI implementations and improve maintainability without removing existing capabilities or changing product behaviour unnecessarily.
|
|
|
|
This is a controlled cleanup—not a rewrite, architecture replacement or new feature-development phase.
|
|
|
|
## 1. Prerequisites
|
|
|
|
Before modifying code, verify:
|
|
|
|
- Phase 9 requalification decision.
|
|
- CV-UX-01 acceptance.
|
|
- CV-IMPORT-01 acceptance.
|
|
- CV-QA-01 acceptance.
|
|
- Phase 10 readiness approval.
|
|
- Current preservation status.
|
|
- Latest accepted development commit and remote state.
|
|
|
|
Read the original Phase 10 specification and all relevant acceptance reports.
|
|
|
|
If mandatory cleanup entry criteria remain NO-GO, do not bypass them.
|
|
|
|
## 2. Branch
|
|
|
|
Create:
|
|
|
|
`feature/phase10-cleanup`
|
|
|
|
Base it on the newest accepted development integration baseline containing the applicable Phase 9 and CV work.
|
|
|
|
Do not branch from outdated production main.
|
|
|
|
Commit and push independently validated cleanup checkpoints.
|
|
|
|
Do not merge into main or deploy.
|
|
|
|
## 3. Complete legacy inventory
|
|
|
|
Inspect:
|
|
|
|
- Old page components.
|
|
- Superseded layouts.
|
|
- Old CV Editor implementations.
|
|
- Obsolete CV Import screens.
|
|
- Unused document components.
|
|
- Duplicated styling.
|
|
- Unused design tokens.
|
|
- Dead hooks and utilities.
|
|
- Unused frontend routes.
|
|
- Unreferenced API endpoints.
|
|
- Obsolete feature flags.
|
|
- Unused dependencies.
|
|
- Old localisation keys.
|
|
- Deprecated test fixtures.
|
|
- Dead asset references.
|
|
|
|
For every proposed deletion, record:
|
|
|
|
- File/component/endpoint.
|
|
- Historical purpose.
|
|
- Current consumers.
|
|
- Evidence it is unused.
|
|
- Preservation group affected.
|
|
- Tests required.
|
|
- Risk.
|
|
- Proposed action.
|
|
|
|
Do not determine deletion safety from a single text search.
|
|
|
|
Inspect route registration, dynamic imports, runtime configuration, API consumers, persisted references and compatibility requirements.
|
|
|
|
## 4. Preserve application functionality
|
|
|
|
Protect all 57 functionality-preservation groups and all valid routes.
|
|
|
|
Preserve:
|
|
|
|
- Authentication.
|
|
- Account recovery.
|
|
- Career Profile.
|
|
- Jobs.
|
|
- Dashboard.
|
|
- CV Editor.
|
|
- CV Import.
|
|
- Cover letters.
|
|
- Documents.
|
|
- PDF export.
|
|
- Analytics.
|
|
- Notifications.
|
|
- Admin.
|
|
- Settings.
|
|
- English/Bokmål.
|
|
- Responsive layouts.
|
|
- AI sidecar contracts.
|
|
|
|
No working capability may disappear without an explicitly approved product decision.
|
|
|
|
A feature marked PARTIAL or DEFERRED must not be deleted merely because it lacks complete acceptance evidence.
|
|
|
|
## 5. CV implementation consolidation
|
|
|
|
The new CV Editor and Import workflows may have superseded legacy components.
|
|
|
|
Identify which old paths are genuinely obsolete.
|
|
|
|
Remove them only after verifying:
|
|
|
|
- New paths provide the required capabilities.
|
|
- Historical CVs still load.
|
|
- Submitted/frozen revisions remain usable.
|
|
- Old stored formats have appropriate compatibility or migration support.
|
|
- Imported data is preserved.
|
|
- PDF exports still work.
|
|
- Existing links and routes remain valid or have safe redirects.
|
|
|
|
Do not delete the old renderer solely because the new one exists.
|
|
|
|
Preserve any compatibility functionality still required for historical documents.
|
|
|
|
## 6. Backend and database cleanup
|
|
|
|
Audit:
|
|
|
|
- Unused services.
|
|
- Superseded DTOs.
|
|
- Duplicate routes.
|
|
- Obsolete mappings.
|
|
- Provider-specific code.
|
|
- Deprecated imports.
|
|
- Unused database helpers.
|
|
|
|
Do not change production schemas or delete migrations merely to make the repository cleaner.
|
|
|
|
### SQLite
|
|
|
|
A staged SQLite retirement plan already exists.
|
|
|
|
Determine whether its required MariaDB coverage, migration and data-preservation gates have been satisfied.
|
|
|
|
If not, keep SQLite retirement as a separate tracked initiative.
|
|
|
|
Do not make SQLite deletion a prerequisite for unrelated Phase 10 completion.
|
|
|
|
If the owner later approves a full SQLite retirement, carry it out as a separately qualified data-platform change.
|
|
|
|
## 7. Frontend cleanup
|
|
|
|
Consolidate genuinely duplicated:
|
|
|
|
- Layout primitives.
|
|
- Form controls.
|
|
- Styling tokens.
|
|
- Dialog implementations.
|
|
- State-handling utilities.
|
|
- Dead CSS.
|
|
- Accessibility helpers.
|
|
|
|
Prefer established components and avoid introducing another UI framework.
|
|
|
|
Be especially cautious with theme, responsive and localisation contracts.
|
|
|
|
## 8. Dependencies and configuration
|
|
|
|
Identify dependencies no longer used.
|
|
|
|
Before removal, verify:
|
|
|
|
- Runtime imports.
|
|
- Build tooling.
|
|
- Test tooling.
|
|
- Scripts.
|
|
- Conditional features.
|
|
- Docker/runtime usage.
|
|
- Platform-specific usage.
|
|
|
|
Update lockfiles and reproducible builds.
|
|
|
|
Do not run broad dependency upgrades unrelated to the cleanup.
|
|
|
|
## 9. Regression verification
|
|
|
|
Run appropriate complete suites after significant changes.
|
|
|
|
Include:
|
|
|
|
- Backend.
|
|
- Frontend.
|
|
- Browser.
|
|
- Browser contracts.
|
|
- MariaDB integration.
|
|
- Sidecar.
|
|
- PDF fidelity.
|
|
- Types.
|
|
- Lint.
|
|
- Build.
|
|
- Security.
|
|
- Accessibility automation.
|
|
- EN/Bokmål.
|
|
- Preservation checks.
|
|
|
|
Verify historical CV/document compatibility.
|
|
|
|
Perform targeted browser/visual testing on affected routes.
|
|
|
|
Never delete tests merely because they expose a cleanup regression.
|
|
|
|
## 10. Checkpoints
|
|
|
|
### P10-00 — Baseline and deletion eligibility
|
|
Establish the accepted baseline and evidence-backed cleanup inventory.
|
|
|
|
### P10-01 — Frontend components and styling
|
|
Remove proven obsolete frontend implementations.
|
|
|
|
### P10-02 — CV/document legacy paths
|
|
Consolidate superseded CV workflows while protecting historical compatibility.
|
|
|
|
### P10-03 — Backend, dependencies and configuration
|
|
Remove safe dead code and obsolete dependencies.
|
|
|
|
### P10-04 — Functional and data integrity verification
|
|
Run targeted regression, migration and document compatibility tests.
|
|
|
|
### P10-05 — Complete acceptance
|
|
Run full suites, reconcile all 57 preservation groups and prepare the post-redesign handoff.
|
|
|
|
Use established checkpoint naming if different IDs are already authoritative.
|
|
|
|
Commit and push each validated checkpoint.
|
|
|
|
## 11. Deliverables
|
|
|
|
Create:
|
|
|
|
`docs/redesign/phase-10/`
|
|
|
|
Document:
|
|
|
|
- Cleanup inventory.
|
|
- Removed files and dependencies.
|
|
- Evidence of unused status.
|
|
- Retained compatibility code.
|
|
- Architecture improvements.
|
|
- Preservation results.
|
|
- Full regression results.
|
|
- Performance/build-size differences if measurable.
|
|
- Remaining technical debt.
|
|
- Outstanding production blockers.
|
|
- Final Phase 10 acceptance.
|
|
- Post-redesign product review handoff.
|
|
|
|
Do not remove historical documentation or accepted test evidence.
|
|
|
|
## 12. Decisions
|
|
|
|
Phase 10: GO / CONDITIONAL GO / NO-GO.
|
|
|
|
Redesign development completion: GO / CONDITIONAL GO / NO-GO.
|
|
|
|
Product review readiness: GO / CONDITIONAL GO / NO-GO.
|
|
|
|
Production release: GO / NO-GO.
|
|
|
|
A completed cleanup does not mean production is ready.
|
|
|
|
## Final instruction
|
|
|
|
Complete Phase 10 conservatively and autonomously.
|
|
|
|
Only remove proven obsolete functionality.
|
|
|
|
Push validated checkpoints to:
|
|
|
|
`feature/phase10-cleanup`
|
|
|
|
Prepare an accurate handoff for PRODUCT-REVIEW-01.
|
|
|
|
Do not merge into main or deploy production. |