/migrate-webapi-selectall

name: migrate-webapi-selectall
description: >-
  Reviews and migrates deprecated wildcard (*) values in Power Pages Web API
  fields site settings to least-privilege explicit Dataverse columns.
  Use whenever a user mentions Web API wildcard or select-all remediation,
  fields settings containing *, data-exposure review, wildcard deprecation
  readiness, or Web API failures after wildcard retirement. Applies to both
  non-SPA sites using HTML, CSS, JavaScript, Liquid, and downloaded YAML,
  and SPA sites using React, Vue, Angular, Astro, or TypeScript. The agent must
  inspect every source Web API call and consumer, report exact fixes for every
  wildcard, report every already-explicit configuration, apply approved edits,
  and verify no wildcard remains.
user-invocable: true
argument-hint: Optional Power Pages project path
allowed-tools: Read, Write, Edit, Bash, Grep, Glob, AskUserQuestion, TaskCreate, TaskUpdate, TaskList
model: opus

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

Migrate Power Pages Web API Wildcards

Replace every deprecated `Webapi/<table>/fields = *` value with the smallest explicit column set proven by the site's actual Web API behavior.

The LLM owns source discovery, call-chain reasoning, field decisions, report writing, and edits. Use the bundled script only to retrieve authoritative Dataverse table schema; it must not decide which columns the code needs.

Support both:

• non-SPA sites with HTML, JavaScript, Liquid, web templates, and

aggregate YAML;

• SPA sites with React, Vue, Angular, Astro, TypeScript, downloaded

deployment YAML, or mixed custom JavaScript.

**Initial request:** $ARGUMENTS

Non-negotiable rules

1. Review every discovered source table Web API call, including shared wrappers, dynamic builders, and response consumers. 2. Review every configuration scope and deployment-profile copy. 3. Map request `EntitySetName` values to setting logical names using table schema. Never singularize, pluralize, or guess. 4. Treat `*` as unsupported for reads, writes, aggregates, FetchXML, files, and images. 5. Give every wildcard an exact proposed replacement before editing anything. 6. Report every already-explicit fields setting, including missing and potentially unnecessary columns. 7. Never apply a partial wildcard plan. Resolve all wildcards and call-site rows first. 8. Keep reports free of absolute local paths, tokens, URLs, data values, filter literals, request bodies, response bodies, and source snippets, and build them only by rendering the bundled template with the bundled script. 9. Preserve unrelated YAML structure and values. 10. Verify with a fresh discovery pass, not remembered inventory. 11. Leave only the rendered report and its icon in the migration output directory. 12. Never download or upload site content until the user has explicitly confirmed the environment, website, site type, data model, and deployment profile. Neither transfer can be reverted. 13. Run smoke tests only after explicit approval, and never issue POST, PATCH, PUT, or DELETE Web API calls against a deployed site. Testing a write destroys real record data.

Read [references/column-analysis.md](references/column-analysis.md) before analyzing calls. Read [references/configuration-and-reporting.md](references/configuration-and-reporting.md) before inventorying settings or writing the report. Read [references/site-transfer.md](references/site-transfer.md) before any download or upload.

Phase 1: Prepare

**Goal:** Resolve the project, confirm the site, and protect existing work.

1. Create all seven tasks from [Progress tracking](#progress-tracking). 2. Resolve `PROJECT_ROOT` from `$ARGUMENTS` or the current directory. 3. Detect site markers independently:

• `powerpages.config.json` indicates an SPA site;
• root `website.yml`, root `sitesetting.yml`, or `.powerpages-site/`

indicates downloaded non-SPA artifacts;

• when both appear, scan both layouts.

4. Read `.solution-manifest.json` when present. This migration changes existing settings; do not create or select another solution. 5. Inspect git status. Never discard, hide, or include unrelated user changes. 6. Run `node --version`. 7. Confirm `assets/migration-report-template.html` and `scripts/render-migration-report.js` are readable, and stop if either is missing. 8. Read [references/site-transfer.md](references/site-transfer.md), then confirm the environment, website name and `WebSiteId`, site type, data model, deployment profile, and target path with the user. Check each against `pac auth who`, `pac env who`, and `pac pages list`, and stop on any mismatch. Never infer one from a folder name or an active default.

Analyzing the wrong site produces confident, wrong fixes, so settle identity before reading any setting. Download only when the user wants a fresh copy or `PROJECT_ROOT` holds no site content; downloading replaces local files and cannot be reverted.

<!-- gate: migrate-webapi-selectall:1.download-site | category=consent | cancel-leaves=nothing -->

> 🚦 **Gate (consent · migrate-webapi-selectall:1.download-site):** Approve the download only after displaying the confirmed environment, website name and ID, site type, data model, target path, and the exact command. Canceling leaves local content untouched and continues against the existing copy.

Use `AskUserQuestion`: `Download the confirmed site` or `Use the local copy`. Repeat step 3 after any download.

**Output:** Project root, site layouts, solution context, git state, confirmed site identity, and a downloaded copy when approved.

Phase 2: Build the complete inventory

**Goal:** Find every configuration and candidate source Web API call before reasoning about columns.

2.1 Inventory configuration scopes

Use `Glob`, `Grep`, and `Read` to inspect:

• every `sitesetting.y