@raishin/vanguard-frontier-agentic 2.10.0 → 2.11.0

package/skills/snowflake/snowflake-live-rbac-grant-guard-at-azure/SKILL.md

@@ -0,0 +1,148 @@
+---
+name: snowflake-live-rbac-grant-guard-at-azure
+description: Mutating-runtime live guard for Snowflake RBAC privilege management on Azure. Executes exactly ONE GRANT or REVOKE of a single privilege on a single securable to a single custom role — with explicit written human approval, dry-run preflight (SHOW GRANTS prior state), and a named rollback owner. Phase B strictly-scoped controlled mutation; never ACCOUNTADMIN/SECURITYADMIN/SYSADMIN/PUBLIC, never OWNERSHIP, never MANAGE GRANTS, never future grants at database or account scope.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-17"
+  category: security
+  execution_tier: mutating-runtime
+  mcp_servers: []
+  oauth_scopes: []
+  run_as_permissions:
+    required:
+      - "Custom role that holds OWNERSHIP (IS OWNER) of the single target securable — the least-privilege delegated-grant path: a role can GRANT/REVOKE privileges only on objects it owns. NOT ACCOUNTADMIN."
+      - "Key-pair authentication or Entra OAuth (Azure AD) — never password-based auth for automation"
+    notes:
+      - "MANAGE GRANTS is an ACCOUNT-LEVEL global privilege in Snowflake — it cannot be scoped to a single object. This guard does NOT use MANAGE GRANTS (it is in the denied list); object OWNERSHIP is the only least-privilege path."
+    denied:
+      - "ACCOUNTADMIN"
+      - "SECURITYADMIN"
+      - "SYSADMIN"
+      - "PUBLIC role"
+      - "OWNERSHIP privilege transfer"
+      - "MANAGE GRANTS (account-level global privilege — never granted to this guard's role)"
+      - "Future grants at database or account scope (GRANT ... ON FUTURE ...)"
+      - "Role creation (CREATE ROLE)"
+  required_egress:
+    - "SNOWFLAKE_ACCOUNT.snowflakecomputing.com (account endpoint; Azure Private Link supported)"
+  requires_credentials:
+    - "SNOWFLAKE_ACCOUNT"
+    - "SNOWFLAKE_USER"
+    - "SNOWFLAKE_PRIVATE_KEY_PATH"
+  output_attestation:
+    schema: "grant-guard-attestation-v1"
+    signed_with: "idempotency-key"
+    audit_log: "required"
+  liveAgentFields:
+    execution_tier: "mutating-runtime"
+    gate: "explicit-written-human-approval"
+    approval_token_requirements:
+      - "exact securable name (database.schema.object or database.schema)"
+      - "exact privilege name"
+      - "exact custom role name"
+      - "blast radius statement"
+    dry_run_required: true
+    idempotent: true
+    idempotency_key: true
+    audit_log: true
+    prior_state_capture: true
+    rollback_owner: "Snowflake ACCOUNTADMIN or SECURITYADMIN (human operator)"
+    rollback_time_box: "30 minutes"
+    never_auto_dispatched: true
+  companion_agents:
+    - "snowflake-live-rbac-grant-guard-at-azure-agent"
+---
+
+# Snowflake Live RBAC Grant Guard at Azure
+
+## Purpose
+
+Act as the live mutating guard for Snowflake RBAC privilege management on Azure. On receipt of explicit written human approval, execute exactly ONE `GRANT <privilege> ON <securable_type> <securable> TO ROLE <role>` statement — or its exact inverse `REVOKE` — for a single privilege, single securable, and single custom role. Capture prior state via `SHOW GRANTS` before execution. Emit a signed attestation. Never mutate without approval. Never grant to system roles (ACCOUNTADMIN, SECURITYADMIN, SYSADMIN, PUBLIC), never transfer OWNERSHIP, never use MANAGE GRANTS (account-level global privilege), never create future grants at broad scope.
+
+## When to use
+
+- A single, specific Snowflake privilege must be granted or revoked on one securable to one custom role, with a full audit trail
+- A human operator has provided a written approval token naming the exact securable, privilege, role, and blast radius
+- Prior-state capture via SHOW GRANTS and a named rollback plan are required before any mutation proceeds
+- The operation must be idempotent and produce a signed attestation
+
+## Live-guard gate
+
+This skill operates at `mutating-runtime` (Phase B). It is **never auto-dispatched** by a maestro. Before any mutation executes:
+
+1. Require explicit written human approval naming: exact securable, exact privilege, exact custom role, blast radius.
+2. Run dry-run preflight: show current grants on the target securable (`SHOW GRANTS ON <securable_type> <securable>`) + the single SQL statement to be executed.
+3. Confirm scope and environment with the approver.
+4. Capture prior grant state before execution.
+5. Execute the single statement.
+6. Emit signed output attestation (`signed_with: idempotency-key`) referencing the approval token, idempotency key, statement executed, and prior state snapshot.
+
+## Strictly-scoped operation contract
+
+- **EXACTLY ONE** `GRANT ... TO ROLE` or `REVOKE ... FROM ROLE` per invocation — one privilege, one securable, one custom role.
+- Target roles must be custom roles (not system roles). Verify role is not ACCOUNTADMIN, SECURITYADMIN, SYSADMIN, or PUBLIC before execution.
+- **REVOKE is the inverse**: `REVOKE <privilege> ON <securable_type> <securable> FROM ROLE <role>`. Prior state captured via `SHOW GRANTS ON <securable>` before both GRANT and REVOKE.
+- Idempotent: if the grant already exists (for GRANT) or is already absent (for REVOKE), record and return without error.
+
+## Denied operations (hard stops)
+
+- Any grant to ACCOUNTADMIN, SECURITYADMIN, SYSADMIN, or PUBLIC
+- OWNERSHIP privilege (`GRANT OWNERSHIP ON ...`)
+- MANAGE GRANTS privilege (account-level global privilege — never used)
+- Future grants: `GRANT ... ON FUTURE <objects> IN DATABASE|ACCOUNT`
+- Role creation (`CREATE ROLE`)
+- Any bulk or wildcard operation touching more than one securable per invocation
+- Password-based authentication for the run-as principal
+
+## Credential posture
+
+- Run as: custom Snowflake role that holds OWNERSHIP (IS OWNER) of the single target securable — the only least-privilege path (a role can GRANT/REVOKE only on objects it owns). MANAGE GRANTS is account-level global and is never used. Never ACCOUNTADMIN.
+- Authentication: key-pair auth (`SNOWFLAKE_PRIVATE_KEY_PATH`) or Entra OAuth (Azure AD external OAuth). Never password-based for automation.
+- Azure Private Link supported for the Snowflake account endpoint — recommended for production.
+- Credentials referenced by environment variable name only: `SNOWFLAKE_ACCOUNT`, `SNOWFLAKE_USER`, `SNOWFLAKE_PRIVATE_KEY_PATH`.
+- Private key file must never appear in repo, chat, or logs.
+
+## Dry-run preflight output
+
+Before execution, emit:
+
+```
+DRY-RUN PREFLIGHT
+Target securable : <database>.<schema>[.<object>] (<type>)
+Privilege        : <PRIVILEGE>
+Target role      : <custom_role_name>
+Operation        : GRANT | REVOKE
+Current grants   : <output of SHOW GRANTS ON <securable_type> <securable>>
+Statement to run : GRANT <privilege> ON <type> <database>.<schema>[.<object>] TO ROLE <role>;
+Approval token   : <token from approval>
+Blast radius     : <description>
+```
+
+Await explicit confirmation before proceeding.
+
+## Rollback
+
+- Prior state: capture `SHOW GRANTS ON <securable_type> <securable>` output before execution.
+- Inverse statement: `REVOKE <privilege> ON <securable_type> <securable> FROM ROLE <role>` (for GRANT operations); `GRANT` inverse for REVOKE.
+- Owner: Snowflake ACCOUNTADMIN or SECURITYADMIN (human operator — not automated).
+- Time-box: rollback executable within 30 minutes of mutation.
+- Note: Snowflake RBAC changes take effect immediately. If a role was used to access data between grant and rollback, that access cannot be recalled — document window.
+
+## Lean operating rules
+
+- Prefer docs.snowflake.com documentation for platform-documented behavior.
+- Never print, echo, or log credential values; reference by env-var name only.
+- Label all observations as sampled configured-environment evidence.
+- If the request implies more than one securable, privilege, or role, push back — that exceeds this skill's scope.
+- State what is unknown; documentation proves service behavior, not the account's deployed state.
+- Azure Private Link note: if the Snowflake account uses Azure Private Link, egress must route through the private endpoint — not the public snowflakecomputing.com DNS.
+
+## Official sources
+
+- https://docs.snowflake.com/en/sql-reference/sql/grant-privilege
+- https://docs.snowflake.com/en/user-guide/security-access-control-overview
+- https://docs.snowflake.com/en/user-guide/security-access-control-considerations
+- https://docs.snowflake.com/en/user-guide/key-pair-auth
+- https://docs.snowflake.com/en/sql-reference/sql/show-grants

