@apexops/cli 0.10.0-next.0

package/assets/customizations/.github/skills/apex-azure-rbac/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: apex-azure-rbac
+description: "Designs least-privilege Azure access in APEX decisions. Use for managed identities, built-in or custom role requirements, control-plane versus data-plane permissions, assignment scope, prerequisites, and idempotent binding intent."
+user-invocable: false
+---
+
+# APEX Azure RBAC Guidance
+
+Use this skill only for an active architecture or planning task. Accepted requirements, governance constraints, and
+recorded identity decisions are authoritative.
+
+## Prerequisites
+
+- The principal purpose, target resource, required operations, and environment are present in `apex/taskContext`.
+- Accepted role-catalog, identity, governance, and scope evidence is available.
+- A selected IaC/deployment capability owns any future assignment or custom-role change.
+
+## Decision Workflow
+
+1. Describe the exact operation and classify it as control-plane, data-plane, or both.
+2. Resolve the logical principal and require its object/principal identity from accepted identity evidence.
+3. Compare current built-in role definitions and select the narrowest role that covers the operation.
+4. Choose the smallest viable target scope and document why a narrower scope fails.
+5. Use a custom role requirement only when accepted evidence shows no built-in role fits.
+6. Record deterministic assignment intent, caller authorization prerequisites, ordering, and validation expectations.
+7. Check for wildcard permissions, excess scope, credential use, separation-of-duties conflicts, and unresolved evidence.
+
+If a role definition, principal, target scope, or authorized delivery path is unresolved, return a blocker. Never widen
+access to compensate for missing evidence.
+
+## Boundaries
+
+Do not call Azure CLI, Microsoft Graph, ARM, or documentation tools; assign roles; generate direct Bicep/Terraform role
+assignment code; create custom roles; or expose principal IDs, credentials, or secrets. Approved role changes belong in
+the selected IaC/deployment capability and kernel authorization flow.
+
+## References
+
+- Read [least-privilege role selection](references/least-privilege-selection.md) when choosing a built-in or custom role.
+- Read [assignment intent fields](references/assignment-intent.md) when recording a future assignment binding.
+
+## Output
+
+Return bounded role requirements and assignment intents with evidence, scope rationale, prerequisites, risks, and
+unresolved access blockers.

package/assets/customizations/.github/skills/apex-azure-rbac/references/assignment-intent.md

@@ -0,0 +1,39 @@
+# Assignment Intent Fields
+
+Represent a future role assignment as typed intent, not direct execution.
+
+| Field | Purpose |
+| --- | --- |
+| Principal reference | Stable logical identity plus accepted identity-output reference; never expose the physical ID. |
+| Principal purpose and type | Workload function and accepted user, group, service-principal, or managed-identity type. |
+| Required operation | Narrow action or data access requirement. |
+| Permission plane | Control plane, data plane, or explicitly justified combination. |
+| Role requirement | Accepted built-in definition ID or a bounded unresolved custom-role requirement. |
+| Target scope | Stable target resource reference and environment. |
+| Scope rationale | Why resource, resource-group, or subscription scope is necessary. |
+| Requirement traceability | IDs of requirements served by the access. |
+| Evidence references | Governance, identity, role-catalog, and target-resource evidence identifiers. |
+| Assignment identity | Deterministic key derived from scope, principal, and role for idempotent delivery. |
+| Caller prerequisite | Evidence that the delivery principal can write role assignments at the target scope. |
+| Conditions and expiry | Accepted conditional-access expression, eligible duration, or review point when required. |
+| Ordering | Identity and target dependencies that must exist before assignment validation. |
+| Delivery path | Selected IaC binding or explicitly approved capability. |
+
+## Idempotence And Authorization
+
+The selected binding must derive assignment identity deterministically from target scope, principal, and role definition.
+Random assignment names create duplicates and unstable imports. The future delivery principal needs the
+`Microsoft.Authorization/roleAssignments/write` permission at or above the target scope; record missing authorization as
+a blocker rather than proposing a broader role for the workload principal.
+
+## Propagation And Validation
+
+Role assignment creation and effective data-plane access are separate signals. Record the later validation operation,
+expected target, and bounded propagation handling. Do not treat eventual-consistency delay as permission to retry
+indefinitely or to add a second broader assignment.
+
+## Delivery Constraint
+
+Role assignment changes must be represented through the selected IaC binding and approved deployment workflow. Do not
+produce Azure CLI commands, raw Bicep/Terraform role-assignment resources, custom-role JSON, or credential material in
+the advisory skill output.

