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

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

@@ -1,42 +0,0 @@
-# Requirements: {workload}
-
-> Derived from accepted APEX requirements artifact `{artifact-hash}` using template `{template-hash}`.
-
-## Project Overview
-
-- Environment: {environment}
-- Status: {artifact-status}
-- Business context: {business-context}
-- Success criteria: {success-criteria}
-
-## Functional Requirements
-
-{requirements-table}
-
-## Non-Functional Requirements
-
-{nfr-table}
-
-## Security And Compliance
-
-{security-and-compliance-table}
-
-## Budget And Operations
-
-{budget-and-operations}
-
-## Regional And Residency Constraints
-
-{regional-constraints}
-
-## Assumptions
-
-{assumptions-list}
-
-## Unknowns And Deferrals
-
-{unknowns-list}
-
-## Architecture Handoff
-
-{architecture-handoff}

package/assets/client-projections/github-copilot-vscode/.github/skills/apex-artifacts/templates/resource-inventory.md

@@ -1,29 +0,0 @@
-## {artifact-title}
-
-> Reference-only outline: no active renderer binding is declared for this template.
->
-> Presentation receipt: artifact `{artifact-identifier}`; template `{template-identifier}`.
-
-## Inventory Summary
-
-{inventory-summary-by-category}
-
-## Resource Listing
-
-{resource-listing-with-type-sku-location-purpose-and-status}
-
-## Identity Network And Dependency Context
-
-{identity-network-and-dependency-context}
-
-## Cost And Operational Context
-
-{accepted-cost-monitoring-backup-and-ownership-context}
-
-## Coverage Gaps And Deferrals
-
-{coverage-gaps-and-deferrals}
-
-## References
-
-{references}

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

@@ -1,52 +0,0 @@
----
-name: apex-azure-adr
-description: "Records bounded Azure architecture decisions. Use for ADR rationale, alternatives, WAF and compliance consequences, implementation constraints, supersession, and revisit criteria."
-user-invocable: false
----
-
-# APEX Azure Architecture Decisions
-
-Use this skill only for an active architecture or planning task. The kernel-owned architecture artifact, recorded
-architecture decisions, requirements, and governance evidence are authoritative.
-
-## Prerequisites
-
-- A material decision question and affected requirement IDs are present in `apex/taskContext`.
-- Accepted governance, availability, cost, lifecycle, and technical evidence needed for comparison is available.
-- The kernel exposes the decision-recording capability when a new user-owned choice is required.
-
-Create a decision record for a material, cross-cutting, costly-to-reverse, compliance-relevant, or intentionally deferred
-choice. Do not create one for routine implementation detail already fixed by an accepted contract.
-
-## Decision Method
-
-1. Frame one bounded question and state why a decision is needed now.
-2. List the driving requirements, constraints, assumptions, stakeholders, and accepted evidence.
-3. Compare the selected option with viable alternatives against the same criteria.
-4. State the selected option precisely and record why each alternative was rejected.
-5. Record positive, negative, and neutral consequences, including WAF and compliance effects.
-6. Record implementation constraints, validation signals, reversal cost, and revisit triggers.
-7. Check the record with [decision quality](references/decision-quality.md); revise until it passes or return a blocker.
-
-Use kernel-projected lifecycle states. `Proposed`, `Accepted`, `Deprecated`, and `Superseded` describe recorded decision
-state, not an inferred workflow phase. A superseded decision must link to its replacement; do not rewrite history.
-
-## Boundaries
-
-Do not create ADR files, sequence document numbers, write Markdown, use shell or Git, query Azure directly, or alter
-architecture artifacts outside the authorized workflow.
-
-Do not invent mutable service facts, prices, versions, policy state, benchmark results, or implementation outcomes.
-Missing evidence or an unresolved user-owned trade-off is an explicit blocker.
-
-## References
-
-- Read [decision record fields](references/decision-record-fields.md) when constructing the typed rationale.
-- Read [decision quality](references/decision-quality.md) before returning a completed decision.
-- Read [decision guardrails](references/decision-guardrails.md) when alternatives or evidence are weak.
-- Read [decision examples](references/decision-examples.md) when a concrete decision shape is useful.
-
-## Output
-
-Return bounded architecture or plan decision guidance with rationale, alternatives, consequences, requirement
-traceability, accepted evidence references, implementation constraints, revisit triggers, and blockers.

