@apexops/cli 0.10.0-next.5 → 0.11.0-next.1

package/assets/client-projections/github-copilot-cli/.github/skills/apex-azure-rbac/references/least-privilege-selection.md

@@ -1,50 +0,0 @@
-# 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/client-projections/github-copilot-cli/.github/skills/apex-azure-resources/SKILL.md

@@ -1,54 +0,0 @@
----
-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/client-projections/github-copilot-cli/.github/skills/apex-azure-resources/references/inventory-query-patterns.md

@@ -1,49 +0,0 @@
-# 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/client-projections/github-copilot-cli/.github/skills/apex-azure-resources/references/operational-checklist.md

@@ -1,24 +0,0 @@
-# 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/client-projections/github-copilot-cli/.github/skills/apex-azure-storage/SKILL.md

@@ -1,35 +0,0 @@
----
-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/client-projections/github-copilot-cli/.github/skills/apex-azure-storage/references/security-and-governance.md

@@ -1,12 +0,0 @@
-# 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/client-projections/github-copilot-cli/.github/skills/apex-azure-storage/references/service-auth-and-sdk-boundary.md

@@ -1,33 +0,0 @@
-# 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/client-projections/github-copilot-cli/.github/skills/apex-azure-storage/references/storage-selection.md

@@ -1,12 +0,0 @@
-# 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/client-projections/github-copilot-cli/.github/skills/apex-azure-validate/SKILL.md

@@ -1,49 +0,0 @@
----
-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/client-projections/github-copilot-cli/.github/skills/apex-azure-validate/references/operational-checklist.md

@@ -1,24 +0,0 @@
-# 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/client-projections/github-copilot-cli/.github/skills/apex-azure-validate/references/preflight-evidence.md

@@ -1,43 +0,0 @@
-# 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/client-projections/github-copilot-cli/.github/skills/apex-bicep-patterns/SKILL.md

@@ -1,41 +0,0 @@
----
-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/client-projections/github-copilot-cli/.github/skills/apex-bicep-patterns/references/avm-and-codegen-acceptance.md

@@ -1,11 +0,0 @@
-# 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/client-projections/github-copilot-cli/.github/skills/apex-bicep-patterns/references/codegen-acceptance-checklist.md

@@ -1,46 +0,0 @@
-# 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.

package/assets/client-projections/github-copilot-cli/.github/skills/apex-bicep-patterns/references/compiler-and-provider-gotchas.md

