Swasti mForm V2 → V3 Migration — Kickoff Brief

Meeting: [Swasti] mForm V2 to V3 Migration – Kickoff & Requirement Alignment Date: 2026-04-30 Duration: 80 mins Recording: https://fathom.video/share/t4gq7CLGT_isftE-zisk7j7icdfsLMQj Project folder: ~/Dhwani/swasti-mform-migration/kickoff/

Single source of truth for the Swasti V2→V3 cut-over. Updated after each working session. See transcript/full-transcript.md for the raw recording text and screenshots/ for screenshare frames.

1. Context

Client

• Swasti — high-priority strategic client; long-running partnership. Catalyst Group umbrella org (multiple sister domains).
• Programs run by Swasti’s own field workforce — basic-tech surveyors (not ASHA/Anganwadi for the current programs; Anganwadi/ASHA workers are involved on the health side).
• Currently running 3 programs on mForm V2, with a 4th brand-new program (Livelihood) about to start.

What’s being migrated

• Three existing mForm V2 projects → mForm V3 (Flutter + Frappe).
• One new program (“Livelihood”, 4th program) to be launched directly on V3.
• All four go live together on the new V3 stack.

Hard deadline

• May 25th, 2026 — all four programs must be live (3 migrated + 1 new).
• Budget for the new (4th) program: 18 days.
• Information about the deadline came in early April → ~7-week runway, of which a chunk is already spent.

2. Programs & domain model

Master form

• Member Profile — the parent / master form. All other programs hang off this.
• Profiling captures demographics, civic IDs already held (single-select indicators of which docs the member has), geography (state/district/block/GP/village), age, gender, income, PWD status, etc.
• Confirmed fields seen on screen (screenshots/30-civic-id-multiselect-35min.jpg): phone category, gender (Male/Female/Trans), household size, education, religion, occupation status, annual income, vulnerability of household, income stability.
• Member detail view (screenshots/02-member-profile-6min.jpg) has three child-program tabs at the bottom: SCHEME / DOCUMENT / HEALTH, plus an Apply for scheme CTA.
• Geography on the member is always one geography (1 district / 1 block / 1 GP).

Three current programs (children of Member Profile)

A. Scheme Application

• Purpose: Help members apply for and track government schemes.
• Scheme master scale: 107 government schemes in the picker today (screenshots/24-scheme-form-deep-11min.jpg). Includes PM Jan Dhan, PM Garib Kalyan Anna Yojana, Janani Suraksha, Antyodaya Anna, PM Awas, PM Jan Aarogya, PM Atal Pension, PM Matru Vandana, MGNREGA, PM Ujjwala, Indira Gandhi Disability Pension, PM Mudra, Post-Matric Scholarship for SC, Installation of Individual Toilets, etc.
• Eligibility filtering: The Scheme Master is filtered by member attributes — state, age, gender, income, document availability — so only schemes the member is eligible for surface in the picker.
• Linked-out: Each scheme in the master also links to its government portal.
• Per-scheme questions: Same basic question set across schemes (questions do not change per scheme).
• Members can apply to multiple schemes.
• Follow-up form structure (seen): Description, Documents Submitted by Beneficiary, Application Acknowledgement Number, “Did you check the application status with concerned Department on window period” Yes/No, Current Status dropdown (screenshots/05-scheme-form-12min.jpg).
• Follow-ups: First, second, Nth — frequency configurable per application (15 / 30 / 45 days). Each follow-up captures the current status of the application: applied, approved, benefit awaited, benefit received, rejected.
• Termination conditions: “Application approved + benefit received” closes the loop; some other terminal statuses also close.

B. Document Application

• Purpose: Help members obtain personal documents required to unlock scheme eligibility (e.g., PWD certificate, caste certificate). All documents are personal (no land documents).
• Trigger: Profiling marks the member as PWD (etc.) but the cert is missing → move them through Document Application → once obtained, they re-enter the Scheme flow.
• Form structure (seen — screenshots/12-civic-id-doc-33min.jpg, 4.1 Document Application): Beneficiary Details — father’s/spouse name, DOB, age, phone, gender (Male/Female/Trans), Religion, Occupation Status, Annual Income.
• Per-document questions: Same basic data captured regardless of which document — no document-specific question branching.
• Follow-ups: None today (status update only; not a recurring follow-up flow).
• Improvement opportunity (see §4): Auto-trigger Document Application from the Scheme flow when a required doc is missing.