package/assets/client-projections/github-copilot-vscode/.github/skills/apex-azure-adr/references/decision-examples.md

@@ -1,38 +0,0 @@
-# Decision Examples
-
-Use these as decision-shape examples, not as automatic service recommendations.
-
-| Area | Example trade-off |
-| --- | --- |
-| Compute | Container Apps versus App Service for an API with variable demand. |
-| Data | Azure SQL Database versus Cosmos DB for transactional consistency and scale. |
-| Networking | Private endpoints versus approved public access for a data service. |
-| Identity | Managed identity versus application credential for service-to-service access. |
-| Integration | Service Bus versus Event Grid for ordered, durable processing. |
-
-For each example, bind the final choice to projected requirements, cost/availability evidence, governance constraints,
-and any kernel-recorded user decision.
-
-## Example: Compute Hosting
-
-**Question**: Which managed host satisfies burst scaling, private data access, and the team's operating model?
-
-| Option | Fit | Trade-off | Evidence needed |
-| --- | --- | --- | --- |
-| Container Apps | Event-driven scaling and container portability | More platform concepts and network constraints | Scale, region, network, and price evidence |
-| App Service | Familiar managed web hosting | Scaling and container controls differ | Plan/SKU, region, network, and price evidence |
-
-The selected option must state the hosting posture and accepted SKU family, not merely the service name. Consequences
-should cover identity, ingress, diagnostics, scaling behavior, cost sensitivity, and migration effort.
-
-## Example: Data Access Posture
-
-**Question**: Should a production data service use private access or an approved public endpoint?
-
-| Option | Fit | Trade-off | Evidence needed |
-| --- | --- | --- | --- |
-| Private endpoint | Strong isolation and policy alignment | DNS, subnet capacity, routing, and added cost | Policy, topology, DNS, capacity, and price evidence |
-| Restricted public endpoint | Simpler connectivity when policy permits | Greater exposure and compensating controls | Policy, threat model, firewall, identity, and approval evidence |
-
-If accepted governance denies public access, the public option is not viable; record that constraint rather than
-pretending the alternatives are equally available.

package/assets/client-projections/github-copilot-vscode/.github/skills/apex-azure-adr/references/decision-guardrails.md

@@ -1,36 +0,0 @@
-# Decision Guardrails
-
-## Do
-
-- Keep one decision focused on one trade-off.
-- Compare viable alternatives honestly.
-- Record measurable consequences when evidence exists.
-- Trace the decision to requirements, governance, cost, availability, or recorded user choices.
-- Preserve the original record when deprecating or superseding it.
-- State what evidence or condition would cause the decision to be revisited.
-- Preserve unresolved information as a blocker, unknown, or deferred decision.
-
-## Do Not
-
-- Create or number ADR files.
-- Replace typed architecture decisions with Markdown as authority.
-- Use placeholder text, fabricated evidence, or generic implementation guidance.
-- Combine unrelated data, networking, identity, and deployment choices into one decision.
-- Present a predetermined selection with token alternatives that were never viable.
-- Treat a planned benchmark, migration, validation, or deployment as an observed result.
-- Copy prices, versions, service retirement dates, policy state, or availability claims from memory.
-- Perform Azure reads, writes, deployments, or role assignments directly.
-
-## Common Failures
-
-| Failure | Correction |
-| --- | --- |
-| Vague selected option | Name the service, posture, or constraint and its requirement traceability. |
-| Missing alternative | Record a viable option and why accepted evidence or constraints rejected it. |
-| False alternative | Remove the option or explain the mandatory constraint it violates. |
-| One-sided consequence | Include both benefits and costs, risks, or operational obligations. |
-| Missing WAF impact | State the relevant affected pillars and the resulting trade-off. |
-| Generic implementation note | Record typed module, identity, network, diagnostics, or recovery constraints. |
-| Outcome stated as intent | Label the item planned and name the future acceptance evidence. |
-| Stale decision | Preserve it as deprecated or superseded and link the accepted replacement. |
-| Multi-decision record | Split choices whose alternatives, owners, or reversal triggers differ. |

package/assets/client-projections/github-copilot-vscode/.github/skills/apex-azure-adr/references/decision-quality.md

