@apexops/cli 0.10.0-next.0

package/assets/client-projections/github-copilot-cli/.github/skills/apex-azure-defaults/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: apex-azure-defaults
+description: "Applies projected Azure defaults safely in APEX decisions. Use for region fallback, CAF naming, tags, security, service lifecycle, AVM bindings, network planning, governance effects, and cost monitoring."
+user-invocable: false
+---
+
+# APEX Azure Defaults
+
+Use this skill only for an active APEX task. Accepted governance constraints and runtime configuration are
+authoritative. Task context supplies only the values actually provided for the active task. This skill does not define
+customer policy, discover Azure state, or execute Azure operations.
+
+## Prerequisites
+
+- `apex/taskContext` identifies the active workload, environment, target, and IaC track.
+- Governance, availability, pricing, quota, and module evidence required by the decision is accepted and current.
+- A kernel capability owns any lookup, validation, or state change the decision requires.
+
+## Precedence
+
+Apply accepted governance first, then explicit requirements and decisions, then runtime configuration. Use a baseline
+fallback only when accepted evidence establishes that no stronger contract applies. Incomplete discovery is not the
+same as an empty policy result.
+
+## Decision Workflow
+
+1. Use the environment and target only when the active task context provides them; otherwise return a blocker. Do not
+  infer a region, subscription, tag, or policy requirement from chat history.
+2. Resolve conflicts through the precedence rule and preserve the governing evidence identifier.
+3. Select service, region, network, identity, module, monitoring, and naming intent from accepted inputs.
+4. Record every fallback, exception, unknown, and deferred decision with requirement and evidence traceability.
+5. Check the bounded decision for policy coverage, lifecycle support, region/SKU fit, security, repeatability, and cost.
+6. If the check exposes a gap, revise the decision and repeat. If evidence or capability is absent, return a blocker.
+
+## References
+
+- Read [baseline fallbacks](references/baseline-fallbacks.md) only when accepted evidence permits fallback behavior.
+- Read [naming guidance](references/naming.md) when binding resource names or uniqueness inputs.
+- Read [tag precedence](references/tag-precedence.md) when policy, inheritance, casing, or fallback tags are relevant.
+- Read [security baseline](references/security-baseline.md) for identity, exposure, encryption, lifecycle, and diagnostics.
+- Read [AVM binding guidance](references/avm-binding-guidance.md) when choosing or excepting a module.
+- Read [service selection](references/service-selection.md) when comparing Azure service classes or WAF trade-offs.
+- Read [governance effects](references/governance-effects.md) when translating accepted policy into decisions.
+- Read [network planning](references/network-planning.md) when a workload requires VNet attachment or private access.
+- Read [cost monitoring](references/cost-monitoring.md) when planning budgets, alert routing, anomaly detection, or cost
+  evidence.
+- [Decision boundaries](references/decision-boundaries.md) - fallback order, matrix use, and deferred evidence.
+
+## Capability Boundaries
+
+- Do not query Azure, registries, documentation, prices, quotas, identities, or repositories from this skill.
+- Do not select a mutable version, SKU, region, price, retirement date, or provider limit from memory.
+- Do not emit Bicep, Terraform, shell commands, policy exemptions, role assignments, or deployment actions.
+- Treat missing discovery, resolver, pricing, networking, or validation capability as a blocker, not permission to guess.
+
+## Output
+
+Return bounded architecture, plan, or binding decisions with requirement IDs, evidence identifiers, source precedence,
+exceptions, unknowns, deferrals, and blockers. Never turn absent evidence into a default or a successful validation.

package/assets/client-projections/github-copilot-cli/.github/skills/apex-azure-defaults/references/avm-binding-guidance.md