package/assets/customizations/.github/skills/apex-azure-rbac/references/least-privilege-selection.md

@@ -0,0 +1,50 @@
+# Least-Privilege Role Selection
+
+Start with the operation a workload identity needs to perform. Prefer a built-in Azure role that covers that operation
+at the narrowest viable scope.
+
+## Operation Decomposition
+
+Describe the resource provider, resource type, operation, target data, read/write/delete semantics, and whether access is
+needed continuously or only for a bounded task. Separate control-plane `actions` from data-plane `dataActions`; a role
+that manages a resource does not necessarily read its data, and a data role need not manage the resource.
+
+## Selection Workflow
+
+1. Prefer managed identity over credentials or shared keys.
+2. Use accepted current role-definition evidence to identify built-in candidates by permissions, not role-name memory.
+3. Exclude candidates missing required actions or containing unjustified write, delete, delegation, or wildcard access.
+4. Prefer resource scope, then resource-group scope, then broader scopes only when the operation truly spans them.
+5. Check accepted governance, deny assignments, conditions, and separation-of-duties constraints.
+6. Record the selected role definition identifier and why narrower candidates or scopes were insufficient.
+
+Use a custom role only when accepted catalog evidence shows no built-in role satisfies the requirement. Define only the
+required `actions` and `dataActions`, use `notActions` or `notDataActions` where justified, avoid wildcards, and keep
+assignable scopes as narrow as future assignment needs permit.
+
+## Principal And Scope Gotchas
+
+- Bind an Azure RBAC assignment to the principal/object ID from accepted identity output, not an app/client ID label.
+- Managed identities are represented by service principals, but principal type must come from accepted identity evidence.
+- A resource-group scope grants access to every matching current and future child resource; document that blast radius.
+- Subscription or management-group scope requires an explicit cross-resource requirement and stronger review.
+- Resource-level scope may be unsupported for some operations; require current role/provider evidence before widening.
+- Azure Policy and deny assignments can still block an operation granted by RBAC; do not claim effective access from a
+  role assignment alone.
+
+## Evidence Requirements
+
+A role decision must identify the principal purpose, required operation, proposed role requirement, scope rationale,
+requirement IDs, role-definition identifier, permission-plane analysis, and accepted governance or identity constraints.
+When role-definition evidence is absent or stale, preserve an explicit unresolved decision instead of guessing.
+
+## Validation
+
+Before handoff, verify required permissions are covered, excess permissions are explained, scope contains the target,
+the principal and role identifiers are accepted, and no custom role duplicates a suitable built-in role. Runtime access
+and propagation require later validation receipts; this decision is not proof that access exists.
+
+## Boundaries
+
+Do not query live role definitions, enumerate assignments, assign roles, create custom roles, or expose principal IDs.
+Those operations require dedicated read capability evidence or an approved IaC/deployment path.

package/assets/customizations/.github/skills/apex-azure-resources/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: apex-azure-resources
+description: "Guide APEX analysis from accepted Azure inventory evidence. Use for resource scope and tag coverage."
+user-invocable: false
+---
+
+# APEX Azure Resource Inventory Guidance
+
+Use this skill for an active APEX task that needs a bounded view of existing
+Azure resources. Only capability-produced, accepted inventory evidence in
+`apex/taskContext` is authoritative.
+
+## Prerequisites
+
+- The task identifies the inventory question, target subscription set,
+  resource-group boundary when applicable, and result limit.
+- Accepted evidence records the scope, query intent or pattern, observation
+  time, result completeness, and redactions or truncation.
+
+Return a blocker when inventory evidence is missing, stale, incomplete, or
+outside the requested scope. Do not present a partial page as a complete
+inventory, and do not infer resource state from names or model memory.
+
+## Workflow
+
+1. Match the evidence scope to the task's subscriptions, resource groups,
+   resource types, and observation time.
+2. Confirm the inventory query pattern answers the stated question, such as
+   type inventory, location inventory, orphan candidate, tag coverage, or
+   configuration posture.
+3. Treat pagination, result limits, redactions, and indexing delay as explicit
+   inventory boundaries.
+4. Report only observed resource facts and label orphan candidates as
+   candidates until accepted dependency evidence confirms them.
+5. Carry the evidence identifier, scope, pattern, observation time, and
+   completeness status into the typed analysis or planning artifact.
+6. Route a missing or inadequate inventory to the resource-inventory
+   capability with a narrower or corrected query intent.
+
+## Boundaries
+
+- This skill is read-only and advisory. It does not execute Azure discovery,
+  run Resource Graph or KQL, create diagrams or files, or modify resources.
+- Inventory evidence is not real-time monitoring, compliance certification,
+  cost analysis, or deployment authorization.
+- Remediation and resource changes require their authorized capability and
+  gate; this skill may only describe the evidence-backed need.
+
+## References
+
+- [Inventory and query patterns](references/inventory-query-patterns.md) -
+  scope rules, pattern selection, and interpretation limits.
+- [Operational checklist](references/operational-checklist.md) -
+   inventory intent, bounded results, and candidate handling.

