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

package/assets/client-projections/github-copilot-vscode/.github/skills/apex-azure-defaults/references/service-selection.md

@@ -1,51 +0,0 @@
-# Service Selection And WAF Criteria
-
-Use service classes as candidates, not predetermined recommendations. Select services only when requirements, accepted
-cost/availability evidence, governance, and architecture decisions support them.
-
-## Elicit Before Selecting
-
-Capture workload pattern, application layers, availability and recovery objectives, compute model, relational and
-non-relational data needs, storage semantics, messaging, ingress, observability, compliance, team capability, and known
-SKU or commitment preferences. Treat "no preference" as permission to evaluate, not permission to pick from memory.
-
-Do not infer compliance solely from industry, choose an enterprise tier solely from company size, or recommend
-Kubernetes when operational requirements do not justify it.
-
-## Candidate Evaluation
-
-For each service candidate, compare:
-
-- Requirement coverage and workload fit
-- Security and identity model
-- Network and data residency constraints
-- Availability, recovery, and scalability objectives
-- Accepted regional availability, quota, lifecycle, and cost evidence
-- Operational burden, ownership, support model, and migration constraints
-- Module/provider support and implementation constraints
-
-Keep at least one viable alternative when the decision is material. Reject candidates with a reason tied to a
-requirement, policy, lifecycle limitation, or WAF consequence.
-
-## Well-Architected Questions
-
-| Pillar | Decision prompt |
-| --- | --- |
-| Security | Does the candidate support the required identity, encryption, private access, and data controls? |
-| Reliability | Can it meet accepted availability, RTO, RPO, and backup objectives? |
-| Performance | Can it meet projected throughput, latency, and growth needs? |
-| Cost | Is the selected SKU/quantity supported by accepted pricing evidence? |
-| Operations | Can it provide required diagnostics, health, ownership, and maintenance behavior? |
-
-## Lifecycle And SKU Rules
-
-- Use accepted current evidence for service availability, runtime support, SKU features, quotas, and retirement status.
-- Prefer supported GA/LTS versions for durable workloads and avoid deprecated or classic services for greenfield use.
-- Treat access tier, redundancy, orchestration mode, hosting plan, and commitment as separate decisions when applicable.
-- Do not convert an advisory workload matrix into a locked SKU or price.
-- Return a blocker when no candidate satisfies a mandatory requirement or evidence is missing.
-
-## Output
-
-Record selected and rejected candidates with evidence hashes, requirement IDs, WAF consequences, and unresolved
-assumptions. Do not turn an advisory service matrix into an automatic SKU decision.

package/assets/client-projections/github-copilot-vscode/.github/skills/apex-azure-defaults/references/tag-precedence.md

@@ -1,31 +0,0 @@
-# Tag And Governance Precedence
-
-Accepted governance constraints are the current authority for required tag keys, casing, values, inheritance, and
-exceptions. Baseline tags are only a fallback when the task context explicitly establishes that no policy contract
-exists.
-
-## Decision Order
-
-1. Confirm governance discovery is complete for inherited and target scopes.
-2. Apply required keys, casing, values, exclusions, inheritance, and enforcement behavior from accepted constraints.
-3. Resolve values only from projected workload, environment, ownership, finance, and operations inputs.
-4. If accepted evidence explicitly reports no applicable tag policy, apply the authorized fallback from
-   `baseline-fallbacks.md` and record that source.
-5. Return a blocker when a required owner, cost center, contact, or restricted value is unresolved.
-
-## Casing And Inheritance
-
-- Use one casing for each logical key. Do not emit case variants such as `owner` and `Owner` together.
-- Distinguish tags required on the resource group from tags required on child resources.
-- Model `Modify` inheritance as expected behavior, but do not rely on it when a `Deny` requires the tag at creation.
-- Preserve exemptions with scope and expiry. An exemption does not remove the requirement outside its scope.
-
-## Existing Workloads
-
-Preserve deployed casing and keys when drift evidence shows they are intentional and an accepted compatibility decision
-requires them. Do not propagate a legacy convention to new resources merely because an older workload used it.
-
-## Output Constraint
-
-Place tag intent, value source, propagation behavior, exception, and governance evidence identifier in the architecture
-or binding decision. Do not query policy, create policy assignments, or write tags directly from this skill.

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

