Mosaikasa product sync

Use this guide when a reviewed central product change is missing from the Mosaikasa tenant or Shopify. Read the flow overview first to understand the scope.

Before operating

This guide describes the cited source revision, not a verified current deployment. Confirm the environment, deployed command, correct change window and normal database backup procedure with the system owner. Do not run an apply operation solely because this page exists.

Collect the evidence

Record the SKU, affected field and locale, supplier, central change time and author, tenant and storefront URL. Determine where the first mismatch occurs: central product, tenant raw value, tenant flat row, Shopify product/variant, or storefront. Record any run status and report directory without copying credentials or private data into a ticket.

Inspect the command report

The documented command is meduse:mosaikasa:sync-products-from-central. Without --apply it performs a dry run; it still creates local report files. With --apply, it asks for confirmation before mutation. When there is no saved successful checkpoint, it reports NEEDS_INPUT and requires an explicitly verified --since UTC boundary. See the source guide and confirm the deployed command before use.

For an approved sync from the deployed Meduse application directory, the normal interactive command is:

php artisan meduse:mosaikasa:sync-products-from-central --apply

For a dry run, omit --apply. If the command reports NEEDS_INPUT, obtain the last verified exclusive UTC boundary from the owner and supply it using --since=...; do not guess the date. A run with unresolved blockers retains its checkpoint, so review the reported window and blockers before the next attempt.

Status	Meaning	Next action
READY / READY_WITH_BLOCKERS	Dry-run preflights completed for eligible products; the latter also lists unresolved products.	Review the window, eligible products and blocker reasons.
NO_CHANGES	No eligible changes in the selected window.	Confirm the window and change author match the expected edit.
SYNCED	The command completed its stages and advanced the checkpoint.	Verify relevant Shopify and storefront values independently.
SYNCED_WITH_BLOCKERS	Eligible products completed; others remain unresolved and the checkpoint was retained.	Resolve or assign the listed products before advancing the window.
BLOCKED / NEEDS_INPUT	A preflight or another stage failed before recorded database writes, no eligible product can proceed, or a first-run boundary is missing.	Investigate the failed stage or reported decisions, or agree on the verified boundary.
FAILED / PARTIAL_FAILURE	A stage failed; a partial failure can follow database writes.	Read the failed stage and reports; do not blindly rerun or assume rollback.
CANCELLED	Confirmation was declined before the apply stages.	No apply was started by that run.

The run reports and product-level rollback files are stored under the command's report directory, normally storage/app/mosaikasa-targeted-sync/. A product-level rollback file does not replace a verified database backup.

Check the destination

For affected products, compare the exact field and locale in central and tenant data. Check Shopify product and variant mappings, then read back the relevant content and images in Shopify and the appropriate FR/ES storefront. Price and shipping have separate paths: verify their source values and destination behavior independently. A successful job or tenant verification alone is not storefront acceptance.

Escalate or recover

Include the SKU, selected window, status, failed stage, affected destination and report location when handing the issue to the owner. Missing products, categories, mismatched attribute definitions or missing option values may need a separate decision or workflow. Use the owner's approved recovery procedure; the source guide does not establish a safe automatic rollback of a partially completed Shopify sync.