rulesync-feature-research

name: rulesync-feature-research description: >- Maps rulesync feature implementations to upstream coding-agent documentation. Use when evaluating rulesync issues, comparing any coding-agent client with rulesync source capability surfaces, checking support, or planning a client map.

Rulesync Feature Research

What

Build a reproducible map between a coding-agent client, an upstream feature surface, and the local rulesync implementation.

A target without references/<client>.md is To be coming, not unsupported.

To add a client map:

1. Create references/<client>.md from the closest existing map.
2. Fill Official Docs with the client's docs URLs and feature surfaces.
3. Add Client Anchors only for behavior not obvious from rulesync-source-map.md.
4. Add the client to the request target table.

Contract

Input:

Reproducibility boundary: same question, official docs, local source tree, and dry-run command/config.

Collect:

1. Canonical target and feature lists from references/rulesync-source-map.md.
2. Rulesync support labels from README, source, processor gates, and dry-run.
3. Official docs from the selected client map.
4. Re-check sentinel rows through official docs/site, then web search if needed; confirm candidate URLs with Curl or Fetch. Recognized sentinel phrases:
   • No dedicated upstream <feature> surface in map — upstream has no dedicated docs surface that this row could point at.
   • No Rulesync-supported <feature> target in map — no Rulesync adapter is known to target this feature.
   • Rulesync maps <surface>; verify upstream before expanding behavior — Rulesync ships an adapter, but the upstream docs surface is thin or missing; treat as low confidence until re-verified.
5. Client anchors for surfaces not obvious from naming rules.
6. Dry-run output for generator gates and output roots.

Scope:

• Inspect every rulesync feature for each requested client.
• Do not narrow the investigation by feature or surface.
• Do not explain scope normalization in the final answer.

Dry-run commands:

pnpm run dev generate --targets <client> --features "*" --dry-run
pnpm run dev generate --targets <client> --features "*" --global --dry-run
pnpm run dev generate --targets "*" --features "*" --dry-run

Use client all-feature dry-runs by default. Use the all-target dry-run for cross-client questions. Dry-run is validation, not the answer.

Output:

1. Start with the result table.

Use README-style support labels for Rulesync: project, global, simulated, unsupported.

2. Add a surface table when the feature has sub-surfaces such as hook events, MCP transports, permission actions, config keys, metadata fields, or output roots.

3. End with capability gaps.

Use this section title:

## Capability Gaps

List only material feature gaps: unsupported upstream capabilities, missing project/global scope, missing event/config surfaces, lossy import/export, or deprecated surfaces that should be replaced. Each bullet should name the feature and user-visible missing capability. Write None only when every observed difference is an intentional mapping or already covered behavior.

For gaps based on any of the sentinel phrases listed in Collect step 4, re-check during the current run before claiming absence or low confidence.

Do not list tests, fixtures, refactors, source locations, or implementation chores unless they are necessary to explain the capability gap. Do not write "implementation change is not needed"; it is ambiguous.

Skip separate sections for canonicalization, map status, dry-run logs, and source lists unless the user asks for them.