@@ -0,0 +1,29 @@
+# AVM And Module Binding Guidance
+
+Prefer Azure Verified Modules or the selected track's approved provider modules. Record module choices in typed bindings,
+not direct source files.
+
+## Selection Workflow
+
+1. Use the selected track's resolver capability to find the matching module family.
+2. Select an exact stable version from accepted resolver evidence; exclude prerelease versions unless explicitly allowed.
+3. Read the exact-version interface evidence and map every required input, output, child resource, and scope.
+4. Bind architecture intent, policy properties, tags, identity, networking, diagnostics, recovery, and SKU constraints.
+5. Check module defaults for SKU/feature conflicts and deprecated or immutable parameters.
+6. Validate that every planned resource has a binding and every binding traces to a planned resource.
+
+Record module source, exact version, resolver evidence, interface evidence, and review policy. A copied version, `latest`,
+or an unverified registry path is not an acceptable pin.
+
+## Exception Contract
+
+Use a non-AVM implementation only when accepted resolver evidence shows no suitable module or the module cannot satisfy
+an accepted requirement. Record resource type, track, scope, evidence, incompatibility, alternative, rationale, risk,
+owner, and review point. The exception authorizes a later CodeGen decision; it does not authorize this skill to emit code.
+
+## Do Not
+
+- Fetch registries or modules directly from the skill.
+- Invent a module version or claim it is current.
+- Paste raw Bicep or Terraform module code into a decision artifact.
+- Treat an AVM choice as proof that runtime policy or deployment validation passed.

package/assets/client-projections/github-copilot-cli/.github/skills/apex-azure-defaults/references/baseline-fallbacks.md

@@ -0,0 +1,53 @@
+# Baseline Fallbacks
+
+Use fallbacks only when accepted governance evidence is complete and explicitly reports no stronger applicable
+contract. Runtime configuration owns fallback values; this reference defines how to apply them safely.
+
+## Activation Test
+
+1. Confirm the target scope and inherited governance discovery are complete and current.
+2. Confirm the relevant contract is explicitly empty or absent by design, not unavailable or partially discovered.
+3. Confirm `apex/taskContext` projects fallback mode and the required runtime values.
+4. Record the fallback source, evidence identifier, affected environment, and review condition.
+
+If any test fails, return a blocker or kernel-owned deferral.
+
+## Region Fallback
+
+Use the runtime-projected primary region, service-specific override, and failover region. Before binding, require
+accepted evidence for service and SKU availability, data residency, latency, paired-region behavior, and quota. Never
+copy a region literal from guidance or silently move one service without documenting the cross-region consequence.
+
+## Tag Fallback
+
+When the runtime explicitly authorizes the greenfield tag fallback, use these lowercase semantic keys:
+
+- `environment`
+- `owner`
+- `costcenter`
+- `application`
+- `workload`
+- `sla`
+- `backup-policy`
+- `maint-window`
+- `technical-contact`
+
+Values still require projected inputs. Missing ownership, finance, or contact values are blockers. Optional provenance
+tags remain optional and must not be represented as policy requirements.
+
+## Naming And Uniqueness Fallback
+
+Use CAF-style resource abbreviations, project/environment semantics, and one kernel-projected stable uniqueness token.
+Normalize and truncate for the service before appending the token. Preserve existing deployed names unless an accepted
+migration authorizes replacement.
+
+## Security And Lifecycle Fallback
+
+Prefer managed identity, secret references, HTTPS-only transport, an accepted supported TLS floor, disabled anonymous
+blob access, private production data access, diagnostics, backup, and explicit recovery objectives. Select only a
+supported GA/LTS engine or runtime backed by current accepted evidence. No baseline fallback weakens accepted policy.
+
+## Module Fallback
+
+Prefer an exact-version AVM or track-approved module resolved by a capability. If no suitable module exists, require a
+structured exception before CodeGen. Missing resolver capability is a blocker, not permission to emit a raw resource.

package/assets/client-projections/github-copilot-cli/.github/skills/apex-azure-defaults/references/cost-monitoring.md

