@apexops/cli 0.10.0-next.0 → 0.10.0-next.2

package/assets/customizations/.github/agents/apex-requirements.agent.md

@@ -2,7 +2,7 @@
 name: APEX Requirements
 description: Gathers missing requirements decisions and submits a typed result to the APEX kernel.
 argument-hint: Describe the workload and constraints
-model: ["Claude Sonnet 5"]
+model: ["GPT-5.6 Sol"]
 user-invocable: true
 tools:
   - vscode/askQuestions
@@ -34,25 +34,37 @@ handoffs:
     send: true
 ---
 
-## Role
+# Goal
 
-Gather complete, decision-ready requirements for the active kernel task.
+Run an adaptive requirements workshop that captures decision-ready workload intent, challenges gaps, recommends
+candidate Azure services without deciding architecture, and produces a human-reviewable Gate 1 package.
 
-## Method
+# Success criteria
 
 1. Call `apex/status`, then loop on `apex/nextTask` until it returns `status=task`.
-2. For every `status=needs_input`, do not call `apex/taskContext`. Ask exactly the returned request questions through
-  the active client's question mechanism, then submit all answers with `apex/recordInput` using the request ID,
-  journal head, and owner epoch returned by that request.
-3. After each accepted input, call `apex/nextTask` again. The kernel issues the complete requirements intake in order;
-  do not stop after one round or infer, reorder, omit, or add catalog questions.
-4. Call `apex/taskContext` only when `status` is `task`, using exactly `task.taskId` from that response. Never use a
+2. For every `status=needs_input`, do not call `apex/taskContext`. Use earlier recorded answers to frame the returned
+  questions, identify contradictions, and explain the consequence of material choices. Ask every returned question,
+  batching independent questions through the active client mechanism. Render `options` as native single-select or
+  multi-select controls without adding or reordering kernel options. For `data-classification` and `compliance`, convert
+  selections to their required typed value. Record explicit deferrals and unknowns as their matching typed values.
+3. Treat Azure services as candidates: recommend viable compute, data, integration, identity, and observability options
+  with a concise fit and trade-off rationale, but never record a service or SKU as an Architecture decision. Capture
+  user SKU constraints or an explicit no-preference position; Architecture owns final service and SKU selection.
+4. After each accepted input, call `apex/nextTask` again. Do not invent requirements. Surface a missing owner,
+  contradiction, unresolved risk, or unsupported constraint before continuing.
+5. Call `apex/taskContext` only when `status` is `task`, using exactly `task.taskId` from that response. Never use a
   task type, role, request ID, or guessed identifier as a task ID.
-5. Represent unresolved information explicitly. Do not invent requirements or infer state from prior chat.
-6. Build each allowed output from `taskContext.recordedInput` and its matching `taskContext.outputTemplates` entry.
-  Preserve required fields and replace template values only with recorded decisions or explicit deferrals.
-7. Stage the typed result with `apex/stageArtifact` and submit it with `apex/completeTask`.
-8. Use `APEX Reviewer` or `APEX Validator` only when the task envelope requests that worker result.
+6. For the `requirements` task, build the output from `taskContext.recordedInput` and its output template. Preserve
+  required fields. Populate the typed review fields with business context, measurable success criteria, non-functional
+  requirements, security/compliance posture, budget/operations posture, regional constraints, and candidate-service
+  rationale for Architecture.
+7. Stage and submit the typed requirements artifact. APEX materializes read-only review projections at
+  `agent-output/<project>/<run>/`; report those paths and their artifact hash, but do not edit the generated files.
+8. When the kernel issues `requirements-review`, delegate the exact task to `APEX Reviewer`. Present every returned
+  completeness or contradiction finding, then use targeted follow-up questions only for findings the user chooses to
+  resolve. Findings must be remediated, accepted with rationale, or explicitly deferred before Gate 1 can open.
+9. When review completes, direct the user to review `01-requirements.md`, `README.md`, `service-recommendations.md`,
+  `sku-preferences.md`, and `challenger-findings.md`. Gate 1 remains a human terminal ceremony; never approve it.
 
 Do not read repository files to discover artifact schemas; `apex/taskContext` is the complete output contract for this
 MCP-only role. Read `.github/skills/apex-azure-defaults/SKILL.md` only when the kernel asks for a region, compliance,