@@ -1,50 +0,0 @@
----
-name: apex-azure-deploy
-description: "Explain approved APEX Azure deployment previews and lifecycle outcomes. Use for approved changes, recovery, verification, and trusted CLI handoff."
-user-invocable: false
----
-
-# APEX Azure Deployment Guidance
-
-Use this skill only for an active operator or deployment task. It explains the exact kernel-provided approved preview,
-its lifecycle position, recovery state, and verification evidence. Deployment itself is reserved to trusted CLI
-ceremonies and kernel authorization.
-
-## Prerequisites
-
-- `apex/taskContext` identifies the active operation, target, authorization state, and validated evidence references.
-- `apex/preview` provides the current, unexpired preview created for that active operation.
-- The preview and validation evidence match the target and artifact revision selected by the kernel. A missing,
-  mismatched, expired, or partial preview is a blocker.
-
-## Workflow
-
-1. Read the current kernel-created preview only. Explain its semantic changes, target, expiry, destructive actions,
-   ignored or unevaluated items, dependencies, and uncertainty without adding inferred changes.
-2. State the lifecycle condition exactly as projected: awaiting decision, authorized, executing, succeeded, failed, or
-   indeterminate. Do not infer completion from files, portal state, or chat history.
-3. Explain the recovery path returned by the kernel. For an indeterminate operation, direct reconciliation through the
-   trusted lifecycle rather than retrying the side effect.
-4. Explain verification evidence, including the observations required to establish the expected post-operation state.
-5. Direct the operator to the trusted `apex gate decide` and `apex deploy` CLI ceremonies when the kernel marks them as
-   the next action. Do not expose deployment commands, substitute another tool, or invoke a deployment operation.
-
-## Boundaries
-
-- Do not run or provide direct AZD, Azure CLI, Bicep, Terraform, ARM, portal, or SDK deployment instructions.
-- Do not create, alter, approve, refresh, or extend previews; do not choose a target or grant authorization.
-- Do not independently retry, roll back, or reconcile an operation. Provider behavior is not assumed transactional.
-- Transform a direct deployment request into an explanation of the exact approved preview and the kernel-provided
-  trusted CLI ceremony. A request never bypasses validation, approval, expiry, writer-epoch, or authorization checks.
-
-## References
-
-- [Preview, recovery, and verification](references/preview-recovery-verification.md) - explanation rules and outcome
-  semantics.
-- [Operational checklist](references/operational-checklist.md) -
-   preconditions, circuit-breaker routing, drift, and verification limits.
-
-## Output
-
-Return the operation ID, target, lifecycle state, preview expiry, evidence references, blockers, and kernel-provided next
-action. Describe only facts supplied by the active task and preview itself.

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

@@ -1,26 +0,0 @@
-# Deployment Operational Checklist
-
-## Preconditions
-
-- Confirm the active operation, validated evidence, target, artifact revision,
-  and unexpired approved preview all match before explaining a deployment.
-- Explain destructive actions, dependencies, ignored items, and uncertainty as
-  returned by the preview. A preview does not authorize a different target.
-- Treat absent or mismatched validation proof as a blocker and return to the
-  trusted validation lifecycle.
-
-## Recovery And Circuit Breaking
-
-- For policy, governance, budget, build, validation, authentication, timeout,
-  or provider failures, preserve the reported evidence and stop at the trusted
-  recovery boundary rather than retrying or reconciling independently.
-- Use the kernel-provided circuit-breaker and retry decision. Escalate repeated
-  failure or an indeterminate provider outcome instead of assuming rollback.
-- Route governance drift to renewed accepted evidence and a new authorized
-  preview; drift is not a reason to amend the current operation in place.
-
-## Verification
-
-Explain only returned verification observations and their coverage. Endpoint
-reachability alone does not establish policy, security, data, or operational
-acceptance. Direct provider mutation remains a trusted CLI ceremony.