@@ -0,0 +1,47 @@
+# Cost Monitoring Guidance
+
+Treat cost monitoring as an architecture and binding contract, not proof that an Azure budget or alert exists. Accepted
+governance, environment policy, provider evidence, and runtime configuration determine the exact scope and values.
+
+## Contract Inputs
+
+- Budget amount, currency, time grain, effective period, and deployment scope
+- Actual and forecast notification thresholds from accepted policy or runtime configuration
+- Human owners, action-group mode, recipients, escalation path, and notification constraints
+- Anomaly-detection requirement and provider-supported scope
+- Environment-specific exception policy, owner, rationale, and review or expiry point
+
+## Planning Workflow
+
+1. Match the budget scope to the accepted deployment and governance scope.
+2. Apply accepted threshold/operator/type values within the current provider notification limit.
+3. Route notifications to accepted role recipients and an action group or equivalent escalation target.
+4. Choose create or reuse only from accepted inventory evidence; record the target identifier and ownership.
+5. Require non-empty reachable recipients when monitoring is enforced. An empty list is a blocker, not a silent skip.
+6. Model anomaly detection only at a scope and shape supported by accepted current provider evidence.
+7. Record module resolution, provider constraints, cost, and validation requirements for the selected IaC track.
+8. Reconcile the budget with accepted cost-estimate totals and document intentional variance.
+
+## Provider And Binding Safeguards
+
+- Prefer exact-version AVM or approved provider modules; raw-resource fallback requires a structured exception.
+- Keep display-name, schedule, view, scope, recipient, and uniqueness constraints in typed bindings.
+- Do not hardcode effective dates or far-future schedule endpoints; bind through the selected capability.
+- Do not assume a preview or compilation proves provider-side scheduled-action semantics.
+- Treat role-based notification as informational when accepted evidence cannot establish a reachable human assignee.
+- Account for auto-created or policy-deployed monitoring resources in ownership and drift expectations.
+
+## Cost Evidence Rules
+
+- Every amount needs accepted price evidence with service, SKU, meter, region, currency, quantity, usage, and timestamp.
+- Distinguish regional and global meters using accepted pricing metadata; never substitute a region from memory.
+- Disambiguate products and meters explicitly and preserve the original requested SKU when normalization is accepted.
+- Usage-based meters require workload quantities; a zero projection caused by missing usage is unresolved, not free.
+- Reconcile line-item sums to totals and separate baseline, variable, commitment, egress, transaction, and log costs.
+- If pricing capability or a required meter is unavailable, return `estimate unavailable`; never invent a price.
+
+## Exceptions And Blockers
+
+Production monitoring cannot be weakened without an accepted governance-compatible exception. Record environment,
+scope, rationale, owner, compensating control, and review or expiry point. Missing budget, recipients, provider support,
+module evidence, or pricing evidence must remain explicit blockers or kernel-owned deferrals.

package/assets/client-projections/github-copilot-cli/.github/skills/apex-azure-defaults/references/decision-boundaries.md

@@ -0,0 +1,19 @@
+# Decision Boundaries And Fallbacks
+
+Use stable decision aids only after accepted task inputs and governance constraints. They help compare options; they do
+not establish current cloud facts, prices, quotas, availability, or policy assignments.
+
+## Decision Order
+
+1. Apply accepted requirements, governance constraints, and recorded user decisions.
+2. Compare viable service, module, tag, security, and cost-monitoring options against that evidence.
+3. Record the selected option, rejected alternatives, assumptions, and affected Well-Architected pillars.
+4. Keep missing policy, pricing, quota, availability, and documentation evidence deferred to its qualified owner.
+
+## Fallback Rules
+
+- Use baseline categories only when task context explicitly confirms no stronger policy contract.
+- Treat service matrices as comparison prompts, never an automatic SKU or service selection.
+- Treat cost-monitoring intent as a design obligation; delivery, configuration, and verification require their owned
+  capability and accepted evidence.
+- Return a blocker when the selected track cannot represent a required constraint or no qualified evidence source exists.

package/assets/client-projections/github-copilot-cli/.github/skills/apex-azure-defaults/references/governance-effects.md