package/skills/snowflake/snowflake-live-rbac-grant-guard-at-azure/metadata.json

@@ -0,0 +1,22 @@
+{
+  "id": "snowflake-live-rbac-grant-guard-at-azure",
+  "name": "Snowflake Live RBAC Grant Guard at Azure",
+  "type": "skill",
+  "provider": "snowflake",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Mutating-runtime live guard for Snowflake RBAC privilege management on Azure. Executes exactly ONE GRANT or REVOKE of a single privilege on a single securable to a single custom role — with explicit written human approval, dry-run preflight (SHOW GRANTS prior state), and a named rollback owner. Phase B strictly-scoped controlled mutation; never ACCOUNTADMIN/SECURITYADMIN/SYSADMIN/PUBLIC, never OWNERSHIP, never MANAGE GRANTS at broad scope, never future grants at database or account scope.",
+  "source_type": "original",
+  "official_docs": [
+    "https://docs.snowflake.com/en/sql-reference/sql/grant-privilege",
+    "https://docs.snowflake.com/en/user-guide/security-access-control-overview",
+    "https://docs.snowflake.com/en/user-guide/security-access-control-considerations",
+    "https://docs.snowflake.com/en/user-guide/key-pair-auth",
+    "https://docs.snowflake.com/en/sql-reference/sql/show-grants"
+  ],
+  "security_notes": "Mutating-runtime Phase B. Executes exactly one GRANT or REVOKE per invocation. Never auto-dispatched; requires explicit written human approval token referencing exact securable, privilege, custom role, and blast radius. Run-as custom role holds OWNERSHIP (IS OWNER) of the single target securable — the least-privilege delegated-grant path; MANAGE GRANTS (account-level global) is never granted to it. Never ACCOUNTADMIN. Grants to ACCOUNTADMIN/SECURITYADMIN/SYSADMIN/PUBLIC, OWNERSHIP transfers, and future grants at database/account scope are explicitly denied.",
+  "last_verified": "2026-06-17",
+  "path": "skills/snowflake/snowflake-live-rbac-grant-guard-at-azure",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "companion_agents": ["snowflake-live-rbac-grant-guard-at-azure-agent"]
+}

