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

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

@@ -1,44 +0,0 @@
----
-name: apex-mermaid
-description: "Requests safe inline Mermaid for supported APEX Markdown slots. Use for compact flowcharts, sequences, state machines, ER models, Gantt views, renderer validation, accessible theming, and syntax troubleshooting from accepted artifact data."
-user-invocable: false
----
-
-# APEX Inline Mermaid
-
-The current APEX document registry declares no Mermaid-capable slots. Do not request or emit an inline Mermaid fence
-until a renderer registers a typed source, a supported slot, syntax validation, and a returned document receipt.
-
-## Prerequisites
-
-- The target template exposes a Mermaid-capable inline slot.
-- Accepted artifact data contains every node, relationship, label, and time value to be shown.
-- The renderer declares supported Mermaid syntax and validation behavior.
-
-## Future Renderer Contract
-
-When a renderer-supported slot exists, select the simplest diagram type that preserves accepted relationships. Apply
-[syntax guidance](references/syntax.md) and [styling guidance](references/styling.md), then submit only the bounded
-fence to that renderer. The renderer, rather than this skill, must validate syntax and return the document receipt.
-
-Syntax and styling references are guidance targets, not active renderer slots. They do not make Mermaid output
-available until a typed source, renderer registration, and receipt exist.
-
-## Boundaries
-
-- Do not create standalone architecture, network, runtime, as-built, WAF, cost, or compliance diagrams.
-- Do not write or edit files, invoke deployment, or mutate source-of-truth artifacts, templates, schemas, or state.
-- Do not use unaccepted inputs, infer missing values, or treat rendered Markdown as gate evidence.
-- Do not embed Azure service icons, custom SVG, secrets, physical principal IDs, unsafe links, or Mermaid click actions.
-- Do not claim syntax or visual validation from model inspection; only the renderer receipt supplies that evidence.
-
-## Blockers
-
-When the requested document slot is unsupported, absent, or cannot be filled from accepted data, return a blocker that
-names the slot, diagram type, and missing renderer support or artifact data. Also block when renderer-version syntax,
-escaping, or accessibility cannot be validated. Do not emit a substitute diagram or alter any source.
-
-## Output
-
-Return only the renderer request or its rendered inline document result and receipt. Preserve any projected artifact and
-template hashes, validation status, and unresolved blockers.

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

@@ -1,33 +0,0 @@
-# Styling Guidance
-
-Use a renderer-compatible neutral theme and limited semantic classes. Meaning must remain clear without color.
-
-```mermaid
-%%{init: {'theme': 'neutral'}}%%
-graph LR
-    classDef gate stroke:#2563eb,stroke-width:2px;
-    INPUT["Accepted data"] --> GATE{"Supported slot"}:::gate
-    GATE --> OUTPUT["Rendered inline view"]
-```
-
-## Styling Rules
-
-- Prefer one layout direction, consistent node shapes, and a small semantic class set.
-- Use shape, border, and text labels together; never encode status or severity by color alone.
-- Keep contrast readable in light and dark Markdown renderers. Use renderer-projected colors when available.
-- Use subgraphs only for accepted ownership, trust, lifecycle, or resource boundaries.
-- Keep edge labels short and place detail in surrounding prose when the slot permits it.
-- Avoid service icons, custom SVG, background images, animations, click actions, and external CSS.
-- Do not use emoji as the only identifier; assistive text must carry the meaning.
-
-## Complexity Limits
-
-When labels overlap, crossings obscure meaning, or the renderer cannot fit the slot, reduce the diagram to its primary
-accepted relationship. Split independent concerns into supported slots or use a standalone diagram capability. Do not
-hide nodes or drop material edges merely to make the view attractive.
-
-## Renderer Validation
-
-The renderer decides whether the slot accepts Mermaid, the theme directive is supported, syntax parses, and the result
-fits the document. Inspect the renderer receipt for validation errors. Model inspection, Markdown source appearance, or
-a successful document request is not visual-validation evidence.

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,46 +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 service questions in the workload panel as a preference boundary. Present the kernel recommendation, then
-   capture retained, prohibited, and preferred services, SKU preferences, and environment overrides without selecting
-   architecture, SKUs, or implementation details.
-7. Submit the task-context-defined output through `apex/requirementsComplete`, invoke the required Reviewer, and handle
-   `needs_review` through one native findings panel and `apex/reviewDecide`.
-8. After a clean or fully dispositioned review, ask for explicit Gate 1 approval. Call `apex/gateDecide` only after the
-   user chooses Proceed, then continue to Architecture in the same turn.
-
-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.