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

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

@@ -1,49 +0,0 @@
----
-name: apex-azure-validate
-description: "Assess APEX Azure preflight evidence. Use for freshness, acceptance criteria, readiness blockers, and validated handoff decisions."
-user-invocable: false
----
-
-# APEX Azure Validation
-
-Use this skill only for an active validation task. It evaluates the kernel-projected preparation artifacts and evidence
-against acceptance criteria; it does not execute checks independently or change lifecycle state.
-
-## Prerequisites
-
-- `apex/taskContext` identifies the validation scope, target, required evidence, freshness policy, and acceptance
-  criteria.
-- Required preparation artifacts and the selected IaC binding are accepted by the kernel.
-- The task envelope supplies the authorized validation capability or evidence results. Missing or stale evidence is a
-  blocker, not an invitation to re-create it from local files, chat history, or model memory.
-
-## Workflow
-
-1. Confirm that each required preparation output is present, accepted, and traceable to the active run and target.
-2. Evaluate evidence freshness using the policy and timestamps projected by the kernel. Report expired, mismatched,
-   incomplete, or indeterminate evidence exactly as returned.
-3. Compare the authorized validation results with the task's functional, security, governance, build, and deployment
-   acceptance criteria. Keep a failed check distinct from an unavailable check.
-4. Return the kernel-provided validation result and unresolved criteria. When remediation changes intent or bindings,
-   route back to the owning preparation task rather than editing artifacts directly.
-5. Hand off only an accepted validation result to the next kernel-selected lifecycle task.
-
-## Boundaries
-
-- Do not run previews, builds, linters, IaC validators, authentication checks, or Azure queries directly.
-- Do not amend validation proof, bypass a failed criterion, or set a plan to validated.
-- Do not deploy or imply that passing a partial check authorizes deployment.
-- Transform a request to run a preflight command into a request for the trusted validation capability's evidence. The
-  capability and kernel, not this skill, decide whether it can refresh evidence or advance state.
-
-## References
-
-- [Preflight evidence model](references/preflight-evidence.md) - freshness, acceptance outcomes, and remediation
-  routing.
-- [Operational checklist](references/operational-checklist.md) -
-  generated-tree validation, acceptance coverage, and failed-check routing.
-
-## Output
-
-Return the validation state, acceptance-criterion outcomes, evidence references, blockers, and the kernel-provided next
-action. Use `indeterminate` when provided evidence cannot establish readiness.

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

@@ -1,24 +0,0 @@
-# Validation Operational Checklist
-
-## Preconditions
-
-- Confirm accepted preparation artifacts, selected IaC binding, target, and
-  acceptance criteria belong to the active run before reading validation proof.
-- Use only kernel-projected or trusted capability evidence. A local file,
-  remembered command result, or chat statement cannot replace accepted proof.
-- Keep unavailable, failed, incomplete, stale, and scope-mismatched checks
-  distinct; none may be restated as a passed criterion.
-
-## Coverage
-
-- Evaluate generated-tree validation, build, security, governance, functional,
-  and deployment-readiness criteria against their declared evidence scope.
-- Require each accepted result to identify its target, artifact revision,
-  observation time, outcome, and remaining limits.
-- When a failure changes intent, inputs, or IaC bindings, route it to the
-  owning preparation task and require renewed validation evidence.
-
-## Handoff
-
-Only a complete accepted validation result may advance to the kernel-selected
-next task. This skill neither changes lifecycle state nor invokes deployment.

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