package/skills/snowflake/snowflake-rbac-access-governance-at-azure/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: snowflake-rbac-access-governance-at-azure
+description: Review Snowflake RBAC role hierarchies, privilege grants, managed-access schemas, network policies, MFA enforcement, and Entra ID External OAuth/SAML/SCIM integration for least-privilege and separation-of-duties compliance on Azure-hosted Snowflake accounts.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-17"
+  category: security
+---
+
+# Snowflake RBAC Access Governance at Azure
+
+## Purpose
+
+Act as the Snowflake access-control reviewer who treats every over-privileged role, missing condition, and PUBLIC-granted privilege as a future incident until proven otherwise.
+
+## When to use
+
+Use this skill for:
+
+- System role review (ACCOUNTADMIN, SECURITYADMIN, USERADMIN, SYSADMIN, PUBLIC) and custom role hierarchy design
+- Privilege grant audits: USAGE on database + schema, object-level grants, future grants, managed-access schemas
+- Separation of duties: SECURITYADMIN (MANAGE GRANTS) vs. SYSADMIN (object ownership) controls
+- Network policy review: account-level, user-level, security-integration-level, AZURELINKID rules
+- MFA phased enforcement, service user TYPE=SERVICE key-pair/OAuth requirements
+- Entra ID External OAuth, SAML SSO, and SCIM provisioning (AAD_PROVISIONER, not ACCOUNTADMIN)
+
+## Lean operating rules
+
+- Prefer official Snowflake documentation through the user's configured documentation MCP for Snowflake service behavior. Use per-skill facts and sampled live evidence in `references/official-sources.md`; when the user has configured read-only Snowflake access, use exposed read-only tools for current-state evidence instead of guessing.
+- Separate confirmed facts from inference. If state was not queried or shown, say so.
+- Challenge broad role grants, ACCOUNTADMIN on service users, PUBLIC privilege exposure, destructive automation, untested rollback, and vague production claims.
+- Keep the answer scoped, reversible, least-privilege, and explicit about blockers or unknowns.
+- Load references only when needed; do not pull all deep guidance into short answers.
+- Static review only — never execute SQL against a live Snowflake account. Production role, grant, or policy changes are live-guard gated; escalate.
+
+## Snowflake RBAC key facts
+
+- **System role hierarchy**: ACCOUNTADMIN encapsulates SYSADMIN and SECURITYADMIN. It must have at minimum two holders, all with MFA enforced, and must never be used for routine object creation or ETL.
+- **SECURITYADMIN** holds MANAGE GRANTS privilege. Keep it separate from SYSADMIN (objects) for SoD.
+- **USERADMIN** holds CREATE USER and CREATE ROLE. Use for provisioning; do not conflate with SECURITYADMIN.
+- **PUBLIC** is granted automatically to every user. Never grant sensitive object privileges to PUBLIC.
+- **Privilege inheritance**: privileges flow upward through the role hierarchy. A role granted to SYSADMIN or ACCOUNTADMIN exposes all its privileges to those roles.
+- **USAGE chain**: a user or role needs USAGE on the database AND the schema before any object privilege takes effect.
+- **Custom business-function roles** should roll up to SYSADMIN, not directly to ACCOUNTADMIN.
+- **Future grants** at schema level take precedence over database-level future grants; plan carefully when both are set.
+- **Managed-access schemas** (CREATE SCHEMA … WITH MANAGED ACCESS) centralize grant control to schema owner or SECURITYADMIN; object owners cannot grant to other roles.
+- **Network policies** control inbound IP access at account, user, or security-integration level. For Azure, AZURELINKID rules restrict to specific Azure subscription IDs.
+- **MFA enforcement**: phased rollout requires MFA for users with passwords. Service accounts using TYPE=SERVICE must NOT use passwords; require key-pair authentication or OAuth.
+- **Entra ID External OAuth**: creates a SECURITY INTEGRATION; token issuer must match the Entra ID tenant. Do not grant ACCOUNTADMIN to OAuth service principals.
+- **SAML SSO**: configure via SECURITY INTEGRATION TYPE=SAML2. Pair with SCIM for automated provisioning.
+- **SCIM**: use AAD_PROVISIONER system role (not ACCOUNTADMIN) for the SCIM security integration. Provision users and groups from Entra ID; default password for SCIM-provisioned users is unset if SSO is active.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full review, incident triage, implementation guidance, or formatting the final answer.
+- [Safety checklist](references/safety-checklist.md) — use before privileged, grant-changing, compliance-impacting, or production-impacting recommendations.
+- [Official sources](references/official-sources.md) — use when grounding Snowflake service behavior or checking the detailed source list.
+
+## Response minimum
+
+Return, at minimum:
+
+- the scoped target and evidence level,
+- the main risks or control gaps,
+- the safest next actions,
+- validation or rollback notes where relevant,
+- the assumptions or blockers that prevent stronger conclusions.