@@ -0,0 +1,28 @@
+# Governance Effect Interpretation
+
+Use accepted governance constraints to determine how policy effects change architecture and binding decisions.
+
+| Effect | Decision treatment |
+| --- | --- |
+| Deny | Required implementation constraint. Do not propose a noncompliant configuration. |
+| Modify | Model the resulting property or tag behavior and avoid a conflicting binding. |
+| Audit or AuditIfNotExists | Record the finding, evidence obligation, and validation input; do not call it compliant. |
+| DeployIfNotExists | Account for the dependent resource, identity, remediation ownership, and possible cost. |
+| Append | Model the appended field and ensure the selected module does not conflict with it. |
+| Disabled | Preserve the definition but apply no control from that assignment. |
+| Exempt | Preserve exemption scope, category, expiry, and evidence; do not remove the control globally. |
+
+## Definition Analysis
+
+Do not classify behavior from a display name. Use accepted definition evidence for conditions, parameters, effect,
+resource aliases, scope, enforcement mode, initiative membership, and exemptions. For inherited conflicts, use the
+effective result supplied by governance evidence rather than assuming the nearest assignment wins.
+
+## Reconciliation
+
+Map each applicable constraint to a typed property, architecture adaptation, binding decision, dependent resource,
+evidence obligation, accepted exception, or explicit blocker. Account for auto-deployed resources in ownership, cost,
+and drift expectations.
+
+Return a blocker when discovery is incomplete, a required parameter is unresolved, or the selected track/module cannot
+represent the effect. Do not query assignments, create exemptions, or claim remediation from this skill.

package/assets/client-projections/github-copilot-cli/.github/skills/apex-azure-defaults/references/naming.md

@@ -0,0 +1,47 @@
+# Naming And Binding Guidance
+
+Use projected run identity, selected environment, and accepted governance constraints as naming inputs. Keep names
+deterministic and traceable to the active run.
+
+## Input Contract
+
+Record the semantic workload name, environment, resource purpose, service constraint profile, and kernel-projected
+uniqueness token. Do not use physical tenant, subscription, principal, or secret values as name material.
+
+## Naming Procedure
+
+1. Apply accepted policy casing, prefixes, suffixes, and prohibited-term rules.
+2. Choose the CAF-style abbreviation projected for the resource family.
+3. Normalize only as the service permits: lowercase, remove or replace separators, and restrict the character set.
+4. Reserve space for the environment and run-stable uniqueness token before truncating the semantic portion.
+5. Validate final length, start/end characters, global uniqueness requirements, and sibling-name collisions.
+6. Record the pattern, normalized result, truncation rule, uniqueness source, and evidence in the typed binding.
+
+Generate one stable uniqueness token per deployment identity and pass it to every binding that needs global uniqueness.
+Do not generate unrelated random suffixes per module because that breaks cross-resource traceability and replacement
+analysis.
+
+## Constraint Profiles
+
+| Resource family | Binding treatment |
+| --- | --- |
+| Storage account and registry | Remove separators, use lowercase alphanumerics, preserve suffix room, verify uniqueness. |
+| Key Vault and SQL server | Use lowercase alphanumerics and allowed hyphens, preserve suffix room, verify uniqueness. |
+| Resource group and network | Keep a readable project/environment/purpose pattern within accepted provider limits. |
+| Reserved network resources | Use the exact provider-required name only when the matching resource is in scope. |
+
+Illustrative patterns are `kv-{short-workload}-{env}-{suffix}` and `st{shortworkload}{env}{suffix}`. They are not
+availability claims and do not override an accepted organization pattern.
+
+## Collision And Change Handling
+
+- If truncation makes two semantic names equal, increase disambiguation through the selected naming capability.
+- If accepted availability evidence rejects a global name, request a new kernel-owned token; do not improvise digits.
+- Treat a changed naming input as replacement-risk evidence and surface it before code generation.
+- Preserve established names for existing resources unless an accepted migration decision authorizes replacement.
+
+## Binding Output
+
+Record the naming pattern, uniqueness mechanism, maximum-length handling, and any governance exception in the typed
+binding. Do not generate shell commands, persist suffix files, or claim a name is available without an accepted
+availability or deployment receipt.

package/assets/client-projections/github-copilot-cli/.github/skills/apex-azure-defaults/references/network-planning.md