package/assets/customizations/.github/skills/apex-azure-resources/references/inventory-query-patterns.md

@@ -0,0 +1,49 @@
+# Inventory and Query Patterns
+
+Use this reference to specify what accepted inventory evidence must answer.
+Patterns describe an evidence request; they are not instructions to execute a
+query.
+
+## Scope Contract
+
+Every inventory interpretation needs these boundaries:
+
+- Subscription set and resource-group filter, if any.
+- Resource types and locations included or excluded.
+- Observation time and declared freshness limit.
+- Result limit, pagination status, and whether the result is complete.
+- Query pattern, projected fields, and redaction status.
+
+Missing boundaries make an inventory result unsuitable for broad claims. Route
+the task to the resource-inventory capability with the required boundary,
+rather than widening the claim.
+
+## Pattern Selection
+
+- **What exists?** Request an inventory grouped by type, location, or
+  subscription. Counts apply only to the recorded scope and observation time.
+- **What is in one resource group?** Request a resource-group inventory with
+  identifying fields. It does not establish dependencies outside that group.
+- **What may be unused?** Request candidates for unattached disks, unassigned
+  network interfaces, idle public IPs, or empty backends. A candidate is not
+  proof of safe deletion.
+- **Which resources lack a tag?** Request tag coverage using the required tag
+  keys. Compare those keys with accepted governance evidence.
+- **Which resources expose a setting?** Request configuration posture for the
+  named property. A missing or dynamic property is not a security conclusion.
+
+## Interpretation Rules
+
+- Preserve case-insensitive resource-type matching in the capability request.
+- Use joins only when accepted evidence identifies both datasets and their
+  shared scope.
+- Treat index latency, pagination, and field redaction as result limitations.
+- Do not turn a lookup result into a diagram, remediation plan, or compliance
+  conclusion without the separate accepted evidence required for that task.
+
+## Resource Graph Boundary
+
+Azure Resource Graph lookup and provider-specific resource discovery are deferred capabilities. Request a bounded query
+pattern and result shape, but do not execute KQL, invoke CLI or SDK tools, or infer omitted pages. Architecture diagram
+templates and visualization assets are excluded from inventory guidance; visual output requires separately accepted
+inventory evidence and an authorized presentation path.

package/assets/customizations/.github/skills/apex-azure-resources/references/operational-checklist.md

@@ -0,0 +1,24 @@
+# Inventory Operational Checklist
+
+## Query Intent
+
+- Bind the inventory question to subscriptions, resource groups, types, and
+  an explicit result bound before interpreting any returned evidence.
+- Select one intent: type or location inventory, tag coverage, configuration
+  posture, or dependency candidate. Do not expand scope from resource names.
+- Treat indexing delay, pagination, truncation, and redaction as coverage
+  limits that remain visible in the output.
+
+## Interpretation
+
+- Report observed properties only. A resource name, missing tag, or absent
+  page is not proof of ownership, idleness, or deletion safety.
+- Label unattached or unused-looking items as candidates until compatible
+  dependency and utilization evidence supports a stronger conclusion.
+- Keep inventory separate from real-time monitoring, compliance certification,
+  cost allocation, and deployment authorization.
+
+## Handoff
+
+Record query intent, scope, observation time, evidence identifier, and coverage
+limits. Request a narrower authorized inventory when the evidence is inadequate.

