Prepared for Adem · 14 September 2026

CDA dirty-change recovery and continuation roadmap

Recover the unfinished work, establish a tested OMP baseline, and complete the retained programme workflows. The roadmap below records what has started and what still needs a current product decision.

What moved forward

The first preparation work is complete. All ten repositories have recovery bundles. Their changed and nonignored untracked files restore with matching hashes and Git status. The original repositories remain intact.

An isolated OMP branch now contains the repaired academic-result existence check. Four focused runtime checks pass with dependency test doubles. The same checks fail against the original helper. Native Jest tests are ready, but the application dependencies, full build, and database suite have not been run.

The report experiment is preserved as text outside the application. The district query remains beside it as evidence. SQL, old cookie settings, and generated graphs remain in the private recovery set.

The next gate

Establish the isolated runtime baseline, run the native tests, and finish change classification. Inventory ignored configuration, uploads, and the system of record before cleanup or migration. Recovery of Git and dirty files does not establish a production-data backup.

Current evidence: CONTINUATION_PROGRESS.md, recovery/LATEST.txt, per-repository manifests, and scripts/verify_academic_result.cjs. Verified for this roadmap on 14 September 2026, Africa/Nairobi.

Repository decisions and evidence

Repository	Verified snapshot	Current role
omp-api	1b75249. One modified service and three untracked application artifacts before preservation.	Continuation candidate. Repair work now lives in implementation/omp-api on cda/dirty-change-stabilization.
omp-client	9565dff. Generated audit graph only.	Frontend continuation candidate. Runtime and product parity still need proof.
Latest orphan-database	df7ea1d. Six modified tracked files plus the audit graph.	Preserved reference for geography, uploads, role workflows, and reports.
Earlier orphan-database	0191323. Three modified tracked files plus the audit graph.	Historical evidence. Exclude its insecure cookie override from continuation.
Other six directories	Recovery bundles and restoration verified. Four contain audit graphs; two duplicate directories are clean.	Preserved history. No archive or deletion decision has been made.

Technical review is assigned to Adem for this working plan. Programme, finance, and data owners still need names. Dates for later milestones depend on those assignments and the baseline results; this plan makes no delivery-date commitment.

Milestone 0. Preserve and classify

Owner role: technical lead. Start here. Product questions can be gathered while preservation proceeds.

Capture each repository's HEAD, branches, staged and unstaged status, and untracked file list. Record the runtime manifests and lockfiles without copying credentials into the roadmap.
Create recoverable Git bundles and separate binary patches for staged and unstaged changes. Copy the changed and untracked files with their relative paths. Include the SQL session file and generated artifacts in the private recovery set. A Git bundle alone does not preserve working-tree changes.
Check ignored files for configuration, uploads, or other unique assets. Record them in a private inventory and preserve the required items separately. Treat credentials and programme records as private material.
Verify the recovery set in a temporary checkout. Reapply the patches, restore the copied files, and compare the recovered file hashes with the source. Keep a copy outside the original repositories before cleanup.
Create isolated OMP working copies for implementation. Do not rely on a clean worktree to carry over untracked experiments. Reapply only the changes selected for review.
Classify each change as keep and repair, preserve as an experiment, replace with a new implementation, or exclude from the application baseline. Record the reason, destination, reviewer, and verification for each.

Gate 0

The recovery set can reconstruct all three dirty trees. Every application change and untracked artifact has a recorded destination. No original change is silently discarded. Runtime work uses isolated copies, with the originals preserved.

Milestone 1. Resolve the changes in reviewable pieces

