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

package/assets/client-projections/github-copilot-vscode/.github/skills/apex-azure-compute/references/compute-selection.md

@@ -1,26 +0,0 @@
-# Compute Selection
-
-## Hosting Model
-
-Use a single VM for a distinct, stateful, or individually configured workload. Use VM Scale Sets when the workload has
-an evidenced fleet requirement: interchangeable instances, defined minimum/maximum capacity, and metric or schedule
-scaling. Flexible orchestration suits heterogeneous fleet requirements; record why state, licensing, or networking does
-not prohibit it.
-
-## Family Candidates
-
-Evaluate at least two compatible families when the requirement permits it:
-
-- General purpose for balanced CPU and memory workloads.
-- Compute optimized for sustained CPU-bound work.
-- Memory optimized for memory-bound databases or caches.
-- Storage optimized for high local IOPS or throughput.
-- GPU or HPC families only when an explicit accelerator or interconnect requirement exists.
-
-Do not assert SKU availability, memory, CPU, or feature support from memory. Bind those claims to accepted current
-source evidence for the intended region.
-
-## Recommendation Record
-
-Record workload fit, hosting model, instance count or range, availability design, candidate SKUs, rejected alternatives,
-and unresolved risks. Regional capacity and quota are independent evidence inputs, not inferred from a published SKU.

package/assets/client-projections/github-copilot-vscode/.github/skills/apex-azure-compute/references/pricing-evidence.md

@@ -1,11 +0,0 @@
-# Pricing Evidence
-
-Use the read-only ARM pricing path for current candidate comparison. Match the region, operating system, licensing,
-reservation term, meter, currency, and quantity before comparing prices.
-
-VMSS does not add a separate compute charge: compare the selected VM price multiplied by the accepted capacity model.
-Do not present a unit price as a monthly cost without recording the calculation basis and expected runtime.
-
-A recommendation must state the evidence retrieval time, query scope, candidate SKU, price basis, commitment
-assumption, quantity, and uncertainty. Pricing evidence informs cost trade-offs; it does not choose a SKU, prove quota,
-or authorize procurement.

package/assets/client-projections/github-copilot-vscode/.github/skills/apex-azure-compute/references/recommendation-and-scale-rules.md

@@ -1,44 +0,0 @@
-# Compute Recommendation And Scale Rules
-
-Use these rules to form a bounded architecture recommendation. They do not establish regional availability, quota,
-SKU specifications, or price; bind those claims to accepted current evidence.
-
-## Recommendation Inputs
-
-Record workload type, CPU and memory demand, accelerator or local I/O requirements, operating system, region,
-availability target, budget, and expected instance range. Missing inputs are blockers rather than reasons to select a
-default SKU.
-
-## Model And Family Selection
-
-Use a single VM for a distinct, stateful, long-lived, or individually configured workload. Use VM Scale Sets for an
-interchangeable fleet with an evidenced capacity range and metric or schedule-based scaling need. A stateless web or
-API tier, parallel batch work, and homogeneous replicas are scale-set signals; a jump host, domain controller, or
-unique per-instance configuration is a single-VM signal. Prefer Flexible orchestration for a new scale set unless an
-accepted constraint requires Uniform; orchestration mode is a durable design decision.
-
-Select compatible candidates from the workload shape:
-
-- General-purpose families for balanced workloads; burstable families only when the credit and throttling trade-off is
-  acceptable.
-- Compute-optimized families for sustained CPU demand, memory-optimized families for memory-bound data workloads,
-  and storage-optimized families for high local I/O.
-- GPU, confidential-computing, or HPC families only when an explicit accelerator, isolation, or interconnect
-  requirement exists.
-- Treat Spot capacity as interruptible. It is not suitable for work that cannot tolerate eviction.
-
-## Scale And Cost Evidence
-
-For scale sets, record minimum and maximum capacity, scale triggers, cool-down intent, availability design, and the
-load-balancing or work-pull model. Do not infer production availability from a VMSS choice alone.
-
-Compare at least two viable candidates when requirements permit. Cost comparisons must identify region, operating
-system, price type, unit, collection time, candidate SKU, and instance range. VMSS cost is the underlying instance
-cost across its range; include baseline and peak estimates. Retail price lookup is capability-supplied evidence, not a
-skill operation, and a stale or incomplete result blocks a final cost claim.
-
-## Recommendation Record
-
-Record the selected model, candidate families, assumptions, rejected alternatives, capacity range, availability
-intent, current-evidence references, and unresolved risks. Escalate missing quota, capacity, or documentation evidence
-instead of treating published SKU names as deployment feasibility.