@@ -1,21 +0,0 @@
-# Decision Quality Checklist
-
-Before completing an architecture or plan artifact, verify:
-
-- The decision identifier, lifecycle state, owner, and scope are present.
-- The decision addresses one bounded material trade-off.
-- Context separates the problem from the proposed solution.
-- Drivers name mandatory requirements, assumptions, and accepted evidence.
-- The selected option is precise, scoped, and unambiguous.
-- Viable alternatives are compared against the same criteria and have rejection rationales.
-- Positive, negative, and neutral consequences are honest and measurable where evidence permits.
-- Every WAF pillar is addressed or explicitly marked as having no material effect with rationale.
-- Compliance and governance implications use accepted constraints.
-- Implementation constraints are actionable through typed bindings without embedding execution steps.
-- Validation signals and revisit or supersession triggers are testable.
-- Reversal cost, residual risk, and decision ownership are visible.
-- Unknown and deferred values remain explicit.
-- The decision does not claim live state or results that are absent from task context.
-
-If a mandatory requirement has no supported option, evidence is stale or absent, or a user-owned trade-off remains
-unresolved, return a blocker instead of weakening the record.

package/assets/client-projections/github-copilot-vscode/.github/skills/apex-azure-adr/references/decision-record-fields.md

@@ -1,57 +0,0 @@
-# Architecture Decision Record Fields
-
-Use these fields in a typed architecture or planning decision. They are presentation and quality guidance; the accepted
-artifact schema remains authoritative.
-
-## Identity And Lifecycle
-
-Record the stable decision identifier, concise title, kernel-projected status, decision owner, deciders, decision time,
-and affected workload scope. When applicable, record `supersedes` or `superseded_by`; preserve the earlier rationale.
-
-## Context
-
-State the problem or opportunity, current state, desired outcome, constraints, assumptions, stakeholders, accepted
-evidence, affected requirement IDs, and why a decision is required now. Keep one material trade-off per decision.
-
-## Decision Drivers
-
-List measurable evaluation criteria such as availability, RTO/RPO, latency, consistency, residency, identity, network
-exposure, operability, migration effort, cost envelope, team capability, and reversibility. Mark mandatory constraints.
-
-## Selected Option
-
-State the selected option precisely. Tie it to an accepted requirement, a kernel-recorded user choice, or accepted
-evidence. Include scope and posture, not just a product name. Do not use vague statements such as "use a database".
-
-## Alternatives
-
-Record at least one viable alternative when the choice materially affects the workload. For each alternative, state its
-fit against the same drivers, benefits, drawbacks, evidence, rejection rationale, and affected WAF pillars. Do not pad
-the record with options that violate mandatory constraints unless the violation itself explains the rejection.
-
-## Consequences
-
-Record at least one positive and one negative consequence. Use measurable statements where evidence exists. Include
-neutral constraints, residual risks, migration effects, lock-in, operating burden, cost sensitivity, and follow-up
-obligations when they affect later planning.
-
-## WAF And Compliance
-
-Describe effects on Security, Reliability, Performance Efficiency, Cost Optimization, and Operational Excellence. Record
-direction, rationale, mitigation, and evidence for each material effect. Record compliance, residency, identity,
-governance, audit, and exception implications from accepted constraints; do not infer live policy.
-
-## Implementation Constraints
-
-Record binding constraints such as required module/provider family, identity model, network posture, diagnostics, or
-recovery objective. Do not include direct shell commands, role assignment snippets, secret values, or deployment steps.
-
-## Validation And Revisit
-
-Define observable acceptance signals, decision owner, review event, reversal or migration trigger, and conditions that
-would invalidate the decision. Planned validation is not evidence that validation already passed.
-
-## Provenance
-
-Reference accepted requirement, governance, pricing, availability, benchmark, and user-decision identifiers. Preserve
-unknown and deferred evidence explicitly and never fabricate a citation.

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

