Standards for Bicep template layout, parameter naming, and resource organization that all bicep-agent output must follow.

Domain: bicep

---

Check	Description
STAN-BCP-001	Standard File Layout: Bicep templates must follow a consistent ordering: targetScope (if needed), parameters, variables, resources, modules, outputs. Use separate .bicep files for reusable modules.
STAN-BCP-002	Parameter Conventions: All parameters must have @description decorators and type annotations. Use camelCase for parameter names (Bicep convention). Provide @allowed decorators for constrained values.
STAN-BCP-003	Module Composition: Use Bicep modules for logical grouping of related resources. The main.bicep file should orchestrate modules, not define resources directly (except resource groups at subscription scope).
STAN-BCP-004	Resource Naming via Variables: Define resource names in variables using a consistent naming pattern. Never hardcode resource names in resource blocks.
STAN-BCP-005	Output Important Values: Output resource IDs, endpoints, and principal IDs that downstream modules or deployment scripts will need. Use @description decorators on outputs.
STAN-BCP-006	Cross-Stage Dependencies via Parameters: Multi-stage deployments MUST pass prior-stage resource references as parameters. NEVER hardcode resource names, IDs, or keys from other stages. Use the existing keyword to reference resources created in prior stages, with their names provided via parameters populated from prior stage deployment outputs.
STAN-BCP-007	Complete and Robust deploy.sh: Every stage MUST include a deploy.sh that is syntactically complete and runnable. It must use set -euo pipefail, verify Azure login, run az deployment group create, capture outputs to JSON, and include error handling via trap. NEVER truncate the script.
STAN-BCP-008	Companion Resources for Disabled Auth: When disabling local/key-based auth on any service, the SAME stage MUST also create: (1) a user-assigned managed identity, (2) RBAC role assignments, (3) output the identity clientId and principalId. Without these, applications cannot authenticate.

---

Standard File Layout: Bicep templates must follow a consistent ordering: targetScope (if needed), parameters, variables, resources, modules, outputs. Use separate .bicep files for reusable modules.

Rationale: Consistent file organization makes code reviewable and prevents merge conflicts across stages.
Agents: bicep-agent

• main.bicep — orchestration template that calls modules
• modules/appService.bicep — reusable App Service module
• modules/networking.bicep — reusable networking module

---

Parameter Conventions: All parameters must have @description decorators and type annotations. Use camelCase for parameter names (Bicep convention). Provide @allowed decorators for constrained values.

Rationale: Well-typed parameters with constraints prevent invalid deployments at plan time.
Agents: bicep-agent

• @description('Azure region for all resources') param location string = resourceGroup().location
• @allowed(['dev','staging','prod']) param environment string

---

Module Composition: Use Bicep modules for logical grouping of related resources. The main.bicep file should orchestrate modules, not define resources directly (except resource groups at subscription scope).

Rationale: Modular Bicep templates promote reuse and simplify testing of individual components.
Agents: bicep-agent

• module networking 'modules/networking.bicep' = { ... }
• module compute 'modules/compute.bicep' = { ... }

---

Resource Naming via Variables: Define resource names in variables using a consistent naming pattern. Never hardcode resource names in resource blocks.

Rationale: Parameterized configurations allow reuse across environments and prevent hardcoded values.
Agents: bicep-agent

• var rgName = 'rg-${project}-${environment}'
• var kvName = 'kv-${project}-${take(uniqueString(resourceGroup().id), 6)}'

---

Output Important Values: Output resource IDs, endpoints, and principal IDs that downstream modules or deployment scripts will need. Use @description decorators on outputs.

Rationale: Complete outputs enable downstream stages to reference resources without hardcoding.
Agents: bicep-agent

• @description('App Service default hostname') output appUrl string = app.properties.defaultHostName
• @description('Managed identity principal ID') output principalId string = app.identity.principalId

---

Cross-Stage Dependencies via Parameters: Multi-stage deployments MUST pass prior-stage resource references as parameters. NEVER hardcode resource names, IDs, or keys from other stages. Use the existing keyword to reference resources created in prior stages, with their names provided via parameters populated from prior stage deployment outputs.

Rationale: Complete outputs enable downstream stages to reference resources without hardcoding.
Agents: bicep-agent, cloud-architect

• @description('Resource group from Stage 1') param foundationRgName string
• resource rg 'Microsoft.Resources/resourceGroups@2023-07-01' existing = { name: foundationRgName }

---

Complete and Robust deploy.sh: Every stage MUST include a deploy.sh that is syntactically complete and runnable. It must use set -euo pipefail, verify Azure login, run az deployment group create, capture outputs to JSON, and include error handling via trap. NEVER truncate the script.

Rationale: Complete outputs enable downstream stages to reference resources without hardcoding.
Agents: bicep-agent

• az deployment group create --resource-group $RG --template-file main.bicep --parameters main.bicepparam
• az deployment group show --name $DEPLOYMENT --query properties.outputs > stage-N-outputs.json

---

Companion Resources for Disabled Auth: When disabling local/key-based auth on any service, the SAME stage MUST also create: (1) a user-assigned managed identity, (2) RBAC role assignments, (3) output the identity clientId and principalId. Without these, applications cannot authenticate.

Rationale: Complete outputs enable downstream stages to reference resources without hardcoding.
Agents: bicep-agent, cloud-architect

• resource identity 'Microsoft.ManagedIdentity/userAssignedIdentities@2023-01-31' = { ... }
• resource rbac 'Microsoft.Authorization/roleAssignments@2022-04-01' = { ... }

---