migrate-webapi-selectall

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:

• traditional 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

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 before analyzing calls. Read references/configuration-and-reporting.md before inventorying settings or writing the report. Read references/site-transfer.md before any download or upload.

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

1. Create all seven tasks from 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 declarative 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, 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 (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.

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

Goal: Use authoritative names while letting the LLM determine actual usage.

Goal: Present the full exposure reduction before edits.

Show:

• wildcard issues found and the exact replacement for each;
• evidence for every proposed column;
• source GETs requiring $select;
• already-explicit settings and any missing or excess columns;
• any missing or duplicate settings found during inventory;
• zero unresolved call sites.

🚦 Gate (consent · migrate-webapi-selectall:4.apply-plan): Approve all wildcard replacements, required source projections, optional explicit-setting hardening, and local edits. Canceling preserves only the report.

Use AskUserQuestion with:

• Apply all wildcard fixes and approved explicit fixes;
• Apply all wildcard fixes only;
• Cancel.

Never offer a subset of wildcard fixes.

Goal: Update source projections and every wildcard setting.

1. Use Edit to add approved $select projections. Preserve methods, filters, ordering, expansion, pagination, encoding, Liquid expressions, and error handling.
2. Use Edit to replace every wildcard value in every scope and profile. Preserve identifiers, key names, quoting, indentation, comments, and unrelated values.
3. Apply already-explicit changes only when included in the selected approval.
4. Re-read every changed block immediately and update report status.

If any edit fails or a file changed since review, stop. Do not continue with a partial configuration set and do not perform a broad rollback over user work.

Output: All approved local edits and updated report.

Goal: Prove the migration without trusting prior notes.

1. Repeat Phase 2 discovery from scratch.
2. Confirm every configuration scope contains zero Webapi/<table>/fields wildcard values.
3. Compare each migrated value with its approved exact replacement.
4. Reopen every call site and replay the coverage analysis:
   • mapped table and method remain correct;
   • required setting columns are present;
   • normal record GETs use explicit $select;
   • expanded, lookup, write, FetchXML, file, and image columns remain covered.
5. Run the existing project build for SPA sites. For traditional sites, inspect edited JavaScript and Liquid syntax and use existing site tests when available.
6. Finalize the report status and every entry status, then delete the previous migration-report.html and re-render it from the updated data file.

Do not claim full hardening while explicit configuration gaps remain. Use the partial status defined in the reporting contract when applicable.

Output: Final report and verified local migration.

Goal: Publish only verified changes.

Re-confirm every identity detail in references/site-transfer.md with the user immediately before uploading, and display the exact command. Select the deployment profile the user reviewed, and use default only when they name it. Any change of environment, website, data model, or profile requires a separate deployment approval.

🚦 Gate (final · migrate-webapi-selectall:7.deploy): Approve the verified migration for the displayed environment, website, site type, data model, and deployment profile. Canceling preserves local edits and the final report without changing the live site.

Use AskUserQuestion: Deploy now or Keep local only.

• Re-run pac auth who and pac env who, and stop on any mismatch. pac pages upload-code-site accepts no --environment and targets whatever the active authentication profile reports.
• For SPA sites, confirm .powerpages-site contains the approved configuration edits, run the existing production build, then run pac pages upload-code-site --rootPath "<PROJECT_ROOT>" --siteName "<SITE_NAME>".
• For traditional sites, run pac pages upload --path "<PROJECT_ROOT>" --environment "<ENVIRONMENT>" --modelVersion "<Standard|Enhanced>" --deploymentProfile "<PROFILE>".

Never substitute one upload command for the other. Each corrupts the other site type, and the damage cannot be reverted.

After deployment, list the read paths a smoke test would exercise: GET calls, $select projections, $expand, FetchXML, and aggregates. Never run one unprompted.

🚦 Gate (progress · migrate-webapi-selectall:7.smoke-test): Approve the listed read-path smoke test against the deployed site. Canceling skips it and reports the deployed migration as unverified.

Use AskUserQuestion: Run the read-path smoke test or Skip verification.

Never issue write, file, or image requests. Ask the user to exercise those paths themselves against disposable records.

Treat HTTP 403 responses as evidence to investigate and never restore *. Do not add a column under the prior approval. Return to Phase 3, update the exact plan and report, repeat the Phase 4 approval, independently verify in Phase 6, and obtain a new Phase 7 deployment approval.

Delete every working file created during the migration, keeping only docs/webapi-selectall-migration/migration-report.html and the power-pages-icon.png the renderer places beside it:

• table-identifiers.txt and table-identifiers-pass-<N>.txt;
• table-schema.json and table-schema.pass-<N>.json;
• migration-report.json.

Delete only files this migration created, and confirm the directory holds the report and its icon alone. Skip cleanup while returning to an earlier phase, and delete the regenerated files once that pass finishes.

Record usage by following ${PLUGIN_ROOT}/references/skill-tracking-reference.md with --skillName "MigrateWebapiSelectall".

Summarize wildcard counts, explicit reviews, source edits, report path, verification, deployment, and every path left unverified.

Create these tasks before Phase 1:

Mark each task in_progress when starting and completed when finished.

Begin with Phase 1: Prepare.