docs: user-level sync-seam contract + parity-loop seam rules

[almoretti]

What this proposes

A contract for how parity and feature work handles durable, user-owned state so every domain can later be lifted onto the shared Syncr-owned engine without rewriting call sites — generalizing the proven SkillStore → EngineSkillStore pattern (ADR-0002, docs/skill-store-contract.md) from skills to the whole sync horizon: agents, prompts, Loop definitions, MCP config, session durable state, subagent run records, memory, settings/assignments.

The posture: build behind seams, never block

• Missing engine surface is not a blocker. Implement natively, behind a narrow injectable store interface (single write path, typed shapes, typed failure codes), so the eventual lift is an implementation swap.
• Where engine surface exists, consume it through the seam (ctx.skillStore) — never rebuild shipped capability host-side.
• Engine-adjacent complexity (sync semantics, conflicts, governed history) → short request doc to Syncr (the skill-engine-per-file-conflict-request.md template), then continue on the native implementation without waiting.

Changes

• docs/sync-seams.md (new) — the contract + a live seam registry: per domain, what syncs at user level, today's write path, seam status (lifted / seamed / inline / planned), and lift notes for the engine team. Also records the sync constraints every seam inherits (offline-first, secrets never sync raw, device-local state stays device-local) and the NAPI conventions the skills lift established (named camelCase exports, RESOURCE_* error codes, roots+scope mutations, pinned version floor, optionalDependencies + extraResources packaging).
• .agents/skills/parity-loop/SKILL.md — new "Sync-engine seams" section: before any row touching durable/syncable state, read the contract; consume existing engine surface through the seam; seam new durable stores instead of writing inline; update the registry in the same slice; draft Syncr request docs for engine-natural capability and keep moving.

Why now

The parity loop is about to leave the SUB workstream and enter the skills/agents/prompts catalog rows. Its current instructions never mention the engine, and its required reading (AGENTS.md, docs/agent-guidelines/*) contains no seam rule — the predictable failure mode is rebuilding engine-owned capability host-side (the parallel path P4 just deleted 4,400 lines of), against VISION.md's "no parallel integration paths".

Open for discussion

• Which session stores sync (prefs/pins/drafts) vs stay device-local with reference-level sync (transcripts, content-addressed blobs) — the registry marks these as per-store product decisions, deliberately not decided here.
• Whether agents+prompts share one lift request or two.
• Registry follow-up: SKL-15/16 and the "blocked on 0.1.4" note in the parity register are stale post-0.1.5 and should be corrected separately.

🤖 Generated with Claude Code