package/assets/customizations/.github/skills/apex-azure-storage/SKILL.md

@@ -0,0 +1,35 @@
+---
+name: apex-azure-storage
+description: "Select secure Azure Storage services, tiers, redundancy, and lifecycle intent for active APEX architecture and planning tasks."
+---
+
+# APEX Azure Storage
+
+Use this skill only for an active architecture or planning task. It records storage service and security intent; it does
+not list, read, upload, or modify data.
+
+## Prerequisites
+
+- `apex/taskContext` identifies data classification, recovery objectives, access pattern, and target environment.
+- Governance and security constraints are current and accepted.
+
+## Workflow
+
+1. Select Blob, Files, Queue, Table, or Data Lake with [Storage selection](references/storage-selection.md).
+2. Bind redundancy, tier, lifecycle, identity, and network choices to requirements and governance.
+3. Apply [Security and governance](references/security-and-governance.md) and
+   [Service, authentication, and SDK boundary](references/service-auth-and-sdk-boundary.md) to typed intent.
+4. Return missing classification, RPO/RTO, policy, or network evidence as a blocker.
+
+## Boundaries
+
+- This skill is advisory; it does not issue storage commands, use keys, create data, or modify resources.
+- Inventory and diagnostics require accepted capability evidence; deployment remains an approved lifecycle operation.
+- The kernel owns state, gates, and evidence acceptance.
+
+## References
+
+- [Storage selection](references/storage-selection.md) - service, tier, redundancy, and lifecycle choices.
+- [Security and governance](references/security-and-governance.md) - identity, private access, and policy mapping.
+- [Service, authentication, and SDK boundary](references/service-auth-and-sdk-boundary.md) - source-derived service,
+  authentication, lifecycle, and implementation-boundary rules.

package/assets/customizations/.github/skills/apex-azure-storage/references/security-and-governance.md

@@ -0,0 +1,12 @@
+# Storage Security And Governance
+
+Use managed identity and Entra authorization in preference to shared keys and long-lived SAS. Require HTTPS and modern
+TLS, disable public Blob access unless a specific accepted exception exists, and use private endpoints and private DNS
+for production data services when the policy and network design require it.
+
+Map accepted governance effects to typed resource properties, diagnostics, tags, lifecycle, and exception records. Do
+not treat an AVM selection or a template property as proof of policy compliance; validator and deployment evidence remain
+required.
+
+Record data classification, encryption needs, network path, identity roles, retention, backup, recovery targets, and
+operational ownership. Missing policy, classification, or recovery intent blocks a completed storage design.

package/assets/customizations/.github/skills/apex-azure-storage/references/service-auth-and-sdk-boundary.md

@@ -0,0 +1,33 @@
+# Storage Service, Authentication, And SDK Boundary
+
+Use this reference to record storage design intent. It is not permission to access a storage account, install an SDK,
+or create, read, upload, or delete data.
+
+## Service And Lifecycle Intent
+
+Select Blob for object data, backup, and static content; Files for managed SMB or NFS shares; Queues for simple
+asynchronous work; Tables for basic key-value data; and Data Lake Storage for analytics requiring a hierarchical
+namespace. Record an alternative when a database, eventing service, or messaging service better fits the workload.
+
+Select Standard unless an accepted latency or IOPS requirement supports Premium. Choose Hot, Cool, Cold, or Archive
+from actual access frequency and rehydration tolerance. A lifecycle policy must name the eligible object set, age or
+access basis, action, and retention constraint; lifecycle transitions do not replace backup or retention design.
+
+Select LRS for recreatable noncritical data, ZRS for zonal resiliency, and GRS or GZRS only when the recovery strategy
+requires regional replication. Redundancy alone does not establish RPO, RTO, retention, or restore capability.
+
+## Authentication Posture
+
+Use managed identity and least-privilege Azure RBAC for Azure-hosted production workloads. For external production
+workloads, record a deterministic workload-identity, federation, or certificate posture. Local development credentials
+are not a production authentication design. Never include account keys, connection strings, credential values, or SDK
+configuration in an APEX artifact.
+
+Record the required data-plane role, identity owner, scope, network posture, and evidence needed for the selected
+service. Missing classification, policy, network, or recovery evidence is a blocker.
+
+## SDK Boundary
+
+Language SDK installation, client construction, and data-operation samples remain implementation work outside this
+skill. An authorized implementation capability must select libraries, acquire its own approved identity evidence, and
+perform any data operation. This architecture reference supplies service and authentication intent only.