@@ -1,74 +0,0 @@
-# Compiler And Provider Gotchas
-
-Read this reference before accepting a new AVM binding and when build, preview, and apply results disagree.
-
-## Exact Module Schema Wins
-
-AVM parameter names, nested object fields, required values, and outputs can change between module versions. Inspect the
-schema for the exact selected version before authoring its binding. Do not copy parameter shapes from model memory, an
-older project, or documentation for another version.
-
-Record the inspected inputs and outputs in validation evidence. If the exact schema cannot be inspected, return a
-blocker rather than guessing.
-
-AVM use also requires these checks:
-
-- pin the version selected by the authorized resolver
-- verify output names before creating downstream dependencies
-- confirm required policy tags survive any module-internal tag merge
-- verify diagnostics are emitted by the module or by an explicit companion binding
-- wrap a module to override incompatible defaults; record an exception before replacing AVM with a raw resource
-
-## Bicep Language Constraints
-
-- `utcNow()` is valid only as a parameter default. Do not use it in a variable or resource expression.
-- A child resource `parent` must be calculable at deployment start. A module output is not a static parent name; use a
-  parameter-derived existing resource and an explicit dependency when ordering is otherwise lost.
-- A subscription-scope module called from a resource-group deployment requires an explicit subscription scope.
-- An `existing` resource reference does not prove that its creating module has completed. Add an explicit dependency
-  when a child or extension resource targets something created in the same deployment.
-
-## Identity And RBAC
-
-Keep identity creation separate from target-resource authorization. Putting a target resource's role assignment inside
-the identity module can create a dependency cycle when each module needs the other's output. Place the assignment with
-the target resource and use the identity principal output as an input.
-
-A runtime managed identity is not a data-plane administrator. Use a dedicated administration principal for SQL or other
-data-plane administration, then grant the runtime identity only the application permissions it needs. Deploy-time
-principal IDs remain required environment inputs; CodeGen must not invent or bake them into parameter files.
-
-## Validation Green, Apply Red
-
-A successful build or preview does not prove resource-provider compatibility. Review the rendered resource properties
-when an AVM default may be SKU-dependent. Reject premium-only networking, zone, quarantine, trust, or data-endpoint
-properties on a lower tier unless the exact provider contract supports them.
-
-For scheduled query rules, validate KQL against the target table schema. Bicep treats the query as an opaque string and
-preview does not run the service query parser. Ingestion quota alert queries against `_LogOperation` must use that
-table's columns rather than fields copied from `AzureActivity`, `AzureDiagnostics`, or application tables.
-
-## Service Topology Traps
-
-- AKS egress mode must match the accepted topology: subnet NAT gateway, AKS-managed NAT gateway, explicit default route
-  to an operator-managed firewall, or load balancer are different designs. Fixed-size pools must not carry autoscaling
-  bounds, and a control-plane identity using an existing VNet needs the accepted network role assignment.
-- An Application Gateway backend pool may be empty until its real backend exists. Never use a loopback address as a
-  placeholder.
-- MySQL private endpoint and delegated-subnet injection are different, mutually exclusive topologies. A shared private
-  endpoint subnet is not a delegated MySQL subnet. Treat read-only authentication settings and other post-deployment
-  operations as deployment tasks, not writable Bicep properties.
-- A database major-version upgrade is an isolated lifecycle operation. Do not combine it with unrelated property
-  changes. Resolve supported versions from current service evidence rather than retaining a version literal here.
-- Subscription-scoped cost alerts require a scope-compatible view and module scope.
-- Automation schedules cannot attach to an unpublished runbook. Keep publish-and-link work as an explicit
-  post-deployment task when the resource provider requires it.
-
-## Repair Loop
-
-1. Classify the failure as Bicep language, exact module schema, rendered-template, or provider apply-time behavior.
-2. Check the exact selected schema and accepted architecture/SKU evidence.
-3. Correct the typed binding or record an explicit module exception; do not add a speculative property.
-4. Re-run the owning build, lint, security, policy, and preview validators.
-5. Proceed only when the new receipts are current; an apply-only limitation remains a documented deployment risk or
-   blocker.

package/assets/client-projections/github-copilot-cli/.github/skills/apex-bicep-patterns/references/module-interfaces-and-parameters.md

@@ -1,56 +0,0 @@
-# Module Interfaces And Parameters
-
-Read this reference when a Bicep binding introduces a reusable module or environment-specific inputs.
-
-## Stable Module Interface
-
-Give reusable modules a predictable contract so composition, diagnostics, identity, and downstream dependencies do not
-rely on module-specific guesswork.
-
-Required inputs normally include:
-
-- `name`
-- `location`
-- `tags`
-- the accepted monitoring workspace binding when the resource supports diagnostics
-
-Required outputs normally include:
-
-- `resourceId`
-- `resourceName`
-- `principalId` when managed identity is supported
-
-When a resource has no managed identity, expose an explicitly optional or empty principal value according to the typed
-binding contract. Do not invent an identity merely to satisfy a uniform output shape.
-
-Add service-specific inputs and outputs only when a downstream binding needs them. Keep secrets out of outputs, and do
-not leak generated credentials through module composition.
-
-## Environment Inputs
-
-Keep the generated Bicep tree environment-neutral. Environment-specific subscription IDs, tenant IDs, object IDs,
-notification recipients, budget values, and existing-resource bindings must come from the accepted environment input
-contract rather than literals or environment branches in `main.bicep`.
-
-Use `.bicepparam` files as generated binding surfaces when the selected toolchain supports them. Each parameter must map
-to an accepted typed input. Values resolved at deployment time remain unresolved in source; CodeGen must not fabricate a
-placeholder GUID, address, secret, or recipient.
-
-Reject these patterns:
-
-- project-specific GUIDs or subscription IDs embedded in Bicep or parameter files
-- secret defaults
-- production and non-production identifiers selected by conditional literals in `main.bicep`
-- parameters that are not present in the accepted IaC binding contract
-- environment input names that are silently renamed between planning, CodeGen, and deployment
-
-## Acceptance Check
-
-Before staging CodeGen intent, verify:
-
-- every module input traces to accepted architecture, governance, defaults, or environment intent
-- every output has a known consumer or documented compatibility purpose
-- required monitoring and identity bindings are explicit
-- environment-specific values remain external to the generated source tree
-- parameter names and types match the selected module interface
-- missing deploy-time values return a blocker instead of a generated placeholder