package/assets/client-projections/github-copilot-vscode/.github/skills/apex-azure-deploy/references/preview-recovery-verification.md

@@ -1,48 +0,0 @@
-# Preview, Recovery, and Verification
-
-## Explain the Approved Preview
-
-An approved preview is an operation-specific description of planned provider changes. Explain only the preview returned
-for the active operation and include its target, expiry, semantic changes, destructive actions, dependencies,
-unevaluated items, and uncertainty. The preview is not a command, a general deployment plan, or authorization outside
-its stated lifecycle conditions.
-
-Do not fill in omitted operations from repository files, provider conventions, or expected resource topology. Omitted or
-unevaluated items are evidence limits and must remain visible to the operator.
-
-## Lifecycle and Recovery
-
-| State | Meaning | Permitted Guidance |
-| --- | --- | --- |
-| Awaiting decision | Preview exists but no authorization is recorded | Explain the preview and kernel-provided next action |
-| Authorized | Kernel has accepted the required decision | Direct to the trusted CLI ceremony only |
-| Executing | A trusted ceremony has started the provider operation | Report kernel status; do not duplicate it |
-| Succeeded | Kernel recorded a completed operation | Explain required verification evidence |
-| Failed | Kernel recorded a terminal failure | Explain the reported failure and recovery route |
-| Indeterminate | Provider outcome cannot be established | Direct reconciliation; never retry independently |
-
-Recovery is an authorized lifecycle transition, not a guessed rollback. Preserve the provider and kernel evidence,
-including partial state. The trusted lifecycle determines whether reconciliation, a new preview, a controlled retry, or
-another recovery action is appropriate.
-
-## Delivery Safeguards
-
-Explain only safeguards present in the accepted preview and evidence:
-
-- A deployment strategy is a risk-control decision, not permission to select a target, run a command, or change a
-  rollout.
-- Stop and route to the trusted lifecycle when a circuit-breaker condition, policy precheck failure, validation
-  blocker, or drift signal is reported.
-- Treat drift as a reconciliation input. Do not overwrite observed state, infer a baseline, or propose a corrective
-  action without a new kernel-authorized preview.
-- Keep policy effects, region availability, and known provider limitations visible as blockers or uncertainty. They do
-  not become resolved because a deployment reached a terminal state.
-
-Direct commands, recipes, SDK examples, CI definitions, and provider-specific recovery steps remain outside this
-guidance. The trusted CLI and provider lifecycle own those executable paths.
-
-## Verification Evidence
-
-Verification confirms the expected post-operation state against the active operation. Explain only observations returned
-by the kernel or trusted verification capability, their scope, time, outcome, and limitations. An endpoint being
-reachable, for example, does not establish every security, policy, data, or operational acceptance condition.

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

