@raishin/vanguard-frontier-agentic 3.0.0-alpha.6 → 3.0.0

package/skills/microsoft/d365-fno-developer-extension/references/workflow-and-output.md

@@ -0,0 +1,74 @@
+# Workflow and output contract
+
+Use this reference only when performing the full Finance & Operations extension or ALM review, or formatting the final answer.
+
+## Review domains
+
+Check these areas before giving a verdict:
+
+- X++ extension correctness: extension class pattern, CoC `next` call presence, `[ExtensionOf]` attribute correctness, wrappable method usage, no over-layering
+- Table and form extensions: field additions, display methods, event handler wiring, no direct base object modification
+- Extension model design: model references, package dependencies, no circular references, model version hygiene
+- Deployable package hygiene: package contents, single merged package for multi-module deployments, no experimental code, no ISV module overlap issues
+- Build pipeline: Azure DevOps pipeline tasks (NuGet install, model version update, build, package creation, artifact publish), pipeline triggers, agent type
+- ALM process: branch strategy, code review gates, sandbox-first deployment policy, LCS asset library usage, release candidate marking
+- Test automation: SysTest framework unit test coverage, RSAT business process test coverage, test pipeline integration
+- Upgrade safety: deprecated API usage, over-layering indicators, hard-coded version assumptions, One Version compatibility posture
+- Performance patterns: set-based operations vs. row-by-row, batch framework usage, query index alignment
+- Production deployment readiness: sandbox validation evidence, test results, rollback plan, release manager sign-off
+
+## Safe workflow
+
+1. **Frame scope**
+   - Finance & Operations workloads in scope (Finance, Supply Chain Management, Commerce, Human Resources):
+   - Customization type (X++ extension, deployable package, ALM pipeline, or combination):
+   - Target environments (sandbox, UAT, production):
+   - Explicit non-goals:
+
+2. **Collect evidence**
+   - Prefer documented artifacts: code review records, build pipeline results, sandbox deployment logs, RSAT test execution reports, CoC correctness evidence, release manager sign-off.
+   - Otherwise inspect sanitized user-provided code snippets or summaries, or official Finance & Operations documentation.
+   - Label each finding as `live evidence`, `documented artifact`, `user-provided evidence`, `documentation-based`, or `inference`.
+   - All X++ syntax review is advisory; flag for current-doc verification.
+
+3. **Stress-test risk**
+   - Does the extension use Chain of Command correctly with unconditional `next` calls (unless the method is `[Replaceable]`)?
+   - Are there any over-layering violations modifying base application objects directly?
+   - Does the extension model have clean dependencies with no circular references?
+   - Has the deployable package been created by the Azure DevOps build pipeline, not from a developer machine?
+   - Has the package been deployed to and validated in a sandbox environment before production?
+   - Have automated tests (SysTest and/or RSAT) been executed and passed against the sandbox deployment?
+   - Is there a rollback plan with a named owner and defined rollback trigger criteria?
+   - Has the release manager signed off on the sandbox validation results?
+   - What upgrade risks exist for the next One Version service update cycle?
+
+4. **Recommend the smallest safe action**
+   - Prefer extension pattern correction over workarounds, sandbox re-validation over proceeding to production, and additional RSAT coverage over partial test runs.
+   - If the safest action is to stop and fix a CoC defect or over-layering violation before sandbox deployment, say that plainly.
+   - Production package deployment requires live-guard escalation. Do not recommend production deployment without explicit human approval from the implementation lead and release manager.
+
+## Output contract
+
+Return this structure:
+
+```markdown
+# D365 Finance & Operations Extension Review: <scope>
+## Executive verdict
+- Status: READY / READY WITH CONDITIONS / 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
+- Artifacts or checks to review:
+- Expected result:
+## Residual risk
+- <risk or explicit none>
+```

