CDA orphan programme roadmap

A proposed route from the unfinished OMP rebuild to a working programme system. Start by settling scope and recovering the data, then prove the complete registration, sponsorship, payment, and reporting workflow before cutover.

The direction I recommend

Continue with omp-api and omp-client as the starting point. Keep the latest orphan-database as the reference for existing behaviour. The older clones explain how the product developed, but they do not need separate roadmaps.

OMP has the clearer code structure. The older system still contains business processes that OMP has not finished carrying over. The project needs one agreed definition of a complete release before it needs another long feature list.

Proposal, not an approved scope

This roadmap proposes the work and its order. Repository lineage and missing capabilities come from the audit. Future scope, assigned people, budgets, and release dates still need an owner. Historical Trello cards are evidence of intent, not instructions to implement everything.

Decision	Proposed direction
Product	One system for CDA staff, donors, and social workers to manage orphan cases, sponsorship, payments, follow-up, and required reports.
Code	Evaluate the OMP pair in a running environment, then make it the maintained application. Preserve the latest legacy system as a frozen reference.
First release	Complete one real programme cycle with agreed role permissions, traceable money calculations, case history, and the three supplied report families.
Release standard	An authorized user can complete the cycle on reconciled data. Programme and finance reviewers accept the results.
Schedule	Work proceeds through six phases. Set calendar dates after recovery and the first running demonstration. Unknown data quality and team capacity make a delivery date premature.

What the evidence tells us

The ten repository directories represent eight distinct snapshots. Two pairs are exact duplicates. The latest omp-client continues the orphan-management-client history.
The OMP backend rebuilds the core domain with a clearer structure. OMP still lacks complete evidence of parity for role-specific operations, reporting, activities, and some financial workflows.
The historical registration process joins department management, coordinator intake, donor selection, support plans, fund receipt, payment calculations, finance approval, and social-worker assignment.
The report workbook specifies Payment History, Orphan Termination/Status, and Orphan Education outputs. The later reporting board also records unresolved terms and missing business concepts.
The audit was static. A successful build, a current deployment, the authoritative database, and a usable document store have not yet been established.

These findings make recovery, workflow rules, and reporting release work. They cannot be left as cleanup after the interface is finished.

Six phases to a release

Phase	Deliverable	Completion check
1. Recover and decide	A recoverable baseline, named owners, agreed first-release scope, and a running OMP demonstration.	The team identifies the source of truth, proves a backup restore or records that no source survives, and signs the scope and decision log.
2. Make the foundation usable	Repeatable development and staging, an agreed frontend upgrade path, server permissions, audit history, and migration mappings.	A new checkout starts from documented steps. Permission tests block forbidden actions. A restored test environment survives an upgrade.
3. Complete case operations	Intake, geography, assignments, case history, education, and field follow-up for the chosen user roles.	Representative users complete a case from registration through an education or follow-up update, including correction and reassignment.
4. Complete sponsorship and payments	Donor selection, support plans, governed status changes, fund receipt, allocation, approval, and payment-sheet export.	Programme and finance reviewers accept an end-to-end payment example and its failure cases. Every amount and status change has an explanation.
5. Prove reports and migration	Accepted report contracts, repeatable data conversion, exception handling, and reconciled outputs.	The three report families match approved fixtures. Two migration rehearsals reconcile records, balances, history, and attachments.
6. Pilot and cut over	A bounded pilot, trained users, support ownership, an approved cutover, and a tested rollback.	The pilot completes one operational cycle. Owners accept the reconciliations and cutover plan. The legacy system becomes read-only at the agreed time.

Work that can overlap

Inspect source data and draft report examples during phase 1. Start migration mappings in phase 2 and refine them as workflows settle. Report implementation can overlap payment work after the calculation rules are agreed. Cutover depends on all earlier completion checks.

Phase 1. Recover and decide

The first ten working days should produce answers and a small demonstration. They should not disappear into a framework migration.

Name a programme decision maker, a finance reviewer, a technical lead, and a data custodian. One person may hold more than one role. Record who can accept each milestone.
Inventory repository branches, uncommitted work, hosting, databases, uploaded documents, backups, and deployment access. Preserve the three dirty working trees before choosing a baseline.
Restore the best available database and document backup into an isolated environment. Record its age and coverage. If no recoverable dataset exists, adopt a documented re-entry plan and adjust the roadmap.
Run OMP with synthetic data. Walk through login, orphan intake, project and support-plan creation, payment entry, education, and reporting. Record actual failures and missing steps.
Walk the historical process with programme staff, a coordinator, a donor representative, a social worker, and finance. Resolve who performs each action today.
Review the proposed port, replace, and retire decisions below. Turn retained work into a new backlog with evidence, an owner, dependencies, and an acceptance example.
Estimate the remaining phases from the running baseline and data inspection. Choose pilot participants and the programme segment they will cover.

Gate 1

A scope owner accepts the first-release workflow and exclusions. The technical lead demonstrates the baseline. The data custodian records what can be recovered. Unanswered questions have an owner and a due date.

