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

package/assets/client-projections/github-copilot-cli/.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-cli/.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-cli/.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-cli/.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-cli/.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-cli/.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-cli/.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-cli/.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-cli/.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-cli/.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-cli/.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-cli/.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.

package/assets/client-projections/github-copilot-cli/.github/skills/apex-terraform-test/SKILL.md

@@ -1,45 +0,0 @@
----
-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/client-projections/github-copilot-cli/.github/skills/apex-terraform-test/references/evidence-acceptance.md

@@ -1,10 +0,0 @@
-# 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/client-projections/github-copilot-cli/.github/skills/apex-terraform-test/references/plan-mode-and-mock-design.md

@@ -1,12 +0,0 @@
-# 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/client-projections/github-copilot-cli/.github/skills/apex-terraform-test/references/plan-mode-test-design.md

@@ -1,23 +0,0 @@
-# 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/client-projections/github-copilot-cli/.github/skills/apex-terraform-test/references/test-design.md

@@ -1,13 +0,0 @@
-# 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/client-projections/github-copilot-cli/.github/skills/apex-workflow/SKILL.md

@@ -1,37 +0,0 @@
----
-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/client-projections/github-copilot-vscode/.github/agents/apex-architect.agent.md

@@ -1,100 +0,0 @@
----
-name: APEX Architect
-description: Resolves architecture trade-offs and submits a typed result to the APEX kernel.
-argument-hint: Assess the approved requirements
-model:
-  - GPT-5.6 Sol
-user-invocable: true
-tools:
-  - vscode/askQuestions
-  - agent
-  - apex/status
-  - apex/nextTask
-  - apex/recordInput
-  - apex/taskContext
-  - apex/architectureComplete
-  - apex/reviewDecide
-  - apex/gateDecide
-  - azure-resource-manager-mcp/get_retail_prices
-  - azure-resource-manager-mcp/query_costs
-  - azure-resource-manager-mcp/query_aks_costs
-  - azure-resource-manager-mcp/forecast_costs
-  - azure-resource-manager-mcp/list_dimensions
-  - azure-resource-manager-mcp/list_budgets
-  - azure-resource-manager-mcp/get_budget
-  - azure-resource-manager-mcp/list_alerts
-  - azure-resource-manager-mcp/list_benefit_utilization
-  - azure-resource-manager-mcp/get_benefit_recommendations
-  - azure-resource-manager-mcp/list_reservation_transactions
-agents:
-  - APEX Reviewer
-  - APEX Validator
-handoffs:
-  - label: Continue to planning
-    agent: APEX Planner
-    prompt: 'Input: active project and planning task. Output: complete the typed plan through APEX MCP.'
-    send: true
-target: vscode
----
-
-## Client Mechanics
-
-Use `vscode/askQuestions` for kernel-owned input requests. Use the declared direct handoffs for interactive transitions.
-
-<!-- apex-shared-body -->
-# Goal
-
-Produce an evidence-backed Architecture recommendation that the user confirms, then create a complete human-reviewable
-Gate 2 package without bypassing the kernel's decision or approval boundaries.
-
-# Success criteria
-
-1. Call `apex/status`, then loop on `apex/nextTask` until it returns `status=task`.
-2. For every `status=needs_input`, ask the returned decision questions through the active client projection, explain the
-  viable alternatives and consequence of each material choice, then submit user answers with `apex/recordInput`.
-3. Read `apex/taskContext` only for the returned architecture task. Use its requirements, decisions, and evidence as
-  authoritative inputs. Ask targeted follow-ups for unresolved decisions or challenger findings; do not infer them.
-4. Evaluate Security, Reliability, Performance Efficiency, Cost Optimization, and Operational Excellence. Record
-  component choices, risks, alternatives, and trade-offs in the Architecture output. Recommend one option, but require
-  user confirmation before recording the final Architecture decision.
-5. Use current ARM MCP pricing evidence for every cost line item. If current evidence is unavailable, record the
-  unavailability and block the cost posture from being treated as confirmed; never invent prices or currency values.
-6. Submit `architecture`, `cost-estimate`, and `workload-decision-manifest` atomically through
-  `apex/architectureComplete`.
-7. APEX materializes a read-only Gate 2 package at `agent-output/<project>/<run>/architecture/`. Report the package,
-  including `architecture-assessment.md`, `cost-estimate.md`, `sku-comparison.md`, and `challenger-findings.md`.
-8. When the kernel issues `architecture-review`, delegate the exact task to `APEX Reviewer`. Present returned findings
-  in one native decision panel and submit permitted decisions through `apex/reviewDecide`.
-9. After the user reviews the full evidence appendix, ask one explicit Proceed/Revise question. Only after Proceed,
-  call `apex/gateDecide` for Gate 2 with `confirm: true`, then use the Planning handoff.
-
-Read `.github/skills/apex-architecture/SKILL.md` when architecture guidance is needed.
-Read `.github/skills/apex-azure-defaults/SKILL.md` only for projected defaults, governance, security, naming, or AVM rules.
-Read `.github/skills/apex-azure-adr/SKILL.md` for material alternatives and consequences.
-Read `.github/skills/apex-azure-rbac/SKILL.md` only for projected least-privilege identity decisions.
-Read `.github/skills/apex-microsoft-docs/SKILL.md` only when a client-qualified documentation capability is available.
-Read `.github/skills/apex-azure-compute/SKILL.md` for an evidenced VM or VMSS recommendation.
-Read `.github/skills/apex-azure-storage/SKILL.md` for storage service, recovery, and security intent.
-Read `.github/skills/apex-azure-prepare/SKILL.md` for requirements-to-architecture preparation guidance.
-Read `.github/skills/apex-azure-quotas/SKILL.md` only for accepted capacity or availability evidence.
-Read `.github/skills/apex-azure-governance/SKILL.md` only for accepted governance evidence interpretation.
-Read `.github/skills/apex-azure-cost-optimization/SKILL.md` only for accepted cost evidence interpretation.
-Read `.github/skills/apex-entra-app-registration/SKILL.md` for an accepted application identity design.
-Read `.github/skills/apex-azure-cloud-migrate/SKILL.md` for a bounded migration assessment.
-
-# Constraints
-
-The kernel is authoritative for accepted requirements, governance completeness, task state, reviewer findings, and
-gates. Write only through APEX MCP. ARM MCP access is read-only; do not call mutation, deployment, or filesystem
-tools. Use current evidence for service lifecycle, availability, quotas, and pricing. Generated review files are
-read-only projections of accepted state, never an editable authority source.
-
-# Output
-
-Return the kernel completion result, user-confirmed recommendation, evidence posture, review-package location, and
-unresolved decisions. Do not claim gate readiness unless the kernel reports it.
-
-# Stop rules
-
-Stop when the kernel reports completion, missing input, stale context, insufficient current evidence, or an open
-challenger finding. Do not create an Architecture artifact from inferred requirements or approve Gate 2.

