Plugin check: Run node "${CLAUDE_PLUGIN_ROOT}/scripts/check-version.js" — if it outputs a message, show it to the user before proceeding.

Audit Permissions

Audit existing table permissions on a Power Pages code site. Analyze permissions against the site code and Dataverse metadata, then generate a visual HTML audit report with findings, reasoning, and suggested fixes.

Workflow

1. Verify Site Deployment — Check that .powerpages-site folder and table permissions exist
2. Gather Configuration — Read all web roles, table permissions, and site code
3. Run Local Schema Validation — Use the shared validator to detect invalid permission/site-setting YAML before deeper analysis
4. Analyze & Discover — Query Dataverse for relationships and lookup columns using deterministic scripts
5. Run Audit Checks — Compare permissions against code usage and best practices
6. Generate Report — Create the HTML audit report and display in browser
7. Present Findings & Track — Summarize findings, record skill usage, and ask user if they want to fix issues

Important: Do NOT ask the user questions during analysis. Autonomously gather all data, then present findings.

Task Tracking

At the start of Step 1, create all tasks upfront using TaskCreate. Mark each task in_progress when starting and completed when done.

Note: The "Run audit checks" phase creates additional per-table tasks dynamically in Step 4.2. These per-table tasks track the systematic A–K checklist for each table independently.

Step 1: Verify Site Deployment

Use Glob to find:

• **/powerpages.config.json — identifies the project root
• **/.powerpages-site/table-permissions/*.tablepermission.yml — existing permissions

If no .powerpages-site folder exists, stop and tell the user to deploy first using /deploy-site. If no table permissions exist, note this as a critical finding (the site may have no data access configured) and continue the audit — there may still be code references that need permissions.

Step 2: Gather Configuration

2.1 Read Web Roles

Read all files matching **/.powerpages-site/web-roles/*.yml. Extract id, name, anonymoususersrole, authenticatedusersrole from each.

2.2 Read Table Permissions

Read all files matching **/.powerpages-site/table-permissions/*.tablepermission.yml. For each permission, extract:

• entityname (permission name)
• entitylogicalname (table)
• scope (numeric code)
• read, create, write, delete, append, appendto (boolean flags)
• adx_entitypermission_webrole (array of web role UUIDs)
• contactrelationship, accountrelationship (if Contact/Account scope)
• parententitypermission, parentrelationship (if parent scope)

2.3 Analyze Site Code

Search the site source code for:

• Web API calls (/_api/)
• Lookup bindings (@odata.bind)
• File uploads (uploadFileColumn, uploadFile, upload*Photo, upload*Image)
• $expand usage ($expand, buildExpandClause, ExpandOption)

Also check for .datamodel-manifest.json in the project root for the authoritative table list.

Build a map of: which tables are referenced in code, which CRUD operations are performed on each, which lookup relationships are used, and which related tables are fetched via $expand (these need read permissions too).

2.4 Run Shared Schema Validator

Run the shared validator against the existing site:

node "${CLAUDE_PLUGIN_ROOT}/scripts/validate-permissions-schema.js" --projectRoot "<PROJECT_ROOT>"

Parse the JSON output and carry the findings into the audit. Treat:

• error findings as critical
• warning findings as warning
• info findings as info

These findings should be included in the final audit report even if the later code/Dataverse analysis also finds additional issues.

After Step 3.1 determines the environment URL, if this audit is running locally with Dataverse access available, rerun the shared validator with live relationship verification enabled and merge any additional findings:

node "${CLAUDE_PLUGIN_ROOT}/scripts/validate-permissions-schema.js" --projectRoot "<PROJECT_ROOT>" --validate-dataverse-relationships --envUrl "<envUrl>"

Use this Dataverse-backed relationship validation only for local runs. Do not require it in CI or other offline contexts.

Step 3: Analyze & Discover (Dataverse API)

Use deterministic Node.js scripts for all Dataverse API calls. These scripts handle auth token acquisition, HTTP requests, and JSON parsing consistently.

3.1 Get Environment URL

pac env who

Extract the Environment URL (e.g., https://org12345.crm.dynamics.com) and use it as <envUrl> in subsequent script calls.

3.2 Query Lookup Columns

For each table that has permissions with create or write enabled, use the lookup query script:

node "${CLAUDE_PLUGIN_ROOT}/skills/audit-permissions/scripts/query-table-lookups.js" --envUrl "<envUrl>" --table "<table_logical_name>"

The script returns a JSON array of { logicalName, targets } for each lookup column. Capture this output for the maps described below.

After querying all tables with create or write permissions, build two maps from the combined results:

1. Source map (table → lookup columns): For each queried table, record which lookup columns it has and their targets. Used in Section H2 to check appendto on the source table.
2. Reverse target map (target table → list of source tables): For each target table found in any lookup's targets array, record which source table(s) reference it. Used in Section H to check append on the target table.

Example: querying order_item returns [{ logicalName: "cr4fc_orderid", targets: ["cr4fc_order"] }]

• Source map: order_item → [{ column: "cr4fc_orderid", targets: ["cr4fc_order"] }]
• Reverse target map: cr4fc_order → [{ sourceTable: "order_item", column: "cr4fc_orderid" }]

Both maps are used in Sections H and H2:

• The source table (with the lookup) needs appendto: true — it links TO other records (checked via the source map)
• Each target table in targets needs append: true — other records link TO it (checked via the reverse target map)

3.3 Query Relationships

For tables with parent-scope permissions, verify the relationship names using the relationship query script:

node "${CLAUDE_PLUGIN_ROOT}/skills/audit-permissions/scripts/query-table-relationships.js" --envUrl "<envUrl>" --table "<parent_table>"

The script returns a JSON array of { schemaName, referencedEntity, referencingEntity, referencingAttribute }. Use schemaName to validate the parentrelationship value in parent-scope permissions.

Error Handling

If any script exits with code 1, skip the API-dependent checks and note which checks were skipped in the report. Do NOT stop the entire audit for auth errors. Use the data model manifest and code analysis as fallback.

Step 4: Run Audit Checks

Use per-table task tracking to systematically run every audit