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

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

package/assets/client-projections/github-copilot-cli/.github/skills/apex-azure-prepare/SKILL.md

@@ -1,52 +0,0 @@
----
-name: apex-azure-prepare
-description: "Prepare traceable Azure delivery intent in APEX. Use for requirements, architecture, implementation planning, and IaC bindings before validation."
-user-invocable: false
----
-
-# APEX Azure Preparation
-
-Use this skill only for an active requirements, architecture, planning, or CodeGen task. It translates accepted intent
-into traceable architecture, plan, and selected-track IaC binding artifacts. The kernel owns task state, approvals,
-artifact acceptance, and every repository mutation.
-
-## Prerequisites
-
-- `apex/taskContext` identifies the active task, its allowed outputs, target environment, and evidence references.
-- Requirements and any predecessor architecture or governance evidence are accepted and fresh for the active run.
-- A selected IaC track is present before a binding is created; otherwise return `needs_input` or a blocker.
-
-## Workflow
-
-1. Trace the accepted requirements to resource, identity, networking, data, diagnostic, recovery, and operational
-   decisions. Preserve unknowns and external dependencies as explicit blockers.
-2. For architecture tasks, record material Well-Architected trade-offs, evidence references, and user-owned choices
-   through the kernel task workflow. Do not infer subscription, policy, quota, or availability facts.
-3. For planning tasks, express deployment-neutral logical intent, dependencies, ownership, controls, and acceptance
-   obligations. Keep provider syntax and implementation details out of neutral planning intent.
-4. Bind the accepted plan to exactly one selected IaC track. Place module, provider, API, parameter, state, and
-   ownership details in that binding, while preserving the trace back to planned intent and accepted policy.
-5. Use only the kernel-authorized artifact and generation capabilities named by the task envelope. Return their typed
-   result, or a blocker when an output, evidence item, or approval is missing.
-6. For Azure Functions intent, use [Azure Functions recipe pack](references/functions-recipe-pack.md). The pack is
-   deferred: record its unavailable materialization dependency rather than reading or composing its source templates.
-
-## Boundaries
-
-- Do not write files directly; selected IaC generation and staging belong to the authorized CodeGen capability.
-- Do not run commands, contact Azure, select a subscription, retrieve secrets, preview infrastructure, or deploy.
-- Do not mark a plan approved, validated, or deployable. Those state transitions are kernel-controlled.
-- Transform a request for direct Bicep, Terraform, AZD, or deployment work into the active task's approved binding and
-  capability path. A direct-operation request is not authorization to mutate the workspace or Azure.
-
-## References
-
-- [Preparation lineage and binding](references/preparation-lineage.md) - evidence flow, artifact distinctions, and
-  handoff criteria.
-- [Azure Functions recipe pack](references/functions-recipe-pack.md) - deferred corpus status and safe design
-   checklist.
-
-## Output
-
-Return kernel-provided artifact identifiers, requirement traces, binding references, blockers, and the next task. Do
-not claim implementation is ready for deployment until validation evidence is accepted.

package/assets/client-projections/github-copilot-cli/.github/skills/apex-azure-prepare/references/functions-recipe-pack.md

@@ -1,27 +0,0 @@
-# Azure Functions Recipe Pack
-
-The Azure Functions recipe corpus is source-bound in
-[`config/recipe-packs.v1.json`](../../../../../config/recipe-packs.v1.json). It contains service guidance, base
-specifications, recipe templates, and evaluation fixtures, but it is not an active capability.
-
-## Availability
-
-The `azure-functions-recipes` pack is `deferred` until an authorized `recipe-materializer` capability exists. Return an
-unavailable blocker for requests to inspect, select, compose, stage, materialize, validate, or publish a recipe. Do not
-load template content from the corpus as a workaround.
-
-## Design Checklist
-
-- Establish the trigger, event source, concurrency, retry, identity, network, data, and observability requirements.
-- Select a hosting model only from accepted workload evidence. Treat runtime-version support as an external fact that
-  needs fresh evidence.
-- For Event Grid blob processing, record the required storage endpoints, identity roles, subscription ownership, and
-  startup behavior as accepted implementation obligations.
-- For Durable Functions, preserve orchestration determinism, state ownership, replay implications, and dependency
-  boundaries in architecture and test intent.
-- Keep source, target, and secret values out of task artifacts. Materialization and publishing remain unavailable.
-
-## Handoff
-
-Record the recipe family and unmet materialization dependency in the IaC binding. Continue only with an authorized
-alternative generation path or return the blocker to the kernel.