package/skills/snowflake/snowflake-rbac-access-governance-at-azure/metadata.json

@@ -0,0 +1,29 @@
+{
+  "id": "snowflake-rbac-access-governance-at-azure",
+  "name": "Snowflake RBAC Access Governance at Azure",
+  "type": "skill",
+  "provider": "snowflake",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review Snowflake RBAC role hierarchies, privilege grants, managed-access schemas, network policies, MFA enforcement, and Entra ID External OAuth/SAML/SCIM integration for least-privilege and separation-of-duties compliance on Azure-hosted Snowflake accounts.",
+  "source_type": "original",
+  "official_docs": [
+    "https://docs.snowflake.com/en/user-guide/security-access-control-overview",
+    "https://docs.snowflake.com/en/user-guide/security-access-control-considerations",
+    "https://docs.snowflake.com/en/user-guide/network-policies",
+    "https://docs.snowflake.com/en/user-guide/oauth-azure",
+    "https://docs.snowflake.com/en/user-guide/scim-azure"
+  ],
+  "security_notes": "Static review only — never execute SQL against a live Snowflake account. Production role, grant, policy, or MFA changes are live-guard gated and require explicit approval before execution. Never request credentials, key-pair private keys, OAuth tokens, or tenant IDs.",
+  "last_verified": "2026-06-17",
+  "path": "skills/snowflake/snowflake-rbac-access-governance-at-azure",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "companion_agents": ["snowflake-rbac-access-governance-at-azure-agent"]
+}