@@ -0,0 +1,47 @@
+# Network Planning Guidance
+
+Plan networking when a selected service requires VNet attachment, private endpoints, delegated subnets, internal
+ingress, gateways, firewalls, private DNS, or controlled egress. Accepted governance network constraints always win.
+
+## Required Inputs
+
+- New or existing VNet decision and accepted scope
+- Address spaces already used by connected networks
+- Service/SKU network requirements and current documentation evidence
+- Connectivity, ingress, egress, DNS, inspection, peering, and hybrid requirements
+- Growth, scale, availability-zone, environment, and ownership expectations
+
+An existing VNet requires accepted inventory or validation evidence. A user-supplied resource ID alone does not prove
+address space, region, reachability, ownership, or available capacity.
+
+## Planning Workflow
+
+1. Derive required subnets from selected services and accepted topology; do not start from a fixed subnet count.
+2. Record each subnet's purpose, address prefix, delegation, NSG, route table, service endpoints, and policy behavior.
+3. Validate containment, pairwise non-overlap, connected-network overlap, usable capacity, and growth headroom.
+4. Check exact service/SKU minimums against accepted current documentation; record both minimum and chosen headroom.
+5. Add private DNS zones and VNet links for every private endpoint domain represented by accepted service evidence.
+6. Account for billable gateways, firewalls, NAT, private endpoints, peering, DNS, and egress in cost inputs.
+7. Reconcile the plan with governance and return conflicts as blockers.
+
+## Durable Constraints
+
+- Azure reserves addresses in each subnet; calculate usable capacity rather than comparing total addresses.
+- Use exact reserved subnet names only when the matching service is in scope.
+- Keep private-endpoint subnets distinct when policy, routing, scale, or ownership requires isolation.
+- Apply the accepted delegation for delegated services; do not place incompatible delegations in one subnet.
+- Private endpoint network-policy behavior must be explicit and supported by accepted service evidence.
+- Attach NSGs and route tables according to accepted governance and service support; never assume universal support.
+- Prefer an AKS networking mode supported for greenfield use and size from nodes, maximum pods, surge, and growth.
+- NAT Gateway associates with workload subnets and does not imply a dedicated subnet.
+
+## Capacity Evidence
+
+For each subnet record total addresses, provider-reserved addresses, current demand, scale ceiling, surge demand, private
+endpoint count, and remaining headroom. If any service-specific minimum, overlap check, or existing-VNet fact is
+unavailable, mark the network decision blocked rather than auto-selecting a CIDR.
+
+## Output
+
+Return a typed network plan with evidence identifiers, topology assumptions, DNS ownership, cost-bearing resources,
+exceptions, and unresolved dependencies. This skill does not probe VNets, allocate CIDRs, or create network resources.

package/assets/client-projections/github-copilot-cli/.github/skills/apex-azure-defaults/references/security-baseline.md

@@ -0,0 +1,40 @@
+# Security Baseline Guidance
+
+Apply these controls when compatible with accepted requirements and governance constraints. A stricter projected policy
+always wins.
+
+## Core Controls
+
+| Area | Preferred decision |
+| --- | --- |
+| Transport | HTTPS only and the strongest accepted service-supported TLS floor. |
+| Identity | Managed identity over passwords, keys, or long-lived credentials. |
+| Secrets | Typed secret references; never literal secret values in artifacts or documents. |
+| Data plane | Private access for production data services unless an accepted exception exists. |
+| Storage | Disable anonymous/public blob access unless an accepted requirement requires it. |
+| Encryption | Use platform encryption and accepted customer-managed key requirements. |
+| Recovery | Make soft delete, purge protection, backup, retention, RTO, and RPO explicit. |
+| Diagnostics | Route required logs, metrics, and audit events to the accepted monitoring destination. |
+| Access | Least privilege, narrow scope, and explicit role intent. |
+
+## Service And Module Checks
+
+1. Select supported GA or LTS engine/runtime versions from accepted current documentation evidence.
+2. Reject preview, innovation, classic, or retiring options for durable greenfield workloads unless explicitly accepted.
+3. Check module defaults against the chosen SKU; a module may emit premium-only properties for a lower tier.
+4. Treat immutable first-deployment settings as migration-sensitive decisions.
+5. Use connection-string or endpoint patterns that replace deprecated keys when accepted service guidance requires it.
+6. Map every accepted `Deny` constraint to a concrete typed property or return an unsatisfied blocker.
+
+Do not treat compilation or preview success as proof that provider-side feature/SKU combinations are valid. Require the
+validation receipt owned by the active track.
+
+## Exceptions
+
+An exception must identify the requirement, affected resource and environment, rationale, compensating control, owner,
+expiry or review point, and accepted approval evidence. Public exposure, local authentication, shared keys, missing
+diagnostics, or weakened recovery must never become an implicit fallback.
+
+## Evidence Boundary
+
+This guidance does not prove configuration. Validation, policy, and deployment receipts provide the authoritative proof.