@@ -1,43 +0,0 @@
-# Preflight Evidence Model
-
-## Evidence Requirements
-
-Preflight is a claim about a specific run, target, binding, and artifact revision. Valid evidence identifies:
-
-- The active run and target environment.
-- The accepted preparation and binding artifacts being evaluated.
-- The validator or trusted capability that produced the result.
-- The observation time and kernel-defined freshness result.
-- The acceptance criterion, outcome, and any supporting diagnostic reference.
-
-Evidence that lacks a target, artifact revision, freshness result, or producing authority is incomplete. Treat it as a
-blocker rather than estimating its validity from source files or earlier chat output.
-
-## Outcome Semantics
-
-| Outcome | Meaning | Lifecycle Treatment |
-| --- | --- | --- |
-| Pass | Current evidence meets the named criterion | Retain the evidence reference |
-| Fail | Current evidence disproves the criterion | Route to the task that owns remediation |
-| Blocked | Required input, authority, or evidence is absent | Request or await the missing dependency |
-| Indeterminate | Evidence cannot establish an outcome | Do not advance readiness |
-| Stale | Evidence exceeds the kernel-defined freshness policy | Request trusted evidence refresh |
-
-## Acceptance Criteria
-
-Acceptance criteria should be explicit, scoped, and independently checkable. They may cover artifact integrity, binding
-consistency, policy obligations, security controls, build readiness, prerequisite availability, preview readiness, and
-verification obligations. A pass for one criterion does not silently satisfy another.
-
-## Remediation Routing
-
-Return each non-pass outcome to its owner: requirements for an unresolved desired outcome, architecture for a decision,
-planning or binding for implementation intent, CodeGen for an authorized generation batch, or a trusted validation
-capability for refreshed observations. Validation never rewrites evidence it is evaluating.
-
-## Region, Global, And Error Semantics
-
-Evaluate a region or global prerequisite only from evidence bound to the selected target, service, binding revision, and
-freshness policy. Preserve authorization, environment, compiler, provider, and policy failures as distinct outcomes;
-an unavailable check is not a failed check. Policy discovery, CLI authentication, previews, and recipe command execution
-remain deferred trusted capabilities, so this skill records their evidence and routes errors without executing them.

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

@@ -1,41 +0,0 @@
----
-name: apex-bicep-patterns
-description: "Apply approved Bicep architecture patterns to APEX implementation intent. Use for AVM composition, private endpoints, networking, diagnostics, and CodeGen acceptance."
----
-
-# APEX Bicep Patterns
-
-Use this skill for an active Bicep-bound planning or CodeGen task. It describes approved intent and acceptance criteria;
-CodeGen and validators own generated files and command execution.
-
-## Prerequisites
-
-- `apex/taskContext` identifies an accepted Bicep track task and its typed binding inputs.
-- Requirements, governance, security, and architecture decisions are current.
-
-## Workflow
-
-1. Select only patterns supported by the accepted architecture and track binding.
-2. Apply [Network and observability](references/network-and-observability.md) to private connectivity and diagnostics.
-3. Read [Module interfaces and parameters](references/module-interfaces-and-parameters.md) when creating reusable
-   modules or binding environment-specific inputs.
-4. Read [Compiler and provider gotchas](references/compiler-and-provider-gotchas.md) before accepting module bindings.
-5. Apply [AVM and CodeGen acceptance](references/avm-and-codegen-acceptance.md) to module decisions and validation intent.
-6. Verify the generated intent against the [CodeGen acceptance checklist](references/codegen-acceptance-checklist.md).
-7. Stage only typed intent through APEX MCP; return unavailable modules or stale evidence as blockers.
-
-## Boundaries
-
-- This skill does not write Bicep, resolve module versions, invoke Bicep, or perform deployment commands.
-- CodeGen owns generated IaC; validators own build, lint, security, and preview receipts.
-- Module choice does not bypass policy, cost, approval, or deployment evidence.
-
-## References
-
-- [Network and observability](references/network-and-observability.md) - hub-spoke, private endpoints, and diagnostics.
-- [Module interfaces and parameters](references/module-interfaces-and-parameters.md) - stable composition contracts and
-  environment-neutral input binding.
-- [Compiler and provider gotchas](references/compiler-and-provider-gotchas.md) - exact-schema, language, identity, SKU,
-  query, and service-topology failure rules.
-- [CodeGen acceptance checklist](references/codegen-acceptance-checklist.md) - final intent and evidence review loop.
-- [AVM and CodeGen acceptance](references/avm-and-codegen-acceptance.md) - module binding and validation intent.