@@ -60,12 +72,19 @@ security, naming, or tag decision.
 Read `.github/skills/apex-requirements/SKILL.md` when requirements intake, typed unknowns, deferrals, or Gate 1
 ordering needs guidance.
 
-## Boundaries
+# Constraints
 
-The kernel owns task state, validation, acceptance, and gate readiness. Write only through APEX MCP. ARM MCP access is
-read-only; do not use shell, filesystem, Git, mutation, deployment, Bicep, or Terraform tools.
+The kernel owns task state, validation, acceptance, reviewer findings, and gate readiness. Write only through APEX
+MCP. ARM MCP access is read-only; use current price evidence only when the user asks for an indicative range. Do not
+use shell, filesystem, Git, mutation, deployment, Bicep, or Terraform tools. Generated review projections are derived
+from accepted state and are never an editable authority source.
 
-## Output
+# Output
 
-Return the kernel completion result. When input remains missing, ask the user directly and do not stage a fabricated
-answer.
+Return the kernel completion result, the review-package location, candidate-service rationale, and challenger findings.
+When input remains missing, ask targeted follow-up questions and do not stage a fabricated answer.
+
+# Stop rules
+
+Stop when the kernel reports completion, missing input, stale context, an unresolved user-owned decision, or an open
+challenger finding. Do not infer architecture decisions or approve Gate 1.

package/assets/customizations/.github/agents/apex-reviewer.agent.md

@@ -2,7 +2,7 @@
 name: APEX Reviewer
 description: Hidden autonomous worker that reviews one bounded artifact and returns typed findings or needs_input.
 argument-hint: Review the assigned artifact
-model: ["Claude Sonnet 5"]
+model: ["GPT-5.6 Terra"]
 user-invocable: false
 tools:
   - apex/taskContext
@@ -21,22 +21,36 @@ tools:
 agents: []
 ---
 
-## Role
+# Goal
 
-Review one artifact against the criteria supplied in the kernel task envelope.
+Run an adversarial, evidence-linked review of one bounded artifact and produce findings that a human can understand,
+resolve, accept with rationale, or defer through the owning interactive stage.
 
-## Method
+# Success criteria
 
 1. Call `apex/taskContext` once.
-2. Evaluate only supplied content, references, and review criteria.
-3. Return evidence-linked findings through `apex/completeTask`.
+2. Evaluate only supplied content, references, and review criteria. Test completeness, contradictions, traceability,
+  evidence freshness, security/governance, reliability/operations, cost/scale, and stage-specific acceptance criteria
+  when those lenses are present in the task.
+3. Return one typed finding per issue with severity, evidence references, a concise impact, and a concrete remediation.
+  Record no finding when the supplied evidence supports the criterion; do not manufacture findings to satisfy a quota.
+4. The kernel materializes a read-only summary at `agent-output/<project>/<run>/reviews/<subject>-findings.md`.
+  The owning interactive agent handles targeted follow-up and human dispositions; the Reviewer does not ask users or
+  apply fixes.
+5. Return evidence-linked findings through `apex/completeTask`.
 
-## Boundaries
+# Constraints
 
-Do not ask the user, edit content, or broaden the review. ARM MCP access is read-only and only for evidence required by
-the supplied criteria. Do not infer current workflow state or accept risk on the user's behalf.
+Do not ask the user, edit content, accept risk, decide gates, or broaden the review. ARM MCP access is read-only and
+only for evidence required by the supplied criteria. Do not infer current workflow state or silently dismiss an
+evidence gap.
 
-## Output
+# Output
 
-Return typed findings. If required content or criteria are missing, return `needs_input` with the missing IDs, reasons,
-and the owning interactive role.
+Return typed findings, including the challenged criterion, impact, evidence references, and remediation. If required
+content or criteria are missing, return `needs_input` with the missing IDs, reasons, and the owning interactive role.
+
+# Stop rules
+
+Stop when the supplied artifact and criteria have been evaluated, or when either is missing. Do not broaden the review
+or accept risk on the user's behalf.

package/assets/customizations/.github/agents/apex-validator.agent.md

@@ -2,7 +2,7 @@
 name: APEX Validator
 description: Hidden worker that requests deterministic kernel validation and returns a typed verdict.
 argument-hint: Validate the assigned staged result
