Central Meduse to Mosaikasa and Shopify

This guide explains the targeted sync for reviewed changes to existing products. It is a separate path from new product publication and from scheduled price, stock and other connector processes.

Evidence boundary

The flow below is based on the cited Meduse source revision. It does not establish which revision is currently deployed, whether workers or schedules are running, or whether a particular product reached a storefront. Check the deployed environment and destination state before relying on an operational result.

At a glance

Stage	What to check
Central changes	The planner reads product audit history for a bounded UTC window and a configured change author. A candidate is a product found in that history, not a promise that it is eligible for sync.
Eligibility	The planner selects the supported Menzzo/no-dropship and MauroFerretti cohorts, matches an existing target product, and reports products requiring decisions. It does not create missing products.
Tenant update	Preflights check product identity, attribute definitions, family assignments and option codes. Apply updates selected raw values, then flat rows.
Shopify	After tenant verification, the command runs the targeted Shopify attribute and image stages. The final result and detailed reports expose failures and blocked products.
Storefront	A successful command is a checkpoint, not proof that the expected product, image, price and shipping are correct on both storefronts. Verify the actual destination separately.

Field ownership

For this targeted path, existing Mosaikasa categories are preserved. Existing Menzzo-product titles and descriptions remain Mosaikasa-owned; Mauro titles and descriptions may be eligible when the technical preflight passes. Other supported attributes and images are subject to the plan and preflight. The source guide describes these constraints.

This does not describe all price, shipping, stock or new-product creation paths. See Meduse workflows, connectors and scheduled jobs for adjacent source-traced paths and their separate evidence limits.

How a run progresses

1. Plan: select a time window and reviewed product changes. The first run needs a verified lower boundary when no successful checkpoint exists.
2. Preflight: check raw values, flat rows, Shopify attributes and images. A dry run stops here and produces a final status.
3. Confirm and apply: synchronize eligible tenant values and flat rows, then verify tenant state. The command asks once before applying.
4. Send to Shopify: run the targeted attribute and image stages, then perform final tenant verification.
5. Review the report: eligible products can finish even when others are blocked. In that case the status is SYNCED_WITH_BLOCKERS and the checkpoint is retained; stage failures may leave partial work that needs investigation.

The top-level command and reports are explained in the sync runbook. Do not assume every product, every Shopify field, or a public storefront was checked by the final tenant verification.

Automatic tenant-to-Shopify updates

The reviewed event provider registers listeners for Mosaikasa tenant name and attribute events on the export queue and image events on export-product-images. This is a source-level description: it does not confirm that the event was emitted, a worker consumed the job, or Shopify accepted and displayed a change. It also does not establish that all central changes are automatically copied into the tenant.

Sources and open questions

• Top-level command and stages
• Central change planner
• Targeted sync source guide

Still to verify: current deployed command and checkpoint, worker health, the separate creation/category mapping workflow, field-level price and shipping propagation, connector IDs and current FR/ES storefront readback.