@apexops/cli 0.10.0-next.4 → 0.11.0-next.0

package/assets/client-projections/github-copilot-vscode/.github/skills/apex-mermaid/references/syntax.md

@@ -1,99 +0,0 @@
-# Syntax Guidance
-
-Use one compact diagram in a fenced `mermaid` block for a renderer-supported inline slot.
-
-## Choose The Diagram Type
-
-| Accepted relationship | Diagram type |
-| --- | --- |
-| Branching process, dependency, or decision | `flowchart` or `graph` |
-| Ordered interaction among actors | `sequenceDiagram` |
-| Lifecycle states and transitions | `stateDiagram-v2` |
-| Entity relationships and cardinality | `erDiagram` |
-| Dated tasks and dependencies | `gantt` |
-
-Use a standalone diagram capability for architecture, network, runtime, as-built, WAF, cost, or compliance visuals.
-
-## Flowchart
-
-```mermaid
-graph TB
-    START["Accepted input"] --> CHECK{"Gate"}
-    CHECK -->|"Pass"| RENDER["Render slot"]
-    CHECK -->|"Block"| STOP["Return blocker"]
-```
-
-Use `TB` for vertical flows and `LR` for short horizontal flows. Group related nodes only when an accepted boundary
-exists. Use `-->` for primary flow, `-.->` for an accepted optional relationship, and `==>` sparingly for an accepted
-critical path. Label decisions and non-obvious edges.
-
-## Sequence
-
-```mermaid
-sequenceDiagram
-    participant CLIENT as Client
-    participant API as API
-    participant STORE as Data store
-    CLIENT->>API: Accepted request
-    API->>STORE: Read accepted record
-    STORE-->>API: Result
-    API-->>CLIENT: Response
-```
-
-Declare participants in first-use order. Use solid arrows for calls and dashed arrows for responses. Do not invent
-authentication, retries, timing, or failure paths absent from accepted data.
-
-## State
-
-```mermaid
-stateDiagram-v2
-    [*] --> Proposed
-    Proposed --> Accepted: Approve
-    Accepted --> Superseded: Replace
-    Superseded --> [*]
-```
-
-Use explicit transition labels and only accepted states. Avoid modeling an action as a state or implying a transition
-the kernel does not authorize.
-
-## Entity Relationship
-
-```mermaid
-erDiagram
-    WORKLOAD ||--o{ RESOURCE : contains
-    RESOURCE ||--o{ EVIDENCE : supported_by
-```
-
-Use accepted cardinality. Keep entity and relationship names concise; do not expose sensitive field values.
-
-## Gantt
-
-```mermaid
-gantt
-    title Accepted delivery window
-    dateFormat YYYY-MM-DD
-    section Delivery
-        Foundation :foundation, 2030-01-01, 2d
-        Validation :validation, after foundation, 1d
-```
-
-Use dates and durations only from accepted schedule data. A Gantt chart is a presentation, not authorization or proof
-that a task started or completed.
-
-## Safe Identifiers And Labels
-
-- Use short, unique ASCII IDs; keep human-readable text in quoted labels or participant aliases.
-- Keep labels factual and concise. Use renderer-supported line breaks only when validation confirms them.
-- Avoid reserved keywords as IDs, duplicate IDs, unescaped quote characters, raw URLs, and HTML labels.
-- Preserve accepted relationship direction; do not reverse arrows to improve layout.
-- Omit unavailable values rather than inserting placeholders or guessed nodes.
-
-## Troubleshooting
-
-| Renderer finding | Correction |
-| --- | --- |
-| Parse error near label | Replace the display label with a quoted label and a simple ASCII ID. |
-| Duplicate or merged nodes | Give every semantic node a unique ID while retaining its accepted display label. |
-| Unsupported directive or diagram | Use the renderer-supported syntax or return an unsupported-capability blocker. |
-| Unreadable dense graph | Split by accepted concern or use the standalone diagram capability. |
-| Relationship appears wrong | Check the accepted source mapping; never fix layout by changing semantics. |

package/assets/client-projections/github-copilot-vscode/.github/skills/apex-microsoft-docs/SKILL.md