@@ -1,60 +0,0 @@
----
-name: apex-azure-diagnostics
-description: "Interpret APEX diagnostic evidence for Azure service symptoms. Use for health, logs, metrics, failed requests, cold starts, image pulls, and probe analysis."
-user-invocable: false
----
-
-# APEX Azure Diagnostics
-
-Use this skill for an active APEX task that interprets capability-produced
-diagnostic evidence. It supports evidence-based triage; it does not run
-diagnostics, alter service state, or establish a root cause without proof.
-
-## Prerequisites
-
-- `apex/taskContext` identifies the affected target, symptom, time window,
-  environment, customer impact, and sensitivity boundary.
-- Accepted evidence records the producing capability, evidence hash, target
-  scope, query intent, observation time, freshness, completeness, and
-  redactions.
-- The requested time window is sufficient to compare an incident interval with
-  a baseline. Otherwise, retain a single-window interpretation as uncertain.
-
-## Workflow
-
-1. Define the symptom as an observable failure, degradation, or anomaly and
-   verify that the evidence window and target match it.
-2. Evaluate health, activity, logs, metrics, dependencies, and change evidence
-   as separate signals. Absence in one signal is not proof of health.
-3. Use [diagnostic interpretation](references/diagnostic-interpretation.md) to
-   classify correlations, confidence, and diagnostic gaps.
-4. Distinguish observed facts, likely contributors, and untested hypotheses.
-   Do not label a correlation as root cause without causal evidence.
-5. Return the impact summary, evidence-backed findings, uncertainty, and a
-   kernel-provided escalation or next-investigation decision.
-
-## Boundaries
-
-- Do not invoke external diagnostics, run queries, access logs, inspect live
-  service state, or attempt mitigation. Treat all observations as scoped
-  capability-produced evidence.
-- Do not expose request payloads, credentials, tokens, personal data, or stack
-  traces beyond approved redaction boundaries.
-- Escalate confirmed or suspected security exposure to the appropriate security
-  assessment. Route deployment readiness and spending questions to their owning
-  assessments.
-- A diagnostic conclusion never authorizes a configuration change, rollback,
-  scaling operation, or deployment.
-
-## Output
-
-Return the symptom, target and time scope, evidence hashes and freshness,
-observed facts, hypotheses with confidence, coverage limits, impact, escalation
-boundary, and kernel-provided next action.
-
-## References
-
-- [Diagnostic interpretation](references/diagnostic-interpretation.md) -
-  evidence sequence, KQL result meaning, service signals, and uncertainty.
-- [Operational checklist](references/operational-checklist.md) -
-  symptom framing, signal correlation, and escalation boundaries.

package/assets/client-projections/github-copilot-vscode/.github/skills/apex-azure-diagnostics/references/diagnostic-interpretation.md

@@ -1,42 +0,0 @@
-## Evidence Sequence
-
-Interpret diagnostic evidence in this order: target identity and health,
-incident-window logs, request and dependency outcomes, performance metrics,
-then change correlation. Each signal must retain its query intent or collection
-purpose, evidence hash, time range, completeness, freshness, and redactions.
-
-Use a baseline window when available. A spike is meaningful only relative to a
-comparable normal period and can still reflect traffic mix, sampling, retention,
-or instrumentation changes.
-
-## Query Result Meaning
-
-| Signal | Supports | Does not prove |
-| --- | --- | --- |
-| Recent exceptions | Errors occurred in the observed window | The error caused the customer symptom |
-| Failed requests | Failure rate and affected operation patterns | A backend, network, or code root cause |
-| Slow requests | Latency distribution or slow operations | Capacity exhaustion or the causal dependency |
-| Failed dependencies | Downstream failure correlation | Ownership or origin of the failure |
-| Health or activity events | Control-plane or service-health context | Complete application health |
-
-Time bounds, result limits, sampling, missing diagnostics, and redacted fields
-are material uncertainty. Empty results mean only that the scoped evidence did
-not observe a match; they do not establish absence.
-
-## Service Signals
-
-For containerized services, image acquisition, startup delay, probe failures,
-port mismatch, and revision transitions are distinct hypotheses. For functions,
-invocation failures, timeout patterns, binding failures, cold starts, and
-missing configuration signals likewise need separate evidence. Preserve this
-separation in the finding set so a common symptom is not mistaken for one cause.
-
-## Confidence And Escalation
-
-Use `observed` for directly evidenced facts, `correlated` for aligned signals,
-and `hypothesis` for plausible but untested explanations. Increase confidence
-only when independent evidence sources agree on target and time window.
-
-Escalate when impact is broad, customer-facing, security-sensitive, or evidence
-is too incomplete to bound the risk. The handoff identifies the unanswered
-question and needed scoped evidence; it does not prescribe a live action.

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