@@ -1,55 +0,0 @@
----
-name: apex-azure-cloud-migrate
-description: "Assess cross-cloud workload migration intent in APEX. Use for readiness, AWS or GCP workload mapping, migration risks, staged validation, and authorized handoffs."
-user-invocable: false
----
-
-# APEX Azure Cloud Migration Guidance
-
-Use this skill only for an active assessment, 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, source evidence, target constraints, and evidence
-  references.
-- A bounded workload inventory or owner-supplied evidence identifies the source platform, services, runtime, interfaces,
-  data classification, and critical dependencies; otherwise return `needs_input`.
-- A migration action is available only through a kernel-authorized capability. A migration request does not authorize
-  source inspection, code conversion, file creation, testing, or deployment.
-
-## Workflow
-
-1. Produce an evidence-bounded readiness assessment. Identify unknowns, compatibility risks, security constraints,
-   continuity needs, and user-owned choices without inspecting source or querying cloud services.
-2. Map each accepted workload concern to a logical Azure target pattern. Record confidence, trade-offs, assumptions,
-   dependencies, and unresolved mapping decisions instead of asserting a one-to-one service replacement.
-3. Define staged validation intent: assessment acceptance, authorized implementation evidence, isolated functional
-   validation, integration validation, and production-readiness evidence. A failed or absent receipt blocks the next
-   stage.
-4. Submit the assessment or migration plan only through the kernel-authorized capability named in the task envelope.
-   Preserve the returned receipt or blocker in the active artifact.
-5. Handoff accepted intent to the authorized preparation, implementation, validation, or operations capability. Do not
-   state that a workload is migrated, tested, or deployed without accepted receipts for that stage.
-6. For Lambda-to-Functions requests, apply
-   [Lambda to Functions assessment](references/lambda-to-functions-assessment.md) to the accepted evidence. Return a
-   blocker when the task needs source inspection, code conversion, publishing, or cutover.
-
-## Boundaries
-
-Do not use cloud portals, CLI, SDKs, APIs, repositories, source scanning, code conversion, IaC, deployment tooling, or
-file-mutation actions. Do not discover workloads, access source, create migration output, alter environments, test,
-deploy, or handle secrets. Convert direct operational requests into bounded intent and an authorized capability handoff.
-
-## References
-
-- [Migration readiness assessment](references/migration-readiness.md) - evidence, risk, and blocker criteria.
-- [Workload mapping intent](references/workload-mapping.md) - logical service, identity, data, and observability mapping.
-- [Staged validation and handoff](references/staged-validation-handoff.md) - receipt gates and next-task routing.
-- [Lambda to Functions assessment](references/lambda-to-functions-assessment.md) - workload mapping, runtime review,
-  and blocked-operation boundary.
-
-## Output
-
-Return an evidence-bounded migration assessment or plan, requirement traces, capability receipt references, explicit
-blockers, and the next kernel-controlled task.

package/assets/client-projections/github-copilot-vscode/.github/skills/apex-azure-cloud-migrate/references/lambda-to-functions-assessment.md

@@ -1,29 +0,0 @@
-# Lambda To Functions Assessment
-
-Use this reference to assess a proposed AWS Lambda to Azure Functions migration from accepted evidence. It is not a
-source-discovery or code-conversion procedure.
-
-## Mapping Checklist
-
-| AWS concern | Azure assessment focus |
-| --- | --- |
-| Lambda handler and event | Functions trigger, invocation model, retry, and idempotency intent |
-| API Gateway | HTTP trigger, authentication boundary, and gateway requirement |
-| S3 events | Blob and Event Grid delivery semantics, ordering, and poison handling |
-| SQS or SNS | Queue, Service Bus, or Event Grid delivery guarantees and dead-letter ownership |
-| DynamoDB streams | Cosmos DB change-feed fit, data model, and consistency assumptions |
-| CloudWatch | Application Insights and Azure Monitor evidence requirements |
-| IAM role | Managed identity and least-privilege Azure RBAC intent |
-
-## Runtime And Data Review
-
-- Identify the source runtime, dependency model, handler contract, bindings, environment configuration, and test scope.
-- Separate portable business logic from event adapters, SDK usage, and source-cloud service assumptions.
-- Record data residency, transfer, retention, recovery, cutover, rollback, and ownership constraints before any
-  transformation is considered.
-- Treat target runtime support, service limits, and provider behavior as evidence that must be current and accepted.
-
-## Blocked Operations
-
-Source-cloud reads, repository scans, code transformation, local execution, publishing, data transfer, and cutover are
-not authorized by this assessment. Return an unavailable or needs-input blocker when the task needs any of them.

package/assets/client-projections/github-copilot-vscode/.github/skills/apex-azure-cloud-migrate/references/migration-readiness.md