package/assets/client-projections/github-copilot-cli/.github/skills/apex-azure-prepare/references/preparation-lineage.md

@@ -1,36 +0,0 @@
-# Preparation Lineage and Binding
-
-## Evidence Flow
-
-The preparation lifecycle maintains a one-way evidence chain:
-
-1. Accepted requirements establish outcomes, constraints, and acceptance intent.
-2. Architecture decisions explain the selected service, identity, networking, resilience, and operational approach.
-3. The implementation plan turns those decisions into logical resources, dependencies, ownership, controls, and
-   verification obligations.
-4. A selected IaC binding expresses the track-specific module, provider, API, parameter, and state details needed for
-   a bounded generation capability.
-
-Every artifact must retain requirement IDs and accepted evidence references. An unresolved policy, quota, availability,
-cost, ownership, or environment input remains unresolved; it must not become an assumed implementation value.
-
-## Artifact Boundaries
-
-| Artifact | Owns | Must Not Own |
-| --- | --- | --- |
-| Architecture | Decision rationale and material trade-offs | Provider syntax or direct resource definitions |
-| Plan | Logical resources, controls, dependencies, and acceptance obligations | Track-specific implementation syntax |
-| IaC binding | Track-specific module and configuration intent | New architecture or policy decisions |
-| Generated batch | Kernel-authorized implementation output | Approval, validation, or deployment authority |
-
-## Handoff to Validation
-
-Preparation is complete only when the task's required artifacts are staged and accepted, the selected binding is
-unambiguous, and all known constraints have a trace. This is evidence of preparation, not proof that the output is
-valid, current, or deployable. Validation independently checks that claim.
-
-## Direct-Operation Transformation
-
-When a request asks to create infrastructure, configure Azure, or execute an IaC workflow, express the requested
-outcome as a requirement or plan change. Route implementation through the kernel-selected binding and authorized
-generation capability. Never translate it into a shell command, a direct file write, or an Azure operation.

package/assets/client-projections/github-copilot-cli/.github/skills/apex-azure-quotas/SKILL.md

@@ -1,53 +0,0 @@
----
-name: apex-azure-quotas
-description: "Guide APEX capacity planning from accepted Azure quota evidence. Use for limits and region comparisons."
-user-invocable: false
----
-
-# APEX Azure Quota Guidance
-
-Use this skill for an active APEX planning or validation task that needs a
-capacity decision. Only capability-produced, accepted quota and availability
-evidence in `apex/taskContext` is authoritative.
-
-## Prerequisites
-
-- The task specifies the resource demand, provider, candidate region, and
-  target subscription.
-- Accepted evidence identifies the quota resource, limit, usage, observation
-  time, and scope for each evaluated region.
-
-Return a blocker when quota evidence is missing, stale, incomplete, or outside
-the requested provider, subscription, region, or resource boundary. Do not
-assume a quota value or infer a quota resource name from an ARM resource type.
-
-## Workflow
-
-1. Confirm the evidence scope matches the deployment intent and each candidate
-   region.
-2. Verify the capability resolved the provider-specific quota resource rather
-   than relying on an ARM type-name assumption.
-3. Calculate available capacity as `limit - (usage + requested demand)` for
-   each applicable quota.
-4. Treat a nonpositive result as a capacity blocker; distinguish it from a
-   service hard limit or an unavailable quota surface.
-5. Compare only regions with equally fresh, compatible evidence and preserve
-   the selected region's evidence identifier in the typed decision.
-6. Route insufficient capacity to an authorized quota-request or deployment
-   planning path; do not request increases from this skill.
-
-## Boundaries
-
-- This skill does not discover quotas, check live usage, select subscriptions,
-  request increases, configure alerts, or alter resources or files.
-- Quota sufficiency is not a deployment approval, price estimate, or service
-  availability guarantee.
-- A capacity claim may not be extended beyond the accepted provider, region,
-  resource family, subscription, and observation time.
-
-## References
-
-- [Capacity decision rules](references/capacity-decision-rules.md) - scope,
-  resource-name mapping, calculation, and outcomes.
-- [Operational checklist](references/operational-checklist.md) -
-   mapping, capacity comparison, and unavailable-surface handling.