C. Health Screening

• Purpose: Basic health check-ups. NCD-style screening on the member.
• Captures (seen — screenshots/10-document-application-27min.jpg, mislabeled but actually shows HS): Date of Health Screening, HB Status (e.g. Normal Anaemia), BP Status (e.g. Severe High), RBS Status (e.g. Diabetic), Current Status, Follow-up due Date.
• Follow-up history (also in same screenshot): Visit-numbered list. Example visits captured: “Member visited the Referral centre but Screening not completed”, “Member not interested to Screening and Closing the Form”. This is the longitudinal record the Frappe audit log must preserve.
• Follow-ups: “Did the check-up happen?” / “Did they visit a hospital? Private or government?” / “Did they get the diagnosis?” / similar simple cycles.
• Workforce: Nurses, Anganwadi workers, ASHA workers (different from the surveyors used for Scheme/Document).
• Status: Currently very basic. Reference model for a richer rebuild = TDH NCD project (assessment → risk → screening → diagnosis → treatment, with role separation).

New (4th) program: Livelihood

• Status: Brand new — not on mForm today.
• Shape: ~2 forms total (livelihood split into two parts), with up to 11 follow-ups per response.
• Form designs: Requirements + logic shared by client; visual designs not yet started by Dhwani.
• Same Member Profile parent.

3. Pain points (must-fix in V3)

P1. Geography scoping is wrong (data scope = surveyor, not geography)

• What happens today: Once a user logs in, they only see members they personally uploaded. If two surveyors in the same geography are both working, neither can see the other’s data.
• Why it bites: Bulk uploads done by an admin user are invisible to the field surveyor who actually works that geography — because the surveyor didn’t upload them.
• What’s wanted: Scope by geography, not by user.
  • Schemes & Documents → expected by user (per workforce model).
  • Health & Livelihood (4th program) → expected by geography.
• Bonus pain (related): When a surveyor is assigned multiple geographies, child forms (Scheme / Health) cannot pre-fill the member’s GP/Block — they come up blank. The system can’t infer which of the surveyor’s geographies the form is for, even though the member itself has a single geography.

P2. Member geography not flowing into child forms

• The member already has district/block/GP captured on Member Profile.
• Child forms (Scheme application, Health screening) should auto-prefill those geography fields from the member.
• Today: works only when the surveyor has 1:1 geography. Breaks the moment the surveyor has multiple geographies.
• Decision (see §4): New solution = hidden member-ID question carried forward + app-layer prefill from member, not on the form/data layer.

P3. UI is not scalable to N programs

• The home screen lists program tiles for the 3 current programs (screenshots/13-geography-issue-38min.jpg, 31-home-screen-stats-41min.jpg). It already has scroll/text-size faults at 3.
• Today’s tiles (live values for surveyor “Harikrishnan”): Members 533 / Pending Application 57 / Applied (Scheme) 485 / Applied (Document) 0 / Health Screening 57 / Draft (Scheme) 0. Bottom nav: Home / Scheme Follow up / Health Follow up / Document Follow up / Settings.
• Adding a 4th and 5th program (Livelihood + future) on the same UI will not work.
• Decision: V3 redesigns this with a scalable tile/list layout from day one.

P4. Self-linking creates response sprawl

• Today: every follow-up on a scheme creates a new mForm response that “self-links” back to the original. Status updates pile up as separate response rows.
• This was an mForm constraint, not a product preference.
• Visual evidence: screenshots/10-document-application-27min.jpg shows the multi-visit FOLLOW-UP HISTORY for a Health Screening member — each visit is a separate row carrying a status, but the user wants a single record with embedded history.
• Decision (see §4): Replace with a Frappe-native audit log within a single record — keep history visible, no new response rows.

P5. Document flow disconnected from Scheme flow

• Today: the surveyor manually moves a member from Scheme → Document → back to Scheme.
• Improvement (pitchable): When applying for a scheme, check required docs vs member’s held docs; if missing, auto-trigger the Document Application flow inline.

P6. Follow-up discoverability

• No way to see “what’s pending today” / “due in N days” cleanly. No push notifications.
• Surveyors forget upcoming follow-ups → quality drops.
• Decision: New homepage = members searchable + “what’s pending today / this week” buckets + colour coding (red = problematic / overdue, green = on track) + push notifications (paid feature enhancement).