@@ -1,53 +0,0 @@
----
-name: apex-microsoft-docs
-description: "Researches official Microsoft documentation for APEX decisions. Use for Microsoft Learn concepts, limits, version support, WAF and architecture guidance, configuration, tutorials, and official code samples with cited evidence."
----
-
-# APEX Microsoft Documentation
-
-Use this skill only for an active APEX architecture or planning task that needs current official Microsoft guidance.
-The documentation capability is currently unavailable until it is activated and qualified for the selected client.
-
-## Prerequisites
-
-- `apex/taskContext` identifies the current task and the decision that needs evidence.
-- An activated, client-qualified, read-only documentation capability is available for the selected projection.
-
-Until that capability is active, return a missing-evidence blocker. Do not substitute model memory, a web scrape, a
-CLI fallback, or an unverified third-party source.
-
-## Workflow
-
-1. Frame a specific question with product, service, version, platform, task intent, and the decision it supports.
-2. Search through the qualified documentation capability before retrieving content.
-3. Rank official results by directness, version/platform fit, scope, and currency.
-4. Use the search excerpt when sufficient; otherwise fetch only the relevant page or section.
-5. Request an official code-sample search only when runnable example code is part of the question.
-6. Reconcile conflicting or incomplete sources and preserve unresolved applicability as a blocker.
-7. Record concise evidence with URL, title, heading, retrieval time, applicability, and uncertainty.
-8. Check that each material claim is supported and that documentation is not standing in for another evidence type.
-
-Read [the research method](references/research-method.md) before issuing a documentation request.
-
-## Boundaries
-
-- This skill is advisory. It does not configure MCP servers, execute commands, or modify files.
-- Azure pricing remains the read-only ARM MCP pricing evidence path, not a documentation lookup.
-- Documentation does not replace governance, quota, availability, approval, or deployment evidence.
-- Official examples are illustrative inputs to a later implementation decision, not proof that code compiles or deploys.
-- Do not fetch broad documentation trees, copy long page bodies, or use model memory to fill a missing source.
-
-## Blockers
-
-Return a missing-evidence blocker when the qualified capability is absent, no official source covers the target version
-or platform, sources materially conflict, the page is stale or inaccessible, or applicability cannot be established.
-Name the unresolved question and the evidence needed; do not fall back to CLI, web scraping, or third-party summaries.
-
-## References
-
-- [Research method](references/research-method.md) covers query framing, source selection, samples, conflicts, and evidence.
-
-## Output
-
-Return a bounded evidence result for the active APEX decision. Include supported claims, source URLs, applicability,
-retrieval metadata, uncertainty, conflicts, and missing-evidence blockers without changing task state.

package/assets/client-projections/github-copilot-vscode/.github/skills/apex-microsoft-docs/references/research-method.md