package/assets/client-projections/github-copilot-cli/.github/skills/apex-azure-defaults/references/service-selection.md

@@ -0,0 +1,51 @@
+# Service Selection And WAF Criteria
+
+Use service classes as candidates, not predetermined recommendations. Select services only when requirements, accepted
+cost/availability evidence, governance, and architecture decisions support them.
+
+## Elicit Before Selecting
+
+Capture workload pattern, application layers, availability and recovery objectives, compute model, relational and
+non-relational data needs, storage semantics, messaging, ingress, observability, compliance, team capability, and known
+SKU or commitment preferences. Treat "no preference" as permission to evaluate, not permission to pick from memory.
+
+Do not infer compliance solely from industry, choose an enterprise tier solely from company size, or recommend
+Kubernetes when operational requirements do not justify it.
+
+## Candidate Evaluation
+
+For each service candidate, compare:
+
+- Requirement coverage and workload fit
+- Security and identity model
+- Network and data residency constraints
+- Availability, recovery, and scalability objectives
+- Accepted regional availability, quota, lifecycle, and cost evidence
+- Operational burden, ownership, support model, and migration constraints
+- Module/provider support and implementation constraints
+
+Keep at least one viable alternative when the decision is material. Reject candidates with a reason tied to a
+requirement, policy, lifecycle limitation, or WAF consequence.
+
+## Well-Architected Questions
+
+| Pillar | Decision prompt |
+| --- | --- |
+| Security | Does the candidate support the required identity, encryption, private access, and data controls? |
+| Reliability | Can it meet accepted availability, RTO, RPO, and backup objectives? |
+| Performance | Can it meet projected throughput, latency, and growth needs? |
+| Cost | Is the selected SKU/quantity supported by accepted pricing evidence? |
+| Operations | Can it provide required diagnostics, health, ownership, and maintenance behavior? |
+
+## Lifecycle And SKU Rules
+
+- Use accepted current evidence for service availability, runtime support, SKU features, quotas, and retirement status.
+- Prefer supported GA/LTS versions for durable workloads and avoid deprecated or classic services for greenfield use.
+- Treat access tier, redundancy, orchestration mode, hosting plan, and commitment as separate decisions when applicable.
+- Do not convert an advisory workload matrix into a locked SKU or price.
+- Return a blocker when no candidate satisfies a mandatory requirement or evidence is missing.
+
+## Output
+
+Record selected and rejected candidates with evidence hashes, requirement IDs, WAF consequences, and unresolved
+assumptions. Do not turn an advisory service matrix into an automatic SKU decision.

package/assets/client-projections/github-copilot-cli/.github/skills/apex-azure-defaults/references/tag-precedence.md

