@apexops/cli 0.10.0-next.0

package/assets/customizations/.github/skills/apex-microsoft-docs/references/research-method.md

@@ -0,0 +1,91 @@
+# 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/customizations/.github/skills/apex-operations/SKILL.md

@@ -0,0 +1,34 @@
+---
+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/customizations/.github/skills/apex-planning/SKILL.md

@@ -0,0 +1,36 @@
+---
+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/customizations/.github/skills/apex-requirements/SKILL.md

@@ -0,0 +1,43 @@
+---
+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/customizations/.github/skills/apex-terraform-import/SKILL.md

@@ -0,0 +1,47 @@
+---
+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/customizations/.github/skills/apex-terraform-import/references/adoption-attestation.md

@@ -0,0 +1,10 @@
+# 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/customizations/.github/skills/apex-terraform-import/references/import-assessment.md

@@ -0,0 +1,14 @@
+# 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/customizations/.github/skills/apex-terraform-import/references/import-mapping.md

@@ -0,0 +1,27 @@
+# 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/customizations/.github/skills/apex-terraform-import/references/mapping-and-adoption-attestation.md

@@ -0,0 +1,12 @@
+# 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/customizations/.github/skills/apex-terraform-patterns/SKILL.md

@@ -0,0 +1,49 @@
+---
+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/customizations/.github/skills/apex-terraform-patterns/references/module-composition-and-refactor.md

@@ -0,0 +1,20 @@
+# 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/customizations/.github/skills/apex-terraform-patterns/references/module-composition-and-state-boundaries.md

@@ -0,0 +1,11 @@
+# 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/customizations/.github/skills/apex-terraform-patterns/references/module-locks-and-codegen-acceptance.md

@@ -0,0 +1,14 @@
+# 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/customizations/.github/skills/apex-terraform-patterns/references/network-and-observability.md

@@ -0,0 +1,12 @@
+# 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/customizations/.github/skills/apex-terraform-patterns/references/plan-and-change-assessment.md

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

package/assets/customizations/.github/skills/apex-terraform-test/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: apex-terraform-test
+description: "Design receipt-gated Terraform test intent in APEX. Use for unit and integration coverage, assertions, mocks, negative cases, and test-evidence acceptance."
+user-invocable: false
+---
+
+# APEX Terraform Test Design
+
+Use this skill for an active Terraform test-design or validation task. It specifies coverage and assertion intent;
+authorized capabilities own test materialization, execution, environment access, and evidence production.
+
+## Prerequisites
+
+- `apex/taskContext` identifies the accepted Terraform binding, scoped target, test objective, and acceptance criteria.
+- The exact provider and module locks are accepted for the binding under test.
+- Required test or validation capability receipts are accepted and current for the same target.
+
+## Workflow
+
+1. Classify the requirement with [Test design](references/test-design.md): deterministic unit, negative validation,
+   mock-backed behavior, or integration behavior.
+2. Apply [Plan-mode and mock design](references/plan-mode-and-mock-design.md) to define deterministic scope without
+   promoting mocked behavior to live-service evidence.
+3. Define observable assertions, expected failures, test inputs, and isolation boundaries without assuming unobserved
+   provider behavior.
+4. Apply [Evidence acceptance](references/evidence-acceptance.md) to distinguish test-design intent from accepted
+   execution evidence.
+5. Apply [Plan-mode test design](references/plan-mode-test-design.md) for deterministic coverage. Apply-mode and
+   real-provider work remain blocked until separately authorized.
+6. Submit the test specification through an authorized capability. Return unavailable capabilities, absent environment
+   authorization, stale locks, or incomplete evidence as blockers.
+
+## Boundaries
+
+- Do not write or run test files, configure providers, access environments, or mutate files.
+- Do not invoke Terraform, inspect provider registries, query cloud state, or create infrastructure.
+- A mock-backed result does not establish live-service behavior; an integration result does not authorize deployment.
+
+## References
+
+- [Test design](references/test-design.md) - coverage classification, assertion quality, mocks, and negative cases.
+- [Plan-mode and mock design](references/plan-mode-and-mock-design.md) - deterministic coverage and mock boundaries.
+- [Evidence acceptance](references/evidence-acceptance.md) - receipt scope, result interpretation, and blocker routing.
+- [Plan-mode test design](references/plan-mode-test-design.md) - mock boundary, assertions, and blocked apply-mode
+   work.

package/assets/customizations/.github/skills/apex-terraform-test/references/evidence-acceptance.md

@@ -0,0 +1,10 @@
+# Evidence Acceptance
+
+An accepted test receipt identifies the active run, scoped target, exact provider and module locks, test classification,
+inputs or fixtures, assertion outcomes, observation time, and cleanup or retention outcome when applicable. Evaluate
+each assertion against the task acceptance criteria and preserve failures, skips, indeterminate outcomes, and
+environment limitations distinctly.
+
+Do not promote a test design to a passed result. Do not infer results from configuration, prior chat content, or a
+receipt for another target or lock set. Expired, incomplete, mismatched, or unaccepted receipts require a capability
+refresh request; unavailable capabilities remain blockers rather than a reason to downgrade acceptance criteria.

