[kingwil]

Maintainer scope / stacked dependency

Separate explicitly authorized toolkit-maintainer implementation. This fork PR isolates the new route on kingwil/toolkit-reviewed-workbook-updates (8d45648), since upstream oferInbar#9 remains OPEN. No oferInbar branch was modified. After PR9 merges, carry a3a077d into a new upstream PR against Solution-toolkit-master.

Supported normal ARM route

Add python -m sentinel_xdr_migration.arm_workbook_deployment plan|review|execute, separate from extension-direct dispatch and all-content acceptance. Current clean authored review receipts and existing V3.1 package projection/exact versioned ZIP checks remain mandatory. Bind original and semantic-compact template hashes, parameter/request hashes, package identity, exact target, delegated ARM user object ID, CLI/profile and every effective resource to user review and immediate confirmation.

Only DeployDefenderWorkbook is true; every other declared Deploy* flag is explicitly false. Enumerate unconditional registrations and nested deployments, do not suppress them or pretend this is workbook objects only. Preserve public files, all strings/query whitespace, IDs and versions. Bound the full request including conservative CLI serialization to 4 MiB.

Execution checks the existing account/token and live workspace identity, reruns exact-byte Provider validation, durably reserves one attempt, then submits the whole template via authenticated Azure CLI az rest to normal resource-group Deployments PUT. ARM owns nested preview-provider execution; the toolkit makes no extension-direct authentication claims. Poll the exact ARM deployment record; only terminal Succeeded without errors passes. Errors/unknown outcomes remain durable and block blind retry.

No existing workflow gate is completed/imported by this receipt. Installation, repeat-install/update, extension-direct contract, runtime/UI and completed Qualification remain unverified. No Graph/AH credential reuse, sign-in, grants, active rule deployment, ingestion or browser operations. Canonical docs distinguish the routes.

Verification / limitations

• 136 passed, 1 deselected, 17 subtests passed: new route + existing acceptance/preflight. The excluded unchanged baseline assertion compares POSIX and native Windows paths.
• Three additional existing ARM producer/validation regression cases passed in UTF-8 mode. Broader existing ARM tests encountered unchanged Windows read-only snapshot teardown errors/default cp1252 decoding errors; no unrelated fixes. Known residue cleaned.
• Offline actual-package compatibility checks passed for XDR 3.2.2: 11 effective resources, full request conservative bound 3,965,185 bytes; O365 3.2.1: 8 resources, 1,395,798 bytes. These are LOCAL checks, not live provider acceptance.
• Module CLI help and git diff --check passed.

No Azure cloud resource write/deployment was performed. Earlier Provider validation is permission/template evidence, not successful write. Actual execution still requires exact-scope user approval and immediate confirmation, then live ARM success; workbook installation/readback and runtime qualification remain separate.

[kingwil]

Maintainer follow-up: d58b621 fixes Azure CLI ARM token preflight to use --subscription only. Azure CLI rejects combining --subscription with --tenant. The existing exact approved token tid, delegated user principal, audience, expiry and scope checks remain unchanged at both preflight identity checks.

Validation: all 17 focused synthetic ARM workbook deployment tests passed; the runner now rejects combined arguments. Regression coverage verifies both subscription-only checks, wrong-tenant rejection before validation/reservation/write, reuse of an unchanged approved plan after a preflight-only failure, and continued no-retry after submission. git diff --check passed. Documentation explains the existing retry/approval boundary; scope, gates and approval semantics are unchanged.

Offline inspection of both existing approved local plans confirms unchanged plan hashes/provenance/snapshots, blocked preflight evidence with writeAttempted=false, and no attempt.json. Both existing reviews were still sealed, approved and fresh when checked. The same plans remain eligible for a subsequent separately confirmed execution under all existing gates; an expired review requires renewed explicit same-hash approval, not replanning unless inputs change. No evidence was deleted, no approval renewed, and no actual Azure CLI/cloud operation or deployment was performed for this fix.

This remains stacked on the existing base; no upstream branch was modified.