package/assets/client-projections/github-copilot-cli/.github/skills/apex-azure-quotas/references/capacity-decision-rules.md

@@ -1,48 +0,0 @@
-# Quota Capacity Decision Rules
-
-Use accepted quota evidence as a scoped snapshot. The evidence must identify
-the provider, subscription, region, quota resource, limit, usage, unit, and
-observation time.
-
-## Resource Mapping
-
-An ARM resource type does not have a universal one-to-one relationship with a
-quota resource. One resource type can consume a family quota, a regional
-resource-count quota, or multiple quotas. Accept only capability-produced
-mapping evidence that names the evaluated quota resource and its unit.
-
-Treat the following as blockers:
-
-- No resolved quota resource for the requested demand.
-- A mapping for a different provider, resource family, or region.
-- Ambiguous units between demand, usage, and limit.
-- Evidence that has passed its declared freshness limit.
-
-## Capacity Calculation
-
-For each required quota, calculate:
-
-`remaining capacity = limit - (current usage + requested demand)`
-
-Capacity is sufficient only when every required quota has positive remaining
-capacity after the requested demand. Preserve the inputs and result in the
-typed planning decision so later validation can repeat the interpretation.
-
-## Decision Outcomes
-
-| Evidence outcome | Planning result |
-| --- | --- |
-| Every required quota is sufficient | Record a bounded capacity decision for the evaluated scope. |
-| A quota is insufficient | Record a blocker and route to an authorized request or region decision. |
-| A quota is fixed by a service limit | Record the blocker; do not call it an adjustable quota. |
-| Provider or quota surface is unsupported | Record an evidence gap and require a capability result. |
-
-Do not compare regions using different demand assumptions, units, or freshness
-windows. A regional comparison is a decision aid, not an authorization to
-change the target region.
-
-## Provider And Troubleshooting Boundary
-
-Record provider support, extension or command failure, invalid scope, unavailable quota surface, and service hard-limit
-signals as evidence gaps or blockers. CLI discovery, command execution, monitoring configuration, and quota-increase
-workflows are deferred provider capabilities. A troubleshooting note must not turn into a command or a request action.

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

@@ -1,23 +0,0 @@
-# Capacity Operational Checklist
-
-## Mapping And Scope
-
-- Confirm the provider-specific quota resource from accepted evidence. An ARM
-  resource type is not a reliable quota-resource name.
-- Compare only records for the same subscription, provider, region, resource
-  family, observation policy, and requested demand.
-- Separate quota capacity from service hard limits and regional availability;
-  none of these establishes deployment approval.
-
-## Decision
-
-- Compute remaining capacity from the observed limit, usage, and requested
-  demand, then retain each source value in the decision record.
-- Treat nonpositive remaining capacity as a blocker. Treat an unsupported or
-  unavailable quota surface as indeterminate, not unlimited capacity.
-- Do not compare region alternatives whose evidence freshness or scope differs.
-
-## Handoff
-
-Route capacity gaps to an authorized planning or quota-request path. This skill
-does not request an increase, select a subscription, or promise allocation.

package/assets/client-projections/github-copilot-cli/.github/skills/apex-azure-rbac/SKILL.md