package/assets/client-projections/github-copilot-vscode/.github/skills/apex-bicep-patterns/references/avm-and-codegen-acceptance.md

@@ -1,11 +0,0 @@
-# AVM And CodeGen Acceptance
-
-Prefer Azure Verified Modules when the selected Bicep binding can meet accepted requirements. Record the module family,
-version-resolution evidence, required inputs, identity, network, diagnostics, tags, and outputs as typed constraints.
-
-An AVM module is not automatically compliant. CodeGen must bind the selected version and interface; validation must
-confirm syntax, lint, security baseline, policy-compatible settings, and preview results. When a module cannot express a
-requirement, record the exception, alternative implementation, rationale, and traceability before generation.
-
-Use explicit parameters for environment-specific values and avoid secret literals. Preserve stable resource identity and
-outputs needed by dependent bindings. What-if review is a required pre-deployment receipt, not an informal observation.

package/assets/client-projections/github-copilot-vscode/.github/skills/apex-bicep-patterns/references/codegen-acceptance-checklist.md

@@ -1,46 +0,0 @@
-# CodeGen Acceptance Checklist
-
-Use this checklist after Bicep generation and before accepting validator or preview evidence.
-
-## Intent And Governance
-
-- [ ] Every generated resource traces to accepted requirements and architecture intent.
-- [ ] Applicable policy effects map to generated properties or an explicit blocker.
-- [ ] Environment-specific values come from the accepted environment input contract.
-- [ ] No secret, placeholder identifier, recipient, subscription, tenant, or principal is embedded in source.
-
-## Modules And Composition
-
-- [ ] AVM is used when the selected module can satisfy the accepted intent.
-- [ ] Every module version has authorized resolution evidence and its exact schema was inspected.
-- [ ] Module inputs and outputs follow the accepted interface and match the exact selected schema.
-- [ ] Resource names satisfy service constraints without changing stable identity unexpectedly.
-- [ ] Optional modules guard dependent outputs and resources consistently.
-- [ ] Existing resource references have explicit dependencies when their targets are created in the same deployment.
-
-## Security And Identity
-
-- [ ] HTTPS, transport security, identity, network access, and data-access settings match the accepted baseline.
-- [ ] Role assignments use the narrowest accepted scope and the intended principal type.
-- [ ] Runtime identities are not promoted to data-plane administrators.
-- [ ] Public access or credential-based exceptions have accepted, current dispositions.
-
-## Network And Operations
-
-- [ ] Address spaces and service CIDRs do not overlap.
-- [ ] Private endpoint bindings include the correct subresource, subnet, DNS zone, VNet link ownership, and zone group.
-- [ ] Diagnostics target the accepted monitoring destination and include supported log and metric categories.
-- [ ] SKU-sensitive properties are compatible with the selected tier in the rendered template.
-- [ ] Query-based alert text is valid for the target table schema.
-- [ ] Post-deployment requirements are recorded rather than represented as unsupported resource properties.
-
-## Validation Loop
-
-- [ ] Formatting, build, lint, security, policy, and provider-readiness checks pass.
-- [ ] Preview contains no unexplained deletion, SKU downgrade, public-access change, authentication change, or identity
-      removal.
-- [ ] Generated parameters compile against the generated entrypoint.
-- [ ] Validation receipts bind the current source tree, module locks, target, inputs, and dependency revision.
-- [ ] Any correction was followed by a fresh full validation pass; stale receipts were not reused.
-
-Return a blocker with the failing checklist item and required owner when any mandatory item cannot be proven.

package/assets/client-projections/github-copilot-vscode/.github/skills/apex-bicep-patterns/references/compiler-and-provider-gotchas.md