Phase 2. Make the foundation usable

Make development, test, and staging reproducible. Pin dependencies, document configuration, and validate database migrations. Keep synthetic fixtures available for routine development.
Choose the frontend maintenance path after testing representative OMP pages. Use a short compatibility exercise to decide between an incremental upgrade and rebuilding the shell while retaining the agreed workflows.
Define server permissions by role, action, and record scope. Cover department managers, coordinators, donors, social workers, administrators, and the agreed finance approval responsibility.
Add audit history for case changes, sponsorship transitions, financial actions, assignment changes, and exports. Define who can view sensitive records and how corrections are recorded.
Set account creation and recovery rules, session handling, upload access, backup retention, and operational error reporting.
Draft legacy-to-OMP mappings for identifiers, education history, guardians and jobs, housing, sponsorship, financial records, and attachment locations.

Gate 2

A fresh checkout starts with documented commands. Automated checks reject unauthorized cross-role and cross-territory access. The team can restore a test backup, apply migrations, and recover from a failed release.

Phase 3. Complete case operations

Finish the department-manager and coordinator workflows for geography, users, donors, projects, territories, and social-worker assignments.
Complete orphan registration, family and guardian records, housing, assets, documents, photos, letters, health, and education. Mark which information is required at intake and which can arrive later.
Agree duplicate detection and correction rules. Define age and education checks with programme staff instead of encoding assumptions from old forms.
Give social workers the agreed minimum workspace for assigned cases and follow-up. Include education updates, photos, letters, and account details if the programme retains that responsibility.
Preserve dated history and the actor behind changes. Define how users correct mistakes without silently rewriting important history.
Test incomplete forms, interrupted submissions, duplicate attempts, reassignment, restricted access, and changes to shared guardian or sibling data.

Gate 3

A department manager, coordinator, and social worker complete their parts of a representative case without developer intervention. Required validation and permission tests pass. Programme reviewers accept the record and its history.

Phase 4. Complete sponsorship and payments

This is the centre of the operational release. A payment must be traceable from donor and support plan to approval and orphan allocation.

Define sponsorship transitions, allowed actors, effective dates, reasons, graduation, termination, expiry, and return to the unsponsored pool.
Complete donor review and selection, individual or group support plans, schedules, and coordinator handoff. A staff-assisted donor workflow is acceptable only if the scope owner chooses it explicitly.
Agree currency precision, exchange-rate source and date, administration-fee basis, rounding, gross and net amounts, allocation totals, and handling of partial or excess funds.
Implement fund receipt, payment calculation, review, approval, allocation, and payment-sheet export in the agreed order. Keep submission and approval responsibilities distinct where policy requires it.
Make retries safe. Define reversal and correction behaviour, rejected approvals, closed plans, donor mismatches, and duplicate receipts.
Use finance-approved examples to test each calculation. Check that allocations reconcile to the approved amount and that unauthorized users cannot approve or alter payments.

Gate 4

Finance and programme reviewers accept a complete sample cycle, including one correction and one rejected or partial payment. The payment sheet, balances, sponsorship history, and audit history agree.

Phase 5. Prove reports and migration

Build the required reports as application functions with permission checks and stable exports. Keep exploratory analytics as later work. The supplied workbook is the starting contract, and programme staff must settle the meanings that the workbook leaves open.

Report	Required coverage	Acceptance check
Payment History	Orphan, donor, and project views. Dates, currencies, administration fees, gross and net ETB values, support-plan grouping, and totals.	Each total reconciles to the accepted payment examples. Display, export, and print use the same approved calculations.
Orphan Status	Donor and project views. Orphan identity, effective date, status or termination event, and reason.	Agree whether this is general history or termination-only. Test changes, corrections, and reporting as of a selected date.
Orphan Education	Location, donor, and project views. Name, gender, grade, status, reason, and repeat count.	Agree the academic period, current-record rule, and repeat-count definition. Test multiple years and changed assignments.

Agree filters, date boundaries, grouping, empty results, totals, access, export format, and print layout before calling a report done.
Separate confirmed fields from unresolved requests such as newly sponsored or support history. Assign definitions and data sources before adding them to the release.
Build a repeatable importer with an old-ID to new-ID map, dry-run output, rejected-record report, and safe reruns. Preserve source extracts and original attachment references.
Rehearse migration twice. Compare counts by record type, relationships, sponsorship and education history, attachment checks, and financial totals. Give each exception an owner and resolution.
Have staff compare a representative sample of migrated cases and reports against the source. Record accepted differences instead of hiding them.

Gate 5

Approved fixtures pass for all three report families. Rehearsals produce consistent results, no unexplained financial differences, and no unowned migration exceptions. The data custodian and finance reviewer sign the reconciliation.

Phase 6. Pilot and cut over