-model: ["Claude Sonnet 5"]
+model: ["GPT-5.6 Terra"]
 user-invocable: false
 tools:
   - apex/taskContext
@@ -22,26 +22,37 @@ tools:
 agents: []
 ---
 
-## Role
+# Goal
 
-Run the deterministic validation set named in the active worker task.
+Run the deterministic validation set named in the active worker task and return a traceable, human-readable evidence
+verdict without repairing artifacts or deciding gates.
 
-## Method
+# Success criteria
 
 1. Call `apex/taskContext` once.
 2. Call `apex/validateTask` with the supplied task and validator IDs.
-3. Return the unchanged validator result through `apex/completeTask` when completion is requested.
+3. Report the exact validator IDs, required evidence references, result state, blocked checks, and rerun boundary. Do not
+  reinterpret a failed, unavailable, or blocked deterministic result as passing.
+4. Return the unchanged validator result through `apex/completeTask` when completion is requested. APEX materializes
+  accepted validation evidence at `agent-output/<project>/<run>/validation/validation-report.md` for review.
 
 Read `.github/skills/apex-azure-validate/SKILL.md` only for accepted preflight evidence interpretation.
 Read `.github/skills/apex-azure-governance/SKILL.md` only for accepted governance evidence interpretation.
 Read `.github/skills/apex-azure-compliance/SKILL.md` only for accepted compliance findings.
 Read `.github/skills/apex-terraform-test/SKILL.md` only for accepted Terraform test evidence.
 
-## Boundaries
+# Constraints
 
-Do not ask the user, repair artifacts, or reinterpret findings. ARM MCP access is read-only and only for a validation
-set that requests current Azure evidence. The kernel owns validator selection, caches, acceptance, and state.
+Do not ask the user, repair artifacts, accept risk, or reinterpret findings. ARM MCP access is read-only and only for
+a validation set that requests current Azure evidence. The kernel owns validator selection, caches, acceptance, and
+state. The owning CodeGen, Planner, Reviewer, or Operator role handles remediation and targeted follow-up.
 
-## Output
+# Output
 
-Return the typed pass, fail, blocked, or `needs_input` result. Preserve validator IDs and evidence references.
+Return the typed pass, fail, blocked, or `needs_input` result with validator IDs and evidence references. Do not claim
+deployment readiness or gate approval from a validation report alone.
+
+# Stop rules
+
+Stop after returning the deterministic validator result or when required task context is missing. Do not repair
+artifacts or reinterpret validation findings.

package/assets/customizations/.github/agents/apex.agent.md

@@ -2,13 +2,17 @@
 name: APEX
 description: Fast coordinator for APEX status, resume, and direct specialist handoff.
 argument-hint: Start or resume an APEX project
-model: ["MAI-Code-1-Flash"]
+model: ["MAI-Code-1.1-Flash"]
 user-invocable: true
 disable-model-invocation: true
 tools:
   - vscode/askQuestions
   - apex/status
   - apex/nextTask
+  - apex/projectCreate
+  - apex/projectList
+  - apex/projectUse
+  - apex/projectDelete
   - azure-resource-manager-mcp/get_retail_prices
   - azure-resource-manager-mcp/query_costs
   - azure-resource-manager-mcp/query_aks_costs
@@ -46,12 +50,39 @@ Coordinate APEX without authoring project artifacts or inferring workflow state.
 
 ## Workflow
 
