Make Amazon Ads a first-class platform (closeable parity gaps vs native Google/Meta)

[hyoshi]

Problem

Amazon Ads is wired via the official-MCP bridge (#113 Phase 1/2). The structural layer is at parity with mureo-native Google/Meta (callable, audited, throttled, action_log promotion, observation window, LwA auto-refresh). But Amazon is not yet a first-class platform the way native Google/Meta are. This issue tracks the closeable engineering gaps (the "C" set from the honest gap analysis) — distinct from the deep per-platform analytics, which are inherently hand-authored and tracked separately in #120.

Gaps (each independently shippable)

1. STRATEGY.md / STATE.json first-class integration. Native platforms appear in STATE.json platforms, carry per-platform goals, are covered by onboarding + goal-progress, and have hand-written strategy-gating reasons. Amazon currently only lands in action_log (structural) and is treated advisory/best-effort by skills. → Make amazon_ads a configured platform: onboarding, STATE schema, per-platform goal progress, strategy gating.

2. Executable rollback. Native google_ads_* / meta_ads_* writes are in the rollback planner allow-list, so rollback_apply can actually reverse them. Amazon mutations record reversal intent only — not executable. → Define an Amazon reversal mapping + allow-list entries so Amazon writes are truly reversible.

3. Setup UX. Google/Meta have a configure Web-UI auth wizard, env-var credential fallback, and a re-authorization path. Amazon requires hand-editing ~/.mureo/credentials.json + manual mureo amazon refresh-manifest, and the LwA refresh token's 365-day expiry has no in-product re-auth flow. → configure-UI Amazon auth wizard, amazon_ads env-var fallback, guided re-authorization.

4. Data-path normalization. Native adapters apply mureo-tuned pagination, field mapping, and error normalization. Amazon is a raw pass-through to a beta/volatile MCP surface with no mureo-side normalization. → A normalization/adaptation layer over the bridged tools where it adds reliability.

5. Manifest freshness. Native tools are static and always present; Amazon depends on a manually-run manifest and goes stale if Amazon changes its tool surface. → Scheduled/auto manifest refresh + staleness signalling.

6. Cross-source correlation. daily-check / multi-platform skills correlate Google/Meta with Search Console (organic pulse) and GA4 (on-site behavior). Amazon is not woven into these. → Include Amazon in the relevant cross-source skill flows.

Non-goals / scope

• Deep per-platform analytics (anomaly detection, result_indicator CV-mismatch, RSA audit, rule-based scoring, etc.) are NOT in scope here — inherently hand-authored, tracked in Official-MCP-backed platforms lack mureo's deep per-platform analytics (structural layer only) #120.
• BYOD for Amazon: explicitly out of scope (maintainer decision — no Amazon export path needed).
• Not a blocker for feat: first-class Amazon Ads support (official Amazon Ads MCP integration) #113 Phase 1/2 (shipped). These are incremental first-class-platform gaps; each can be delivered independently and prioritized later.

Refs: #113 (Amazon bridge Phase 1/2), #120 (official-MCP deep-analytics, the "B" set), #114 (plugin/bridge safety-layer honest scope).