@@ -1,91 +0,0 @@
-# Official Documentation Research Method
-
-## Frame The Question
-
-Include the Microsoft product or Azure service, feature, exact or supported version family, platform, operating system,
-IaC or SDK language when relevant, task intent, environment constraint, and decision to resolve.
-
-Good query shapes name an outcome and source type:
-
-- `Azure Storage private endpoint DNS zone group configuration`
-- `Azure VMSS flexible orchestration limitations Linux`
-- `.NET supported version policy App Service Linux`
-- `Azure Well-Architected reliability checklist stateful workload`
-
-Use `overview` for concepts, `quickstart` or `tutorial` for a guided task, `reference` for exact configuration, `limits`
-for service boundaries, and `version support` or `retirement` for lifecycle questions.
-
-## Select The Source Type
-
-| Question | Preferred official source |
-| --- | --- |
-| Exact property, API, SDK, limit, or supported value | Product reference for the target version |
-| Setup sequence or learning task | Current quickstart or tutorial for the target platform |
-| Architecture trade-off | Azure Architecture Center or Well-Architected guidance |
-| Lifecycle or compatibility | Product support, release, or retirement policy |
-| Runnable example | Official code-sample result plus its parent documentation |
-
-## Retrieve Evidence
-
-1. Search first; do not begin with a full-page fetch.
-2. Keep only results on official Microsoft domains supplied by the qualified capability.
-3. Rank exact product/version/platform matches above generic, archived, training, or community pages.
-4. Stop at the excerpt when it directly answers the question and supplies a citable URL.
-5. Fetch one page or named section when qualifiers, tables, prerequisites, or exceptions are missing from the excerpt.
-6. Run code-sample search only when the user or decision needs code; bind language, SDK, and version in the query.
-
-Do not load an entire documentation tree. A second page is justified only when the first page explicitly delegates a
-material prerequisite, limit, or exception to it.
-
-## Evaluate Applicability
-
-Check service and feature, cloud or region scope, version, platform, API surface, publication/update metadata, preview or
-GA status, prerequisites, exclusions, and whether the page describes control plane, data plane, SDK, portal, or IaC.
-
-Documentation can establish published behavior but cannot prove that a target subscription has quota, a SKU is currently
-available in a region, a policy permits it, a deployment succeeded, or a price is current. Request the owning evidence
-capability for those claims.
-
-## Handle Code Samples
-
-- Treat samples as illustrative and inspect their stated version, dependencies, authentication, and prerequisites.
-- Prefer managed identity or `DefaultAzureCredential` patterns when the official sample supports them.
-- Never copy credentials, connection strings, tenant values, or deprecated authentication patterns into an artifact.
-- Record gaps between sample defaults and accepted security, governance, networking, or lifecycle requirements.
-- Require later compile, test, and deployment validation; sample provenance is not execution evidence.
-
-## Resolve Conflicts
-
-Prefer the more specific current product reference over generic architecture prose for exact behavior. Prefer the target
-version's page over an unversioned sample. When two applicable official sources materially disagree, retain both URLs,
-describe the conflict, and return a blocker rather than choosing silently.
-
-## Record The Result
-
-For every material claim, retain:
-
-- concise paraphrased claim
-- page title, URL, and relevant heading
-- retrieval time and capability evidence identifier
-- applicable product, service, version, platform, and scope
-- decision and requirement IDs informed
-- caveats, conflicts, uncertainty, and follow-up evidence needed
-
-Quote only the short phrase needed for exact terminology. Do not retain full page content in project artifacts. Treat a
-changed, unavailable, archived, or ambiguous source as missing evidence.
-
-## Validation Loop
-
-1. Match every material claim to a captured source.
-2. Check version, platform, scope, and preview/GA qualifiers.
-3. Remove claims supported only by model memory or a search-title inference.
-4. Search or fetch one narrower official source when a gap is resolvable.
-5. Return the remaining gap as a blocker when the qualified capability cannot resolve it.
-
-## Do Not
-
-- Treat a search result as approval, policy, quota, availability, or pricing evidence.
-- Fetch broad documentation trees or retain raw documentation in project artifacts.
-- Use third-party summaries when an official Microsoft source is required.
-- Add an unqualified documentation server or fallback command to a managed client projection.
-- Claim an official sample is production-ready, secure for the workload, compiled, or deployed without separate evidence.

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

@@ -1,34 +0,0 @@
----
-name: apex-operations
-description: "Provides internal APEX operations guidance for status, preview, inventory, reconciliation, and diagnosis."
-user-invocable: false
----
-
-## APEX Operations
-
-Use this skill only in the interactive Operator agent.
-
-## Prerequisites
-
-- `apex/status` identifies the selected run.
-- A task context is required only when the kernel issues a task-backed operation.
-
-## Workflow
-
-1. Use `apex/status` for taskless status. Use `apex/preview` only to read the current preview and explain its recorded
-   semantic changes, target, expiry, destructive actions, ignored or unevaluated items, and uncertainty.
-2. Use `apex/inventory` only to read the inventory already recorded for the selected run. Use `apex/reconcile` only for
-   an indeterminate operation; do not repeat a side effect independently.
-3. Use `apex/diagnose` only when the kernel issues a task-backed diagnosis, then read its exact `apex/taskContext`.
-4. Direct the user to `apex gate decide` and `apex deploy`; those trusted CLI ceremonies are not MCP tools.
-5. Report provider and kernel results without claiming transactional rollback, live Azure diagnostics, or a diagnosis
-   beyond the returned bounded status and doctor checks.
-
-## Output
-
-Return the operation ID, state, evidence references, blockers, and kernel-provided next action.
-
-## Boundaries
-
-Required validation, authorization, freshness, and writer-epoch checks are kernel-controlled. Do not invent operations,
-retry effects, or claim a provider inspection that the current APEX MCP result does not contain.

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