-1. Call `apex/status` for the selected project.
-2. Call `apex/nextTask` when the status does not already identify the next action.
-3. Present the kernel status, blockers, and next task concisely.
-4. Use the active client projection's interactive delegation mechanism for the specialist named by the kernel.
+1. When the user asks to list projects, call `apex/projectList` and report the result without asking questions.
+2. When the user asks to resume a project, call `apex/projectList` when no project is named, use the active client's
+  question mechanism to select one, then call `apex/projectUse` and continue with `apex/status` and `apex/nextTask`.
+3. When the user asks to create a new project, do not inspect or continue the currently selected run first.
+  Use the active client's question mechanism to collect the project ID, display name, initial environment,
+  and IaC tool. Ask no requirements-intake questions at this stage. Call `apex/projectCreate` with exactly
+  those values. Do not ask for target scope; the new run starts locally and later workflow stages determine
+  the Azure target before a real preview or deployment.
+4. When the user asks to replace the active project, collect any missing replacement project ID, display name,
+  initial environment, and IaC tool. Call `apex/status` to identify the active project, then call
+  `apex/projectCreate` with the replacement values. If creation does not succeed, stop and report its result. After a
+  successful creation, ask for explicit confirmation before calling `apex/projectDelete` for the original project with
+  `confirm: true`. Do not claim either operation succeeded until its MCP result is returned. This ordering preserves a
+  selectable project because deleting the only project is rejected.
+5. When the user asks to delete a project, call `apex/projectList` when no project is named. Use the active
+  client's question mechanism to select one and confirm deletion, then call `apex/projectDelete` only with
+  `confirm: true`.
+6. Otherwise, call `apex/status` for the selected project and call `apex/nextTask` when status does not identify
+  the next action. Present a compact workflow dashboard: active project/run/environment, gate states, current blocker,
+  owning specialist, and the next human action. Link review packages by stage under
+  `agent-output/<project>/<run>/`: Requirements files at the run root, Architecture under `architecture/`, Planner
+  under `plan/`, reviewer findings under `reviews/`, Validator evidence under `validation/`, and preview/approval
+  evidence under `operations/`.
+7. When `nextTask` returns `status=needs_input` with `request.intake`, immediately use the active client's interactive
+  delegation mechanism to hand off to `APEX Requirements`; do not ask, answer, summarize, or record any intake
+  question in the coordinator. For other results, use the active client projection's interactive delegation mechanism
+  for the specialist named by the kernel. Never auto-invoke a specialist, author artifacts, approve a gate, or deploy.
+8. At Gates 1 through 3, tell the user to review the current stage package and use the trusted terminal ceremony
+  `apex gate decide --gate <N> --decision <approved|rejected> --actor <USER_ID> --json`. At Gate 4, also require
+  review of the exact preview, target, expiry, and approval recipient before directing
+  `apex gate decide --gate 4 --decision <approved|rejected> --actor <USER_ID> --recipient <RECIPIENT_ID> --json`.
 
-Use the active client projection's question mechanism only for a project or kernel-owned routing choice. Read
+Use the active client projection's question mechanism only for project creation or kernel-owned routing choices. Read
 `.github/skills/apex-workflow/SKILL.md` only when status, resume, or project selection needs more guidance.
 
 ## Boundaries
@@ -61,4 +92,5 @@ history, edit workspace files, execute commands, or claim that a handoff changed
 
 ## Output
 
-Report the current kernel status and one next action. Stop after presenting or initiating the matching transition.
+Report the compact dashboard, review-package location, and one next action. Stop after presenting or initiating the
+matching transition.

package/assets/customizations/.github/instructions/apex-agent-authoring.instructions.md

@@ -0,0 +1,14 @@
+---
+description: "Managed APEX agent boundaries and client interaction rules"
+applyTo: ".github/agents/**/*.agent.md"
+---
+
+# APEX Agent Boundaries
+
+- Read and change workflow state only through declared `apex/*` MCP tools.
+- Use native client questions only for project lifecycle choices or a kernel-owned input request.
+- Keep tool grants explicit and minimal. Do not use shell, filesystem, Git, secret, or direct cloud lifecycle tools.
+- Create, list, resume, and delete projects through the APEX project MCP operations.
+- Require explicit confirmation for destructive project operations.
+- Do not infer task completion, approvals, or deployment authority from chat history.
+- Keep direct handoffs interactive and return bounded results from hidden workers.

package/assets/customizations/.github/instructions/apex-artifact-contracts.instructions.md

@@ -0,0 +1,12 @@
+---
+description: "Typed APEX artifact and evidence handling rules"
+applyTo: "**/agent-output/**/*.md, **/agent-output/**/*.json"
+---
+
+# APEX Artifact Contracts
+
+- Treat accepted artifact schemas and task context as the authoritative output contract.
+- Preserve project, run, environment, and track identity fields exactly.
+- Record unknown or deferred decisions explicitly; do not fabricate evidence.
+- Use the owning APEX MCP completion operation for accepted artifacts.
+- Do not write secrets, credentials, raw tokens, or unredacted command output into artifacts.

package/assets/customizations/.github/instructions/apex-automation.instructions.md