@@ -1,27 +0,0 @@
-# Migration Readiness Assessment
-
-Base an assessment only on accepted requirements and owner-supplied evidence. It describes readiness, not a discovery
-result or a completed migration. Missing evidence is a blocker, not permission to inspect source or cloud resources.
-
-## Assessment Fields
-
-| Area | Capture |
-| --- | --- |
-| Workload | Source platform, business function, owner, criticality, runtime, and interfaces |
-| Data | Classification, residency, recovery needs, and transfer constraints |
-| Identity | Current trust boundary, target identity intent, and access unknowns |
-| Dependencies | External services, contracts, supportability, and ordering dependencies |
-| Operations | Availability, observability, continuity, support, and rollback expectations |
-| Risk | Compatibility, security, data, downtime, cost, and governance risk with evidence |
-
-## Readiness Decision
-
-Use `ready_for_planning` only when required evidence and ownership are accepted. Use `needs_input` for missing workload
-facts. Use a blocker for unsupported requirements, unresolved policy constraints, unsafe data movement, or a missing
-owner. Record risk mitigation as planned intent, never as completed control evidence.
-
-## Runtime Compatibility
-
-Capture the source trigger, runtime family, supported target runtime, dependency model, state assumptions, and
-unsupported feature risk. A runtime compatibility statement is an assessment input, not code conversion evidence.
-When conversion, source inspection, or runtime verification is needed, defer it to a separately authorized capability.

package/assets/client-projections/github-copilot-vscode/.github/skills/apex-azure-cloud-migrate/references/staged-validation-handoff.md

@@ -1,26 +0,0 @@
-# Staged Validation And Handoff
-
-A migration proceeds through kernel-authorized stages. Passing an earlier stage does not prove a later stage, and no
-stage may be skipped because a plan exists.
-
-## Stages
-
-| Stage | Required evidence | Blocker condition |
-| --- | --- | --- |
-| Assessment | Accepted scope, risks, target intent, and owners | Missing source evidence or unresolved critical risk |
-| Implementation | Authorized capability receipt and trace to approved intent | Missing authorization or rejected output |
-| Functional validation | Accepted isolated behavior evidence | Failure, missing test evidence, or unsupported runtime |
-| Integration validation | Accepted interface, identity, data, and observability evidence | Contract or access mismatch |
-| Production readiness | Accepted governance, recovery, operations, and approval evidence | Unaccepted gate or incomplete ownership |
-
-## Handoff Rules
-
-Preserve the producing capability, receipt identifier, status, evidence reference, blockers, and next task. Route work
-only to the capability named by the active task envelope. Do not execute, simulate, or claim a handoff, validation, or
-deployment.
-
-## Deferred Implementation Boundary
-
-Code migration, source-runtime inspection, local testing, and deployment are provider- or workspace-backed operations.
-Until a capability for that operation is separately qualified, record `defer-capability` with the required scope and
-acceptance evidence rather than using a CLI, SDK, repository scan, or generated migration output.

package/assets/client-projections/github-copilot-vscode/.github/skills/apex-azure-cloud-migrate/references/workload-mapping.md

@@ -1,27 +0,0 @@
-# Workload Mapping Intent
-
-Map source capabilities to logical Azure target patterns from accepted evidence. A mapping is a design hypothesis until
-an authorized implementation and validation capability produces accepted receipts.
-
-## Mapping Dimensions
-
-| Source concern | Target intent to record |
-| --- | --- |
-| Compute and triggers | Execution model, event boundary, runtime support, and scale requirements |
-| Data and messaging | Managed service pattern, consistency, retention, residency, and recovery needs |
-| Identity and access | Managed identity preference, least-privilege requirement, and consent or role blockers |
-| Networking | Connectivity, ingress, egress, private access, and policy constraints |
-| Observability | Logs, metrics, traces, alerts, retention, and operational ownership |
-| Delivery | Approved IaC track, environment promotion intent, validation obligations, and rollback ownership |
-
-## Confidence And Alternatives
-
-For each material mapping, record evidence source, confidence, rejected alternative, and decision owner. When no direct
-Azure analogue satisfies the accepted requirements, return a blocker or user decision rather than inventing equivalence.
-
-## Lambda-To-Functions Assessment
-
-For a Lambda-to-Functions proposal, preserve trigger semantics, event payload contracts, retry and dead-letter behavior,
-timeout and concurrency needs, runtime support, dependency packaging, configuration references, and identity boundary.
-These are mapping dimensions only. Source discovery, code conversion, local execution, and runtime deployment require a
-qualified capability and remain outside this guidance.

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

