Make consumer synchronization manifest-driven and policy-aware

[coisa]

Objective

Reshape consumer synchronization so synchronized assets are defined through a reusable manifest or resource-registry model instead of growing as ad hoc logic inside SyncCommand and one-off sync helpers.

Current Limitation

DevTools already synchronizes many different asset types: scripts, workflow stubs, repository defaults, funding metadata, gitignore/gitattributes, wiki setup, packaged skills, and packaged agents. As this surface grows, the current approach becomes harder to extend consistently.

That makes three adjacent needs harder than they should be:

• adding new synchronized resource families, such as community health templates and additional GitHub defaults;
• applying different overwrite or preservation policies per resource;
• keeping dev-tools:sync orchestration small while resource-specific behavior grows.

Proposed Work

Introduce a manifest-driven synchronization model where each managed resource or resource family declares its source, target, default policy, mutability rules, and verification behavior. Use that model to progressively move dev-tools:sync away from hard-coded resource orchestration.

The first extraction should also cover currently missing or under-managed GitHub defaults, such as issue templates and pull-request templates, and should support per-resource policies like missing-only, repair-only, or managed overwrite behavior.

Scope

• Extract synchronization metadata into a reusable manifest or registry.
• Support per-resource synchronization policies instead of one global behavior.
• Prepare the architecture for more synchronized GitHub/community-health assets.
• Include community health templates in the managed sync surface when they fit the model.

Non-goals

• Do not rewrite every sync concern in one pass if an incremental migration is safer.
• Do not remove consumer-first override behavior.
• Do not force the same overwrite policy on every resource type.

Acceptance Criteria

Delivery Criteria

• dev-tools:sync uses a reusable manifest or registry model for managed resources instead of continuing to grow as hard-coded orchestration.
• Resource definitions capture source, target, and synchronization policy in one place.
• The architecture supports extending synchronization to issue templates, pull-request templates, or other community-health defaults without duplicating orchestration logic.
• Different resource families can declare distinct overwrite or preservation policies.
• Focused tests cover manifest evaluation, policy behavior, and representative resource families.
• README and docs are updated where synchronization behavior or managed resources change.

Architectural / Isolation Criteria

• MUST: The core logic MUST be isolated into dedicated classes or services instead of living inside command or controller entrypoints.
• MUST: Responsibilities MUST be separated across input resolution, domain logic, processing or transformation, and output rendering when the change is non-trivial.
• MUST: The command or controller layer MUST act only as an orchestrator.
• MUST: The implementation MUST avoid tight coupling between core behavior and CLI or framework-specific I/O.
• MUST: The design MUST allow future extraction or reuse with minimal changes.
• MUST: The solution MUST remain extensible without requiring major refactoring for adjacent use cases.
• MUST: Argument and option resolution MUST be validated separately from command execution logic.
• MUST: Console formatting and rendering MUST stay separate from domain processing.
• MUST: Exit behavior, error messaging, and generated output MUST remain deterministic and testable.
• MUST: Data gathering or transformation MUST be isolated from filesystem writes or publishing steps.
• MUST: Generated output ordering and formatting MUST remain deterministic across runs.
• MUST: Re-running the workflow MUST be idempotent or clearly bounded in its side effects.