fix: get the right page path even in edit mode

[amol-anand]

Issue: When using schedule sidekick plugin in edit mode, the path is incorrect.

Fix: We need to resolve the path using status api for that to get the right path to use for preview and publish.

Test URLs:

• Before: https://main--helix-tools-website--adobe.aem.live/tools/scheduler/schedule.html
• After: https://fix-scheduler-edit-mode--helix-tools-website--adobe.aem.live/tools/scheduler/schedule.html

[aem-code-sync]

Hello, I'm the AEM Code Sync Bot and I will run some actions to deploy your branch and validate page speed.
In case there are problems, just click a checkbox below to rerun the respective action.

• Re-run all PSI checks
• Re-run failed PSI checks
• Re-sync branch

Commits

• b213790 ✅ (latest)
• 8a531f9 ✅

[aem-code-sync]

	Page	Scores	Audits	Google
📱	/tools/scheduler/schedule.html
🖥️	/tools/scheduler/schedule.html

[claude]

Code Review

Reviewed the fix for scheduler path resolution in Sidekick edit mode (tools/scheduler/schedule.js, tools/scheduler/utils.js, tools/scheduler/README.md, tests/tools/scheduler/utils.test.js).

Summary

• isPageHost/parseSidekickParams cleanly separates "referrer is the page itself" (.aem.page/.aem.live/.aem.reviews) from "referrer is an authoring surface" (SharePoint, Google Docs, custom prod domains), and the new isProject flag correctly gates when the pathname can be trusted directly.
• resolvePagePath in schedule.js falls back to the Admin API's status endpoint with editUrl — the same mechanism Sidekick itself uses — only when path is empty and a referrer is present. The gating condition (!path && !isProject && org && site && referrer) is correct, and since path can only be non-empty when isProject is true, the checks are consistent (the !path check is redundant but harmless).
• Error handling follows the existing { path/ok, error, resp } envelope pattern used elsewhere in the file (ensurePreview, writeIntent), and the missing-context message is correctly overridden with the specific resolution error when available.
• New tests (isPageHost, parseSidekickParams) cover the pure branching logic per this repo's testing philosophy (TESTING.md) — the DOM/fetch orchestration in resolvePagePath is reasonably left untested since it isn't a shared-library contract.
• README update accurately documents the new fallback behavior and its rationale.

I did not find any BLOCKING or SHOULD FIX issues. One thing worth a manual sanity check before merge (not a code issue, just unverifiable from static review): confirm the Admin status API response field is actually webPath for your account/site, since that's the crux of the fix — the PR description's "Before/After" preview links suggest this was already tested manually via Sidekick edit mode, which would confirm it.

Note: I was unable to execute npm run lint / npm test in this sandbox (tool execution was restricted), so please confirm CI is green via gh pr checks.

Verdict

APPROVE