@@ -1,24 +0,0 @@
-# Diagnostics Operational Checklist
-
-## Frame The Investigation
-
-- State the affected target, observable symptom, environment, impact, and
-  investigation window. A single window may establish correlation only.
-- Compare incident evidence with a compatible baseline when one exists; keep
-  the absence of a signal distinct from proof of health.
-- Keep health, activity, logs, metrics, dependencies, and change evidence as
-  separate signals before drawing a conclusion.
-
-## Interpret Safely
-
-- Classify statements as observed fact, supported contributor, or untested
-  hypothesis. Root-cause claims require causal evidence, not timing alone.
-- For image pulls, cold starts, probes, and request failures, preserve the
-  service-specific evidence and the tested configuration boundary.
-- Redact request bodies, credentials, tokens, personal data, and unapproved
-  stack details; do not reconstruct redacted values by correlation.
-
-## Escalation
-
-Return impact, evidence hashes, uncertainty, and the authorized next
-investigation. Diagnostics never authorizes scaling, rollback, or mitigation.

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

@@ -1,52 +0,0 @@
----
-name: apex-azure-governance
-description: "Guide APEX planning from accepted Azure governance evidence. Use for policy constraints and blockers."
-user-invocable: false
----
-
-# APEX Azure Governance Guidance
-
-Use this skill for an active APEX planning, architecture, or validation task
-that needs Azure Policy constraints. Only capability-produced, accepted
-governance evidence in `apex/taskContext` is authoritative.
-
-## Prerequisites
-
-- The task context identifies the target subscription and applicable
-  management-group ancestry.
-- Accepted governance evidence includes its discovery status, discovery time,
-  freshness limit, completeness signature, and scope.
-
-Return a blocker when evidence is missing, partial, failed, stale, unsigned,
-or scoped to a different subscription or management-group ancestry. Do not
-infer policy state from model memory, templates, or a prior task.
-
-## Workflow
-
-1. Confirm the evidence has a `COMPLETE` status and covers the task scope.
-2. Compare the discovery time with its declared freshness limit; route stale
-   evidence to the governance discovery capability.
-3. Treat `Deny` findings as blockers unless an accepted exemption records
-   them as informational.
-4. Account for `DeployIfNotExists` and `Modify` findings as deployment-time
-   conditions rather than silently assuming the desired result.
-5. Carry required tags, allowed locations, and relevant property-path
-   constraints into the typed planning or architecture decision.
-6. Record the evidence identifier, scope, completeness signature, and any
-   unresolved constraint in the staged artifact.
-
-## Boundaries
-
-- This skill is advisory. It does not discover policy state, query Azure,
-  refresh evidence, or modify resources, files, or task state.
-- Governance evidence constrains a design; it does not grant an exemption or
-  override an unresolved policy.
-- Send deployment and remediation decisions to their authorized capability
-  and gate, not to this skill.
-
-## References
-
-- [Evidence interpretation](references/evidence-interpretation.md) -
-  envelope checks, classification, exemptions, and blocker routing.
-- [Operational checklist](references/operational-checklist.md) -
-   resume conditions, effect handling, and evidence handoff.

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

@@ -1,58 +0,0 @@
-# Governance Evidence Interpretation
-
-Use this reference after accepted governance evidence is available in the
-active task context. The evidence is a point-in-time attestation, not a
-standing authorization.
-
-## Acceptance Checks
-
-Treat the evidence as usable only when all of the following hold:
-
-- Discovery status is `COMPLETE`.
-- Discovery time is within the evidence freshness limit.
-- Subscription and management-group ancestry match the intended task scope.
-- A completeness signature is present and matches the accepted evidence
-  record.
-- A nonempty discovery result is consistent with the evidence metadata.
-
-Any failed check is a blocker. State which check failed and route the task to
-the governance discovery capability; do not continue with a guessed baseline.
-
-## Classification Rules
-
-| Policy effect | Planning interpretation |
-| --- | --- |
-| `Deny` | Block the incompatible design unless an accepted exemption applies. |
-| `DeployIfNotExists` | Model it as a deployment-time condition that the plan must accommodate. |
-| `Modify` | Model it as a deployment-time mutation that may change the final resource state. |
-| `Audit` or `AuditIfNotExists` | Preserve as informational context when present in accepted evidence. |
-| `Disabled` | Do not treat as a live constraint. |
-
-An accepted exemption retains the original policy effect but changes its
-planning classification to informational. Record its category, expiry, scope,
-and rationale. An expired, missing, or scope-mismatched exemption is not an
-override.
-
-## Planning Handoff
-
-Project only applicable constraints into the typed decision:
-
-- Required tag keys and values.
-- Allowed locations.
-- Resource-property constraints with resolvable target paths.
-- Policy identifiers, classifications, exemptions, and evidence provenance.
-
-Leave an unresolved property path explicit rather than inventing an IaC
-mapping. Authorized planning and delivery capabilities own any later
-translation or remediation.
-
-## Resume And Reconciliation
-
-On resume, repeat the acceptance checks against the current task scope and freshness limit. A prior `COMPLETE` result
-does not survive a changed subscription, management-group ancestry, evidence signature, or expiry window. When
-delivery reports policy drift or an indeterminate provider outcome, preserve the observed result and route it to the
-authorized reconciliation lifecycle. Do not rerun discovery, apply an override, or synthesize a corrected policy
-baseline from this guidance.
-
-Discovery scripts, pack execution, and terminal commands remain outside this skill until a separately qualified typed
-capability owns them.

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