Work item	Proposed treatment	Proof required
D1. Academic-result existence helper	Repaired in the isolated OMP copy. The helper awaits findOne and throws NotFoundException when no record exists. No callers of this newly added helper were found in the original source.	Four focused runtime checks pass for present, missing, rejected, and delayed results. Equivalent native Jest tests are added but await dependency setup. Full application validation remains open.
D2. Reporting experiment	Preserved as experiments/reporting/legacy-count-report.ts.txt outside application discovery. The district query is retained beside it. Replace the experiment only after its report contract is accepted.	The isolated application contains no copy of the experiment. A future implementation must await all operations, assert fixture totals, and propagate failures.
D3. District query and SQL session	Retain the GraphQL query only with its intended report or a labelled example. Inspect the SQL privately for useful queries, credentials, data, and mutations before moving anything into maintained code.	The SQL file has a documented disposition and has not been executed against an unknown database. Approved examples contain synthetic data and belong to a defined report contract.
D4. Geography registration	Port useful behaviour into OMP after comparing current forms and API rules. The legacy edits change region/zone/district selection, refresh options after creation, and make the village district required.	Switching parent selections clears stale descendants. Cancelling and reopening works. Duplicate names cannot select the wrong ID. The API rejects invalid parent-child relationships.
D5. Geography reassignment and project dates	Decide the rule before implementation. The GraphQL diff deprecates district reassignment arguments; a deprecation label does not enforce a restriction. The UI also removes project start-date limits.	Direct API calls enforce the agreed reassignment policy. Programme reviewers accept historical and future project-date cases.
D6. Upload filenames	Replace the legacy filename helper with a reviewed storage rule in OMP if needed. The dirty helper replaces characters and truncates names; preserve original display names separately.	Long names, Unicode, duplicate names, extension preservation, and invalid uploads have defined outcomes. Stored attachment references remain valid.
D7. Local ports and formatting	Keep local port choices in environment configuration. Exclude whitespace and formatting-only hunks from functional patches after preservation.	Frontend endpoint, API listener, and allowed development origins agree. The change can be reviewed without unrelated formatting.
D8. Old startup and dependency edits	Preserve as historical evidence. Replace any still-useful startup convention in the maintained OMP deployment. Do not transplant the old Prisma version bump into OMP.	Lockfile and manifest agree in the chosen baseline. Documented startup works in a clean environment.
D9. Old session-cookie changes	Retire the insecure override from future code. The older clone sets httpOnly and secure to false. Keep the original diff only in the recovery archive.	The retained application's production session configuration has the required cookie protections and works behind its actual deployment proxy.
D10. Generated audit directories	Keep useful domain graphs with supporting documentation or exclude them from application tracking through a deliberate repository decision.	No generated audit artifact is mistaken for an unfinished product feature. The originals remain recoverable.

Order the review as D1 to D3, D4 to D7, then D8 to D10. Keep commits separated by behaviour. The legacy fixes are requirements evidence for OMP, not an instruction to merge unrelated repository histories.

Gate 1

All ten items have an accepted disposition. Retained OMP changes pass their focused checks. Deferred experiments have a location and owner. The isolated continuation baseline has no unexplained changes; the preserved originals may remain dirty.

Milestone 2. Prove the baseline and close access gaps

Owner role: technical lead, with programme input on permissions. Depends on Gate 0 and the relevant Milestone 1 decisions.

Install from the selected lockfiles in isolated copies. Record the actual Node and package-manager requirements. Run builds and existing tests, then record failures as baseline issues. The OMP lint script currently applies fixes, so use a check-only invocation while measuring the baseline.
Use a disposable database and synthetic fixtures. Review test and startup scripts before running them. Establish login, intake, geography, education, support plans, payments, and upload smoke checks.
Address the audit's known frontend auth condition and missing layout. Confirm the current code before repairing them. Decide the Nuxt/Vue maintenance path from a small compatibility exercise rather than combining a full upgrade with every parity fix.
Define and enforce a server role/action/record-scope matrix. Cover self-selected signup roles, cross-donor and cross-territory access, exports, assignments, deletions, and account maintenance.
Remove fallback secrets from the release configuration. Define account recovery and session handling. Add dated actor history for sensitive case, assignment, sponsorship, and financial changes.

Gate 2

A new checkout starts from documented steps with synthetic data. Builds and required checks pass, or each nonblocking inherited failure has a written reason and owner. Unauthorized reads and writes fail at the API. No access or session blocker remains for the chosen release scope.

Milestones 3 to 6. Finish the programme workflow

Milestone and dependency	Deliverable and role owner	Completion gate
3. Case operations and product decisions. After Gate 2.	Programme owner and technical lead agree the retained roles, then finish intake, geography, assignment, education, health, documents, photos, and letters. Resolve validation and duplicate-handling rules.	Representative staff complete intake, correction, reassignment, and an education or field update. Required validations and record permissions pass.
4. Sponsorship and finance. After agreed roles and case rules.	Programme and finance owners define donor selection, plans, transition dates/reasons, expiry, receipts, exchange rates, fee basis, precision, rounding, allocation, approval, and corrections.	One complete registration-to-sponsorship-to-payment cycle reconciles. Tests cover retries, donor mismatch, partial funds, rejected approval, reversals, and invalid transitions.
5. Reports and migration. Contracts start during Milestone 3; acceptance follows stable workflow rules.	Programme, finance, and data owners accept Payment History, Status, and Education contracts. Technical lead implements reports and a repeatable legacy-ID-to-OMP-ID importer.	Report fixtures match the approved layouts and totals. Two migration rehearsals reconcile records, relationships, money, dated history, and attachments. No unexplained difference remains.
6. Pilot, cutover, and archive. After Gate 5 and release checks.	Operational reviewers complete a bounded programme cycle. Technical and data owners rehearse final backup, edit freeze, import, reconciliation, switch, and rollback.	Owners accept pilot results and a tested rollback. Support and backup ownership are assigned. Archive restoration and unique-data checks precede duplicate removal.