@@ -1,36 +0,0 @@
----
-name: apex-planning
-description: "Provides internal APEX planning guidance for implementation intent, controls, dependencies, and bindings."
-user-invocable: false
----
-
-## APEX Planning
-
-Use this skill only for an active planning task.
-
-## Prerequisites
-
-- The kernel projects accepted architecture and current governance inputs.
-- The selected IaC track and target environment are present in the task envelope.
-
-## Workflow
-
-1. Use accepted task-context artifacts and preserve their source hashes in implementation intent. Keep intent free of
-   Bicep or Terraform syntax.
-2. Define logical resources, controls, dependencies, identity, networking, diagnostics, outputs, and environment
-   obligations. Keep dependencies acyclic.
-3. Put modules, providers, API versions, variables, parameters, phases, backend, and stack ownership in the selected
-   binding rather than neutral intent. Bind only the selected task track.
-4. Trace every binding obligation to intent and projected policy requirements. Represent environment secrets only as
-   typed references; do not include secret values.
-5. Stage each typed output through `apex/stageArtifact`, then call `apex/completeTask` once with every required
-   output in `outputs`. Do not submit a single-output completion for a multi-output task.
-
-## Output
-
-Return the kernel result and any architecture-rooted or user-owned blocker.
-
-## Boundaries
-
-The kernel validates source hashes, track consistency, binding coverage, dependency shape, and secret safety. Do not
-claim a binding, hash format, provider capability, or gate result that is not returned by the current task contract.

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

@@ -1,43 +0,0 @@
----
-name: apex-requirements
-description: "Provides internal APEX requirements guidance for typed intake, scope, constraints, and budget."
-user-invocable: false
----
-
-## APEX Requirements
-
-Use this skill only for an active requirements task.
-
-## Prerequisites
-
-- `apex/taskContext` returns a requirements task envelope.
-- The interactive Requirements agent is active when user input may be needed.
-- The kernel's returned input request is the authoritative requirements question catalog.
-
-## Workflow
-
-1. Call `apex/nextTask`. Validate that a returned `task` is owned by the requirements role before reading its context.
-2. When it returns `needs_input`, use its `intake` metadata and `questions` exactly as returned; do not maintain a
-   separate client-side question list.
-3. Ask the returned questions through the active client projection's question mechanism. Record each response as a
-   supplied value, typed unknown, or explicit deferral with its owner; never replace an unknown with an inferred value.
-4. Submit that request only through `apex/recordInput`, preserving its request ID, expected journal head, and owner
-   epoch.
-5. Call `apex/nextTask` again and repeat until it returns a requirements `task`; only then read `apex/taskContext`.
-6. Treat the service-preferences round as a preference boundary. Capture retained, prohibited, and preferred services,
-   SKU preferences, and environment overrides without selecting architecture, SKUs, or implementation details.
-7. Stage the task-context-defined requirements output, complete the requirements task, and wait for the required review
-   result before reporting that Gate 1 is ready. Only the kernel opens or evaluates Gate 1.
-
-The kernel catalog and its versioned input contracts are authoritative. Do not choose architecture, SKUs, or
-implementation details while gathering requirements.
-
-## Boundaries
-
-Do not read task context for `needs_input`, a task owned by another role, or a stale task ID. Treat `APEX_STALE` as a
-fresh-status requirement, and return kernel validation or authorization errors without fabricating a requirements
-result.
-
-## Output
-
-Return the kernel result plus any unresolved user-owned fields.

package/assets/client-projections/github-copilot-vscode/.github/skills/apex-terraform-import/SKILL.md

@@ -1,47 +0,0 @@
----
-name: apex-terraform-import
-description: "Assess Terraform adoption of existing Azure resources in APEX. Use for scoped inventory evidence, import mapping, provider and module locks, drift assessment, and adoption attestation."
-user-invocable: false
----
-
-# APEX Terraform Import Assessment
-
-Use this skill for an active Terraform adoption task concerning existing resources. It evaluates accepted inventory and
-mapping evidence, then records adoption intent; authorized capabilities own discovery, configuration generation,
-stateful operations, validation, and lifecycle changes.
-
-## Prerequisites
-
-- `apex/taskContext` identifies the accepted adoption task, target boundary, resource scope, and acceptance criteria.
-- Accepted inventory evidence identifies its observation scope, completeness, redactions, and observation time.
-- Required mapping, provider/module lock, and validation capability receipts are accepted and current for that target.
-
-## Workflow
-
-1. Apply [Import assessment](references/import-assessment.md) to match accepted inventory facts to resource mappings
-   and ownership boundaries.
-2. Apply [Mapping and adoption attestation](references/mapping-and-adoption-attestation.md) to bind each candidate to
-   its intended address and accepted outcome evidence.
-3. Record a typed adoption proposal with scoped identifiers, exact provider/module locks, expected managed identities,
-   and reconciliation criteria.
-4. Apply [Adoption attestation](references/adoption-attestation.md) to evaluate authorized outcomes and remaining drift.
-5. Apply [Import mapping and reconciliation](references/import-mapping.md) to preserve candidate boundaries and
-   expected reconciliation without generating import blocks or executing a stateful operation.
-6. Route missing inventory, mapping, stateful-operation, or validation capabilities to the kernel as blockers. Never
-   replace a missing receipt with inferred configuration or model memory.
-
-## Boundaries
-
-- Do not query cloud inventories, inspect state, generate configuration, invoke Terraform, or mutate files.
-- Do not perform import, preview, apply, or deployment actions.
-- Import assessment does not establish ownership, compliance, a drift-free result, or deployment authorization without
-  accepted evidence.
-
-## References
-
-- [Import assessment](references/import-assessment.md) - scoped inventory, mappings, locks, and adoption intent.
-- [Mapping and adoption attestation](references/mapping-and-adoption-attestation.md) - candidate-to-address evidence
-   and outcome review.
-- [Adoption attestation](references/adoption-attestation.md) - receipt requirements, reconciliation, and handoff.
-- [Import mapping and reconciliation](references/import-mapping.md) - candidate records, drift review, and blocked
-   operations.