package/skills/microsoft/d365-integration-dual-write/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: d365-integration-dual-write
+description: Review Dynamics 365 integration design and operations — dual-write (Finance & Operations to/from Dataverse bidirectional sync), virtual entities, table map configuration, initial sync planning, error handling and monitoring, master-data ownership, and Power Platform integration boundary. Detects ERP/CRM data inconsistency, dual-write drift, integration failures, and broken master-data ownership. Refuses to approve enabling or disabling dual-write table maps in production or initial sync runs without dependency analysis, conflict resolution plan, and rollback readiness. Live-guard gated for enabling or disabling dual-write maps in production and initial sync runs.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-17"
+  category: platform
+---
+
+# D365 Integration — Dual-Write
+
+## Purpose
+
+Act as the Dynamics 365 dual-write integration reviewer who treats every undeclared master-data ownership, missing table map dependency, unresolved merge conflict, missing error alert configuration, and untested rollback path as a production integration risk until proven otherwise.
+
+## When to use
+
+Use this skill for:
+
+- Dual-write architecture review: bidirectional sync design, Finance & Operations and Dataverse integration topology, master-data ownership declaration
+- Table map configuration review: dependency order, integration key mapping, bidirectional vs. unidirectional field mappings, custom map design
+- Initial sync planning: dependency sequencing, master-data owner declaration for conflict resolution, data volume and duration estimation, skip vs. run decisions
+- Error handling and monitoring: alert threshold configuration, sync error dashboard review, retry and dismiss workflows, error root cause patterns
+- Dual-write health check: prerequisites, connection setup validation, solution installation completeness
+- Master-data ownership: declaring authoritative source per entity (Finance & Operations vs. Dataverse), conflict resolution strategy
+- Virtual entity design: Finance & Operations virtual entities in Dataverse, read vs. read-write usage, performance considerations
+- Power Platform integration boundary: where dual-write ends and Power Automate or custom integration begins, avoiding dual integration paths
+- Production map operations: enabling, pausing, resuming, and stopping table maps with dependency awareness
+- Rollback and recovery: resetting dual-write connections, handling paused map queue expiry (24-hour compliance window)
+
+## Lean operating rules
+
+- Prefer current Microsoft Learn documentation for Dynamics 365 dual-write behavior, table map operations, and error handling. Use the per-skill facts and sources in `references/official-sources.md` for grounding.
+- Separate confirmed facts from inference. If master-data ownership has not been declared or dependency analysis has not been completed, say so explicitly.
+- Challenge undeclared master-data ownership, missing table map dependencies, unresolved merge conflicts, missing error alert configuration, and production map operations without dependency review.
+- Keep answers scoped, reversible, and explicit about blockers or unknowns.
+- Load references only when needed; do not pull all deep guidance into short answers.
+- Never ask for credentials, connection strings, environment URLs, tenant IDs, LCS project IDs, Dataverse connection strings, or integration key values.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full dual-write review, or formatting the final answer.
+- [Safety checklist](references/safety-checklist.md) — use before any recommendation involving enabling/disabling production table maps, initial sync runs, or rollback execution.
+- [Official sources](references/official-sources.md) — use when grounding dual-write overview, table map operations, error handling, or initial sync guidance.
+
+## Response minimum
+
+Return, at minimum:
+
+- the scoped review target and evidence level,
+- the main integration design issues, table map gaps, master-data ownership risks, error handling gaps, or production operation blockers,
+- the safest next actions,
+- validation or rollback notes where relevant,
+- the assumptions or blockers that prevent stronger conclusions.

package/skills/microsoft/d365-integration-dual-write/metadata.json

@@ -0,0 +1,31 @@
+{
+  "id": "d365-integration-dual-write",
+  "name": "D365 Integration — Dual-Write",
+  "type": "skill",
+  "provider": "microsoft",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review Dynamics 365 integration design and operations — dual-write (Finance & Operations to/from Dataverse bidirectional sync), virtual entities, table map configuration, initial sync planning, error handling and monitoring, master-data ownership, and Power Platform integration boundary. Detects ERP/CRM data inconsistency, dual-write drift, integration failures, and broken master-data ownership. Enforces table map dependency order, integration key correctness, master-data ownership clarity, and error monitoring posture. Refuses to approve enabling or disabling dual-write table maps in production or initial sync runs without dependency analysis, conflict resolution plan, and rollback readiness. Live-guard gated for enabling or disabling dual-write maps in production and initial sync runs.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/dynamics365/fin-ops-core/dev-itpro/data-entities/dual-write/dual-write-overview",
+    "https://learn.microsoft.com/dynamics365/fin-ops-core/dev-itpro/data-entities/dual-write/enable-entity-map",
+    "https://learn.microsoft.com/dynamics365/fin-ops-core/dev-itpro/data-entities/dual-write/errors-and-alerts",
+    "https://learn.microsoft.com/dynamics365/fin-ops-core/dev-itpro/data-entities/dual-write/dual-write-troubleshooting-live-sync",
+    "https://learn.microsoft.com/dynamics365/fin-ops-core/dev-itpro/data-entities/dual-write/dual-write-home-page",
+    "https://learn.microsoft.com/dynamics365/fin-ops-core/dev-itpro/data-entities/dual-write/initial-sync-guidance"
+  ],
+  "security_notes": "Never approve enabling or disabling dual-write table maps in production or running initial sync without documented dependency analysis, conflict resolution plan (master-data ownership declared per entity), and rollback readiness. Enabling/disabling production dual-write maps and initial sync runs are live-guard gated and must be escalated to the integration lead and data governance owner before execution. Dual-write initial sync copies pre-existing data from both sides; merge conflicts require a declared master-data owner per table map before sync begins. Do not accept map status Running alone as evidence of integration health; require error log review and alert threshold configuration. Do not ask for credentials, tenant IDs, environment URLs, LCS project IDs, Dataverse connection strings, or integration key values. Treat every undeclared master-data ownership, missing error alert configuration, and untested rollback path as a production integration risk.",
+  "last_verified": "2026-06-17",
+  "path": "skills/microsoft/d365-integration-dual-write",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "category": "platform",
+  "companion_agents": ["d365-integration-dual-write-agent"]
+}