P7. Multi-language is layered awkwardly

• mForm V2 supports English / Kannada / Telugu for Swasti.
• Frappe’s translation model is different — view/UI labels and data collection are separate layers. View can be Kannada, but data is stored in English; for free-text fields, the data is whatever the user typed (Kannada/Telugu/Gujarati).
• Free-text in regional script breaks downstream visualisation (e.g., a phone number entered in Gujarati script).
• Decision: Confirm exact languages with Swasti and design multi-language support carefully — different from mForm’s “upload a translation” model.

P8. QA is the bottleneck (process pain, not product)

• Old life cycle: 15 days per release → enough time for manual regression. Now: cycles are days, not weeks. Sachin (QA) can’t sit and re-run the full regression suite for every cut and still cover other projects.
• Decision: Set up an automated regression pipeline:
  • Dedicated QA PC (or emulator) running 24/7.
  • AI/MCP agent runs the regression test suite when a new APK is dropped.
  • Sachin owns first-run feature testing for new forms only; regression is automated thereafter.
  • Mobile regression is the hardest part. Frappe (web) regression is solvable with Playwright.

4. Decisions made in the call

5. Action items

6. Open questions / things to confirm with Swasti

1. Exact list of languages required for V3 (currently English, Kannada, Telugu — re-confirm and check whether new program adds anything).
2. Geography vs user scoping per program — confirm Scheme & Document = user-scoped, Health & Livelihood = geography-scoped.
3. Document follow-ups — is “no follow-up on document applications” a hard rule, or do they want at least a status update flow?
4. Auto-trigger Document from Scheme — pitch this and confirm before building.
5. Health module ambition — stay basic, or accept a TDH-style scope (gamification, role separation, FHIR-out)?
6. Push notifications — feature enhancement; confirm willingness to pay.
7. Bulk-upload behaviour under new geography scoping — how should admin uploads surface to the right surveyor(s)?
8. OCR on uploaded evidence — they don’t ask for it today; OCR is costly. Confirm they don’t want it.
9. Dashboard parity — they have an existing Superset dashboard. Confirm they’re OK moving to a custom Frappe dashboard for V3.

7. Tech stack & architectural notes

• Mobile: Flutter app, V3 SDK (same approach as Reliance / rel-mis).
• Backend: Frappe (Doctype-driven form definitions; no client-facing survey builder).
• Bootstrap path: Import from live mForm V2 instance (form JSON, geography masters, scheme master, members, responses) — not greenfield. See §10 for the import-pipeline plan.
• rel-mis posture: Reference for Frappe app shape, hooks, audit-log pattern, mobile sync, deployment. Not a literal template — Swasti’s geography model is simpler (no User Program Assignment, no multi-geography permission expansion).
• Form authoring: Excel design template → Doctype generation (Dhwani team owns this).
• Dashboard: Frappe Insights or custom Next.js, AI-assisted chart generation. Superset deprecated.
• Translation: Frappe view-label translation for UI; data stays in English where possible; free-text remains in entered language.
• Audit / history: Native Frappe document history / change log instead of mForm’s self-link pattern.
• Multi-language data is stored as the user typed it; visualisation strategy needs to handle mixed-script free-text.
• Web app: Yes, expected. Frappe web side mirrors mobile flows. Auto-fill / pre-fill behaviour must match mobile.
• Ticketing: Internal HRMS-linked ticketing for dev work orders.
• Help / KB: Frappe Desk knowledge base for client self-service.

8. Risks & flags

1. 🔴 Deadline. May 25 with 4 programs (3 migrate + 1 new in 18 days) is tight. QA automation must land before sprint mid-point or it becomes the bottleneck.
2. 🔴 QA bandwidth. Sachin is a single-point dependency today. Regression automation is the unblocker; if it slips, QA blocks every release.
3. 🟡 Language model. Frappe’s translation differs structurally from mForm; the mixed-script free-text problem is unsolved and will surface in dashboards.
4. 🟡 Dashboard handoff. Swasti is used to a Superset dashboard — re-confirm OK with custom Frappe before we drop Superset.
5. 🟡 Geography logic regression. The hidden-member-ID + app-layer prefill is new code; needs a dedicated regression case across user-scoped and geography-scoped programs.
6. 🟢 Form authoring is owned by us, not the client. Excel template + Doctype path is well-understood; low risk.
7. 🟢 Programs are conceptually similar across V2. Member Profile is the master, child programs share the same shape — minimal domain modelling surprises expected.