package/assets/client-projections/github-copilot-vscode/.github/skills/apex-terraform-import/references/adoption-attestation.md

@@ -1,10 +0,0 @@
-# Adoption Attestation
-
-An accepted adoption receipt identifies the active run, scoped target, candidate identifiers, exact provider and module
-locks, authorized operation outcome, reconciliation evidence, observation time, and unresolved differences. Evaluate
-the receipt against the declared criteria: each approved candidate is accounted for, no unapproved target is included,
-and remaining differences are classified rather than silently accepted.
-
-Carry accepted evidence identifiers and unresolved drift into the next kernel-selected task. A successful adoption
-outcome is not a policy, security, cost, or deployment approval. Stale, partial, mismatched, or absent attestation is a
-blocker and must be routed to the owning authorized capability.

package/assets/client-projections/github-copilot-vscode/.github/skills/apex-terraform-import/references/import-assessment.md

@@ -1,14 +0,0 @@
-# Import Assessment
-
-Start with accepted inventory evidence that is complete for the declared subscription, resource-group, resource-type,
-and result boundary. Treat each observed resource as a candidate until its mapping, dependencies, ownership boundary,
-and required configuration are accepted. Do not infer resource facts from names or incomplete inventory pages.
-
-For every candidate, record the scoped resource identifier, intended Terraform address, resource mapping evidence,
-exact provider lock, exact module lock when adoption uses a module, required identity, network and diagnostics intent,
-and reconciliation criteria. Preserve parent-child and cross-resource dependencies so the authorized capability can
-sequence adoption safely.
-
-Raw resource mapping may be a temporary accepted stage when an AVM binding cannot yet represent the resource. Record
-the target module transition, rationale, and stable-address strategy as typed intent. Missing mapping evidence, an
-unresolved lock, or an unavailable authorized capability is a blocker.

package/assets/client-projections/github-copilot-vscode/.github/skills/apex-terraform-import/references/import-mapping.md

@@ -1,27 +0,0 @@
-# Import Mapping And Reconciliation
-
-Use accepted inventory evidence to describe Terraform adoption candidates. It does not authorize a cloud read,
-configuration generation, state import, plan, or apply.
-
-## Candidate Record
-
-For every candidate, preserve:
-
-- scoped resource identifier and inventory observation boundary;
-- intended Terraform address and mapping rationale;
-- exact provider lock and any accepted module lock;
-- parent, child, and cross-resource dependencies;
-- identity, network, diagnostics, and ownership intent; and
-- expected reconciliation result and remaining-drift classification.
-
-## Review Checklist
-
-- Reject incomplete pages, inferred names, ambiguous resource types, and mappings without evidence.
-- Keep raw-resource adoption and later AVM refactoring as distinct, reviewable stages.
-- Require an explicit stable-address strategy before any stateful transition.
-- Treat unexpected create, delete, replacement, or drift as a blocker for the owning authorized capability.
-
-## Blocked Operations
-
-Terraform import apply, state mutation, cloud inventory reads, generated import blocks, preview, and deployment remain
-outside this skill.

package/assets/client-projections/github-copilot-vscode/.github/skills/apex-terraform-import/references/mapping-and-adoption-attestation.md

