Resource Verification
Run these checks immediately after writing each resource to plan.resources[]. Fix issues in-place before moving to the next resource. Load the relevant category file from resources/ for naming constraints, valid SKUs, and pairing rules.
1. Name Checks
| # | Check | Fix |
|---|---|---|
| 1 | Follows CAF pattern from resource file Identity/Naming section | Rewrite using correct abbreviation |
| 2 | Length within min/max for type | Truncate or restructure |
| 3 | Only allowed characters for type | Strip disallowed characters |
| 4 | Globally-unique names avoid collisions | Add distinguishing suffix |
| 5 | Required subnet names exact (AzureFirewallSubnet, GatewaySubnet, AzureBastionSubnet) |
Use exact required string |
| 6 | Function Apps sharing Storage diverge within first 32 chars | Rename or separate storage |
| 7 | AKS MC_{rg}_{cluster}_{region} ≤ 80 chars |
Shorten names |
2. Dependency Checks
| # | Check | Fix |
|---|---|---|
| 1 | Every dependencies entry references an existing resource name in the plan |
Add missing resource or remove stale ref |
| 2 | Implicit dependencies are explicit (subnet→VNet, App Service→Plan) | Add missing entries |
| 3 | No circular dependencies | Break weaker edge |
3. Property & Pairing Checks
Read pairing-checks.md in full. It covers SKU compatibility, subnet/network conflicts, storage pairing, Cosmos DB, Key Vault/CMK, SQL Database, and AKS networking. For every connected pair of resources in the plan, walk through each applicable rule, confirm compliance, and fix any violation in-place before moving on to the next pair.
4. Insights Checks
Skip this section when insights.json does not exist or contains no insights.
| # | Check | Fix |
|---|---|---|
| 1 | Every insight in insights.json is either justified in inputs.insightsApplied or has a documented reason for non-application in plan.overallReasoning.tradeoffs. An insight must not appear in both. |
Add the insight to insightsApplied or document why it was not followed. |
| 2 | Every entry in inputs.insightsApplied cites the insight ID correctly, and its description of how and why it was applied references the insight's pattern and planning implication. |
Correct the entry or remove it if it was applied incorrectly. |
| 3 | No insight should result in a weaker security posture than available alternatives, unless it is explicitly requested in the user prompt or stated in the sub-goals. | Revert to the stronger alternative and move the insight to plan.overallReasoning.tradeoffs with an explanation. |