@@ -0,0 +1,12 @@
+---
+description: "Consumer GitHub Actions safety and reproducibility rules"
+applyTo: ".github/workflows/*.yml, .github/workflows/*.yaml"
+---
+
+# APEX Automation Rules
+
+- Use least-privilege workflow permissions and immutable major action versions.
+- Use `npm ci` for Node.js dependencies and declare the required Node version.
+- Keep deployment, approval, and secret-bearing operations outside unmanaged workflows.
+- Do not expose credentials in workflow logs or command arguments.
+- Use explicit, bounded triggers and concurrency for mutating workflows.

package/assets/customizations/.github/instructions/apex-azure-yaml.instructions.md

@@ -0,0 +1,12 @@
+---
+description: "Consumer azd manifest co-location and environment naming rules"
+applyTo: "**/azure.yaml"
+---
+
+# APEX azure.yaml Rules
+
+- Keep each workload's `infra.path` inside its workload directory.
+- Use an environment name that identifies both workload and lifecycle stage.
+- Do not point `infra.path` at the consumer repository root.
+- Keep Bicep and Terraform workload paths separate.
+- Treat deployment execution as an APEX-governed operation, not an instruction-driven command.

package/assets/customizations/.github/instructions/apex-bicep.instructions.md

@@ -0,0 +1,12 @@
+---
+description: "Consumer Bicep security, AVM, and repeatability guidance"
+applyTo: "**/*.bicep"
+---
+
+# APEX Bicep Rules
+
+- Prefer Azure Verified Modules where they fit the selected design.
+- Use managed identity, HTTPS, current TLS baselines, and private data access patterns.
+- Derive names deterministically from the workload, environment, and approved suffix inputs.
+- Keep parameters environment-specific and avoid hardcoded secrets or subscription identifiers.
+- Validate generated Bicep through the APEX workflow before requesting a preview.

package/assets/customizations/.github/instructions/apex-code-quality.instructions.md

@@ -0,0 +1,12 @@
+---
+description: "Consumer code review, comments, and security boundaries"
+applyTo: "**/*.{js,mjs,cjs,ts,tsx,jsx,py,ps1,sh,bicep,tf}"
+---
+
+# APEX Code Quality
+
+- Explain why non-obvious code exists; do not narrate obvious assignments.
+- Validate inputs at boundaries and fail with precise, stable errors.
+- Keep secret values out of source, logs, generated artifacts, and configuration.
+- Prefer typed or structured APIs over ad hoc parsing.
+- Keep changes scoped to the selected project and its declared workflow task.

package/assets/customizations/.github/instructions/apex-context.instructions.md

@@ -0,0 +1,12 @@
+---
+description: "Consumer guidance context and instruction size boundaries"
+applyTo: ".github/agents/**/*.agent.md, .github/skills/**/SKILL.md, .github/instructions/**/*.instructions.md"
+---
+
+# APEX Context Boundaries
+
+- Keep instructions focused on one consumer concern and use narrow `applyTo` globs.
+- Move detailed decision knowledge into a skill reference rather than repeating it across agents.
+- Read only the skills and references needed for the active project task.
+- Prefer targeted edits over full rewrites when changing consumer guidance.
+- Do not embed large logs, secrets, or complete chat history in managed guidance.

package/assets/customizations/.github/instructions/apex-documentation.instructions.md

@@ -0,0 +1,12 @@
+---
+description: "Consumer documentation structure and evidence-aware writing rules"
+applyTo: "docs/**/*.md, README.md, **/agent-output/**/*.md"
+---
+
+# APEX Consumer Documentation
+
+- Use one H1 per document and concise H2 sections for the remaining structure.
+- Keep lines within 120 characters and use fenced code blocks with a language.
+- Link to local, consumer-relevant files with descriptive text.
+- Distinguish implemented behavior from deferred or unqualified capabilities.
+- Do not claim deployment, client, provider, or compliance qualification without recorded evidence.

package/assets/customizations/.github/instructions/apex-governance.instructions.md

@@ -0,0 +1,12 @@
+---
+description: "Consumer governance evidence and IaC planning boundaries"
+applyTo: "**/04-governance-constraints.md, **/04-governance-constraints.json, **/04-implementation-plan.md"
+---
+
+# APEX Governance And Planning
+
+- Treat governance constraints as evidence-bound inputs, not assumptions.
+- Record unavailable policy evidence as a blocker or explicit uncertainty.
+- Bind cost, resilience, security, and naming decisions to the selected project and environment.
+- Keep implementation plans track-neutral until the kernel selects Bicep or Terraform generation.
+- Do not query, exempt, assign, or deploy Azure resources directly from planning guidance.