@@ -1,74 +0,0 @@
-# Compiler And Provider Gotchas
-
-Read this reference before accepting a new AVM binding and when build, preview, and apply results disagree.
-
-## Exact Module Schema Wins
-
-AVM parameter names, nested object fields, required values, and outputs can change between module versions. Inspect the
-schema for the exact selected version before authoring its binding. Do not copy parameter shapes from model memory, an
-older project, or documentation for another version.
-
-Record the inspected inputs and outputs in validation evidence. If the exact schema cannot be inspected, return a
-blocker rather than guessing.
-
-AVM use also requires these checks:
-
-- pin the version selected by the authorized resolver
-- verify output names before creating downstream dependencies
-- confirm required policy tags survive any module-internal tag merge
-- verify diagnostics are emitted by the module or by an explicit companion binding
-- wrap a module to override incompatible defaults; record an exception before replacing AVM with a raw resource
-
-## Bicep Language Constraints
-
-- `utcNow()` is valid only as a parameter default. Do not use it in a variable or resource expression.
-- A child resource `parent` must be calculable at deployment start. A module output is not a static parent name; use a
-  parameter-derived existing resource and an explicit dependency when ordering is otherwise lost.
-- A subscription-scope module called from a resource-group deployment requires an explicit subscription scope.
-- An `existing` resource reference does not prove that its creating module has completed. Add an explicit dependency
-  when a child or extension resource targets something created in the same deployment.
-
-## Identity And RBAC
-
-Keep identity creation separate from target-resource authorization. Putting a target resource's role assignment inside
-the identity module can create a dependency cycle when each module needs the other's output. Place the assignment with
-the target resource and use the identity principal output as an input.
-
-A runtime managed identity is not a data-plane administrator. Use a dedicated administration principal for SQL or other
-data-plane administration, then grant the runtime identity only the application permissions it needs. Deploy-time
-principal IDs remain required environment inputs; CodeGen must not invent or bake them into parameter files.
-
-## Validation Green, Apply Red
-
-A successful build or preview does not prove resource-provider compatibility. Review the rendered resource properties
-when an AVM default may be SKU-dependent. Reject premium-only networking, zone, quarantine, trust, or data-endpoint
-properties on a lower tier unless the exact provider contract supports them.
-
-For scheduled query rules, validate KQL against the target table schema. Bicep treats the query as an opaque string and
-preview does not run the service query parser. Ingestion quota alert queries against `_LogOperation` must use that
-table's columns rather than fields copied from `AzureActivity`, `AzureDiagnostics`, or application tables.
-
-## Service Topology Traps
-
-- AKS egress mode must match the accepted topology: subnet NAT gateway, AKS-managed NAT gateway, explicit default route
-  to an operator-managed firewall, or load balancer are different designs. Fixed-size pools must not carry autoscaling
-  bounds, and a control-plane identity using an existing VNet needs the accepted network role assignment.
-- An Application Gateway backend pool may be empty until its real backend exists. Never use a loopback address as a
-  placeholder.
-- MySQL private endpoint and delegated-subnet injection are different, mutually exclusive topologies. A shared private
-  endpoint subnet is not a delegated MySQL subnet. Treat read-only authentication settings and other post-deployment
-  operations as deployment tasks, not writable Bicep properties.
-- A database major-version upgrade is an isolated lifecycle operation. Do not combine it with unrelated property
-  changes. Resolve supported versions from current service evidence rather than retaining a version literal here.
-- Subscription-scoped cost alerts require a scope-compatible view and module scope.
-- Automation schedules cannot attach to an unpublished runbook. Keep publish-and-link work as an explicit
-  post-deployment task when the resource provider requires it.
-
-## Repair Loop
-
-1. Classify the failure as Bicep language, exact module schema, rendered-template, or provider apply-time behavior.
-2. Check the exact selected schema and accepted architecture/SKU evidence.
-3. Correct the typed binding or record an explicit module exception; do not add a speculative property.
-4. Re-run the owning build, lint, security, policy, and preview validators.
-5. Proceed only when the new receipts are current; an apply-only limitation remains a documented deployment risk or
-   blocker.