@@ -1,25 +0,0 @@
-# Governance Operational Checklist
-
-## Evidence Resume
-
-- Reuse governance evidence only when its scope, management-group ancestry,
-  completeness signature, and freshness policy still match the active task.
-- Treat a changed target, expired freshness, missing signature, `PARTIAL`, or
-  `FAILED` discovery result as a blocker requiring a new authorized discovery.
-- Preserve unresolved property paths as unresolved. Do not manufacture an IaC
-  equivalent from a policy display name or remembered convention.
-
-## Effect Handling
-
-- Treat `Deny` as a design blocker unless an accepted, in-scope exemption is
-  current and recorded with its rationale.
-- Model `Modify` and `DeployIfNotExists` as delivery-time conditions that can
-  alter the observed result; they are not evidence that remediation completed.
-- Keep `Audit`, `AuditIfNotExists`, and `Disabled` findings distinct from
-  blocking constraints and retain their evidence provenance.
-
-## Handoff
-
-Record the evidence identifier, accepted scope, constraints, exemptions, and
-unknowns in the decision. A governance result constrains later work; it never
-grants an exemption, provider access, or remediation authority.

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

@@ -1,58 +0,0 @@
----
-name: apex-azure-kusto
-description: "Interpret APEX Azure Data Explorer evidence and KQL analysis. Use for Kusto, ADX, KQL, schema, aggregation, time-series, correlation, and anomaly findings."
-user-invocable: false
----
-
-# APEX Azure Data Explorer Analysis
-
-Use this skill for an active APEX task that interprets accepted Azure Data
-Explorer evidence and KQL analysis results. It does not discover schemas,
-execute queries, export data, or mutate clusters.
-
-## Prerequisites
-
-- `apex/taskContext` identifies the cluster and database boundary, approved
-  table scope, analytic question, time range, result limit, and data handling
-  constraints.
-- Capability-produced evidence carries its producer, query intent or pattern,
-  evidence hash, target scope, observation time, freshness, completeness,
-  sampling or truncation status, and redaction boundary.
-- Schema evidence is accepted for the same target and sufficiently fresh for
-  the query interpretation. Do not infer columns or semantics from table names.
-
-## Workflow
-
-1. Confirm the analytic question and select the applicable interpretation
-   pattern in [KQL evidence interpretation](references/kql-evidence-interpretation.md).
-2. Verify that time bounds, filters, projections, joins, and aggregation grain
-   answer that question without silently excluding relevant records.
-3. Distinguish record retrieval, aggregate trend, correlated event, and anomaly
-   evidence. State what the pattern establishes and what it cannot establish.
-4. Carry evidence hash, target scope, time window, result completeness,
-   redactions, and uncertainty into the result.
-5. Return observations and an authorized next-assessment request when evidence
-   is insufficient. Route operational incidents to diagnostics and cost
-   questions to cost assessment.
-
-## Boundaries
-
-- Do not invoke external queries, inspect schemas, retrieve data, or export
-  results. All inputs are scoped capability-produced evidence.
-- Do not treat sampled, limited, partial, or stale results as population-wide
-  truth. Do not recover redacted values through correlation or inference.
-- Do not create mutation, retention, access, or cluster-management decisions.
-  Escalate such requests to the kernel-selected owner.
-
-## Output
-
-Return the question, target scope, query-pattern intent, evidence hashes,
-freshness, redaction and completeness limits, observations, uncertainty, and
-kernel-provided next action. Use `indeterminate` for incomplete support.
-
-## References
-
-- [KQL evidence interpretation](references/kql-evidence-interpretation.md) -
-  query pattern meaning, quality checks, and analytic limits.
-- [Operational checklist](references/operational-checklist.md) -
-  schema, query-shape, result-limit, and redaction checks.