Choose a bounded programme segment that includes the retained user roles and a complete payment and reporting cycle. Train those users with their actual tasks.
Agree where new edits belong during the pilot. Avoid uncontrolled editing in both systems. Record comparison results and fixes in one issue list.
Measure failed tasks, report disagreements, payment exceptions, support requests, and cases that require developer intervention.
Rehearse the final backup, write freeze, final import, reconciliation, application switch, and rollback. Specify who can make the go or no-go decision.
Cut over only after users complete the pilot cycle and owners accept the data and reports. Assign ongoing support, backups, incident handling, and release ownership.
Make legacy applications read-only, tag the preserved repositories, and verify archive restoration. Delete duplicate clones only after the data custodian confirms nothing unique remains.

Gate 6

The pilot has no unresolved blocker for access, case operations, payment accuracy, or the required reports. Programme, finance, data, and technical owners approve cutover. Restore and rollback instructions have been exercised.

Proposed decisions for legacy behaviour

These recommendations make the scope review concrete. Port means preserve the business capability using the new implementation. Replace means preserve its purpose with an agreed alternative. Retire means exclude the old capability from the maintained product. Retirement never implies deleting historical records.

Legacy capability	Proposal	Where it belongs
Donor and social-worker workspaces	Port the required tasks with current role and record permissions.	Phases 3 and 4. Confirm whether donors act directly or through an agreed staff-assisted process.
Sponsorship decisions and status history	Port as a dated workflow with allowed transitions and reasons.	Phase 4. Free editing of a status value is insufficient.
Payment, status, and education reports	Port the supplied report contracts and required exports.	Phase 5, with contract examples agreed during phase 1.
Financial records	Replace with an agreed model that distinguishes disbursements, other support, and corrections.	Define in phase 1. Implement the first-release needs in phase 4 and preserve historical data during migration.
Current and latest orphan snapshots	Replace with dated history and a documented current-record rule.	Phases 3 and 5. Preserve the information needed for historical reports.
Account-maintenance approvals	Replace with controlled account recovery and separately governed changes to bank or payment details.	Phases 2 and 4. Review which old requests concern identity versus money.
Daily and project activities	Port after the pilot unless the programme identifies them as required for its operating cycle.	Record cadence, required fields, reviewer, and reports before scheduling.
Income-generating activities and photos	Retire from the first-release scope, subject to programme confirmation.	Preserve historical data. If still active, define the workflow and move it into a later funded phase.
Custom statistics and exploratory dashboards	Replace ad hoc requests with a defined report catalogue, then evaluate an analytics tool.	The three required report families ship first. Budget additional reports individually.
Donor website integration, broad account enhancements, and other historical suggestions	Retire from the first-release backlog unless a current owner presents a need.	Reconsider after the pilot. Authentication controls needed for the chosen deployment still belong in phase 2.

Ownership and decisions that can move the plan

Owner role	Responsibility
Programme decision maker	Accept scope, terminology, role workflows, report meaning, pilot results, and retained or retired capabilities.
Finance reviewer	Accept currency and fee rules, approval responsibilities, corrections, reconciliations, and payment outputs.
Technical lead	Own the application baseline, upgrade path, permissions, tests, deployment, migration tooling, and release readiness.
Data custodian	Identify authoritative records, control source extracts, accept migration exceptions, verify backups, and approve archive handling.
Operational reviewers	Demonstrate coordinator, donor, department-manager, and social-worker tasks and report where the proposed process fails.

Open question	Default for planning	Effect of a different answer
Does an active production dataset survive?	Assume recovery is required until phase 1 proves otherwise.	No usable source requires a re-entry plan. An active source requires a final write freeze or controlled change capture.
Which roles will use the first release?	Retain department management, coordination, donor work, and social-worker work.	A staff-only release needs an explicit delegation process and a revised permission and acceptance matrix.
Which financial rules are authoritative?	Use finance-approved examples before implementation.	Unresolved currency, fee, or approval rules block phase 4 acceptance.
Are activity and IGA workflows still used?	Defer activities and exclude IGA from the first release pending confirmation.	Current operational use may require an earlier port and a longer scope.
What team and review time are available?	Assign roles in phase 1, then estimate.	Limited reviewer availability delays acceptance even when engineering work is finished.

The plan is ready to become a backlog after phase 1. Each item should name the user task, the relevant evidence, its owner, its dependency, and the result that proves it works.

Evidence and limits

This roadmap draws on ORPHAN_PRODUCT_CHAIN_REPORT.md and TRELLO_BOARD_CONTEXT.md in the project workspace. The latter reconciles the original 198-card depOrph dump, the 13-card reporting dump, and CDA reports ready for INTEGRATION.xlsx.

The Trello records describe historical work from 2020 through 2023. Their dumps omit comment text, checklist-item text, and attachment contents. The workbook specifies empty report layouts. Neither an old Done label nor a filled checklist count proves current functionality.

The baseline audit examined local code and history. Phase 1 must refresh repository state and verify runtime behaviour, data availability, and current stakeholder needs. This is a proposed roadmap prepared on 12 September 2026, with no implementation or archival actions approved by its publication.