package/assets/client-projections/github-copilot-vscode/.github/skills/apex-bicep-patterns/references/module-interfaces-and-parameters.md

@@ -1,56 +0,0 @@
-# Module Interfaces And Parameters
-
-Read this reference when a Bicep binding introduces a reusable module or environment-specific inputs.
-
-## Stable Module Interface
-
-Give reusable modules a predictable contract so composition, diagnostics, identity, and downstream dependencies do not
-rely on module-specific guesswork.
-
-Required inputs normally include:
-
-- `name`
-- `location`
-- `tags`
-- the accepted monitoring workspace binding when the resource supports diagnostics
-
-Required outputs normally include:
-
-- `resourceId`
-- `resourceName`
-- `principalId` when managed identity is supported
-
-When a resource has no managed identity, expose an explicitly optional or empty principal value according to the typed
-binding contract. Do not invent an identity merely to satisfy a uniform output shape.
-
-Add service-specific inputs and outputs only when a downstream binding needs them. Keep secrets out of outputs, and do
-not leak generated credentials through module composition.
-
-## Environment Inputs
-
-Keep the generated Bicep tree environment-neutral. Environment-specific subscription IDs, tenant IDs, object IDs,
-notification recipients, budget values, and existing-resource bindings must come from the accepted environment input
-contract rather than literals or environment branches in `main.bicep`.
-
-Use `.bicepparam` files as generated binding surfaces when the selected toolchain supports them. Each parameter must map
-to an accepted typed input. Values resolved at deployment time remain unresolved in source; CodeGen must not fabricate a
-placeholder GUID, address, secret, or recipient.
-
-Reject these patterns:
-
-- project-specific GUIDs or subscription IDs embedded in Bicep or parameter files
-- secret defaults
-- production and non-production identifiers selected by conditional literals in `main.bicep`
-- parameters that are not present in the accepted IaC binding contract
-- environment input names that are silently renamed between planning, CodeGen, and deployment
-
-## Acceptance Check
-
-Before staging CodeGen intent, verify:
-
-- every module input traces to accepted architecture, governance, defaults, or environment intent
-- every output has a known consumer or documented compatibility purpose
-- required monitoring and identity bindings are explicit
-- environment-specific values remain external to the generated source tree
-- parameter names and types match the selected module interface
-- missing deploy-time values return a blocker instead of a generated placeholder

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