@@ -0,0 +1,31 @@
+# Tag And Governance Precedence
+
+Accepted governance constraints are the current authority for required tag keys, casing, values, inheritance, and
+exceptions. Baseline tags are only a fallback when the task context explicitly establishes that no policy contract
+exists.
+
+## Decision Order
+
+1. Confirm governance discovery is complete for inherited and target scopes.
+2. Apply required keys, casing, values, exclusions, inheritance, and enforcement behavior from accepted constraints.
+3. Resolve values only from projected workload, environment, ownership, finance, and operations inputs.
+4. If accepted evidence explicitly reports no applicable tag policy, apply the authorized fallback from
+   `baseline-fallbacks.md` and record that source.
+5. Return a blocker when a required owner, cost center, contact, or restricted value is unresolved.
+
+## Casing And Inheritance
+
+- Use one casing for each logical key. Do not emit case variants such as `owner` and `Owner` together.
+- Distinguish tags required on the resource group from tags required on child resources.
+- Model `Modify` inheritance as expected behavior, but do not rely on it when a `Deny` requires the tag at creation.
+- Preserve exemptions with scope and expiry. An exemption does not remove the requirement outside its scope.
+
+## Existing Workloads
+
+Preserve deployed casing and keys when drift evidence shows they are intentional and an accepted compatibility decision
+requires them. Do not propagate a legacy convention to new resources merely because an older workload used it.
+
+## Output Constraint
+
+Place tag intent, value source, propagation behavior, exception, and governance evidence identifier in the architecture
+or binding decision. Do not query policy, create policy assignments, or write tags directly from this skill.

package/assets/client-projections/github-copilot-cli/.github/skills/apex-azure-deploy/SKILL.md

@@ -0,0 +1,50 @@
+---
+name: apex-azure-deploy
+description: "Explain approved APEX Azure deployment previews and lifecycle outcomes. Use for approved changes, recovery, verification, and trusted CLI handoff."
+user-invocable: false
+---
+
+# APEX Azure Deployment Guidance
+
+Use this skill only for an active operator or deployment task. It explains the exact kernel-provided approved preview,
+its lifecycle position, recovery state, and verification evidence. Deployment itself is reserved to trusted CLI
+ceremonies and kernel authorization.
+
+## Prerequisites
+
+- `apex/taskContext` identifies the active operation, target, authorization state, and validated evidence references.
+- `apex/preview` provides the current, unexpired preview created for that active operation.
+- The preview and validation evidence match the target and artifact revision selected by the kernel. A missing,
+  mismatched, expired, or partial preview is a blocker.
+
+## Workflow
+
+1. Read the current kernel-created preview only. Explain its semantic changes, target, expiry, destructive actions,
+   ignored or unevaluated items, dependencies, and uncertainty without adding inferred changes.
+2. State the lifecycle condition exactly as projected: awaiting decision, authorized, executing, succeeded, failed, or
+   indeterminate. Do not infer completion from files, portal state, or chat history.
+3. Explain the recovery path returned by the kernel. For an indeterminate operation, direct reconciliation through the
+   trusted lifecycle rather than retrying the side effect.
+4. Explain verification evidence, including the observations required to establish the expected post-operation state.
+5. Direct the operator to the trusted `apex gate decide` and `apex deploy` CLI ceremonies when the kernel marks them as
+   the next action. Do not expose deployment commands, substitute another tool, or invoke a deployment operation.
+
+## Boundaries
+
+- Do not run or provide direct AZD, Azure CLI, Bicep, Terraform, ARM, portal, or SDK deployment instructions.
+- Do not create, alter, approve, refresh, or extend previews; do not choose a target or grant authorization.
+- Do not independently retry, roll back, or reconcile an operation. Provider behavior is not assumed transactional.
+- Transform a direct deployment request into an explanation of the exact approved preview and the kernel-provided
+  trusted CLI ceremony. A request never bypasses validation, approval, expiry, writer-epoch, or authorization checks.
+
+## References
+
+- [Preview, recovery, and verification](references/preview-recovery-verification.md) - explanation rules and outcome
+  semantics.
+- [Operational checklist](references/operational-checklist.md) -
+   preconditions, circuit-breaker routing, drift, and verification limits.
+
+## Output
+
+Return the operation ID, target, lifecycle state, preview expiry, evidence references, blockers, and kernel-provided next
+action. Describe only facts supplied by the active task and preview itself.