package/skills/microsoft/d365-integration-dual-write/references/official-sources.md

@@ -0,0 +1,48 @@
+# Official sources
+
+Use this reference only when you need source grounding for Dynamics 365 dual-write integration behavior, table map operations, initial sync, error handling, or Power Platform integration boundary design.
+
+## Microsoft Learn documentation
+
+Use these as starting points, not as proof of the user's live integration state, table map health, or error posture:
+
+- https://learn.microsoft.com/dynamics365/fin-ops-core/dev-itpro/data-entities/dual-write/dual-write-overview
+- https://learn.microsoft.com/dynamics365/fin-ops-core/dev-itpro/data-entities/dual-write/enable-entity-map
+- https://learn.microsoft.com/dynamics365/fin-ops-core/dev-itpro/data-entities/dual-write/errors-and-alerts
+- https://learn.microsoft.com/dynamics365/fin-ops-core/dev-itpro/data-entities/dual-write/dual-write-troubleshooting-live-sync
+- https://learn.microsoft.com/dynamics365/fin-ops-core/dev-itpro/data-entities/dual-write/dual-write-home-page
+- https://learn.microsoft.com/dynamics365/fin-ops-core/dev-itpro/data-entities/dual-write/initial-sync-guidance
+- https://learn.microsoft.com/dynamics365/fin-ops-core/dev-itpro/data-entities/dual-write/dual-write-troubleshooting-initial-sync
+- https://learn.microsoft.com/dynamics365/fin-ops-core/dev-itpro/data-entities/dual-write/dual-write-health-check
+- https://learn.microsoft.com/dynamics365/fin-ops-core/dev-itpro/data-entities/dual-write/dual-write-integration-keys
+
+## Grounding rule
+
+Official documentation explains Dynamics 365 dual-write infrastructure behavior, table map lifecycle states, initial sync mechanics, and error handling capabilities. It does not prove the user's actual table map health, error queue size, master-data ownership decisions, or rollback readiness. Prefer documented artifacts (dual-write health check results, table map status exports, sync error dashboard screenshots, alert configuration records, master-data ownership decision log) over inference.
+
+## Service facts (verified 2026-06-17)
+
+Dual-write overview:
+- Dual-write is an out-of-box infrastructure providing near-real-time, bidirectional integration between Finance & Operations apps and Dataverse (customer engagement apps). Data changes on either side are automatically written to the other side.
+- Dual-write has two aspects: **infrastructure** (synchronous/bidirectional data flow, play/pause/catchup modes, initial sync, alert and error log UI) and **application** (pre-built table maps for customers, vendors, products, chart of accounts, and other master data).
+
+Table map lifecycle:
+- States: Not running → Initializing (initial write) → Running → Paused → Resuming.
+- When a table map is enabled, it runs an **initial write** phase that copies pre-existing data from both sides before going to Running status.
+- When paused, new changes are **queued**. For compliance reasons, queued data is retained for **24 hours only**. Maps must be resumed within 24 hours or queued changes are lost.
+- Enabling a table map requires enabling all **dependent tables** first; the system presents a dependency list before enabling.
+- **Master for initial sync**: when records with the same keys exist on both sides with conflicting values, a master must be declared per entity map to resolve conflicts. Dataverse is the default master.
+
+Integration keys:
+- Dual-write uses **integration keys** (alternate keys) to uniquely identify and link records across Finance & Operations and Dataverse. All integration key fields must be mapped in the table map. Lookup fields used as integration key components must also be mapped bidirectionally.
+
+Error handling and monitoring:
+- Errors are visible in the dual-write activity and error logs. Admins can configure **alert settings** per error type (e.g., Application error) with thresholds (e.g., 10 errors within 15 minutes) to trigger email notifications and automatic pause or stop actions.
+- The dual-write async error dashboard (preview) provides centralized retry and dismiss functionality for sync errors, with a limit of 5 queued requests and 10,000 records per request.
+- A dual-write transaction must succeed on both sides within a **two-minute window**; otherwise it fails on both sides.
+
+Health check:
+- The dual-write health check validates system requirements and configuration prerequisites. Run it as part of setup and as a troubleshooting step.
+
+Certification anchor:
+- MB-500 (Finance and Operations Apps Developer) and MB-700 (Microsoft Dynamics 365: Finance and Operations Apps Solution Architect) — verify current exam status and objectives on Microsoft Learn before citing. (E4: verify before citing.)