package/assets/client-projections/github-copilot-vscode/.github/skills/apex-azure-kusto/references/kql-evidence-interpretation.md

@@ -1,41 +0,0 @@
-## Interpretation Patterns
-
-| Pattern | Useful for | Required limits to report |
-| --- | --- | --- |
-| Retrieval | Inspecting bounded recent records | Time range, filter, projection, result limit |
-| Aggregation | Counts, distributions, and top contributors | Grouping dimensions, time bucket, omitted values |
-| Time series | Trend, latency, volume, and anomaly signals | Baseline, bucket size, sampling, seasonality |
-| Correlation | Events aligned by a declared key and interval | Join type, unmatched records, key quality |
-| Schema evidence | Understanding available fields and types | Schema freshness, permissions, partial visibility |
-
-Every interpretation begins with the question, target, and time range. A
-time-series result needs a bounded time filter; an exploratory result needs a
-declared limit. A pattern that is not present in evidence cannot be assumed.
-
-## Quality Checks
-
-- Confirm filters were applied before broad correlation or aggregation where
-  the evidence's query intent requires a constrained population.
-- Confirm projected fields contain only approved, redacted data and that
-  aggregations do not disclose protected values through small groups.
-- Confirm `bin`-style bucketing matches the decision horizon; a coarse bucket
-  can hide bursts and a fine bucket can create noise.
-- Treat joins as a relationship claim only when the correlation key, time
-  alignment, and unmatched-record behavior are documented.
-- Compare anomaly or percentile claims to an accepted baseline. A single high
-  percentile or spike does not establish a persistent trend.
-
-## Limits And Escalation
-
-Result limits, sampling, retention, late-arriving events, schema drift,
-permission-based partial visibility, and redaction can all bias a conclusion.
-State these limits with the evidence hash and freshness rather than compensating
-with assumptions. When a conclusion needs wider scope, unredacted data, a
-different time window, or causal service evidence, return `indeterminate` and
-ask the kernel to obtain the needed scoped capability evidence.
-
-## Query Capability Boundary
-
-Schema discovery, KQL execution, CLI or REST fallback, and data export are provider-backed operations. Preserve their
-query intent, scope, limits, and failure state in an evidence request, but defer execution until a qualified capability
-exists. Do not replace an unavailable query result with model-generated records or inferred schema.

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

@@ -1,25 +0,0 @@
-# Kusto Evidence Operational Checklist
-
-## Query Shape
-
-- Confirm accepted schema evidence for the same cluster, database, table, and
-  freshness policy before interpreting a query result.
-- Bound time-series questions by time range and result size. Filter and project
-  early, and keep joins and aggregation grain aligned with the stated question.
-- Distinguish record retrieval, aggregate trends, correlations, and anomaly
-  signals; each has different limits on the conclusions it can support.
-
-## Result Quality
-
-- Preserve query intent, target scope, time window, sampling, truncation,
-  redaction, and evidence hash with the result.
-- Treat a schema mismatch, unbounded question, partial result, or stale data as
-  indeterminate. Do not infer columns or semantics from names alone.
-- Do not recover redacted values, export data, or turn query findings into
-  retention, access, or cluster-management decisions.
-
-## Routing
-
-Route operational symptoms to diagnostics and spend questions to cost
-assessment. Request an authorized collection only when accepted evidence is
-insufficient.