Reconciliation at Scale

Using AI to modernize FileMaker, one reconciled step at a time

The system is a FileMaker Pro solution that runs across thirteen offices in the same vertical: roughly 123 tables, 1,157 scripts, 624 layouts, the full operational workflow those offices share. The job is to rebuild it as a browser-and-tablet web app on a TypeScript stack, and to do it once for all thirteen offices instead of thirteen times. The driver is web access and vendor independence from Claris and Apple.

That scale is exactly where a FileMaker migration usually goes wrong. The artifacts come out clean, the plan reads well, and then the build quietly drifts away from the plan. This is the day the pipeline closed that gap.

The pipeline, in order

The work is not one skill. It is five steps that hand off to each other, each one producing the input the next one trusts.

1. migrate-filemaker created the artifacts. The skill parsed the DDR export and ran its explorer workflows — function, script, calculation, hide-object-when, naming, workflow, security. That produced the structured artifacts: the app summary, discovery answers, recommendations, the schema migration plan, the API design, the UI spec, and the business-logic doc. Evidence, not narrative.

2. We established gold. Thirteen variants of the same system needed one reference. One office became the gold baseline, frozen as a timestamped snapshot. Everything downstream measures against it.

3. We documented the variances. Cross-office explorer runs compared every other office to gold and wrote the deltas — schema differences, naming differences, data-security differences. Three tiers of divergence emerged: offices that stayed close, offices with small local changes, and offices that had structurally drifted. That classification is what told us what must be identical, what may vary by office, and what was old scaffolding that should not survive the rebuild.

4. We ran prd-builder. With the artifacts and the deltas in hand, prd-builder turned them into a phased PRD: an index plus per-phase task lists, scoped to a Phase 1 launch cohort of five offices across phases 1A through 1H. Phase 2 and 3 offices were deferred on purpose so they could inform future-proofing without blocking launch.

5. Then we built phase-dev

Here is the part that was missing, and the reason this day matters.

A PRD phase doc is a task checklist. It is intent. It is not the source of truth, and on a system this size it cannot be, because the design lives across many authoritative docs that do not always agree with each other. The live database schema says one thing, the canonical schema says another, the tech-stack guardrails forbid a tool the PRD casually assumed. Build straight off the checklist and you inherit every one of those disagreements as a bug.

So before any phase gets code, phase-dev runs a second reconciliation pass — this time against an explicit authority hierarchy:

1. Live Drizzle schema — what physically exists right now
2. Canonical schema + API — the data shape and contracts
3. Tech-stack guardrails — tool choices the PRD is not allowed to override
4. Phase-scope reconciliation — what is in or out of Phase 1
5. UI spec + style guide — routes, screens, form specs, tokens
6. Domain / business truth — how the offices actually work
7. PRD phase doc — intent, reconciled against everything above, never trusted over it
8. Schema standards — conventions for anything new

When two docs disagree, the higher authority wins for its domain. phase-dev builds the misalignment matrix, fills genuine gaps in the repo's existing conventions, surfaces the real decisions for a human, writes a per-phase build plan, and only then — on approval — builds: migration, then API, then UI, then tests.

Why this is not theater

The behavior was validated by hand on Phase 1A before it became a skill, and the catches were real. The PRD said email login; canonical said username. It assumed a sessions table that did not exist. It reintroduced Redis that the tech stack had already dropped. It specified argon2 when Bun ships hashing built in. Every one of those was a higher-authority source quietly contradicting the checklist. Every one would have shipped if the build had trusted the PRD.

That is the whole argument for a reconciliation gate. The expensive drift on a FileMaker migration is not the schema you can see. It is the small assumption that reads as obviously correct and is wrong against a doc nobody re-opened.

Where this leaves the work

The gold baseline is frozen. The cross-office deltas are written. The PRD is phased and the Phase 1 cohort is locked. phase-dev now sits in front of every phase, so the chain from FileMaker export to running code has a checkpoint at each step instead of one hopeful leap at the end.

A migration tool can copy a system. Modernizing thirteen FileMaker variants into one product takes classification first and reconciliation at every build step. The pipeline now does both, and the drift dies at the gate instead of in a code review three weeks later.