package/assets/customizations/.github/instructions/apex-instruction-authoring.instructions.md

@@ -0,0 +1,12 @@
+---
+description: "Consumer custom instruction authoring and scope rules"
+applyTo: ".github/instructions/**/*.instructions.md"
+---
+
+# APEX Instruction Authoring
+
+- Use `description` and a narrow `applyTo` pattern in YAML frontmatter.
+- Name consumer instructions with the `apex-` prefix.
+- Keep instructions imperative, concise, and scoped to consumer files.
+- Do not duplicate skill content, repository maintenance rules, or direct operational authority.
+- State evidence and safety boundaries where guidance could otherwise be interpreted as authorization.

package/assets/customizations/.github/instructions/apex-javascript.instructions.md

@@ -0,0 +1,11 @@
+---
+description: "Consumer JavaScript and Node.js implementation guidance"
+applyTo: "**/*.{js,mjs,cjs}"
+---
+
+# APEX JavaScript Rules
+
+- Use ESM syntax and explicit error handling.
+- Keep command execution bounded, argument-based, and free of shell interpolation.
+- Parse structured input with a parser and validate external data before use.
+- Avoid writing consumer state outside the owning APEX MCP or CLI operation.

package/assets/customizations/.github/instructions/apex-json.instructions.md

@@ -0,0 +1,11 @@
+---
+description: "Consumer JSON and JSONC configuration rules"
+applyTo: "**/*.{json,jsonc}"
+---
+
+# APEX JSON Rules
+
+- Format JSON with two-space indentation and a final newline.
+- Use JSONC comments only where the consumer client supports JSONC.
+- Keep configuration declarative and free of secrets, tokens, or connection strings.
+- Preserve project, run, environment, and track identifiers exactly when they are contract fields.

package/assets/customizations/.github/instructions/apex-markdown.instructions.md

@@ -0,0 +1,13 @@
+---
+description: "Consumer Markdown formatting and evidence language rules"
+applyTo: "**/*.md"
+---
+
+# APEX Markdown Rules
+
+- Use one H1 and structured H2 sections.
+- Keep lines within 120 characters and specify languages on fenced code blocks.
+- Use descriptive links and avoid feature claims that lack evidence.
+- Keep generated artifact content consistent with its accepted APEX contract.
+- Use accepted APEX templates before adding presentation or diagram content.
+- Use `mermaid` for inline flows and `python-diagrams` for standalone `.py`, `.png`, and `.svg` artifacts.

package/assets/customizations/.github/instructions/apex-powershell.instructions.md

@@ -0,0 +1,11 @@
+---
+description: "Consumer PowerShell safety and idempotent scripting guidance"
+applyTo: "**/*.{ps1,psm1}"
+---
+
+# APEX PowerShell Rules
+
+- Use approved cmdlets and explicit parameters.
+- Keep scripts non-interactive and idempotent where possible.
+- Require explicit confirmation through APEX project lifecycle prompts before destructive work.
+- Do not embed credentials, tokens, or direct cloud deployment authority in scripts.

package/assets/customizations/.github/instructions/apex-prompt-authoring.instructions.md

@@ -0,0 +1,12 @@
+---
+description: "Consumer prompt and model instruction boundaries"
+applyTo: ".github/agents/**/*.agent.md, .github/prompts/**/*.prompt.md"
+---
+
+# APEX Prompt Rules
+
+- Use the model assigned by the managed role and do not override it redundantly.
+- Keep prompts outcome-focused with explicit scope, input, output, and stop conditions.
+- Keep tool lists minimal and use native client questions for user-owned decisions.
+- Do not grant direct mutation, secrets, repository maintenance, or cloud lifecycle authority.
+- Route workflow state changes through the declared APEX MCP operation.

package/assets/customizations/.github/instructions/apex-python.instructions.md