10. Bootstrap approach: import from existing mForm V2 instance

Decision (post-kickoff, 2026-04-30, Abhijit): The Swasti V3 Frappe app is not built greenfield from the rel-mis blueprint. Instead, we connect to Swasti’s existing mForm V2 instance and pull everything live into the new Frappe app — form definitions, masters, and member data.

What we need to extract from mForm V2

• Form JSON definitions for all forms across all 3 current programs (Member Profile, Scheme Application, Scheme Followup, Document Application, Health Screening, all sub-forms / child forms / followup forms).
• Geography master — full state/district/block/GP/village hierarchy as Swasti has it loaded.
• Scheme master — all 107 schemes with their eligibility filters (state, age, gender, income, required documents) and government-portal links.
• Document master — list of personal documents Swasti supports.
• User / surveyor list with their assigned geographies (single or multiple).
• Member data — all profiled members with their geography and civic-ID flags.
• Response data — all submitted responses including the “self-linked” follow-up history (so we can reshape it into the Frappe audit-log model on the way in — see D3).

What we don’t know yet (open)

• Access method to the mForm V2 instance — REST API? Database export? Both? Direct DB access via mForm admin? — needs to be confirmed with the mForm team.
• Translations — only language[0].lng="en" is present in the dumped JSONs. Kannada/Telugu strings live elsewhere in mForm V2. PM design sheet also English-only. Where? (Gap A14a — see 03-mform-json-analysis.md §3 finding 1, confirmed unresolved in 05-pm-design-doc.md §12.)
• Master data values — the dump contains form definitions only, not master data. PARTIALLY resolved by 05-pm-design-doc.md §9: Custom Fields catalog (Occupation/Marital/Religion/Caste/Disability/Family Income/Civic IDs) for member is in the PM sheet. Still missing: the 107 schemes (eligibility filters + portal links), document master, donor master, geography hierarchy. (Gap A14b — see 03-mform-json-analysis.md §3 finding 2.)
• Validation rules — validation[].condition is null in every form. RESOLVED. Validations live in per-question sibling keys (pattern, min/max, minRange/maxRange, restrictions, editable, isToBeEncrypted) plus input_type-implicit rules. The validation[].condition array is a placeholder. The conversion skill’s validation-layer-matrix.md is the canonical lookup. See 04a-validation-source-resolution.md. Strike A14c from the mForm-team queue. Micro-TODO: sample one form’s restrictions array shape when picking up A16.
• Form-JSON shape in mForm V2 vs. what the Doctype generator expects. The 13 form sample is documented in 03-mform-json-analysis.md — order (string-numeric) is the universal join key, parent/child/dataOrdersMapping all reference questions by order. Job 1 of the pipeline is a (formId, order) → fieldname registry.
• Rare input types — codes 13, 29, 30 appear in the JSONs but were not sampled. Pipeline must hard-fail on unmapped types.
• Self-link unwind logic — the order of operations to collapse N “self-linked” responses into 1 record + N audit-log entries needs to be defined and tested before bulk import. Decoder is in the JSON — getDynamicOption + dataOrdersMapping + closedItself (form 1011 spells out terminal status codes 2/4/5/12/13/14 on order 22). Implementable now.
• Idempotency / re-runs. Whether the import can run multiple times during dev without duplicating data — design upfront.
• Excluded forms. 1012 (up-test) is a developer test form — exclude from production import. formId 1013 was deleted historically and isn’t in the dump.

How this changes the rel-mis reference

rel-mis (02-reliance-frappe-context.md) is now reference, not template:

• Use it to understand the target shape of the Frappe app — naming, hooks pattern, audit-log Doctype, mobile sync API, deployment.
• Do not lift the User Program Assignment / multi-geography permission infrastructure — Swasti’s geography model is simpler.
• The “Replication checklist” in that doc is a from-scratch-build path; for Swasti, sequence is import pipeline first, then layer the Frappe shape around the imported data.

New action items added by this decision