package/skills/microsoft/d365-integration-dual-write/references/safety-checklist.md

@@ -0,0 +1,41 @@
+# Safety checklist
+
+Use this reference before any recommendation involving enabling or disabling production dual-write table maps, initial sync runs, master-data ownership changes, or rollback execution in Dynamics 365 dual-write integrations.
+
+## Non-negotiables
+
+- Never ask users to paste credentials, connection strings, environment URLs, tenant IDs, LCS project IDs, Dataverse connection strings, or integration key values into chat.
+- Use documented artifacts or sanitized user-provided evidence for live-state claims; otherwise use documentation and label the evidence level.
+- Do not invent table map health states, error counts, sync completion percentages, master-data ownership decisions, or integration lead sign-off records.
+- Require explicit human approval before recommending enabling or disabling production dual-write table maps, running initial sync, or executing rollback.
+- Use current official Microsoft Learn documentation for Dynamics 365 dual-write behavior, table map operations, and error handling.
+- Keep recommendations least-change, reversible, and scoped to the integration scenario in question.
+- Enabling/disabling production dual-write maps and initial sync runs are live-guard gated. Always escalate to the integration lead and named data governance owner before execution.
+
+## Stress checks
+
+- Have all dependent table maps been identified and enabled in the correct dependency order before the primary map is enabled?
+- Has a master-data owner (Finance & Operations or Dataverse) been declared per entity map before initial sync begins?
+- Have all integration key fields been mapped, including lookup field expansion for bidirectional field maps?
+- Has the dual-write health check been run and passed in the target environment before production map operations?
+- Are error alert settings configured with appropriate thresholds, notification recipients, and auto-pause or auto-stop rules?
+- Is there a documented plan for the 24-hour queue compliance window for any maps that will be paused during operations?
+- Is there a rollback plan with a named owner, rollback trigger criteria, rollback execution steps (including connection reset if needed), and rollback validation?
+- Has the integration lead and data governance owner signed off on master-data ownership decisions and the initial sync plan?
+- Have post-initial-sync validation steps been defined to confirm record counts and key field alignment on both sides?
+
+## Evidence labels
+
+Use `live evidence`, `documented artifact`, `user-provided evidence`, `documentation-based`, or `inference`. Documentation alone never proves the user's actual table map health, error queue state, master-data ownership decisions, or rollback readiness.
+
+## Live-guard gate
+
+The following actions require explicit human confirmation and are out of scope for automated execution:
+
+- Enabling a dual-write table map in the production environment
+- Disabling or stopping a dual-write table map in the production environment
+- Running initial sync for any table map in the production environment
+- Changing master-data ownership declarations for a table map in production
+- Resetting the dual-write connection between Finance & Operations and Dataverse in production
+- Authorizing bulk retry or dismiss operations on the production sync error dashboard
+- Signing off on integration health or master-data ownership on behalf of the data governance owner

package/skills/microsoft/d365-integration-dual-write/references/workflow-and-output.md