@@ -1,45 +0,0 @@
----
-name: apex-azure-rbac
-description: "Designs least-privilege Azure access in APEX decisions. Use for managed identities, built-in or custom role requirements, control-plane versus data-plane permissions, assignment scope, prerequisites, and idempotent binding intent."
-user-invocable: false
----
-
-# APEX Azure RBAC Guidance
-
-Use this skill only for an active architecture or planning task. Accepted requirements, governance constraints, and
-recorded identity decisions are authoritative.
-
-## Prerequisites
-
-- The principal purpose, target resource, required operations, and environment are present in `apex/taskContext`.
-- Accepted role-catalog, identity, governance, and scope evidence is available.
-- A selected IaC/deployment capability owns any future assignment or custom-role change.
-
-## Decision Workflow
-
-1. Describe the exact operation and classify it as control-plane, data-plane, or both.
-2. Resolve the logical principal and require its object/principal identity from accepted identity evidence.
-3. Compare current built-in role definitions and select the narrowest role that covers the operation.
-4. Choose the smallest viable target scope and document why a narrower scope fails.
-5. Use a custom role requirement only when accepted evidence shows no built-in role fits.
-6. Record deterministic assignment intent, caller authorization prerequisites, ordering, and validation expectations.
-7. Check for wildcard permissions, excess scope, credential use, separation-of-duties conflicts, and unresolved evidence.
-
-If a role definition, principal, target scope, or authorized delivery path is unresolved, return a blocker. Never widen
-access to compensate for missing evidence.
-
-## Boundaries
-
-Do not call Azure CLI, Microsoft Graph, ARM, or documentation tools; assign roles; generate direct Bicep/Terraform role
-assignment code; create custom roles; or expose principal IDs, credentials, or secrets. Approved role changes belong in
-the selected IaC/deployment capability and kernel authorization flow.
-
-## References
-
-- Read [least-privilege role selection](references/least-privilege-selection.md) when choosing a built-in or custom role.
-- Read [assignment intent fields](references/assignment-intent.md) when recording a future assignment binding.
-
-## Output
-
-Return bounded role requirements and assignment intents with evidence, scope rationale, prerequisites, risks, and
-unresolved access blockers.

package/assets/client-projections/github-copilot-cli/.github/skills/apex-azure-rbac/references/assignment-intent.md

@@ -1,39 +0,0 @@
-# Assignment Intent Fields
-
-Represent a future role assignment as typed intent, not direct execution.
-
-| Field | Purpose |
-| --- | --- |
-| Principal reference | Stable logical identity plus accepted identity-output reference; never expose the physical ID. |
-| Principal purpose and type | Workload function and accepted user, group, service-principal, or managed-identity type. |
-| Required operation | Narrow action or data access requirement. |
-| Permission plane | Control plane, data plane, or explicitly justified combination. |
-| Role requirement | Accepted built-in definition ID or a bounded unresolved custom-role requirement. |
-| Target scope | Stable target resource reference and environment. |
-| Scope rationale | Why resource, resource-group, or subscription scope is necessary. |
-| Requirement traceability | IDs of requirements served by the access. |
-| Evidence references | Governance, identity, role-catalog, and target-resource evidence identifiers. |
-| Assignment identity | Deterministic key derived from scope, principal, and role for idempotent delivery. |
-| Caller prerequisite | Evidence that the delivery principal can write role assignments at the target scope. |
-| Conditions and expiry | Accepted conditional-access expression, eligible duration, or review point when required. |
-| Ordering | Identity and target dependencies that must exist before assignment validation. |
-| Delivery path | Selected IaC binding or explicitly approved capability. |
-
-## Idempotence And Authorization
-
-The selected binding must derive assignment identity deterministically from target scope, principal, and role definition.
-Random assignment names create duplicates and unstable imports. The future delivery principal needs the
-`Microsoft.Authorization/roleAssignments/write` permission at or above the target scope; record missing authorization as
-a blocker rather than proposing a broader role for the workload principal.
-
-## Propagation And Validation
-
-Role assignment creation and effective data-plane access are separate signals. Record the later validation operation,
-expected target, and bounded propagation handling. Do not treat eventual-consistency delay as permission to retry
-indefinitely or to add a second broader assignment.
-
-## Delivery Constraint
-
-Role assignment changes must be represented through the selected IaC binding and approved deployment workflow. Do not
-produce Azure CLI commands, raw Bicep/Terraform role-assignment resources, custom-role JSON, or credential material in
-the advisory skill output.