[MWPW-203054] [MWPW-203055] - Additional Manifest and Page Summary fields.

[AdobeLinhart]

Updates

• [MWPW-203055] Manifest card: replace the single "Mktg Action" row with four flat fields — Geo Restriction, Type, Override Name, Execution Order — pulled from the manifest's info-tab metadata, each showing "none" when blank
• [MWPW-203054] Page Summary card: replace the "Target Integration" and "Personalization" rows with a new Manifest Sources section containing Target Integration, Personalization Metadata, Promo Metadata, and MEP Param, each as on/off
• [MWPW-203054] Add a Load Target Faster (v2) row (on/off/n/a) reflecting the personalization-v2 metadata flag, shown as n/a when Target integration is off
• [MWPW-203054] Nested on/off values (inside Manifest Sources) now get the same emphasis highlight as Consent's on/off rows when the value is "on"
• Export getPromoMepEnablement from utils.js so the overlay can reuse the existing multi-region promo-metadata detection instead of duplicating it

Instructions

These fields are metadata/param driven, so to see non-default (on) states while testing:

1. Open the page with ?mepnext=on&mep and ?milolibs=mn-manifest-page-labels to load the new overlay code.
2. Open the MEP overlay (FAB → Summary tab → Page card) to see Manifest Sources and Load Target Faster (v2).
   • Personalization Metadata is "on" when the page has a personalization metadata tag.
   • Promo Metadata is "on" when the page has a manifestnames (or regional *_manifestnames) metadata tag.
   • MEP Param is "on" when the URL includes a mep query param with a value.
   • Load Target Faster (v2) is "n/a" unless Target integration is on, in which case it reflects the personalization-v2 metadata tag.
3. Open the Manifests tab and expand a manifest card to see Geo Restriction, Type, Override Name, and Execution Order — these come from the manifest's own info tab and show "none" when not set.

Resolves: MWPW-203054, MWPW-203055

Test URLs:

• Before: https://main--da-cc--adobecom.aem.page/products/photoshop?mep=&mepnext=on

Integration Off

• https://main--da-cc--adobecom.aem.page/products/photoshop?mep=&mepnext=on&martech=off&milolibs=mn-manifest-page-labels

Integration On

• https://main--da-cc--adobecom.aem.page/products/photoshop?mep=&mepnext=on&target=on&milolibs=mn-manifest-page-labels

PSI: https://=mn-manifest-page-labels--da-cc--adobecom.aem.page/products/photoshop?martech=off

[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

• 6aa6dc4 ✅ (latest)
• 0c36ef0 ✅
• 562af96 ✅
• 4932f6b ✅
• 2b2ef23 ✅
• 19e18a6 ✅

[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.

[jpratt2]

@AdobeLinhart What do you think of putting a tool tip or hover text over these new fields? Something to explain their source. Something like this: pulled from the manifest's info-tab metadata

[jpratt2]

@skumar09 In case you're interested, there is a case of a "flaky test" in https://github.com/adobecom/milo/actions/runs/31547667785/job/93963513898?pr=6446 where a locator wasn't able to be clicked. Somehow the test still passed and the nala test detected that it was flaky. I tried limiting workers to 2 prior to this test run, but this still happened, fyi, in case that helps in detecting the cause or if it helps with prescribing some solution code.

[jpratt2]

@AdobeLinhart
Here are 2 code review items from Claude:

[markpadbe]

Looks good to me. Two small notes(@jpratt2 already flagged the first one), both non-blocking:

1. Metadata on/off reads (L269, L122) — long-standing convention, just flagging
Not an ask on this PR, and definitely not something introduced here — the getMetadata(x) ? 'on' : 'off' idiom goes all the way back to the original MEP Manifest Manager in preview.js, so the new L269 is correctly following how MEP preview tooling has always read these flags. The only wrinkle: getMetadata returns the raw string, so an author writing content="off" would be truthy and render as on. In practice these flags are authored as presence-only, so it basically never bites. If we ever decide to harden it, getMepEnablement('personalization-v2') (utils.js:2145) handles off/other values correctly — the same shape the file already uses at L401 for mas-geo-detection. Fine to leave as-is; noting it only for the record.

2. Commented-out caas badge assertion (mep-next-button.test.js)
Fine as a temporary stopgap to keep CI green. It's a genuine flake with a distinct root cause (the caas badge waits on loadCaas loading React/chimera from www.adobe.com, which the aem.live throttle pacer doesn't cover), so commenting it out here is reasonable. I'll track a potential real fix + re-enable under MWPW-198784.