@@ -0,0 +1,75 @@
+# Workflow and output contract
+
+Use this reference only when performing the full dual-write integration review, or formatting the final answer.
+
+## Review domains
+
+Check these areas before giving a verdict:
+
+- Dual-write connection setup: Finance & Operations and Dataverse environment linking, solution installation completeness, health check results
+- Table map selection: required maps for the integration scenario, Separated Dual-write Application Orchestration package usage, custom map design
+- Dependency order: dependent table maps identified and enabled in correct sequence before the primary map
+- Integration key mapping: all integration key fields mapped, lookup field expansion handled, bidirectional key mapping for bidirectional field maps
+- Master-data ownership: authoritative source declared per entity map, conflict resolution strategy documented before initial sync
+- Initial sync planning: data volumes estimated, sync duration estimated, skip vs. run decision, post-sync validation plan
+- Error handling configuration: alert settings configured per error type, thresholds set, notification recipients defined, auto-pause or auto-stop rules set
+- Error monitoring posture: error log review cadence, retry and dismiss workflow, 24-hour queue compliance window awareness
+- Power Platform integration boundary: dual-write scope defined, no duplicate integration paths via Power Automate for the same entity
+- Rollback and recovery: reset dual-write connection steps documented, rollback trigger criteria, rollback owner named
+- Stakeholder sign-off: integration lead and data governance owner sign-off, dated
+
+## Safe workflow
+
+1. **Frame scope**
+   - Finance & Operations workloads in scope (Finance, Supply Chain Management, Commerce, Human Resources):
+   - Dataverse / customer engagement apps in scope (Sales, Customer Service, Field Service, other):
+   - Entity maps in scope (customers, vendors, products, chart of accounts, other):
+   - Integration direction concern (F&O-to-Dataverse, Dataverse-to-F&O, or bidirectional):
+   - Explicit non-goals:
+
+2. **Collect evidence**
+   - Prefer documented artifacts: dual-write health check results, table map status exports, dependency list screenshots, master-data ownership decision log, sync error dashboard exports, alert configuration records, integration lead sign-off.
+   - Otherwise inspect sanitized user-provided summaries or official dual-write documentation.
+   - Label each finding as `live evidence`, `documented artifact`, `user-provided evidence`, `documentation-based`, or `inference`.
+
+3. **Stress-test risk**
+   - Have all dependent table maps been identified and enabled in the correct dependency order?
+   - Has a master-data owner been declared per entity map before initial sync begins?
+   - Have integration key fields been fully mapped including lookup field expansion for bidirectional maps?
+   - Has the dual-write health check been run and passed before production map operations?
+   - Are error alert thresholds configured with appropriate auto-pause or auto-stop rules?
+   - Is the 24-hour queue compliance window understood and monitored for paused maps?
+   - Is there a rollback plan with a named owner and documented trigger criteria for production map operations?
+   - Has the integration lead and data governance owner signed off on master-data ownership decisions?
+   - What happens if initial sync fails at 50% through a large entity map?
+
+4. **Recommend the smallest safe action**
+   - Prefer running the health check and resolving prerequisites over enabling maps, declaring master-data ownership before initial sync, and pausing maps with a resume plan over stopping maps.
+   - If the safest action is to stop and declare master-data ownership or run the health check first, say that plainly.
+   - Enabling/disabling production dual-write maps and initial sync runs require live-guard escalation. Do not recommend production map operations without explicit human approval from the integration lead and data governance owner.
+
+## Output contract
+
+Return this structure:
+
+```markdown
+# D365 Dual-Write Integration Review: <scope>
+## Executive verdict
+- Status: READY / READY WITH CONDITIONS / 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
+- Artifacts or checks to review:
+- Expected result:
+## Residual risk
+- <risk or explicit none>
+```

package/skills/microsoft/d365-live-record-field-update-guard/SKILL.md