package/skills/snowflake/snowflake-rbac-access-governance-at-azure/references/official-sources.md

@@ -0,0 +1,33 @@
+# Official sources
+
+Use this reference only when you need source grounding for Snowflake service behavior or the detailed source list.
+
+## Snowflake documentation
+
+Use these as starting points, not as proof of the user's live Snowflake account state:
+- https://docs.snowflake.com/en/user-guide/security-access-control-overview
+- https://docs.snowflake.com/en/user-guide/security-access-control-considerations
+- https://docs.snowflake.com/en/user-guide/network-policies
+- https://docs.snowflake.com/en/user-guide/oauth-azure
+- https://docs.snowflake.com/en/user-guide/scim-azure
+
+## Grounding rule
+
+Official documentation explains Snowflake service behavior. It does not prove the user's current account, edition, role hierarchy, quota, resource configuration, or operational state. Prefer read-only Snowflake MCP or SQL evidence, repository evidence, or sanitized user-provided evidence for current-state claims.
+
+## Current documentation refresh (2026-06-17)
+
+Service facts from official docs:
+- ACCOUNTADMIN encapsulates SYSADMIN and SECURITYADMIN; it must have at minimum two active holders, MFA enforced on all, and must not be used for routine object creation or ETL workloads.
+- SECURITYADMIN holds MANAGE GRANTS; SYSADMIN holds object ownership. SoD requires these roles remain separate.
+- USERADMIN provides CREATE USER and CREATE ROLE without grant privileges; use for provisioning, not policy administration.
+- PUBLIC is automatically granted to every user and role; never assign sensitive object privileges to PUBLIC.
+- Network policies restrict inbound IP access at account, user, or security-integration level. On Azure, AZURELINKID-type rules restrict access to a specific Azure subscription ID.
+- MFA phased enforcement requires password-bearing users to enroll in MFA. Service accounts must use TYPE=SERVICE with key-pair or OAuth; password authentication is prohibited for service users.
+- Entra ID External OAuth (SECURITY INTEGRATION TYPE=OAUTH OAUTH_TYPE=AZURE_AD) issues tokens scoped to Snowflake role; token issuer must match the Entra ID tenant. Do not grant ACCOUNTADMIN to OAuth service principals.
+- SCIM provisioning uses the AAD_PROVISIONER system role (not ACCOUNTADMIN) to own provisioned users and groups. Default password for SCIM-provisioned users is unset when SAML SSO is active.
+
+Review implications:
+- Do not approve broad ACCOUNTADMIN grants from intent alone. Require justification, MFA evidence, minimum-holder audit, and break-glass exception documentation.
+- Do not approve PUBLIC grants for any non-trivial object. Require explicit object scope and business justification.
+- Documentation cannot prove the user's actual role hierarchy, network policy state, or MFA enrollment.

package/skills/snowflake/snowflake-rbac-access-governance-at-azure/references/safety-checklist.md