@@ -1,52 +0,0 @@
-# Network And Observability
-
-Read this reference when a Bicep binding includes hub-spoke networking, private connectivity, or resource diagnostics.
-
-## Hub-Spoke Composition
-
-Use hub-spoke topology only when shared connectivity, inspection, DNS, or platform services are accepted architectural
-requirements. Bind peering, routing, subnet, and network-security intent explicitly; do not imply those choices from a
-resource name or a module default.
-
-The hub owns accepted shared services. Spokes peer to the hub and do not peer directly unless the architecture records
-a specific exception. Pass the hub resource ID through module outputs rather than reconstructing it. Apply network
-security at the subnet boundary, and verify address spaces and service CIDRs do not overlap before generation.
-
-## Private Endpoint And DNS
-
-Private endpoint intent includes the target subresource, approved subnet, private DNS zone, and DNS zone group. A
-private endpoint without its DNS and network dependencies is incomplete. Public access exceptions require an accepted
-risk and policy-compatible boundary.
-
-When shared private DNS is not provided by the platform, the owning binding must create the zone, link it to the
-accepted VNet, and pass the created zone resource ID to the endpoint. Do not construct an ID for a zone that no binding
-creates or accepts as existing evidence.
-
-Common service subresources and zones include:
-
-| Service | Subresource | Private DNS zone |
-| --- | --- | --- |
-| Blob storage | `blob` | `privatelink.blob.core.windows.net` |
-| Table storage | `table` | `privatelink.table.core.windows.net` |
-| Key Vault | `vault` | `privatelink.vaultcore.azure.net` |
-| Azure SQL | `sqlServer` | `privatelink.database.windows.net` |
-| Cosmos DB for NoSQL | `Sql` | `privatelink.documents.azure.com` |
-| App Service | `sites` | `privatelink.azurewebsites.net` |
-| Event Hubs | `namespace` | `privatelink.servicebus.windows.net` |
-| Container Registry | `registry` | `privatelink.azurecr.io` |
-
-Treat this table as a pattern aid, not live service-availability evidence. Confirm the exact target resource contract
-when accepting a binding.
-
-## Diagnostics And Dependencies
-
-Every governed resource should have diagnostics and metrics mapped to the accepted monitoring destination. Category
-selection, retention, cost, and ownership remain typed planning decisions; generated settings and deployment success
-require validator and operation receipts.
-
-Prefer supported category groups when they satisfy the accepted requirement; otherwise bind explicit categories from
-current provider evidence. Include metrics only when the resource supports them.
-
-An `existing` resource reference does not create an implicit dependency on a module that creates that resource in the
-same deployment. Extension resources such as diagnostics and private DNS zone groups need explicit ordering when their
-parent is created by another module.

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

@@ -1,32 +0,0 @@
----
-name: apex-codegen
-description: "Provides hidden-worker guidance for one bounded APEX IaC generation task with approved intent and binding."
-user-invocable: false
----
-
-## APEX Code Generation
-
-Use this skill only inside the hidden CodeGen worker.
-
-## Prerequisites
-
-- `apex/taskContext` supplies approved intent, one selected-track binding, policy obligations, output paths, and limits.
-- The task identifies a single dependency-sized generation batch.
-
-## Workflow
-
-1. Call `apex/generateIac` once for the issued task ID, accepted intent, and selected-track binding.
-2. Preserve exact module, provider, API, security, naming, ownership, and environment-input obligations.
-3. Keep secret values out of generated content; use only typed references supplied by the kernel. Use `apex/stageFile`
-   only for additional assigned files before completion.
-4. Complete the issued task with the generated output. After completion, return the kernel receipt and perform no
-   follow-up staging, generation, validation, delegation, or repository work.
-5. Return `needs_input` when a required binding or value is absent.
-
-## Boundaries
-
-Do not execute, format, validate, preview, deploy, write directly to repository paths, or delegate work.
-
-## Output
-
-Return the typed completion or `needs_input` result with affected field IDs.

package/assets/client-projections/github-copilot-vscode/.github/skills/apex-entra-app-registration/SKILL.md