@@ -1,12 +0,0 @@
-# Mapping and Adoption Attestation
-
-For each accepted inventory candidate, record the stable resource identifier, intended Terraform address, mapping
-rationale, parent or dependent relationships, exact provider and module locks, and target boundary. Treat an address
-as proposed until an authorized capability returns target-matched evidence.
-
-An adoption attestation accounts for every approved candidate and no unapproved target. It records the authorized
-outcome, reconciliation evidence, observation time, remaining differences, and any accepted exception. Classify
-unresolved drift rather than treating it as a successful adoption.
-
-Missing inventory scope, mapping evidence, stateful-operation evidence, or validation evidence is a blocker. This
-reference does not authorize discovery, configuration generation, state changes, import, preview, or apply.

package/assets/client-projections/github-copilot-vscode/.github/skills/apex-terraform-patterns/SKILL.md

@@ -1,49 +0,0 @@
----
-name: apex-terraform-patterns
-description: "Apply approved Terraform architecture intent in APEX. Use for hub-spoke, private endpoints, diagnostics, AVM module locks, and CodeGen acceptance."
-user-invocable: false
----
-
-# APEX Terraform Patterns
-
-Use this skill for an active Terraform-bound planning or CodeGen task. It records approved architecture intent and
-acceptance criteria; authorized capabilities own source inspection, generation, validation, and lifecycle changes.
-
-## Prerequisites
-
-- `apex/taskContext` identifies an accepted Terraform track task, scoped target, and typed binding inputs.
-- Architecture, governance, security, and monitoring decisions are accepted for that target.
-- Required capability receipts are accepted, current, target-matched, and include the exact provider and module locks.
-
-## Workflow
-
-1. Select only patterns supported by accepted architecture and track bindings.
-2. Apply [Network and observability](references/network-and-observability.md) for hub-spoke, private connectivity,
-   and diagnostics intent.
-3. Apply [Module locks and CodeGen acceptance](references/module-locks-and-codegen-acceptance.md) for AVM selection,
-   exact locks, and evidence requirements.
-4. Apply [Module composition and state boundaries](references/module-composition-and-state-boundaries.md) to define
-   stable interfaces and record refactoring migration intent.
-5. Apply [Plan and change assessment](references/plan-and-change-assessment.md) to classify proposed actions and
-   surface replacement, deletion, or stateful-resource risk.
-6. Submit typed intent only through an authorized capability. Treat unavailable capabilities, missing locks, stale
-   receipts, or unaccepted evidence as blockers.
-
-## Boundaries
-
-- Do not write Terraform, inspect provider sources, resolve versions, invoke Terraform, or mutate files.
-- Do not discover cloud resources, validate infrastructure, preview changes, or deploy.
-- CodeGen, validation, and operations remain responsible for their own authorized receipts; pattern selection does not
-  bypass policy, cost, approval, or deployment gates.
-
-## References
-
-- [Network and observability](references/network-and-observability.md) - hub-spoke, private endpoints, and diagnostics.
-- [Module locks and CodeGen acceptance](references/module-locks-and-codegen-acceptance.md) - AVM binding, exact
-  locks, and receipt-based acceptance.
-- [Module composition and refactor intent](references/module-composition-and-refactor.md) - boundary, interface, and
-  state-transition review criteria.
-- [Module composition and state boundaries](references/module-composition-and-state-boundaries.md) - output-to-input
-  interfaces and refactoring migration intent.
-- [Plan and change assessment](references/plan-and-change-assessment.md) - receipt-gated action classification and
-  stateful-resource risk review.

package/assets/client-projections/github-copilot-vscode/.github/skills/apex-terraform-patterns/references/module-composition-and-refactor.md

@@ -1,20 +0,0 @@
-# Module Composition And Refactor Intent
-
-Use accepted architecture and exact locks to describe a Terraform module boundary. This reference does not authorize
-Terraform source generation, state inspection, state moves, planning, or apply.
-
-## Composition Checklist
-
-- Group resources only when they share lifecycle, ownership, and a cohesive interface.
-- Keep cross-cutting diagnostics, policy, tags, and environment-specific bindings explicit at the accepted root
-  boundary.
-- Define typed inputs, stable outputs, identity requirements, private networking, and dependent-output contracts.
-- Prefer an accepted AVM interface when it meets the requirement; document an exception, rationale, and review criteria
-  when it does not.
-- Preserve stable resource addresses across module extraction. A state transition requires a separately authorized,
-  reviewed operation and evidence.
-
-## Plan Review Signals
-
-Treat replacement, deletion, unexpected address changes, unmanaged dependencies, provider-lock drift, or missing
-diagnostics as blockers. A clean intent record is not a Terraform plan or proof of safe state migration.