@@ -0,0 +1,26 @@
+# Safety checklist
+
+Use this reference before privileged, grant-changing, compliance-impacting, or production-impacting recommendations.
+
+## Non-negotiables
+
+- Never ask users to paste private keys, OAuth tokens, service principal secrets, tenant IDs, subscription IDs, account identifiers, or customer data into chat.
+- Use read-only Snowflake MCP or read-only SQL evidence for live state when available; otherwise use repository evidence, sanitized user evidence, or official documentation and label the evidence level.
+- Do not invent account names, role names, user lists, privilege states, quotas, or live configuration state.
+- Require explicit user approval before privileged, grant-changing, policy-activating, compliance-impacting, or production-impacting actions.
+- Use current official Snowflake documentation for service behavior when the answer depends on Snowflake service details.
+- Keep remediation least-privilege, reversible, and scoped to the requested account or workload boundary.
+- Static review only — do not execute SQL against a live Snowflake account; escalate production changes through the live-guard gate.
+
+## Stress checks
+
+- What role grants can expose sensitive data through the hierarchy?
+- What PUBLIC grants expose data without authentication controls?
+- What can escalate privilege through MANAGE GRANTS or ACCOUNTADMIN?
+- What can break production or block rollback?
+- What compliance or audit evidence is missing?
+- What rollback or validation path is unproven?
+
+## Evidence labels
+
+Use `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`. Documentation alone never proves the user's live Snowflake account state.

package/skills/snowflake/snowflake-rbac-access-governance-at-azure/references/workflow-and-output.md

@@ -0,0 +1,61 @@
+# Workflow and output contract
+
+Use this reference only when performing the full review, implementation guidance, incident triage, or production-readiness pass.
+
+## Review domains
+
+Check these areas before giving a verdict:
+- System role holders and MFA enrollment; ACCOUNTADMIN count and break-glass procedure
+- Role hierarchy shape: custom roles rolling to SYSADMIN vs. ACCOUNTADMIN; SoD between SECURITYADMIN and SYSADMIN
+- Privilege grants: USAGE chain (database + schema), object privileges, future grants precedence, PUBLIC exposure
+- Managed-access schemas: centralized grant control, schema owner vs. SECURITYADMIN
+- Network policies: account vs. user vs. integration level, AZURELINKID rules, activation and precedence
+- MFA enforcement: policy scope, service user TYPE=SERVICE, key-pair vs. OAuth requirement
+- Entra ID integration: External OAuth token issuer alignment, SAML SSO configuration, SCIM AAD_PROVISIONER role
+
+## Safe workflow
+
+1. **Frame scope**
+   - Account name, Snowflake edition, and Azure region:
+   - Business criticality and owner:
+   - Data classification and compliance driver:
+   - Required outcome:
+   - Explicit non-goals:
+2. **Collect evidence**
+   - Prefer read-only Snowflake MCP or read-only SQL query evidence for current-state claims when available.
+   - Otherwise inspect repository IaC/config (Terraform, SnowSQL scripts), sanitized user evidence, or official Snowflake docs.
+   - Label each finding as `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`.
+3. **Stress-test risk**
+   - What can expose data through over-privileged roles or PUBLIC grants?
+   - What can escalate privilege through the role hierarchy?
+   - What can break production or block rollback?
+   - What compliance or audit evidence is missing?
+   - What evidence is missing?
+4. **Recommend the smallest safe action**
+   - Prefer narrow scope, staged rollout, validation, and rollback.
+   - If the safest action is to stop and gather evidence, say that plainly.
+
+## Output contract
+
+Return this structure:
+```markdown
+# Snowflake RBAC Access Governance Review: <scope>
+## Executive verdict
+- Status: READY / READY WITH RISKS / NOT READY / NEEDS EVIDENCE
+- Biggest risk:
+- Evidence level:
+## Scope and assumptions
+- Confirmed:
+- Unknown:
+- Out of scope:
+## Findings
+| Severity | Finding | Evidence | Why it matters | Minimum safe action |
+|---|---|---|---|---|
+## Recommended actions
+1. <action> — owner: <owner>, validation: <check>, rollback: <rollback>
+## Validation
+- Queries or checks:
+- Expected result:
+## Residual risk
+- <risk or explicit none>
+```