package/assets/client-projections/github-copilot-vscode/.github/skills/apex-azure-cost-optimization/SKILL.md

@@ -1,61 +0,0 @@
----
-name: apex-azure-cost-optimization
-description: "Assess APEX cost and utilization evidence for savings opportunities. Use for cost optimization, rightsizing, orphan candidates, reservations, and Redis cost review."
-user-invocable: false
----
-
-# APEX Azure Cost Optimization
-
-Use this skill for an active APEX assessment that evaluates spending and
-utilization evidence. It is advisory only: a capability produces evidence and
-the kernel decides whether a later task may authorize a change.
-
-## Prerequisites
-
-- `apex/taskContext` identifies the target subscriptions, resource boundary,
-  assessment period, currency, and the cost question to answer.
-- Each evidence record identifies its producing capability, observation time,
-  freshness status, target scope, redactions, completeness, and evidence hash.
-- Cost, utilization, inventory, and pricing evidence use compatible scopes and
-  periods. Missing, stale, partial, or scope-mismatched evidence is a blocker.
-
-## Workflow
-
-1. Confirm the target scope and whether the request is portfolio-wide,
-   resource-specific, or Redis-specific. Do not expand the boundary from names,
-   tags, or model memory.
-2. Separate observed cost from observed utilization, validated price context,
-   and calculated savings. A calculated estimate is not an invoice prediction.
-3. Evaluate only evidence-backed candidates using the assessment rules in
-   [cost assessment criteria](references/cost-assessment-criteria.md).
-4. Classify each candidate as `safe to investigate`, `review required`, or
-   `high risk`. State dependencies, uncertainty, evidence hash, and freshness.
-5. Return ranked opportunities, non-actionable observations, and blockers.
-   Send any proposed configuration, purchase, scaling, or deletion decision to
-   the kernel-authorized owning workflow.
-
-## Boundaries
-
-- Do not request, run, or imply external queries, scans, direct reads, pricing
-  lookups, or resource actions. Treat all such observations as scoped
-  capability-produced evidence.
-- Do not treat an orphan candidate, an unused-looking resource, or a missing
-  tag as proof that removal or downsizing is safe.
-- Do not promise savings where pricing evidence is absent, free allowances may
-  apply, shared allocation is uncertain, or the calculation cannot be traced.
-- Escalate evidence that indicates an availability, security, compliance, or
-  active incident concern to the kernel-selected owning assessment.
-
-## Output
-
-Return the target scope, assessment period, evidence hashes and freshness,
-findings, estimated savings with method, uncertainty, classification, and
-kernel-provided next action. Use `indeterminate` when evidence cannot support
-the conclusion.
-
-## References
-
-- [Cost assessment criteria](references/cost-assessment-criteria.md) - evidence
-  rules, heuristics, Redis assessment, classification, and uncertainty.
-- [Operational checklist](references/operational-checklist.md) -
-  normalization, candidate safety, and savings traceability.

package/assets/client-projections/github-copilot-vscode/.github/skills/apex-azure-cost-optimization/references/cost-assessment-criteria.md