package/assets/client-projections/github-copilot-vscode/.github/skills/apex-terraform-patterns/references/module-composition-and-state-boundaries.md

@@ -1,11 +0,0 @@
-# Module Composition and State Boundaries
-
-Define each module by its stable inputs, outputs, ownership boundary, dependencies, and accepted locks. Compose modules
-through declared outputs and inputs; do not substitute literal resource identifiers for an interface contract.
-
-Group resources only when they share a lifecycle and a clear responsibility. Keep cross-cutting monitoring, identity,
-policy, and provider configuration at an explicit boundary unless accepted architecture says otherwise.
-
-For a refactor, record every source address, destination address, interface change, dependency, migration receipt, and
-rollback condition as typed intent. An address change is not safe until an authorized capability supplies accepted
-state-transition evidence. Do not perform or prescribe state operations.

package/assets/client-projections/github-copilot-vscode/.github/skills/apex-terraform-patterns/references/module-locks-and-codegen-acceptance.md

@@ -1,14 +0,0 @@
-# Module Locks And CodeGen Acceptance
-
-Prefer an accepted Azure Verified Module when its locked interface can satisfy the approved requirements. Record the
-module family, exact module lock, exact provider lock, required inputs, identity, network, diagnostics, tags, and
-dependent outputs as typed constraints. A lock is valid only when its supporting capability receipt is accepted and
-matches the active target and binding.
-
-An AVM selection is not automatically compliant. CodeGen must return an authorized receipt for the locked bindings;
-validation must return accepted evidence for syntax, security baseline, policy compatibility, and preview criteria. When
-a module cannot express a requirement, record the exception, alternative intent, rationale, and traceability before
-requesting generation.
-
-Use typed parameters for environment-specific values and never carry secret literals in intent. Preserve stable resource
-identity and required outputs for dependent bindings. Missing, stale, mismatched, or unavailable evidence is a blocker.

package/assets/client-projections/github-copilot-vscode/.github/skills/apex-terraform-patterns/references/network-and-observability.md

@@ -1,12 +0,0 @@
-# Network And Observability
-
-Use hub-spoke topology only when shared connectivity, inspection, DNS, or platform services are accepted architectural
-requirements. Spokes connect to the hub under accepted routing, peering, subnet, and network-security bindings; do not
-infer these choices from naming or module defaults.
-
-Private endpoint intent is complete only when the target subresource, approved subnet, private DNS zone, and DNS zone
-group are all bound. A public-access exception requires accepted risk evidence and a policy-compatible boundary.
-
-Every governed resource needs diagnostics and metrics mapped to the accepted monitoring destination. Categories,
-retention, cost, ownership, and destination are typed decisions. Generated settings and deployment outcomes require
-accepted validation and operation receipts for the same scoped target.

package/assets/client-projections/github-copilot-vscode/.github/skills/apex-terraform-patterns/references/plan-and-change-assessment.md

@@ -1,24 +0,0 @@
-# Plan and Change Assessment
-
-Assess accepted plan evidence by its declared actions, target scope, and locked provider or module context.
-Do not infer an action from configuration or perform a preview.
-
-| Action class | Assessment intent |
-| --- | --- |
-| Create | Confirm the target is in scope and its governance evidence is current. |
-| In-place update | Confirm the changed properties and dependent interfaces are accepted. |
-| Replace | Escalate downtime, data, identity, network, and rollback consequences for approval. |
-| Delete | Require explicit ownership, recovery, and approval evidence before handoff. |
-| Read | Treat it as observation only; it does not establish desired-state acceptance. |
-
-## Stateful and Drift Signals
-
-Treat replacements or deletions of data, identity, network, and secret-bearing resources as blockers until an
-authorized capability records the required recovery and approval evidence. A broad update set can indicate a
-provider-schema, collection-order, or configuration-drift difference; record the uncertainty instead of assuming it
-is harmless.
-
-## Handoff
-
-Record the receipt identifier, target, exact locks, action summary, accepted exceptions, and unresolved risks.
-CodeGen and validation capabilities own preview generation, provider inspection, and any stateful follow-up.