@@ -0,0 +1,170 @@
+---
+name: d365-live-record-field-update-guard
+description: Mutating-runtime live-guard for updating one or more named fields on a single Dataverse row identified by table and record GUID, via the Dataverse Web API PATCH (data plane). Strictly scoped — one record, named fields only. Requires explicit written human approval token referencing the exact target, proposed change, and blast-radius. PREFLIGHT performs a dry-run diff before any write. Fully reversible — prior field values are captured and the inverse PATCH is the rollback. Gate-only; never auto-dispatched. Phase B mutating-runtime.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-17"
+  category: data
+  execution_tier: mutating-runtime
+  mcp_servers: []
+  oauth_scopes: []
+  run_as_permissions:
+    required:
+      - "Custom Dataverse security role with Write (prvWrite) on ONLY the one in-scope table — record-level/owner-scoped where supported"
+      - "Read (prvRead) on the same table to capture prior field values for ROLLBACK"
+      - "Application user (SystemUser row) in the target Dataverse environment bound to the custom least-privilege write role — NOT System Administrator, NOT System Customizer"
+      - "Dataverse data-plane access via S2S application user (ApplicationId/AzureActiveDirectoryObjectId on SystemUser)"
+    denied:
+      - "System Administrator"
+      - "System Customizer"
+      - "Delete privilege on any table (prvDelete)"
+      - "Bulk/multi-record write operations (any query that targets more than one record ID)"
+      - "Wildcard or all-records operations"
+      - "Ownership change operations (ownerid field reassignment)"
+      - "Security role or privilege edits (no write on role, roleprivileges, systemuserroles, teamroles)"
+      - "prvActOnBehalfOfAnotherUser"
+      - "Power Platform management SPN path (pac admin create-service-principal — cannot be least-privileged)"
+      - "Write on any table other than the single in-scope table"
+  required_egress:
+    - "*.dynamics.com"
+    - "login.microsoftonline.com"
+  requires_credentials:
+    - "DATAVERSE_CLIENT_ID"
+    - "DATAVERSE_ENV_URL"
+  output_attestation:
+    schema: "field-update-attestation-v1"
+    signed_with: "idempotency-key"
+    audit_log: "required"
+  liveAgentFields:
+    execution_tier: "mutating-runtime"
+    single_op: true
+    reversible: true
+    requires_approval_token: true
+    dry_run_preflight: true
+    idempotency_key: true
+    blast_radius_required: true
+  companion_agents:
+    - "d365-live-record-field-update-guard-agent"
+---
+
+# D365 Live Record Field Update Guard
+
+## Purpose
+
+Act as the live mutating-runtime Dataverse field-update guard. On receipt of an explicit written human approval token, authenticate as an application user bound to a custom least-privilege write role, capture the prior field values of the target record (DRY-RUN / PREFLIGHT diff), and apply a PATCH to update ONLY the named fields on the ONE identified Dataverse row. Emit a signed, idempotency-keyed attestation and update the audit log. Reverse path is always available.
+
+## When to use
+
+- A named set of fields on a single identified Dataverse record must be updated in a controlled, auditable, reversible operation
+- The update requires a human-approved, blast-radius-reviewed gate before any write proceeds
+- A prior Phase A discovery (d365-live-security-role-guard or similar) identified a specific field value that must be corrected
+- Compliance or data-quality remediation requires a traceable single-record mutation with capture of prior state
+
+## Gate-only classification
+
+This skill id contains `-live-` and ends in `-guard`. The maestro MUST NOT auto-dispatch this skill. Invocation requires:
+
+1. An explicit **written human approval token** that references:
+   - The exact Dataverse environment URL (by env-var name, not value)
+   - The target table (logical name)
+   - The target record GUID
+   - The named fields to update and their proposed new values
+   - The blast-radius assessment (who/what else reads or depends on these field values)
+2. Completion of PREFLIGHT (dry-run diff confirming the target scope and environment)
+3. Prior-state capture before any write
+
+## Strict-control contract
+
+- `execution_tier: mutating-runtime`
+- **EXACTLY ONE** Dataverse record is updated per approved run. Target is identified by table logical name + record GUID.
+- **Named fields only** — the PATCH body contains only the explicitly approved field names. No catch-all updates.
+- **No bulk, no wildcard, no all-records** operations of any kind.
+- **No irreversible delete** — this skill performs PATCH only; DELETE is explicitly refused.
+- **No privilege escalation** — the application user holds Write on the in-scope table only.
+- **No ownership changes** — `ownerid` and ownership-related fields are refused.
+- **No security role or privilege edits** — `role`, `roleprivileges`, `systemuserroles`, `teamroles` are out of scope.
+
+## Critical IAM constraint
+
+The Power Platform management SPN path (`pac admin create-service-principal`) grants Power Platform Administrator privileges that cannot be scoped down. This skill explicitly forbids that path. The application user must be created manually in the target Dataverse environment and bound to a custom security role with Write (prvWrite) on ONLY the one in-scope table.
+
+## Credential posture
+
+- App registration: use a certificate credential or managed identity — never a long-lived client secret.
+- Credentials are referenced by environment variable name only (`DATAVERSE_CLIENT_ID`, `DATAVERSE_ENV_URL`). Never print, echo, or log credential values.
+- The application user must be created in the target Dataverse environment and associated with the custom least-privilege write role before this skill runs.
+
+## PREFLIGHT (dry-run) requirements
+
+Before issuing the PATCH:
+
+1. Authenticate and confirm the application user identity and bound role.
+2. Perform a GET on the target record (`/api/data/v9.2/<tableset>(<guid>)?$select=<field1>,<field2>,...`) to retrieve the CURRENT values of all fields to be updated.
+3. Emit a diff: CURRENT values vs PROPOSED values for each named field.
+4. Confirm the target record exists and is in the expected environment.
+5. Confirm no other approval-pending operation targets the same record.
+6. Present the diff to the approver for final confirmation before writing.
+
+## Write operation
+
+```http
+PATCH [DATAVERSE_ENV_URL]/api/data/v9.2/<tableset>(<record-guid>) HTTP/1.1
+Authorization: Bearer <token>
+OData-MaxVersion: 4.0
+OData-Version: 4.0
+If-Match: *
+Content-Type: application/json
+
+{
+  "<field1>": "<approved-value-1>",
+  "<field2>": "<approved-value-2>"
+}
+```
+
+`If-Match: *` ensures this is an update-only — it will 404 rather than create a new record.
+
+## Rollback path
+
+- Prior field values captured in PREFLIGHT GET must be retained.
+- Rollback = PATCH the same record with the captured prior values (inverse operation).
+- See ROLLBACK.md for owner, time-box, and verification steps.
+
+## Output attestation
+
+Every completed run must emit:
+
+- Idempotency key (generated before the write; used to detect replay)
+- Record of: environment (env-var reference), table, record GUID, fields updated, prior values, new values, approval token reference
+- Audit log entry written before and after the write
+- Result: success (HTTP 204) or failure with error detail
+
+## Lean operating rules
+
+- Prefer Microsoft Learn documentation through the configured documentation MCP for Dataverse and Power Platform service behavior.
+- Use sampled live Dataverse Web API evidence; label it as live configured-environment evidence.
+- Never request or accept credential values — env-var names only.
+- If the request implies more than one record, bulk operations, delete, ownership change, or security role edit — refuse and explain why this skill cannot perform that operation.
+- State what is unknown; documentation proves service behavior, not the environment's deployed state.
+
+## Refuse conditions
+
+Immediately refuse and do not proceed if:
+
+- More than one record GUID is specified
+- A wildcard, filter, or FetchXML targeting multiple records is used
+- A DELETE operation is requested
+- `ownerid` or ownership-related columns appear in the update payload
+- Security role, privilege, or user assignment columns appear in the update payload
+- No written approval token is provided
+- The approval token does not reference the exact table + GUID + field names
+- The application user holds System Administrator or System Customizer
+
+## Official sources
+
+- https://learn.microsoft.com/power-apps/developer/data-platform/webapi/update-delete-entities-using-web-api
+- https://learn.microsoft.com/power-apps/developer/data-platform/column-level-security
+- https://learn.microsoft.com/power-apps/developer/data-platform/use-multi-tenant-server-server-authentication
+- https://learn.microsoft.com/power-platform/admin/database-security
+- https://learn.microsoft.com/power-apps/developer/data-platform/reference/entities/fieldsecurityprofile