package/assets/customizations/.github/skills/apex-azure-storage/references/storage-selection.md

@@ -0,0 +1,12 @@
+# Storage Selection
+
+Use Blob Storage for object data, backup, and static content; Azure Files for managed SMB/NFS shares; Queues for simple
+asynchronous work; Tables for basic key-value access; and Data Lake Storage for analytics with a hierarchical namespace.
+Record a service alternative when SQL, Cosmos DB, Event Hubs, or Service Bus better fits the requirement.
+
+Choose Standard unless an accepted latency or IOPS requirement supports Premium. Select Hot, Cool, Cold, or Archive
+from the actual access and rehydration requirement. Lifecycle policy should transition or expire eligible objects using
+an explicit age and access basis.
+
+Select LRS for recreatable noncritical data, ZRS for zonal resiliency, and GRS/GZRS only when the accepted recovery
+strategy requires regional replication. Redundancy does not itself establish backup, retention, RPO, or RTO.

package/assets/customizations/.github/skills/apex-azure-validate/SKILL.md

@@ -0,0 +1,49 @@
+---
+name: apex-azure-validate
+description: "Assess APEX Azure preflight evidence. Use for freshness, acceptance criteria, readiness blockers, and validated handoff decisions."
+user-invocable: false
+---
+
+# APEX Azure Validation
+
+Use this skill only for an active validation task. It evaluates the kernel-projected preparation artifacts and evidence
+against acceptance criteria; it does not execute checks independently or change lifecycle state.
+
+## Prerequisites
+
+- `apex/taskContext` identifies the validation scope, target, required evidence, freshness policy, and acceptance
+  criteria.
+- Required preparation artifacts and the selected IaC binding are accepted by the kernel.
+- The task envelope supplies the authorized validation capability or evidence results. Missing or stale evidence is a
+  blocker, not an invitation to re-create it from local files, chat history, or model memory.
+
+## Workflow
+
+1. Confirm that each required preparation output is present, accepted, and traceable to the active run and target.
+2. Evaluate evidence freshness using the policy and timestamps projected by the kernel. Report expired, mismatched,
+   incomplete, or indeterminate evidence exactly as returned.
+3. Compare the authorized validation results with the task's functional, security, governance, build, and deployment
+   acceptance criteria. Keep a failed check distinct from an unavailable check.
+4. Return the kernel-provided validation result and unresolved criteria. When remediation changes intent or bindings,
+   route back to the owning preparation task rather than editing artifacts directly.
+5. Hand off only an accepted validation result to the next kernel-selected lifecycle task.
+
+## Boundaries
+
+- Do not run previews, builds, linters, IaC validators, authentication checks, or Azure queries directly.
+- Do not amend validation proof, bypass a failed criterion, or set a plan to validated.
+- Do not deploy or imply that passing a partial check authorizes deployment.
+- Transform a request to run a preflight command into a request for the trusted validation capability's evidence. The
+  capability and kernel, not this skill, decide whether it can refresh evidence or advance state.
+
+## References
+
+- [Preflight evidence model](references/preflight-evidence.md) - freshness, acceptance outcomes, and remediation
+  routing.
+- [Operational checklist](references/operational-checklist.md) -
+  generated-tree validation, acceptance coverage, and failed-check routing.
+
+## Output
+
+Return the validation state, acceptance-criterion outcomes, evidence references, blockers, and the kernel-provided next
+action. Use `indeterminate` when provided evidence cannot establish readiness.

package/assets/customizations/.github/skills/apex-azure-validate/references/operational-checklist.md

@@ -0,0 +1,24 @@
+# Validation Operational Checklist
+
+## Preconditions
+
+- Confirm accepted preparation artifacts, selected IaC binding, target, and
+  acceptance criteria belong to the active run before reading validation proof.
+- Use only kernel-projected or trusted capability evidence. A local file,
+  remembered command result, or chat statement cannot replace accepted proof.
+- Keep unavailable, failed, incomplete, stale, and scope-mismatched checks
+  distinct; none may be restated as a passed criterion.
+
+## Coverage
+
+- Evaluate generated-tree validation, build, security, governance, functional,
+  and deployment-readiness criteria against their declared evidence scope.
+- Require each accepted result to identify its target, artifact revision,
+  observation time, outcome, and remaining limits.
+- When a failure changes intent, inputs, or IaC bindings, route it to the
+  owning preparation task and require renewed validation evidence.
+
+## Handoff
+
+Only a complete accepted validation result may advance to the kernel-selected
+next task. This skill neither changes lifecycle state nor invokes deployment.