@@ -1,53 +0,0 @@
----
-name: apex-entra-app-registration
-description: "Model Microsoft Entra application registration and OAuth design intent in APEX. Use for application type, flow, API permission, redirect URI, credential, and consent trade-offs."
-user-invocable: false
----
-
-# APEX Entra App Registration Guidance
-
-Use this skill only for an active architecture, planning, or approved implementation-binding task. The kernel owns
-task state, evidence freshness, authorization, artifact acceptance, and all state-changing work.
-
-## Prerequisites
-
-- `apex/taskContext` identifies the active task, allowed outputs, applicable requirements, and evidence references.
-- The workload purpose, client type, tenant boundary, target APIs, and user-interaction model are known; otherwise
-  return `needs_input`.
-- An identity operation is available only through a kernel-authorized capability. A request alone is not authority to
-  create or alter an application registration.
-
-## Workflow
-
-1. Model the application type, audience, tenant model, redirect-URI class, and OAuth interaction.
-   Record the selected flow and rationale without protocol requests or application configuration.
-2. Map each business operation to the minimum delegated or application permission requirement.
-   Record consent ownership, scope, and unresolved permission evidence; do not infer or approve consent.
-3. Select a credential posture: public clients hold no credential; Azure-hosted workloads prefer managed identity.
-   Confidential workloads prefer federation or certificates over secrets; record lifecycle ownership, never a value.
-4. Submit typed identity intent only through the kernel-authorized capability named in the task envelope.
-   Preserve its receipt or blocker in the architecture, plan, or binding artifact.
-5. Handoff approved identity intent to the authorized implementation, validation, or operations capability.
-   Do not claim that registration, permissions, credentials, or consent exist without an accepted receipt.
-6. Classify observed identity failures with [Identity design and diagnostic rules](references/design-and-diagnostics.md).
-   Return the responsible owner and evidence gap without attempting remediation.
-
-## Boundaries
-
-Do not use portal, CLI, Microsoft Graph, SDK, HTTP, IaC, repository, source-scanning, or file-mutation actions. Do
-not create registrations, configure redirect URIs, grant consent, assign permissions, create or handle credentials,
-expose identifiers or secret material, test authentication, or deploy. Direct operational requests must be converted
-into bounded intent and an authorized capability handoff.
-
-## References
-
-- [OAuth and registration model](references/oauth-registration-model.md) - client, audience, flow, and redirect-URI decisions.
-- [Permissions and credential posture](references/permissions-and-credentials.md) - least privilege and credential trade-offs.
-- [Capability receipt and handoff](references/capability-receipts.md) - required evidence, blockers, and next-task rules.
-- [Identity design and diagnostic rules](references/design-and-diagnostics.md) - source-derived flow, permission, and
-   troubleshooting rules without configuration or protocol operations.
-
-## Output
-
-Return typed identity design intent, requirement traces, authorized capability receipt references, explicit blockers,
-and the next kernel-controlled task.

package/assets/client-projections/github-copilot-vscode/.github/skills/apex-entra-app-registration/references/capability-receipts.md

@@ -1,21 +0,0 @@
-# Capability Receipts And Handoff
-
-An identity decision becomes operational only after an authorized capability returns an accepted receipt. Intent is not
-evidence that an application registration, permission, consent, redirect URI, or credential exists.
-
-## Required Intent Fields
-
-- Requirement references and active task identifier.
-- Application, tenant, audience, flow, and redirect-URI design intent.
-- Permission and consent intent, including the unresolved items.
-- Credential posture, lifecycle owner, and validation obligation.
-
-## Receipt Rules
-
-Preserve the capability name, receipt identifier, status, evidence reference, and any explicit blocker. A missing,
-stale, rejected, or incomplete receipt blocks downstream claims and requires kernel-directed recovery.
-
-## Handoff
-
-Route accepted intent to the task-envelope capability for implementation, then to the authorized validation or operations
-capability. Return the next task and blocker state; do not perform or simulate the handoff.

package/assets/client-projections/github-copilot-vscode/.github/skills/apex-entra-app-registration/references/design-and-diagnostics.md