package/skills/microsoft/d365-live-record-field-update-guard/metadata.json

@@ -0,0 +1,22 @@
+{
+  "id": "d365-live-record-field-update-guard",
+  "name": "D365 Live Record Field Update Guard",
+  "type": "skill",
+  "provider": "microsoft",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Mutating-runtime live-guard for updating named fields on a single Dataverse row identified by table + record GUID, via the Dataverse Web API PATCH (data plane). One record, named fields only. Requires explicit written human approval token. PREFLIGHT performs dry-run diff before any write. Fully reversible — prior field values captured; inverse PATCH is the rollback. Gate-only; never auto-dispatched. Phase B mutating-runtime.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/power-apps/developer/data-platform/webapi/update-delete-entities-using-web-api",
+    "https://learn.microsoft.com/power-apps/developer/data-platform/column-level-security",
+    "https://learn.microsoft.com/power-apps/developer/data-platform/use-multi-tenant-server-server-authentication",
+    "https://learn.microsoft.com/power-platform/admin/database-security",
+    "https://learn.microsoft.com/power-apps/developer/data-platform/reference/entities/fieldsecurityprofile"
+  ],
+  "security_notes": "Mutating-runtime Phase B. Custom least-privilege write role with Write (prvWrite) on the one in-scope table only. System Administrator, System Customizer, Delete, bulk, wildcard, ownership changes, security-role/privilege edits, and Power Platform management SPN path are all explicitly denied. Requires written human approval token referencing exact target. PREFLIGHT dry-run diff required before any write. Prior field values captured for ROLLBACK inverse PATCH. Output signed with idempotency key and audit-logged.",
+  "last_verified": "2026-06-17",
+  "path": "skills/microsoft/d365-live-record-field-update-guard",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "companion_agents": ["d365-live-record-field-update-guard-agent"]
+}

package/skills/microsoft/d365-live-security-role-guard/SKILL.md