Report contracts to settle early

Payment History needs orphan, donor, and project views with the specified currency, fee, and total columns. Status needs a decision between termination-only output and general status history. Education needs location, donor, and project groupings plus an academic-period rule and repeat-count definition. The workbook does not settle filter semantics or permissions.

Start read-only data discovery and report examples alongside baseline work. Confirm whether the authoritative database and document store survive before schema migration or archival decisions. If no usable source survives, replace import work with a documented re-entry and reconciliation plan.

Prefer application-native outputs for the three fixed report families as a proposal for review. Defer exploratory analytics until those contracts pass. Do not interpret the unfinished count experiment as delivery of the required reports.

Legacy capabilities need current decisions

These are proposed dispositions, not approved retirements. Port preserves a business capability in OMP. Replace preserves its purpose through an agreed alternative. Retire removes it from maintained scope while keeping required historical records.

Capability	Proposed disposition	Decision owner and deadline
Donor and Social Worker tasks	Port the required tasks. A staff-assisted replacement is an option if direct access is no longer needed.	Programme owner, before Milestone 3 scope is accepted.
Sponsorship transitions and history	Port with allowed actors, effective dates, and reasons.	Programme and finance owners, before Milestone 4.
Financial records and IGA records/photos	Replace overlapping finance records with the agreed model. Decide port or retire for active IGA work after usage review; retain its history either way.	Programme, finance, and data owners, before finance and migration mapping.
Project and daily activities	Propose port if still required for the operating cycle. Otherwise record an explicit retire decision before excluding them.	Programme owner, before pilot scope.
Account-maintenance approvals	Replace with controlled account recovery and separately governed payment-detail changes.	Programme and technical owners, before Gate 2.
Current/latest condition snapshots	Replace with dated history and an explicit current-record rule.	Programme and data owners, before reports and migration.
Payment, status, and education reports	Port the agreed workbook contracts and required exports.	Programme and finance owners, define during Milestone 3.
Other historical suggestions and custom analytics	Defer pending a current requirement. Decide replace or retire individually when reviewed.	Programme owner, before adding any item to the release backlog.

Trello Done labels, checklist counts, and historical suggestions do not establish present scope. If a decision depends on comment, checklist, or attachment content absent from the dumps, inspect that specific card in the signed-in board before accepting the requirement.

Source traceability and decision limits

Source	Roadmap commitments it supports
ORPHAN_PRODUCT_CHAIN_REPORT.md. Proven lineage, capability parity, and decisions required before implementation resumes.	OMP remains the continuation candidate. Preserve the latest legacy reference. Close authorization gaps, stabilize invariants, decide parity, map IDs and histories, then prove migration and cutover.
TRELLO_BOARD_CONTEXT.md. Role-specific operations and intended end-to-end workflow.	Decide Department Manager, Coordinator, Donor, and Social Worker responsibilities. Test intake, donor selection, pending sponsorship, finance calculations, approval, activation, and assignment as one workflow.
TRELLO_BOARD_CONTEXT.md. Exact report layouts and later reporting board.	Payment History by orphan, donor, and project. Status by donor and project. Education by location, donor, and project. Settle newly sponsored, support history, periods, filters, and repeat-count meaning before implementation.
DIRTY_CHANGE_INVENTORY.md. Earlier snapshot dated 12 September 2026.	D1 through D10 retain their identifiers. Current recovery manifests confirm local repository states. The progress record distinguishes actual repairs from proposed treatments.
Historical Trello dumps and the report workbook, as summarized in TRELLO_BOARD_CONTEXT.md.	Descriptions and layouts are requirements evidence. Badge counts do not reveal comments, checklist text, or attachment contents. The workbook defines empty layouts, not production output.

This run used the supplied reports and fresh local repository evidence. It did not refresh the signed-in Trello board, reopen the workbook, fetch remote branches, or inspect production data. Open relevant live cards when a current product decision needs missing card-level detail. Historical completion is not approval for implementation.