@@ -1,61 +0,0 @@
-## Evidence Model
-
-Treat cost assessment as a comparison of four distinct evidence classes:
-
-| Evidence class | Establishes | Does not establish |
-| --- | --- | --- |
-| Actual cost | Charged usage in a stated period and scope | Future price or safe removal |
-| Actual utilization | Measured demand during its observation window | Demand outside that window |
-| Validated price context | Applicable rate, allowance, and commitment context | Realized savings without usage evidence |
-| Dependency evidence | Known consumers and attachment state | Absence of all dependencies unless complete |
-
-Every conclusion must carry the evidence hash, producing capability, target
-scope, observation period, freshness, completeness, and redaction boundary.
-Do not combine incompatible subscriptions, currencies, billing periods, or
-utilization windows without stating the normalization and resulting uncertainty.
-
-## General Heuristics
-
-- Prioritize high recurring cost with sustained low utilization only when both
-  measures cover the same target and a representative period.
-- Treat reservation, commitment, or license opportunities as `review required`:
-  forecast, flexibility, and existing commitments can change the result.
-- Treat unattached disks, addresses, snapshots, or similar inventory signals as
-  candidates. Require complete dependency evidence before describing removal as
-  safe to investigate.
-- For very small savings, emphasize operational simplification only when it is
-  evidence-backed; do not inflate financial impact.
-- Account for free allowances, shared services, minimum charges, data transfer,
-  and downstream performance effects before presenting net savings.
-
-## Redis Assessment
-
-Use Redis-specific signals only within the stated cache scope. A failed or
-long-creating cache, premium capacity in non-production, apparently unused
-enterprise capability, oversized non-production capacity, old test usage, or
-missing lifecycle tags are investigation signals, not action approvals.
-
-Require utilization, consumer dependency, environment classification, and
-pricing context before suggesting a tier or capacity change. Missing expiry or
-ownership metadata is a governance observation, not a savings estimate. Mark
-production caches and workloads with unknown latency, persistence, clustering,
-or availability needs as `high risk`.
-
-## Classification And Escalation
-
-| Classification | Evidence threshold | Required handoff |
-| --- | --- | --- |
-| Safe to investigate | Complete scope and reproducible low-risk observation | Authorized assessment or planning workflow |
-| Review required | Savings is plausible but dependencies, demand, or price terms are uncertain | Owner review through the kernel |
-| High risk | Production impact, data durability, availability, or unknown consumer dependency | Owning reliability, security, or service workflow |
-
-When data is stale, truncated, redacted beyond the needed fields, or missing a
-hash, return `indeterminate` and request refreshed scoped evidence through the
-authorized capability.
-
-## Capability Boundary
-
-Live pricing, Resource Graph inventory, billing exports, and source report rendering require separately qualified
-typed producers. Their absence is a blocker, not permission to substitute a browser lookup, terminal command, or a
-reference-only report outline. Keep any requested report as an assessment finding until a registered producer and
-renderer return a receipt.

package/assets/client-projections/github-copilot-vscode/.github/skills/apex-azure-cost-optimization/references/operational-checklist.md

@@ -1,24 +0,0 @@
-# Cost Assessment Operational Checklist
-
-## Normalize Evidence
-
-- Align cost, utilization, inventory, pricing context, currency, and period
-  before comparing candidates. Do not combine incompatible scopes or windows.
-- Separate observed charges, measured utilization, and calculated savings. A
-  modeled saving is not an invoice prediction or a provider commitment.
-- Preserve allocation uncertainty, free allowances, shared-resource effects,
-  and evidence freshness with every estimate.
-
-## Classify Candidates
-
-- Treat orphan-like resources, low utilization, and missing tags as candidates,
-  not removal or downsizing decisions.
-- Classify each evidence-backed item as safe to investigate, review required,
-  or high risk, with dependencies and a traceable estimate method.
-- For Redis-specific observations, retain the service boundary and workload
-  context; no general portfolio conclusion follows from one service signal.
-
-## Handoff
-
-Route purchases, configuration changes, scaling, and deletion to an authorized
-workflow. Escalate availability, security, compliance, or incident signals.

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

@@ -1,59 +0,0 @@
----
-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-vscode/.github/skills/apex-azure-defaults/references/avm-binding-guidance.md

@@ -1,29 +0,0 @@
-# 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-vscode/.github/skills/apex-azure-defaults/references/baseline-fallbacks.md

@@ -1,53 +0,0 @@
-# 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-vscode/.github/skills/apex-azure-defaults/references/cost-monitoring.md

@@ -1,47 +0,0 @@
-# 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-vscode/.github/skills/apex-azure-defaults/references/decision-boundaries.md

@@ -1,19 +0,0 @@
-# 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-vscode/.github/skills/apex-azure-defaults/references/governance-effects.md

@@ -1,28 +0,0 @@
-# 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-vscode/.github/skills/apex-azure-defaults/references/naming.md

@@ -1,47 +0,0 @@
-# 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-vscode/.github/skills/apex-azure-defaults/references/network-planning.md

@@ -1,47 +0,0 @@
-# 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-vscode/.github/skills/apex-azure-defaults/references/security-baseline.md

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