@@ -1,58 +0,0 @@
----
-name: apex-azure-compliance
-description: "Assess APEX compliance and security evidence. Use for posture findings, configuration review, Key Vault expiration evidence, and finding prioritization."
-user-invocable: false
----
-
-# APEX Azure Compliance Assessment
-
-Use this skill for an active APEX task that evaluates accepted posture evidence.
-It does not certify compliance, perform a scan, disclose sensitive material, or
-authorize remediation.
-
-## Prerequisites
-
-- `apex/taskContext` identifies the target scope, applicable control source,
-  assessment question, sensitivity boundary, and freshness policy.
-- Capability-produced evidence includes its producer, evidence hash, target
-  scope, observation time, completeness, redactions, and control mapping.
-- A finding is traceable to an observed configuration or item metadata. A
-  recommendation without mapped evidence remains an observation.
-
-## Workflow
-
-1. Confirm that evidence scope matches the intended subscription, resource
-   group, resource, or vault boundary and identify omitted targets explicitly.
-2. Separate control status, security posture signal, reliability signal, and
-   cost observation. Do not turn one category into another.
-3. Correlate findings by control, affected target, severity rationale, and
-   evidence hash. Avoid counting duplicate signals as separate exposure.
-4. For expiration evidence, apply the interpretation rules in
-   [compliance finding criteria](references/compliance-finding-criteria.md).
-5. Return a triaged, redacted finding set and route remediation decisions to
-   the kernel-authorized owner. Escalate potential active exposure or outage
-   indicators without asserting exploitation or incident cause.
-
-## Boundaries
-
-- Do not run external assessments, enumerate resources, inspect vault content,
-  or request secret values. All observations are scoped capability-produced
-  evidence and must remain redacted to the task's approved boundary.
-- Do not represent a partial assessment as compliant, noncompliant, or secure.
-- Do not prescribe, apply, or validate remediation. This skill identifies the
-  evidence-backed need and escalation boundary only.
-- Route spend questions to cost assessment, live service symptoms to diagnostic
-  assessment, and policy-scope interpretation to the applicable governance task.
-
-## Output
-
-Return target scope, control basis, evidence hashes, freshness, redaction and
-coverage limits, findings, severity rationale, uncertainty, escalation need,
-and kernel-provided next action.
-
-## References
-
-- [Compliance finding criteria](references/compliance-finding-criteria.md) -
-  control categories, severity, expiration interpretation, and escalation.
-- [Operational checklist](references/operational-checklist.md) -
-   assessment coverage, finding correlation, and redaction limits.

package/assets/client-projections/github-copilot-vscode/.github/skills/apex-azure-compliance/references/compliance-finding-criteria.md