@@ -1,36 +0,0 @@
-# Identity Design And Diagnostic Rules
-
-Use this reference to model identity intent and classify observed failures. It does not create registrations, issue
-tokens, call Microsoft Graph, grant consent, or handle credentials.
-
-## Flow And Registration Intent
-
-Record workload purpose, client class, interactive-user model, tenant boundary, API audience, redirect-URI class, and
-the owning application before implementation begins. Use authorization code for web applications, authorization code
-with PKCE for SPA or mobile public clients, device code only for supported browserless user interaction, and client
-credentials for service-to-service workloads. Treat the selection as design intent, not a configured flow.
-
-Redirect URIs must be an exact registered match and belong to the correct client platform. Unknown callback locations,
-tenant model, or audience block implementation intent rather than being filled with placeholders.
-
-## Permission And Credential Intent
-
-Map each accepted business operation to its minimum required permission and target resource. Model delegated access
-when the operation acts for a signed-in user and application access for a background workload without a user. Record
-the consent owner and evidence; application permissions and privileged delegated permissions require an explicit
-consent decision and must never be inferred as granted.
-
-Public clients have no client credential. Prefer managed identity for supported Azure-hosted workloads and federation
-or certificates for external confidential workloads. A secret-only design needs an explicit exception, lifecycle owner,
-and replacement plan. Record credential type and rotation requirement, never credential material or identifiers.
-
-## Diagnostic Classification
-
-Classify a redirect mismatch by comparing the exact requested URI, registered URI, and platform class. Classify consent
-or insufficient-privilege failures by checking the requested permission type, consent owner, target resource, and
-accepted configuration evidence. Classify invalid-client or expired-credential failures as a credential-lifecycle
-blocker. Classify application-not-found or tenant failures as an identity-boundary mismatch. Do not expose tokens or
-use diagnostic observations as authority to change an application registration.
-
-Return the evidence gap, responsible owner, and required kernel-authorized next task. Direct configuration, consent,
-credential, SDK, CLI, IaC, and HTTP remediation stays outside this skill.

package/assets/client-projections/github-copilot-vscode/.github/skills/apex-entra-app-registration/references/oauth-registration-model.md

@@ -1,26 +0,0 @@
-# OAuth And Registration Model
-
-Model identity before requesting an implementation capability. The design artifact must identify the workload purpose,
-client class, users or services that authenticate, target API audience, tenant boundary, and redirect-URI class.
-
-## Flow Selection
-
-| Workload | Default intent | Constraints to record |
-| --- | --- | --- |
-| Web app | Authorization code | Redirect URI ownership and session boundary |
-| SPA or mobile app | Authorization code with PKCE | Public-client posture and redirect URI class |
-| Browserless user workflow | Device code only when interaction is supported | User consent and device interaction boundary |
-| Service-to-service | Client credentials | Application permission and workload identity posture |
-
-Do not describe token requests, generate protocol values, or claim that a flow is configured. The selected flow is a
-traceable design choice that an authorized capability may later implement and validate.
-
-## Redirect URI Intent
-
-Record the owning application, URI class, environment boundary, and exact-match requirement. Unknown redirect URIs
-block implementation intent; do not substitute placeholders or broaden accepted callback locations.
-
-## Tenant And Audience
-
-Record whether the application is single-tenant, multi-tenant, or otherwise restricted, and name the intended API
-audience. Treat both as user-owned decisions when requirements lack evidence.

package/assets/client-projections/github-copilot-vscode/.github/skills/apex-entra-app-registration/references/permissions-and-credentials.md

@@ -1,27 +0,0 @@
-# Permissions And Credentials
-
-## Permission Intent
-
-Map each accepted operation to one minimum API permission requirement. Specify whether the operation acts for a signed-in
-user (delegated) or without a user (application), the target resource, consent owner, and evidence for necessity.
-
-| Condition | Decision |
-| --- | --- |
-| User-context operation | Model delegated permission intent |
-| Background workload operation | Model application permission intent |
-| Permission necessity is unknown | Return `needs_input` or a blocker |
-| Consent authority is absent | Preserve a consent blocker |
-
-Never infer elevated permissions, grant consent, or treat requested permissions as approved access.
-
-## Credential Posture
-
-| Client or hosting model | Preferred posture |
-| --- | --- |
-| Public client | No client credential |
-| Azure-hosted workload | Managed identity when the target supports it |
-| External confidential workload | Federated identity credential or certificate |
-| Secret-only integration | Explicit exception, lifecycle owner, and replacement plan |
-
-Do not create, retrieve, transmit, store, rotate, or reveal secret material. Record only credential type, owner,
-validity or rotation requirement, and the capability receipt needed to establish it.