[MWPW-191951] MAS publish guardrails

[joaquinrivero]

• Adds Sidekick plugin (tools/mas-publish-guardrails/) that replaces the built-in Publish button on preview/live — scans page for mas.adobe.com/studio.html links, checks each fragment UUID against https://www.adobe.com/mas/io/fragment, and either auto-publishes via AEM admin API or surfaces an overlay listing unpublished fragments with Close, Re-check, and Ignore & Publish actions
• Works for manifest JSON (:type: sheet and multi-sheet) and regular HTML pages via extractFromJson / extractFromText
• Overlay styled with Spectrum 2 tokens; theme-aware via Sidekick <sk-theme color="…"> element

Resolves: MWPW-191951 — [CSO remediation] Fallbacks/error prevention.

Deployment (for production merge)

Add this plugin to the Milo Sidekick config at https://admin.hlx.page/sidekick/adobecom/milo/main/config.json, and set excludePaths: ["/**"] on the built-in publish plugin so only the new "Publish" shows up:

{
  "id": "mas-publish-guardrails",
  "title": "Publish",
  "environments": ["preview", "live"],
  "isPalette": true,
  "passReferrer": true,
  "passConfig": true,
  "url": "/tools/mas-publish-guardrails/index.html",
  "paletteRect": "width:1px;height:1px;position:fixed;top:-9999px;left:-9999px;opacity:0;"
}

Reviewing without merging

Sidekick resolves relative url values against the project's main host (main--milo--adobecom.aem.page), so to test this PR end-to-end you need to override the config locally with an absolute branch URL via Chrome DevTools → Sources → Overrides:

1. In DevTools, open Sources → Overrides, enable "Local overrides", and pick a folder.

2. Open https://admin.hlx.page/sidekick/adobecom/milo/main/config.json in a tab. In DevTools → Network, right-click the response and choose Save for overrides.

3. In the saved file, set excludePaths: ["/**"] on the built-in publish plugin, and paste the config below (already pointing to this branch — no edits needed):

   {
     "id": "mas-publish-guardrails",
     "title": "Publish",
     "environments": ["preview", "live"],
     "isPalette": true,
     "passReferrer": true,
     "passConfig": true,
     "url": "https://mwpw-191951--milo--adobecom.aem.page/tools/mas-publish-guardrails/index.html",
     "paletteRect": "width:1px;height:1px;position:fixed;top:-9999px;left:-9999px;opacity:0;"
   }

4. Reload the test page — the custom Publish now runs from this branch.

Test URLs:

• Before: https://main--milo--adobecom.aem.page/?martech=off
• After: https://mwpw-191951--milo--adobecom.aem.page/?martech=off

Test plan:

• Manifest JSON — https://mwpw-191951--milo--adobecom.aem.page/drafts/rivero/mas-preflight/cc-pro-intro-us-copy.json
  • All fragments published → Publish proceeds automatically (success toast)
  • One fragment unpublished → overlay lists the UUID with MAS Studio link
  • Re-check re-runs and updates the list
  • Ignore & Publish bypasses the guardrail and calls admin API
  • Close hides overlay; next Publish click reopens and re-runs
• Page with fragment — https://mwpw-191951--milo--adobecom.aem.page/drafts/rivero/mas-preflight/my-document-with-unpublish-fragments
  • Same four flows as above

[aem-code-sync]

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

• Re-sync branch

Commits

• a169d61 ✅ (latest)

[github-actions]

This pull request is not passing all required checks. Please see this discussion for information on how to get all checks passing. Inconsistent checks can be manually retried. If a test absolutely can not pass for a good reason, please add a comment with an explanation to the PR.

[narcis-radu]

Hey @joaquinrivero! I strongly believe the direction is incorrect, and I want to make you are aware of the existing concerns and guardrails around this.

• The AEM sidekick should be used as is, without replacing functionality.
• The "Publish" button has an existing workflow, where authors are requested to confirm before the actual publishing happens. We should not alter the behaviour.
• Authors should never be blocked to publish content. The only exception is around specific configuration, where anyone outside a group is blocked from publishing.

Concerns around functionality

• The solution might not always work on DA
• If for any reason the code is not working properly, authors will not be able to publish.

My recommendation is to leverage existing guardrail tools like Preflight. The tool will run in the background and proactively notify authors if there are any critical errors that need to be checked before publishing the page.

[mokimo]

Definitely a +1 on this, it's a very complex matter (bulk tools, DA, Sidekick) - most of which we don't own the code for.

I assume this would break once the Sidekick sees any sort of changes, likely conflicts with other features such as the milo publish permissions which look for the publish button. I don't think it's a rabbit hole we should go down into, but look for alternatives.

The preflight platform seems like the better candidate, notify authors and we log the interactions. If an author does something disregarding recommendations of the tool, we can follow up by logging those pages (@skholkhojaev is currently working on a dashboard for displaying and flagging faulty pages)

[Blainegunn]

@narcis-radu @mokimo
Thanks for the feedback — All fair points on blocking the publish button so we can move the conversation to pre-flight. I think we need to realign on what pre-flight is meant to do here.

To clarify: we're not blocking anyone from publishing. The "Ignore & Publish" escape hatch is intentional and stays. The goal is to make the risk explicit — authors must consciously bypass the warning rather than unknowingly push broken content live.

That said, now that we're actively migrating everyone to M@S, I think we need to go a step further: pre-flight should be mandatory for pages with merch content, not just advisory. The April 7 CSO is a direct example of what happens when a staged/preview-only fragment quietly ends up in a live manifest — the check should catch that before publish, not after.
I'd like to move this to a proper GitHub discussion so we can align on expectations and scope. My position:

Flag any unpublished/preview-only fragments on pages with merch content as a pre-publish requirement
Keep the escape hatch, but log it as an explicit author decision
Treat this as a CSO-prevention guardrail, not just a UX nicety.