2026-03-18

Signal

Auditing what’s complete vs. what remains in a SaaS migration : before writing a single line of new code : is the highest-leverage activity on a complex multi-phase project, because it reveals which work is actually blocked vs. which work merely feels urgent.

Evidence

• Project: projects/jobs-apply/_index : v3.0 SaaS Migration Master Plan audit session; categorized complete vs. incomplete across all migration phases
• Method: Read existing architecture documentation, deployment state, test results, and environment configuration to produce a verified status map
• Project: projects/oil/_index : Opus sub-agent quant plans created and run; model refinement with 20-year quant experience persona; parallel planning and evaluation iterations
• Volume: 134 automated code-review sessions (oil: 67, jobs-apply: 66)

So What (Why Should You Care)

The most expensive mistake in a multi-phase migration is starting phase N+1 before phase N is actually complete. “Feels done” and “is done” are different states, and in complex migrations with many interdependencies, the gap between them is often larger than it appears. An audit session that produces a verified list of “complete / incomplete / blocked” changes the next work session from exploration (what should I do?) to execution (here’s the exact task).

The ROI on a half-day audit session at the start of a migration phase is enormous: it prevents spending a week on work that doesn’t need to happen yet, or work that’s already done. Every migration has rework cycles caused by starting work before its prerequisites are complete : the audit session is how you catch those before they start.

The Opus sub-agent pattern on the oil model shows a complementary principle: when planning work is the bottleneck (not execution), running planning agents in parallel (multiple Opus sub-agents with different personas) produces a higher-quality plan in less wall-clock time than sequential planning. The 20-year quant experience persona isn’t arbitrary roleplay : it’s a prompt that biases the output toward the reasoning patterns of practitioners who have seen these failure modes before.

The migration audit pattern : read existing state first, then categorize : is worth encoding as a reusable approach. Any complex migration has three categories of work: done (verified complete), incomplete (work that needs to happen), and blocked (work that can’t start until something else finishes). Until you have those three lists, you’re guessing about what to work on next. The categorization step takes time upfront but eliminates wasted work downstream. An hour of auditing that prevents a week of wrong-direction work is always worth it.

The architecture of the SaaS migration itself : all code complete, 592 tests passing, only environment configuration remaining : reflects a clean separation of concerns between code and infrastructure. All the code is done and verified. The remaining work is deploying 5 groups of environment variables to Vercel. That’s not a code problem; it’s an ops task. Keeping those categories separate in your tracking makes it easier to see which phase you’re actually in.

What’s Next

• Begin executing identified incomplete migration tasks from the audit
• Continue oil model parameter refinement from the Opus sub-agent plans

Log

• projects/jobs-apply/_index: v3.0 SaaS Migration Master Plan audit
• Reviewed architecture documentation, deployment state, test results, environment configuration
• Categorized all migration work into complete / incomplete / blocked
• Major architectural planning session : identified remaining work clearly
• projects/oil/_index: read oil project documentation; created separate plans for Opus sub-agents
• Ran model refinement iterations with 20-year quant experience persona
• Multiple parallel model evaluation and planning iterations
• 134 automated code-review sessions (oil: 67, jobs-apply: 66)