package/assets/customizations/.github/skills/apex-terraform-test/references/plan-mode-and-mock-design.md

@@ -0,0 +1,12 @@
+# Plan-Mode and Mock Design
+
+Use plan-mode intent for deterministic contracts such as inputs, naming, tags, conditional resources, output shape,
+and validation failures. State the expected observable result and isolate each case unless a declared dependency is the
+behavior under test.
+
+Use a mock only when accepted capability evidence confirms support for the exact provider lock. Record mocked resource
+or data assumptions, asserted outcomes, and known unmodeled behavior. Mock-backed evidence does not establish provider
+API behavior, timing, credentials, or live-service outcomes.
+
+Integration intent requires an authorized environment, scoped cleanup expectations, and target-matched evidence.
+Test design never authorizes execution or deployment.

package/assets/customizations/.github/skills/apex-terraform-test/references/plan-mode-test-design.md

@@ -0,0 +1,23 @@
+# Plan-Mode Test Design
+
+Plan-mode tests give deterministic evidence for configuration contracts without creating infrastructure. They do not
+prove provider behavior or authorize apply-mode execution.
+
+## Coverage Checklist
+
+- Test required inputs, naming, tags, conditional resources, output contracts, and validation failures.
+- Use mock-backed cases only for provider-independent behavior under the accepted provider lock.
+- Make each assertion describe one observable accepted contract and an actionable failure condition.
+- Keep scenarios isolated unless a declared dependency is the behavior being tested.
+- Record fixture provenance and the provider/module locks used to interpret the result.
+
+## Example Intent
+
+An accepted test specification can state: given a private-endpoint-enabled binding, the generated configuration must
+expose the approved private DNS dependency and reject a missing subnet input. The authorized test capability owns the
+test file, execution, and receipt.
+
+## Boundaries
+
+Apply-mode tests, real-provider integration, environment access, cleanup, and publishing remain blocked without an
+explicit authorized capability and accepted environment evidence.

package/assets/customizations/.github/skills/apex-terraform-test/references/test-design.md

@@ -0,0 +1,13 @@
+# Test Design
+
+Prefer deterministic unit coverage for naming, tags, conditional resources, output contracts, and variable validation.
+Use negative cases to prove that invalid inputs are rejected. Assertions should state the observable contract, expected
+condition, and actionable failure meaning; they must not depend on incidental ordering or model-inferred attributes.
+
+Use mock-backed tests for provider-independent logic when an accepted capability confirms mock support under the exact
+provider lock. Mock results validate declared behavior, not live Azure behavior. Keep scenarios isolated unless an
+accepted dependency is the behavior being tested.
+
+Request integration coverage only when the task explicitly requires live behavior and the task envelope supplies an
+authorized environment capability. Scope inputs, resource identity, cleanup expectations, and evidence to the accepted
+target. Missing authorization or a missing capability is a blocker.

package/assets/customizations/.github/skills/apex-workflow/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: apex-workflow
+description: "Provides internal APEX workflow routing for status, resume, project selection, and next tasks."
+user-invocable: false
+---
+
+## APEX Workflow
+
+Use this skill to orient an interactive agent without reconstructing workflow state from chat or files.
+
+## Prerequisites
+
+- The workspace has the APEX CLI and MCP server configured.
+- The user has selected or identified an APEX project when more than one exists.
+
+## Workflow
+
+1. Call `apex/status` for the selected project.
+2. If the selected project is wrong or absent, use the active client question mechanism to select a project, then repeat
+   `apex/status`.
+3. If status identifies blockers, gates, or a terminal run, report that kernel state and do not infer a task.
+4. Otherwise call `apex/nextTask`. For `needs_input`, return the exact request to its owning interactive role. For
+   `task`, route only to the returned task owner through the active client projection.
+5. For resume, fetch fresh status instead of relying on an earlier conversation. On an `APEX_STALE` error, refresh
+   status and do not reuse a task ID, request ID, journal head, or owner epoch.
+
+Do not infer progress from generated files, conversation history, or handoff completion. If selection is ambiguous, the
+interactive agent may use its active client question mechanism before repeating `apex/status`.
+
+## Boundaries
+
+`apex/nextTask` returns only `needs_input` or `task`. Terminal, blocked, missing-project, authorization, and stale
+conditions are represented by status or stable kernel errors; do not invent additional tool results or transitions.
+
+## Output
+
+Report the project, run, environment, current state, blockers, and one kernel-provided next action.

package/assets/customizations/.vscode/mcp.json

@@ -0,0 +1,21 @@
+{
+  "servers": {
+    "apex": {
+      "type": "stdio",
+      "command": "node",
+      "args": [
+        "${workspaceFolder}/node_modules/@apexops/cli/dist/cli.js",
+        "mcp",
+        "serve"
+      ],
+      "cwd": "${workspaceFolder}"
+    },
+    "azure-resource-manager-mcp": {
+      "type": "http",
+      "url": "https://mcp.management.azure.com",
+      "headers": {
+        "x-mcp-toolset": "CostManagement,Pricing"
+      }
+    }
+  }
+}