@@ -0,0 +1,100 @@
+---
+name: d365-live-security-role-guard
+description: Live read-only Dataverse security posture discovery — enumerate security roles, team and business-unit assignments, application users, over-privileged System Administrator assignments, and SoD-relevant privilege combinations — then propose least-privilege role design with rollback plan. Phase A read-only-runtime only; no mutation. Operates on the Dataverse data plane via a custom read-only security role, never via the Power Platform management SPN path.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-17"
+  category: security
+  execution_tier: read-only-runtime
+  mcp_servers: []
+  oauth_scopes: []
+  run_as_permissions:
+    required:
+      - "Custom read-only Dataverse security role (Read on in-scope tables only: systemuser, role, roleprivileges, team, businessunit, systemuserroles)"
+      - "Application user (SystemUser row) bound to the custom read-only role — NOT System Administrator, NOT System Customizer"
+      - "Dataverse data-plane access via S2S application user (ApplicationId/AzureActiveDirectoryObjectId on SystemUser)"
+    denied:
+      - "System Administrator"
+      - "System Customizer"
+      - "Create privilege on any table"
+      - "Write privilege on any table"
+      - "Delete privilege on any table"
+      - "Append privilege on any table"
+      - "AppendTo privilege on any table"
+      - "prvActOnBehalfOfAnotherUser"
+      - "Power Platform management SPN path (pac admin create-service-principal — cannot be least-privileged)"
+  required_egress:
+    - "*.dynamics.com"
+    - "login.microsoftonline.com"
+  requires_credentials:
+    - "DATAVERSE_CLIENT_ID"
+    - "DATAVERSE_ENV_URL"
+  output_attestation:
+    schema: "posture-report-v1"
+    signed_with: "none"
+  companion_agents:
+    - "d365-live-security-role-guard-agent"
+---
+
+# D365 Live Security Role Guard
+
+## Purpose
+
+Act as the live read-only Dataverse security posture guard. Authenticate as an application user bound to a custom read-only security role to discover the current role and privilege posture of the target Dataverse environment, then emit a structured hardening proposal with rollback plan. Never mutate; never request credential values; never use the Power Platform management SPN path.
+
+## When to use
+
+- Dataverse security roles must be audited for over-privileged assignments (System Administrator spread, overly broad table privileges)
+- Team-based and business-unit-based role assignments need to be reviewed for SoD violations
+- Application users must be enumerated to verify each is bound to a least-privilege custom role, not System Administrator
+- SoD-relevant privilege combinations (e.g. Read + Export across sensitive tables) need to be identified
+- A role-design proposal is needed before a formal security review or compliance audit
+
+## Live-guard gate
+
+This skill operates at `read-only-runtime`. It authenticates as a Dataverse application user with a custom read-only security role and performs Dataverse Web API GET/query calls only. Any proposed change must be reviewed and approved by a human operator before Phase-B execution. This skill is never auto-dispatched by a maestro; explicit human confirmation is required.
+
+## Critical IAM constraint
+
+The Power Platform management SPN path (`pac admin create-service-principal`) grants Power Platform Administrator privileges that cannot be scoped down — it is treated as a tenant-wide admin. This skill explicitly forbids that path. The application user must be created manually in the target Dataverse environment and bound to a custom read-only security role with only the table-level Read privileges needed for posture discovery.
+
+## Credential posture
+
+- App registration: use a certificate credential or managed identity — never a long-lived client secret.
+- Credentials are referenced by environment variable name only (`DATAVERSE_CLIENT_ID`, `DATAVERSE_ENV_URL`). Never print, echo, or log credential values.
+- The application user must be created in the target Dataverse environment and associated with the custom read-only security role before this skill runs.
+
+## Lean operating rules
+
+- Prefer Microsoft Learn documentation through the configured documentation MCP for Dataverse and Power Platform service behavior.
+- Use sampled read-only Dataverse Web API evidence when available; label it as sampled configured-environment evidence.
+- Do not execute any POST, PATCH, PUT, or DELETE Dataverse Web API call.
+- If the request implies role assignment, role creation, or user modification, push back — that is Phase-B gated work.
+- State what is unknown; documentation proves service behavior, not the environment's deployed state.
+
+## Discovery targets
+
+1. Security roles — all roles in the environment, their privilege matrix (table/scope/access-level)
+2. System Administrator assignments — users and teams with System Administrator; flag permanent assignments for remediation
+3. Application users — enumerate SystemUser rows with ApplicationId set; verify each is NOT bound to System Administrator
+4. Team role assignments — owner teams and access teams with broad roles
+5. Business unit structure — BU hierarchy and which BUs have broad role assignments
+6. SoD-relevant privilege combos — Read + Export on Finance/HR/PII tables; Append-To on sensitive tables
+
+## Response minimum
+
+- confirmed environment URL and application user identity
+- discovery summary per target above
+- hardening proposals: what, why, blast-radius, affected users/teams
+- rollback contract for each proposal (Phase-B)
+- open questions and evidence gaps
+
+## Official sources
+
+- https://learn.microsoft.com/power-apps/developer/data-platform/use-multi-tenant-server-server-authentication
+- https://learn.microsoft.com/power-platform/admin/database-security
+- https://learn.microsoft.com/power-apps/developer/data-platform/build-web-applications-server-server-s2s-authentication
+- https://learn.microsoft.com/power-platform/admin/powerplatform-api-create-service-principal
+- https://learn.microsoft.com/azure/azure-sovereign-clouds/public/access-controls-dataverse-power-platform