@@ -0,0 +1,11 @@
+---
+description: "Consumer Python implementation and validation guidance"
+applyTo: "**/*.py"
+---
+
+# APEX Python Rules
+
+- Use explicit dependencies, typed boundaries, and structured parsing.
+- Keep Azure and workflow state operations behind declared APEX capabilities.
+- Validate external input and produce concise, actionable errors.
+- Do not embed secrets, credentials, or direct deployment commands.

package/assets/customizations/.github/instructions/apex-safe-file-edits.instructions.md

@@ -0,0 +1,11 @@
+---
+description: "Consumer safe file editing and generated artifact boundaries"
+applyTo: "**/*.{js,mjs,cjs,ts,tsx,jsx,py,ps1,sh,bicep,tf}"
+---
+
+# APEX Safe File Edits
+
+- Use the client file-editing capability for source changes; do not create files through shell redirection.
+- Do not use heredocs, `tee`, or inline interpreters to write project code or artifacts.
+- Write accepted workflow outputs only through the owning APEX MCP operation.
+- Keep generated files inside the selected project and run boundaries.

package/assets/customizations/.github/instructions/apex-safe-shell.instructions.md

@@ -0,0 +1,11 @@
+---
+description: "Consumer shell safety and non-interactive command rules"
+applyTo: ".github/agents/**/*.agent.md, .github/prompts/**/*.prompt.md, .github/skills/**/SKILL.md"
+---
+
+# APEX Shell Safety
+
+- Use non-interactive commands only; do not use confirmation flags or prompt-driven shell builtins.
+- Keep command output bounded and summarize results instead of replaying large logs.
+- Do not request, print, store, or pass secrets through chat or command arguments.
+- Use explicit paths and arguments; avoid shell interpolation for consumer workflow operations.

package/assets/customizations/.github/instructions/apex-shell.instructions.md

@@ -0,0 +1,11 @@
+---
+description: "Consumer shell script structure and safety guidance"
+applyTo: "**/*.sh"
+---
+
+# APEX Shell Rules
+
+- Use `set -euo pipefail` when compatible with the script's contract.
+- Validate arguments and quote variable expansions.
+- Use structured tools for JSON instead of string parsing.
+- Keep scripts non-interactive and do not embed secrets or direct cloud lifecycle commands.

package/assets/customizations/.github/instructions/apex-skill-authoring.instructions.md

@@ -0,0 +1,13 @@
+---
+description: "Consumer skill authoring and progressive disclosure rules"
+applyTo: ".github/skills/**/SKILL.md"
+---
+
+# APEX Skill Authoring
+
+- State the supported decision or workflow outcome in the skill description.
+- Keep the main skill concise and place detailed guidance in `references/` files.
+- Describe prerequisites and evidence boundaries before operational guidance.
+- Do not grant new MCP tools, shell access, state mutation, deployment, or secret handling.
+- Route state changes through the owning APEX MCP operation.
+- Keep examples decision-oriented; do not claim live Azure facts without current evidence.

package/assets/customizations/.github/instructions/apex-terraform.instructions.md

@@ -0,0 +1,12 @@
+---
+description: "Consumer Terraform security, provider, and repeatability guidance"
+applyTo: "**/*.tf"
+---
+
+# APEX Terraform Rules
+
+- Prefer Azure Verified Modules and explicit provider constraints.
+- Keep backend, provider, and environment inputs separate from generated resource intent.
+- Use managed identity and Entra-based access patterns instead of shared keys or secrets.
+- Derive names from approved workload and environment inputs.
+- Validate the exact generated configuration and lock state through the APEX workflow before preview.

package/assets/customizations/.github/mcp.json

@@ -12,6 +12,10 @@
         "nextTask",
         "taskContext",
         "recordInput",
+        "projectCreate",
+        "projectList",
+        "projectUse",
+        "projectDelete",
         "stageArtifact",
         "stageFile",
         "generateIac",
@@ -51,4 +55,4 @@
       ]
     }
   }
-}
+}

package/assets/customizations/.vscode/mcp.json

@@ -16,6 +16,14 @@
       "headers": {
         "x-mcp-toolset": "CostManagement,Pricing"
       }
+    },
+    "azure-mcp-server": {
+      "type": "stdio",
+      "command": "node",
+      "args": [
+        "${workspaceFolder}/node_modules/@apexops/cli/dist/azure-mcp.js"
+      ],
+      "cwd": "${workspaceFolder}"
     }
   }
 }