Progress Tracking

1. Read the ordered ### Phase headings in workflow.md to determine the phase names and total.
2. Read the ordered workflow-unit table in automation.md. For each phase, load the linked automation files that own its work and add their executable headings in document order. Include conditional and optional headings; mark them skipped only after evaluating their conditions.
3. Use a numbered step label such as 4g as its stable ID. For unnumbered work, use the exact heading text.
4. On resume, rebuild the workflow snapshot from the current headings and reconcile it with saved state:
   • preserve matching completed, skipped, deferred, blocked, and pending entries;
   • add new headings as pending in document order;
   • record renamed or removed saved entries under Notes instead of silently discarding them.

Resume After External Provisioning

When Step 4b is blocked on keyless provisioning and the user returns with a target resource ID, load Adopt a User-Provisioned Target before any target writes. Keep the block until read-only verification and user approval succeed. Do not reapply target-name defaults or rerun creation/conversion commands.

Record the adopted target resource ID in Current Status and its verified storage, identity, and monitoring resource IDs in Notes. Mark Step 4b complete only as externally provisioned and verified; reconcile applicable skipped steps as directed by the adoption procedure. Set Next action to the first unfinished step at or after 4c, not app creation. Preserve all outstanding approval gates.

Reporting Rules

1. Before each action, update Current Status and display: Phase <current> of <total> · <step> · <description> · <state>.
2. After success, mark the item complete and immediately display the next item.
3. At an approval gate, use state awaiting approval and invoke ask_user in the same turn.
4. Mark work skipped — <reason> when it is not applicable or the user intentionally omits it and no later action is expected in this migration.
5. Mark work deferred — <reason> when it remains outstanding but the user chooses to continue, such as access-restricted HTTP validation or production trigger cutover. Preserve it in the workflow snapshot and summarize it in Next action or Notes; never represent it as complete.
6. Mark work blocked when an intended action cannot proceed because of an error or unresolved dependency. Record the error without secrets and do not advance unless the user explicitly chooses to defer or skip the work.
7. The workflow may advance past skipped or deferred items. A phase may close with those states, but its summary must identify deferred work.
8. Do not report a percentage; validation and cutover duration varies by function count.

Migration Outcomes

Track an outcome separately from the current step state:

Never infer production cutover complete from successful resource creation, deployment, ARM health, or partial validation alone. A user may explicitly conclude a test migration as validation-only success.

State meanings:

Status Template