package/assets/client-projections/github-copilot-cli/.github/skills/apex-azure-deploy/references/operational-checklist.md

@@ -0,0 +1,26 @@
+# Deployment Operational Checklist
+
+## Preconditions
+
+- Confirm the active operation, validated evidence, target, artifact revision,
+  and unexpired approved preview all match before explaining a deployment.
+- Explain destructive actions, dependencies, ignored items, and uncertainty as
+  returned by the preview. A preview does not authorize a different target.
+- Treat absent or mismatched validation proof as a blocker and return to the
+  trusted validation lifecycle.
+
+## Recovery And Circuit Breaking
+
+- For policy, governance, budget, build, validation, authentication, timeout,
+  or provider failures, preserve the reported evidence and stop at the trusted
+  recovery boundary rather than retrying or reconciling independently.
+- Use the kernel-provided circuit-breaker and retry decision. Escalate repeated
+  failure or an indeterminate provider outcome instead of assuming rollback.
+- Route governance drift to renewed accepted evidence and a new authorized
+  preview; drift is not a reason to amend the current operation in place.
+
+## Verification
+
+Explain only returned verification observations and their coverage. Endpoint
+reachability alone does not establish policy, security, data, or operational
+acceptance. Direct provider mutation remains a trusted CLI ceremony.

package/assets/client-projections/github-copilot-cli/.github/skills/apex-azure-deploy/references/preview-recovery-verification.md

@@ -0,0 +1,48 @@
+# Preview, Recovery, and Verification
+
+## Explain the Approved Preview
+
+An approved preview is an operation-specific description of planned provider changes. Explain only the preview returned
+for the active operation and include its target, expiry, semantic changes, destructive actions, dependencies,
+unevaluated items, and uncertainty. The preview is not a command, a general deployment plan, or authorization outside
+its stated lifecycle conditions.
+
+Do not fill in omitted operations from repository files, provider conventions, or expected resource topology. Omitted or
+unevaluated items are evidence limits and must remain visible to the operator.
+
+## Lifecycle and Recovery
+
+| State | Meaning | Permitted Guidance |
+| --- | --- | --- |
+| Awaiting decision | Preview exists but no authorization is recorded | Explain the preview and kernel-provided next action |
+| Authorized | Kernel has accepted the required decision | Direct to the trusted CLI ceremony only |
+| Executing | A trusted ceremony has started the provider operation | Report kernel status; do not duplicate it |
+| Succeeded | Kernel recorded a completed operation | Explain required verification evidence |
+| Failed | Kernel recorded a terminal failure | Explain the reported failure and recovery route |
+| Indeterminate | Provider outcome cannot be established | Direct reconciliation; never retry independently |
+
+Recovery is an authorized lifecycle transition, not a guessed rollback. Preserve the provider and kernel evidence,
+including partial state. The trusted lifecycle determines whether reconciliation, a new preview, a controlled retry, or
+another recovery action is appropriate.
+
+## Delivery Safeguards
+
+Explain only safeguards present in the accepted preview and evidence:
+
+- A deployment strategy is a risk-control decision, not permission to select a target, run a command, or change a
+  rollout.
+- Stop and route to the trusted lifecycle when a circuit-breaker condition, policy precheck failure, validation
+  blocker, or drift signal is reported.
+- Treat drift as a reconciliation input. Do not overwrite observed state, infer a baseline, or propose a corrective
+  action without a new kernel-authorized preview.
+- Keep policy effects, region availability, and known provider limitations visible as blockers or uncertainty. They do
+  not become resolved because a deployment reached a terminal state.
+
+Direct commands, recipes, SDK examples, CI definitions, and provider-specific recovery steps remain outside this
+guidance. The trusted CLI and provider lifecycle own those executable paths.
+
+## Verification Evidence
+
+Verification confirms the expected post-operation state against the active operation. Explain only observations returned
+by the kernel or trusted verification capability, their scope, time, outcome, and limitations. An endpoint being
+reachable, for example, does not establish every security, policy, data, or operational acceptance condition.