package/assets/customizations/.github/skills/apex-azure-validate/references/preflight-evidence.md

@@ -0,0 +1,43 @@
+# Preflight Evidence Model
+
+## Evidence Requirements
+
+Preflight is a claim about a specific run, target, binding, and artifact revision. Valid evidence identifies:
+
+- The active run and target environment.
+- The accepted preparation and binding artifacts being evaluated.
+- The validator or trusted capability that produced the result.
+- The observation time and kernel-defined freshness result.
+- The acceptance criterion, outcome, and any supporting diagnostic reference.
+
+Evidence that lacks a target, artifact revision, freshness result, or producing authority is incomplete. Treat it as a
+blocker rather than estimating its validity from source files or earlier chat output.
+
+## Outcome Semantics
+
+| Outcome | Meaning | Lifecycle Treatment |
+| --- | --- | --- |
+| Pass | Current evidence meets the named criterion | Retain the evidence reference |
+| Fail | Current evidence disproves the criterion | Route to the task that owns remediation |
+| Blocked | Required input, authority, or evidence is absent | Request or await the missing dependency |
+| Indeterminate | Evidence cannot establish an outcome | Do not advance readiness |
+| Stale | Evidence exceeds the kernel-defined freshness policy | Request trusted evidence refresh |
+
+## Acceptance Criteria
+
+Acceptance criteria should be explicit, scoped, and independently checkable. They may cover artifact integrity, binding
+consistency, policy obligations, security controls, build readiness, prerequisite availability, preview readiness, and
+verification obligations. A pass for one criterion does not silently satisfy another.
+
+## Remediation Routing
+
+Return each non-pass outcome to its owner: requirements for an unresolved desired outcome, architecture for a decision,
+planning or binding for implementation intent, CodeGen for an authorized generation batch, or a trusted validation
+capability for refreshed observations. Validation never rewrites evidence it is evaluating.
+
+## Region, Global, And Error Semantics
+
+Evaluate a region or global prerequisite only from evidence bound to the selected target, service, binding revision, and
+freshness policy. Preserve authorization, environment, compiler, provider, and policy failures as distinct outcomes;
+an unavailable check is not a failed check. Policy discovery, CLI authentication, previews, and recipe command execution
+remain deferred trusted capabilities, so this skill records their evidence and routes errors without executing them.

package/assets/customizations/.github/skills/apex-bicep-patterns/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: apex-bicep-patterns
+description: "Apply approved Bicep architecture patterns to APEX implementation intent. Use for AVM composition, private endpoints, networking, diagnostics, and CodeGen acceptance."
+---
+
+# APEX Bicep Patterns
+
+Use this skill for an active Bicep-bound planning or CodeGen task. It describes approved intent and acceptance criteria;
+CodeGen and validators own generated files and command execution.
+
+## Prerequisites
+
+- `apex/taskContext` identifies an accepted Bicep track task and its typed binding inputs.
+- Requirements, governance, security, and architecture decisions are current.
+
+## Workflow
+
+1. Select only patterns supported by the accepted architecture and track binding.
+2. Apply [Network and observability](references/network-and-observability.md) to private connectivity and diagnostics.
+3. Read [Module interfaces and parameters](references/module-interfaces-and-parameters.md) when creating reusable
+   modules or binding environment-specific inputs.
+4. Read [Compiler and provider gotchas](references/compiler-and-provider-gotchas.md) before accepting module bindings.
+5. Apply [AVM and CodeGen acceptance](references/avm-and-codegen-acceptance.md) to module decisions and validation intent.
+6. Verify the generated intent against the [CodeGen acceptance checklist](references/codegen-acceptance-checklist.md).
+7. Stage only typed intent through APEX MCP; return unavailable modules or stale evidence as blockers.
+
+## Boundaries
+
+- This skill does not write Bicep, resolve module versions, invoke Bicep, or perform deployment commands.
+- CodeGen owns generated IaC; validators own build, lint, security, and preview receipts.
+- Module choice does not bypass policy, cost, approval, or deployment evidence.
+
+## References
+
+- [Network and observability](references/network-and-observability.md) - hub-spoke, private endpoints, and diagnostics.
+- [Module interfaces and parameters](references/module-interfaces-and-parameters.md) - stable composition contracts and
+  environment-neutral input binding.
+- [Compiler and provider gotchas](references/compiler-and-provider-gotchas.md) - exact-schema, language, identity, SKU,
+  query, and service-topology failure rules.
+- [CodeGen acceptance checklist](references/codegen-acceptance-checklist.md) - final intent and evidence review loop.
+- [AVM and CodeGen acceptance](references/avm-and-codegen-acceptance.md) - module binding and validation intent.

