Azure App Rebuild

Implement the customer's explicitly requested application, wave, or slice in their application repository. A complete-app rebuild is a supported delivery scope, not a requirement to rewrite everything in one pass. This is a separate delivery workflow, never an automatic continuation of azure-app-modernization.

1. Reconcile the delivery contract

Read the current repository instructions and the complete package under docs/modernization/: assessment.md, specification.md, strategy-matrix.md, target-architecture.md, infrastructure-plan.md, cost-estimate.md, current-state.drawio, target-architecture.drawio, and migration-plan.md. Inspect the source, tests, manifests, data contracts, deployment configuration, domain records, and relevant UI authority. Discover available supporting skills instead of assuming installation.

Require an explicit delivery scope: complete application, migration wave, or vertical slice, with its boundary, acceptance IDs, preserve/change/retire decisions, prerequisites, and expected validation evidence. Use the reviewed package and explicit delivery request directly; do not require another summary or handoff document. If scope is missing or ambiguous, obtain a decision before editing; do not assume either an unrestricted rewrite or a single-slice outcome. A reviewed package need not carry formal approval unless the customer's governance requires it. Check any required acceptance record.

For complete-app scope, account for every required workflow, integration, and applicable UI surface in the reviewed specification. Track coverage in existing task/test records or the response, linking workflows to acceptance IDs, implementation work, tests/checks, and pass/fail/blocked evidence. Resolve gaps in required behavior or acceptance criteria with the decision owner rather than inventing criteria or silently dropping workflows. An intentional retirement needs a recorded package decision.

Compare current source with the confirmed baseline and selected target. Identify stale evidence, missing artifacts, contradictions, and unresolved feasibility blockers. Stop affected implementation and return material architecture changes to planning; do not invent a target, acceptance criteria, or approval.

Readiness for static planning is not readiness to execute: establish a repeatable build/test approach, safe fixtures, and required local access for the requested scope. Record pre-existing failures separately. Do not execute unknown scripts, restore database backups, or use production credentials simply to establish a baseline.

2. Implement incrementally within the agreed scope

Break the agreed scope into testable end-to-end increments and follow the reviewed dependency order. For complete-app delivery, continue through the increments inside that scope while prerequisites hold; a working first journey is a checkpoint, not completion. Do not require a new scope decision for each already-agreed increment, or stop after one merely because it works. For a wave or slice request, keep later waves and unrelated workflows out of scope. Material blockers or architecture changes still require the affected work to stop.

Use existing patterns and preserve all behavior and contracts not explicitly changed by the specification. Keep unrelated components untouched. Use codebase-design, tdd, or diagnosing-bugs for bounded support when installed, without granting those skills broader scope.

For UI work, load impeccable when available and use PRODUCT.md, DESIGN.md, .impeccable/design.json, and confirmed SURF- dispositions as authority. New frontend technology does not authorize redesign. Report missing design evidence before changing affected surfaces.

For data/integration changes, preserve write ownership, ordering, idempotency, compatibility, coexistence, and rollback/reconciliation boundaries from the plan. Use synthetic or sanitized data. Author migration/IaC/CI files only when in the agreed scope; generating them does not authorize running them. Use infrastructure-plan.md to reconcile the app's configuration, identity, and dependency needs with the provided infrastructure contract.

Do not use the upstream implement skill as an unattended wrapper: its contract includes committing work. Do not commit, publish issues, provision resources, deploy, migrate production data, or change repository/cloud settings without explicit authorization for that action in this delivery session. Tool permission prompts and repository controls remain in force.

3. Validate and review

Add focused tests for changed behavior, including important failure and compatibility paths. Run the smallest relevant existing checks, expanding to integration/build checks as needed. Verify every in-scope acceptance criterion with actual output; a generated test or workflow file is not a passed check.

For complete-app scope, reconcile workflow coverage against the full reviewed specification, including workflows absent from the implementation diff. Exercise the app's required workflows and integrations with safe fixtures; record unavailable checks as blocked. Passing one journey, a build, or an increment's tests does not establish whole-app completion.

Review implementation completeness against requirements, wave dependencies, data and UI commitments, and directly related documentation. Use the host's code-review workflow or installed code-review skill, then resolve findings and rerun affected checks. Run a separate security review after completeness findings are resolved or explicitly accepted. If independent review or runtime tooling is unavailable, name the missing review/check and its owner; do not claim it passed.

4. Report results and stop

Report the package revision, requested delivery scope, completed increments, changed files, acceptance IDs with pass/fail/blocked evidence, review findings and disposition, pre-existing failures, remaining prerequisites, and rollback/reconciliation readiness. Distinguish local validation from deployment or production readiness.

A failed, blocked, or uncovered required criterion means the requested scope is incomplete or explicitly partial, not done. For a complete-app request, report remaining workflows and blockers even when several increments are finished. Do not silently relabel partial delivery as a smaller successful scope. Stop at the agreed app/wave/slice boundary; do not advance to an unrequested wave or expand the application. Leave commits and operational execution to separately authorized actions.