• A14 (Abhijit + dev team): Reach out to mForm team / Swasti to confirm access method and credentials for the V2 instance.
  • A14a: Confirm where Kannada/Telugu translations live and how to export them.
  • A14b: Confirm whether there is a masters export endpoint (the 107 schemes’ values, the document master, donors, geography hierarchy) — separate from the form definitions we already have.
  • A14c: Confirm whether validation[].condition is genuinely empty in V2 or stored elsewhere. RESOLVED locally by reading the conversion skill — validations are per-question sibling keys + input_type-implicit. See 04a-validation-source-resolution.md. No mForm-team question needed.
• A15 (dev team): Once access is confirmed, write a small probe script that lists forms, schemes, members count, response count, and sample-fetches one form JSON. Establishes feasibility before designing the full pipeline.
• A16 (dev team): Design the import pipeline. Per 04-mform-to-frappe-skill.md, the skill is a workflow pack covering Phase 02 only (“do not automate end-to-end” — gated verification per form, four-files-in-parity output: DocType JSON + .py + .js + .dart). A16 decomposes into ordered jobs:
  • A16.1 — Cross-form registry. Build and persist (formId, order) → fieldname for all 13 forms before invoking the skill on any form with cross-form refs. Forms 1003/1005/1011 (self-link) and any dataOrdersMapping.fromOrder (input_type 21) silently break without it.
  • A16.2 — Skill run, per-form, gated. Run the conversion skill against each form with manual verification at each step. Outputs four parity files per Doctype.
  • A16.3 — Self-link collapse. Not in the skill’s scope. Implement on top using form 1011’s closedItself terminal-status codes (order 22, values 2/4/5/12/13/14) + rel-mis’s Submission Approval Log pattern from 02-reliance-frappe-context.md.
  • A16.4 — Master-data hydration. Not in the skill’s scope. Skill produces empty Option Masters; we populate them from A14b’s masters export (107 schemes, document master, donors, geography hierarchy).
  • A16.5 — Member + response import. Records hydrated against the registry + audit-log entries from collapsed self-link chains.
  • Must be idempotent and incremental end-to-end.
  • Cross-reference field for durability: every imported Doctype carries description: "form_<id>" as the permanent mForm↔Frappe link.
• A17 (dev team): Run the import end-to-end on a staging Frappe instance and validate counts + spot-check records.
• A18 (dev team): Sample the rare input_type codes (13, 29, 30) from V2; extend the conversion skill to handle them or document them as unsupported.
• A19 (dev team): Reconcile each PM-design row vs. its V2 JSON counterpart per form; produce a delta report (added/removed/renamed/re-ranged questions). Feeds into A16.2 acceptance criteria. See 05-pm-design-doc.md.
• A20 (dev team): Author the Livelihood Doctype directly from 05-pm-design-doc.md §5 (no V2 JSON exists). Use the conversion skill’s templates for shape; inputs are the PM sheet, not a JSON. Adds A16.0 — Greenfield Livelihood to the pipeline.
• A21 (dev team): Encode the HS Logics BMI/HB/BP/RBS lookup tables (05-pm-design-doc.md §6) and BP New Logic max-of-Sys/Dia rule (§7) as Frappe Python helpers + client mirror. Use the 36-row BP matrix as regression fixture.
• A22 (Abhijit + PM): Resolve DRIS-comment open questions on Health Screening (BMI standard WFH/WFA, <5yr profiling, “why only Hb here”, status-count clarification). See 05-pm-design-doc.md §15.
• A23 (dev team): Build the canonical WorkflowStatus Doctype from Status of Apply For Scheme Docu (Scheme 16 + Document 11 statuses) — single source of truth for closure terminals. Replaces V2 form 1003’s closedItself array.
• A24 (PM + Abhijit): Enumerate the “List of 9” Civic IDs (likely matches kickoff screenshot 30-civic-id-multiselect-35min.jpg).
• A25 (dev team): Use HS Test Cases (15 scenarios) as regression fixtures for the BMI/HB/BP compute helpers — wire into QA per A10.

9. References

• Recording: https://fathom.video/share/t4gq7CLGT_isftE-zisk7j7icdfsLMQj
• Raw transcript: kickoff/transcript/full-transcript.md
• Screenshare frames: kickoff/screenshots/
• Architecture (pre-kickoff): mform-migration-architecture.pdf, docs/index.html
• Reliance reference (proven SDK route): ~/Dhwani/rel-mis/
• TDH NCD reference (health module pitch): ~/Dhwani/TDH-AI/, ~/Dhwani/TDH-FHIR/