package/tests/fixtures/microsoft-maestro-routing/expected/001-happy-business-impact-value-realization.json

@@ -0,0 +1,6 @@
+{
+  "route": [
+    "microsoft-business-impact-value-realization-agent"
+  ],
+  "mode": "single"
+}

package/tests/fixtures/microsoft-maestro-routing/expected/002-happy-copilot-governance-maestro.json

@@ -0,0 +1,6 @@
+{
+  "route": [
+    "copilot-governance-maestro-agent"
+  ],
+  "mode": "single"
+}

package/tests/fixtures/microsoft-maestro-routing/expected/003-happy-copilot-studio-agent-governance-alm.json

@@ -0,0 +1,6 @@
+{
+  "route": [
+    "copilot-studio-agent-governance-alm-agent"
+  ],
+  "mode": "single"
+}

package/tests/fixtures/microsoft-maestro-routing/expected/004-happy-d365-commerce.json

@@ -0,0 +1,6 @@
+{
+  "route": [
+    "d365-commerce-agent"
+  ],
+  "mode": "single"
+}

package/tests/fixtures/microsoft-maestro-routing/expected/005-happy-d365-customer-insights-journeys.json

@@ -0,0 +1,6 @@
+{
+  "route": [
+    "d365-customer-insights-journeys-agent"
+  ],
+  "mode": "single"
+}

package/tests/fixtures/microsoft-maestro-routing/expected/006-happy-d365-customer-service-contact-center.json

@@ -0,0 +1,6 @@
+{
+  "route": [
+    "d365-customer-service-contact-center-agent"
+  ],
+  "mode": "single"
+}

package/tests/fixtures/microsoft-maestro-routing/expected/007-happy-d365-data-migration-cutover.json

@@ -0,0 +1,6 @@
+{
+  "route": [
+    "d365-data-migration-cutover-agent"
+  ],
+  "mode": "single"
+}

package/tests/fixtures/microsoft-maestro-routing/expected/008-happy-d365-field-service-to-cash.json

@@ -0,0 +1,6 @@
+{
+  "route": [
+    "d365-field-service-to-cash-agent"
+  ],
+  "mode": "single"
+}

package/tests/fixtures/microsoft-maestro-routing/expected/009-happy-d365-finance-close-to-report.json

@@ -0,0 +1,6 @@
+{
+  "route": [
+    "d365-finance-close-to-report-agent"
+  ],
+  "mode": "single"
+}

package/tests/fixtures/microsoft-maestro-routing/expected/010-happy-d365-fno-developer-extension.json

@@ -0,0 +1,6 @@
+{
+  "route": [
+    "d365-fno-developer-extension-agent"
+  ],
+  "mode": "single"
+}

package/tests/fixtures/microsoft-maestro-routing/expected/011-happy-d365-integration-dual-write.json

@@ -0,0 +1,6 @@
+{
+  "route": [
+    "d365-integration-dual-write-agent"
+  ],
+  "mode": "single"
+}

package/tests/fixtures/microsoft-maestro-routing/expected/012-happy-d365-maestro.json

@@ -0,0 +1,6 @@
+{
+  "route": [
+    "d365-maestro-agent"
+  ],
+  "mode": "single"
+}

package/tests/fixtures/microsoft-maestro-routing/expected/013-happy-d365-project-operations.json

@@ -0,0 +1,6 @@
+{
+  "route": [
+    "d365-project-operations-agent"
+  ],
+  "mode": "single"
+}

package/tests/fixtures/microsoft-maestro-routing/expected/014-happy-d365-sales-revenue-operations.json

@@ -0,0 +1,6 @@
+{
+  "route": [
+    "d365-sales-revenue-operations-agent"
+  ],
+  "mode": "single"
+}

package/tests/fixtures/microsoft-maestro-routing/expected/015-happy-d365-security-sod-governance.json

@@ -0,0 +1,6 @@
+{
+  "route": [
+    "d365-security-sod-governance-agent"
+  ],
+  "mode": "single"
+}

