sync-rules

Sync Rules

When to invoke

WHEN rules-curator updated a rule in one project AND multi-project sync is configured (opt-in via .supervibe/sync-config.yaml).

Expert Operating Standard

Follow docs/references/skill-expert-operating-standard.md: start from source of truth, preserve retrieval evidence, apply scope safety, use real producers with runtime receipts for durable delegated outputs, verify before completion claims, and keep confidence below gate when evidence is partial.

Step 0 — Read source of truth (required)

1. Read .supervibe/sync-config.yaml for sibling project paths
2. Read updated rule file
3. Read sibling projects' versions of same rule (diff source)

Decision tree

No opt-in sync config exists
  -> STOP and report that no sibling project is authorized.

Target rule is identical except for the source update
  -> Propose a clean apply patch in dry-run output.

Target rule has local customization
  -> Ask whether to merge, skip, or send to manual curator review.

Target project lacks the rule or uses a different host adapter
  -> Ask whether this stack should receive a translated host-neutral rule.

Target has a newer version or mandatory enforcement differs
  -> STOP and require manual rule-audit before sync.

Procedure

1. Identify changed rule
2. For each sibling project (per sync-config): a. Read sibling's version of the rule b. Compute diff c. If sibling has divergent customization → ASK user (merge / skip / overwrite) d. If clean → propose patch
3. Show user the planned changes per sibling
4. User confirms each
5. Apply confirmed changes
6. Each sibling's rules-curator validates the patched rule (rule-quality ≥9)

Diff decision tree

Sibling rule is identical except source change applies cleanly
  -> propose apply

Sibling rule has local customization
  -> ask user: merge, skip, or open manual review

Sibling lacks the rule
  -> ask user whether this stack should receive the rule

Sibling has a newer version
  -> stop and require manual curator review

Sibling host adapter differs
  -> translate wording only after host-specific rule audit

Safety policy

• Default mode is dry-run.
• Every target project is opt-in through .supervibe/sync-config.yaml.
• Show diff per target before writing.
• Never overwrite local customization without explicit user choice.
• Never sync secrets, generated state, or project-specific paths blindly.
• Preserve host-neutral wording unless the target rule is adapter-specific.

Audit log

For each target write, record:

• source project;
• target project;
• rule id;
• old version;
• new version;
• decision: applied, skipped, merged, blocked;
• user confirmation;
• validation command and result.

Verification

• Sync config was read.
• Source and target rule versions were compared.
• Dry-run diff was shown.
• User confirmed each write.
• supervibe:rule-audit or equivalent validation ran after changes.
• Divergent local customization was preserved unless explicitly merged.
• Audit log entry was produced for every target.
• Rollback note is included for applied patches.

Output contract

Returns:

• Per-sibling: change applied / skipped / customized
• Audit log entry per sync

Guard rails

• DO NOT: auto-apply without user confirm per sibling
• DO NOT: overwrite divergent customization (merge requires explicit user choice)
• ALWAYS: validate rule-quality after sync

Related

• agents/_meta/rules-curator — triggers this
• supervibe:rule-audit — verifies each sibling's rules post-sync