sync

Sync Coordination Mapping

Generate a sync coordination map — a structured description of how independent concepts interact through synchronization handlers. A sync map replaces reading dozens of handler files with a single page showing the coordination topology, timing patterns, and error strategies.

Syncs implement the execution mechanics of concept interactions. Where CONCEPT.md ## interactions declares relationships, SYNCS.md specifies the execution mechanics: when the sync fires, what data flows, when it skips, and how errors propagate.

How to interpret $ARGUMENTS

Determine the mode from the argument:

• Path to sync directory (e.g. src/lib/server/syncs/): Retrofit mode — read the existing sync handlers, map the coordination patterns, and propose a SYNCS.md. Flag any patterns that bypass concept boundaries.
• Sync description (e.g. Order fulfillment → Inventory update): Greenfield mode — design a sync spec for the described coordination. Define trigger, flow, qualification, and error strategy.
• No arguments: Discovery mode — analyze the project for sync-like patterns (event handlers, cross-concept calls, scheduled jobs, dispatch registrations) and list candidates. Do NOT generate full specs; ask the user which to elaborate. If discovery surfaces data transformation chains without cross-concept coordination, note that /wyx:pipeline covers those.

SYNCS.md Format

Write the spec as a SYNCS.md file placed in the sync directory (e.g. src/lib/server/syncs/SYNCS.md).

# syncs: [Module/Area Name]

## coordination graph
[Text diagram showing concept-to-concept flow through syncs]

[Concept] --(action)--> (SyncName) --> [Concept]
[Concept] --(action)--> (SyncName) --> [Concept]
                                   --> [Concept]

## dispatching
- pattern: [event-driven | explicit-call | hybrid]
- error-isolation: [sync failure does NOT propagate to source | propagates]
- depth-limit: [max cascading depth, if applicable]
- context: [how correlation/tracing works across sync boundaries]

## sync: [SyncName]
trigger: [Concept.action | schedule(interval) | manual]
timing: [post-action | pre-validation | scheduled]
flow:
  1. [Concept.action] → [what data is read]
  2. [transform/filter/validate] → [what happens]
  3. [Concept.action] → [what data is written]
qualification: [conditions for execution vs skip]
error: [isolated | propagates | skip-and-log]
file: [relative path to implementation]