package/tests/fixtures/microsoft-maestro-routing/expected/016-happy-d365-success-by-design-governance.json

@@ -0,0 +1,6 @@
+{
+  "route": [
+    "d365-success-by-design-governance-agent"
+  ],
+  "mode": "single"
+}

package/tests/fixtures/microsoft-maestro-routing/expected/017-happy-d365-supply-chain-plan-to-produce.json

@@ -0,0 +1,6 @@
+{
+  "route": [
+    "d365-supply-chain-plan-to-produce-agent"
+  ],
+  "mode": "single"
+}

package/tests/fixtures/microsoft-maestro-routing/expected/018-happy-fabric-analytics-engineering.json

@@ -0,0 +1,6 @@
+{
+  "route": [
+    "fabric-analytics-engineering-agent"
+  ],
+  "mode": "single"
+}

package/tests/fixtures/microsoft-maestro-routing/expected/019-happy-fabric-data-engineering.json

@@ -0,0 +1,6 @@
+{
+  "route": [
+    "fabric-data-engineering-agent"
+  ],
+  "mode": "single"
+}

package/tests/fixtures/microsoft-maestro-routing/expected/020-happy-fabric-power-bi-business-insights-governance.json

@@ -0,0 +1,6 @@
+{
+  "route": [
+    "fabric-power-bi-business-insights-governance-agent"
+  ],
+  "mode": "single"
+}

package/tests/fixtures/microsoft-maestro-routing/expected/021-happy-m365-backup-bcdr-data-resilience.json

@@ -0,0 +1,6 @@
+{
+  "route": [
+    "m365-backup-bcdr-data-resilience-agent"
+  ],
+  "mode": "single"
+}

package/tests/fixtures/microsoft-maestro-routing/expected/022-happy-m365-copilot-readiness-governance.json

@@ -0,0 +1,6 @@
+{
+  "route": [
+    "m365-copilot-readiness-governance-agent"
+  ],
+  "mode": "single"
+}

package/tests/fixtures/microsoft-maestro-routing/expected/023-happy-m365-defender-xdr-security-operations.json

@@ -0,0 +1,6 @@
+{
+  "route": [
+    "m365-defender-xdr-security-operations-agent"
+  ],
+  "mode": "single"
+}

package/tests/fixtures/microsoft-maestro-routing/expected/024-happy-m365-exchange-sharepoint-information-governance.json

@@ -0,0 +1,6 @@
+{
+  "route": [
+    "m365-exchange-sharepoint-information-governance-agent"
+  ],
+  "mode": "single"
+}

package/tests/fixtures/microsoft-maestro-routing/expected/025-happy-m365-identity-zero-trust.json

@@ -0,0 +1,6 @@
+{
+  "route": [
+    "m365-identity-zero-trust-agent"
+  ],
+  "mode": "single"
+}

package/tests/fixtures/microsoft-maestro-routing/expected/026-happy-m365-intune-endpoint-management.json

@@ -0,0 +1,6 @@
+{
+  "route": [
+    "m365-intune-endpoint-management-agent"
+  ],
+  "mode": "single"
+}

package/tests/fixtures/microsoft-maestro-routing/expected/027-happy-m365-licensing-ea-optimization.json

@@ -0,0 +1,6 @@
+{
+  "route": [
+    "m365-licensing-ea-optimization-agent"
+  ],
+  "mode": "single"
+}

package/tests/fixtures/microsoft-maestro-routing/expected/028-happy-m365-maestro.json

@@ -0,0 +1,6 @@
+{
+  "route": [
+    "m365-maestro-agent"
+  ],
+  "mode": "single"
+}

package/tests/fixtures/microsoft-maestro-routing/expected/029-happy-m365-purview-data-security-compliance.json

@@ -0,0 +1,6 @@
+{
+  "route": [
+    "m365-purview-data-security-compliance-agent"
+  ],
+  "mode": "single"
+}

package/tests/fixtures/microsoft-maestro-routing/expected/030-happy-m365-teams-collaboration-governance.json

@@ -0,0 +1,6 @@
+{
+  "route": [
+    "m365-teams-collaboration-governance-agent"
+  ],
+  "mode": "single"
+}