package/assets/customizations/.github/skills/apex-bicep-patterns/references/avm-and-codegen-acceptance.md

@@ -0,0 +1,11 @@
+# AVM And CodeGen Acceptance
+
+Prefer Azure Verified Modules when the selected Bicep binding can meet accepted requirements. Record the module family,
+version-resolution evidence, required inputs, identity, network, diagnostics, tags, and outputs as typed constraints.
+
+An AVM module is not automatically compliant. CodeGen must bind the selected version and interface; validation must
+confirm syntax, lint, security baseline, policy-compatible settings, and preview results. When a module cannot express a
+requirement, record the exception, alternative implementation, rationale, and traceability before generation.
+
+Use explicit parameters for environment-specific values and avoid secret literals. Preserve stable resource identity and
+outputs needed by dependent bindings. What-if review is a required pre-deployment receipt, not an informal observation.

package/assets/customizations/.github/skills/apex-bicep-patterns/references/codegen-acceptance-checklist.md

@@ -0,0 +1,46 @@
+# CodeGen Acceptance Checklist
+
+Use this checklist after Bicep generation and before accepting validator or preview evidence.
+
+## Intent And Governance
+
+- [ ] Every generated resource traces to accepted requirements and architecture intent.
+- [ ] Applicable policy effects map to generated properties or an explicit blocker.
+- [ ] Environment-specific values come from the accepted environment input contract.
+- [ ] No secret, placeholder identifier, recipient, subscription, tenant, or principal is embedded in source.
+
+## Modules And Composition
+
+- [ ] AVM is used when the selected module can satisfy the accepted intent.
+- [ ] Every module version has authorized resolution evidence and its exact schema was inspected.
+- [ ] Module inputs and outputs follow the accepted interface and match the exact selected schema.
+- [ ] Resource names satisfy service constraints without changing stable identity unexpectedly.
+- [ ] Optional modules guard dependent outputs and resources consistently.
+- [ ] Existing resource references have explicit dependencies when their targets are created in the same deployment.
+
+## Security And Identity
+
+- [ ] HTTPS, transport security, identity, network access, and data-access settings match the accepted baseline.
+- [ ] Role assignments use the narrowest accepted scope and the intended principal type.
+- [ ] Runtime identities are not promoted to data-plane administrators.
+- [ ] Public access or credential-based exceptions have accepted, current dispositions.
+
+## Network And Operations
+
+- [ ] Address spaces and service CIDRs do not overlap.
+- [ ] Private endpoint bindings include the correct subresource, subnet, DNS zone, VNet link ownership, and zone group.
+- [ ] Diagnostics target the accepted monitoring destination and include supported log and metric categories.
+- [ ] SKU-sensitive properties are compatible with the selected tier in the rendered template.
+- [ ] Query-based alert text is valid for the target table schema.
+- [ ] Post-deployment requirements are recorded rather than represented as unsupported resource properties.
+
+## Validation Loop
+
+- [ ] Formatting, build, lint, security, policy, and provider-readiness checks pass.
+- [ ] Preview contains no unexplained deletion, SKU downgrade, public-access change, authentication change, or identity
+      removal.
+- [ ] Generated parameters compile against the generated entrypoint.
+- [ ] Validation receipts bind the current source tree, module locks, target, inputs, and dependency revision.
+- [ ] Any correction was followed by a fresh full validation pass; stale receipts were not reused.
+
+Return a blocker with the failing checklist item and required owner when any mandatory item cannot be proven.