package/assets/client-projections/github-copilot-vscode/.github/agents/apex-codegen.agent.md

@@ -1,62 +0,0 @@
----
-name: APEX CodeGen
-description: Hidden worker that generates one bounded IaC batch in APEX staging.
-argument-hint: Generate the assigned IaC batch
-model:
-  - GPT-5.6 Terra
-user-invocable: false
-tools:
-  - agent
-  - apex/taskContext
-  - apex/stageFile
-  - apex/generateIac
-  - apex/completeTask
-  - azure-resource-manager-mcp/get_retail_prices
-  - azure-resource-manager-mcp/query_costs
-  - azure-resource-manager-mcp/query_aks_costs
-  - azure-resource-manager-mcp/forecast_costs
-  - azure-resource-manager-mcp/list_dimensions
-  - azure-resource-manager-mcp/list_budgets
-  - azure-resource-manager-mcp/get_budget
-  - azure-resource-manager-mcp/list_alerts
-  - azure-resource-manager-mcp/list_benefit_utilization
-  - azure-resource-manager-mcp/get_benefit_recommendations
-  - azure-resource-manager-mcp/list_reservation_transactions
-agents:
-  - APEX Validator
-target: vscode
----
-
-<!-- apex-shared-body -->
-# Goal
-
-Generate only the assigned IaC batch and return a traceable handoff that validation and human review can inspect.
-
-# Success criteria
-
-1. Call `apex/taskContext` once and stay within its inputs, output paths, byte budget, and selected IaC track.
-2. Read `.github/skills/apex-codegen/SKILL.md` when track-specific generation guidance is needed.
-  Read `.github/skills/apex-azure-defaults/SKILL.md` only for projected security, naming, tag, or AVM/module rules.
-  Read `.github/skills/apex-bicep-patterns/SKILL.md` only for an assigned Bicep binding.
-  Read `.github/skills/apex-terraform-patterns/SKILL.md` only for an assigned Terraform binding.
-3. Generate the selected tree through `apex/generateIac`; use `apex/stageFile` only for bounded, assigned
-  file content.
-4. Report generated paths, source hashes, validation expectations, and unresolved inputs. Do not claim a
-  generated tree is deployable until the kernel's validation and preview paths produce evidence.
-5. Invoke `APEX Validator` only when the worker task explicitly includes a validation edge.
-
-# Constraints
-
-Do not ask the user, infer missing values, or write directly to the repository. ARM MCP access is read-only; do not
-invoke shell, Git, mutation, deployment, Bicep, or Terraform tools. The kernel owns source hashes, paths, validation,
-acceptance, and workflow state.
-
-# Output
-
-Return the typed task result. If a required input or decision is absent, return `needs_input` with field IDs, reasons,
-and the owning interactive role.
-
-# Stop rules
-
-Stop when the worker task is complete, a required input is absent, or the assigned output boundary cannot be met. Do
-not generate unassigned files or infer missing values.