@@ -1,63 +0,0 @@
-## Finding Integrity
-
-A compliance finding needs a control basis, an affected target within scope,
-an observed condition, evidence hash, observation time, and coverage status.
-Classify missing access, incomplete results, redacted fields, or stale evidence
-as an assessment limitation rather than an absent finding.
-
-Use categories to preserve meaning:
-
-| Category | Typical evidence-backed concern |
-| --- | --- |
-| Security | Public exposure, encryption, identity, protocol, or access posture |
-| Reliability | Redundancy, backup, recovery, or single-instance posture |
-| Operational | Diagnostics, monitoring, inventory, or tagging coverage |
-| Cost | Unused or oversized resource signal; route to cost assessment |
-
-## Severity
-
-Severity reflects impact and confidence, not the number of recommendations.
-
-| Severity | Assessment meaning | Escalation boundary |
-| --- | --- | --- |
-| Critical | Credible high-impact exposure or expired active dependency | Urgent kernel-selected security or service owner review |
-| High | Material availability or security risk with strong evidence | Priority owner review |
-| Medium | Control gap or configuration concern with bounded impact | Planned owner assessment |
-| Low | Improvement opportunity or weakly evidenced concern | Track with explicit uncertainty |
-
-Reduce confidence when the scan does not cover all targets, control applicability
-is unknown, a recommendation lacks resource context, or the source has not been
-refreshed within policy. Never infer exploitability from configuration alone.
-
-## Expiration Evidence
-
-Interpret only redacted item metadata: item type, enabled state, validity start,
-expiry, creation or update time, and the declared observation time. Do not
-include values or material identifying sensitive content.
-
-- An expiry before the assessment time is an expired-item finding, subject to
-  enabled state and consumer dependency uncertainty.
-- An expiry inside the approved warning threshold is an expiring-item finding;
-  the threshold must be stated rather than assumed.
-- Missing expiry is a policy or lifecycle-risk signal, not proof of compromise.
-- Disabled items can reduce immediate use risk but may retain governance,
-  inventory, or recovery significance.
-- Ambiguous time zone, missing timestamp, or incomplete item coverage produces
-  `indeterminate` status and requires refreshed scoped evidence.
-
-## Safe Reporting
-
-Report aggregate counts and redacted identifiers only as the task permits. Keep
-the target scope, control mapping, evidence hash, freshness, and uncertainty
-alongside every summary. Handoff asks for owner review; it does not contain
-mutation instructions or claim that a finding has been resolved.
-
-## Recommendation And Authentication Signals
-
-Classify recommendation evidence by security, reliability, operational, or cost concern before assigning severity.
-Authentication evidence should distinguish identity posture, least-privilege scope, and credential-management risk from
-proof of access. Managed identity and narrow RBAC are recommendation criteria, not instructions to create identities,
-assign roles, inspect secrets, or remediate a resource.
-
-AzQR, Resource Graph, Key Vault metadata collection, and all SDK operations are deferred provider capabilities. They
-may supply redacted evidence to this assessment only after separate qualification; this guidance never invokes them.

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

@@ -1,24 +0,0 @@
-# Compliance Operational Checklist
-
-## Assessment Coverage
-
-- State the control source, target boundary, observation time, coverage, and
-  omitted targets before interpreting a finding.
-- Keep assessment output, inventory evidence, and Key Vault item metadata
-  separate. Metadata supports expiration posture, not access to item values.
-- Treat a missing, partial, stale, or unredacted assessment as indeterminate.
-
-## Finding Discipline
-
-- Correlate repeated signals by control and affected target before assigning
-  priority; separate observations from evidence-backed findings.
-- Preserve the severity rationale, evidence hash, and redaction boundary for
-  each finding. Do not infer exploitability, incident cause, or remediation.
-- Expiration evidence requires the observed expiration state and assessment
-  policy. Missing expiry metadata is a control gap, not proof of compromise.
-
-## Escalation
-
-Route security exposure indicators to the authorized security owner and
-remediation decisions to the kernel. A scan or assessment result is not a
-compliance certification.

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

@@ -1,36 +0,0 @@
----
-name: apex-azure-compute
-description: "Assess Azure VM and VM Scale Set choices for active APEX architecture or planning tasks. Use for compute families, capacity, pricing evidence, and VMSS trade-offs."
----
-
-# APEX Azure Compute
-
-Use this skill only for an active architecture or planning task. It records a bounded compute recommendation; it does
-not provision, configure, or operate Azure resources.
-
-## Prerequisites
-
-- `apex/taskContext` identifies the active task, target environment, and workload intent.
-- Workload, availability, scaling, region, operating system, and budget are known or explicitly unresolved.
-- Current pricing, quota, availability, and documentation evidence is available when the decision needs it.
-
-## Workflow
-
-1. Select a VM or VMSS model and candidate families with [Compute selection](references/compute-selection.md) and
-   [Recommendation and scale rules](references/recommendation-and-scale-rules.md).
-2. Obtain current, read-only pricing and availability evidence for the target region.
-3. Record the selected model, capacity range, evidence time, assumptions, and rejected alternatives in the typed artifact.
-4. Return missing or stale evidence as a blocker; submit no state change except through APEX MCP.
-
-## Boundaries
-
-- This skill is advisory; it does not execute commands, edit files, or invoke Azure control-plane operations.
-- A capability may supply accepted read-only evidence. Evidence never replaces governance, approval, or deployment checks.
-- CodeGen may generate IaC only after kernel authorization.
-
-## References
-
-- [Compute selection](references/compute-selection.md) - VM/VMSS and family trade-offs.
-- [Pricing evidence](references/pricing-evidence.md) - comparison method and uncertainty rules.
-- [Recommendation and scale rules](references/recommendation-and-scale-rules.md) - source-derived family, VMSS, and
-  evidence rules without price lookup operations.