sync-providers

name

sync-providers

description

Ensures Real and Fake provider implementations stay in sync with their interfaces. Scans provider interfaces, detects missing or mismatched methods in Fake/Real implementations, validates fake data consistency, suggests realistic fake data from Real provider patterns, and can auto-generate stub implementations. Use when the user says /sync-providers, "sync providers", "check provider sync", "providers out of sync", or asks to verify or fix Real/Fake provider implementations.

Provider Pattern Synchronization

Keeps Real and Fake providers in src/Plugins/Providers/ aligned with their interfaces. Use after interface changes or when adding new provider methods.

When to Use

• Check all providers: /sync-providers or "sync providers"
• Check one provider: /sync-providers ICalendarDataProvider or "sync IWeatherDataProvider"
• Auto-fix missing stubs: /sync-providers --fix or "sync providers and apply fixes"

Workflow

1. Discover interfaces and implementations

• Interfaces: src/Plugins/Providers/Interfaces/*.cs — every public interface I*Provider or I*DataProvider.
• Fake: src/Plugins/Providers/Fake/Fake*.cs — class name must match interface (IOutlookEmailProvider → FakeOutlookEmailProvider, IWeatherDataProvider → FakeWeatherDataProvider).
• Real: src/Plugins/Providers/Real/Real*.cs — same naming rule.

For each interface file, infer the expected implementation names: drop the leading I, then use Fake/Real + the rest (e.g. IOutlookEmailProvider → FakeOutlookEmailProvider, RealOutlookEmailProvider).

2. Extract interface methods

From each interface, list every method that returns Task or Task<T>. Treat these as the contract. Ignore properties unless they are part of the provider contract in this project.

3. Check implementations

For each interface:

• Real: Ensure a Real* class exists and implements every interface method. Report missing methods or missing class.
• Fake: Ensure a Fake* class exists and implements every interface method. Report missing methods or missing class.

If the user specified a single provider (e.g. ICalendarDataProvider), run only for that interface.

4. Report format

Use this structure so the user can act or apply fixes:

Analyzing providers...

⚠️  ICalendarDataProvider
  ✓ RealCalendarDataProvider implements all methods
  ✗ FakeCalendarDataProvider missing method: GetRecurringEventsAsync

  Suggested implementation:

  public async Task<List<CalendarEvent>> GetRecurringEventsAsync(DateTime start, DateTime end)
  {
      // Return sample recurring events for testing
      return new List<CalendarEvent>
      {
          new() {
              Title = "Weekly Team Meeting",
              StartTime = DateTime.Today.AddHours(14),
              IsRecurring = true
          }
      };
  }

✓ IStockDataProvider - all implementations in sync
✓ IWeatherDataProvider - all implementations in sync

• ✓ — interface and both implementations in sync.
• ⚠️ — at least one mismatch; list what’s missing and, when possible, add a “Suggested implementation” block.
• Prefer Task.FromResult(...) in Fake methods when there’s no async work (see create-provider / existing Fakes).

End with choices when there are fixes to apply: [Apply Fixes] [Review] [Skip].

5. Suggesting realistic fake implementations

When generating a “Suggested implementation” for a missing Fake method:

1. Use the interface for method name, parameter types, and return type.
2. Use the Real implementation (if present) to infer:
   • DTOs and property names (e.g. CalendarEvent, StartTime, IsRecurring).
   • Typical values (e.g. “Weekly Team Meeting”, realistic times).
3. Match project style:
   • Namespace AnimalAI.Plugins.Providers.
   • In-memory data only; no HTTP or I/O.
   • For simple returns: return Task.FromResult(...);
   • For keyed lookups (e.g. coordinates), round/normalize to a small set and provide a default, like FakeWeatherDataProvider.

If there is no Real implementation, use the interface XML and parameter names to infer a minimal, realistic stub (e.g. list of one item with plausible property values).

6. Validating fake data consistency

When reviewing existing Fake implementations (during “check” or before “apply”):

• Types: Fake return types must match the interface exactly (e.g. Task<List<OutlookEmail>>, Task<OutlookEmail?>).
• Nullability: Respect T? vs T in the interface.
• Defaults: If the Real provider returns null or a safe default on failure, the Fake can return a non-null default for tests, but the type must still match (e.g. Task<OutlookEmail?> may return Task.FromResult<OutlookEmail?>(null) or a mock instance).

Flag any Fake that throws or performs I/O; Fakes should be in-memory only.

7. --fix (auto-generate stubs)

When the user requests /sync-providers --fix or equivalent:

1. Run the same analysis (discover interfaces, extract methods, check Fake/Real).
2. For each missing Fake method:
   • Generate a stub that compiles and matches the interface.
   • Reuse the “Suggested implementation” rules above (Real pattern + project style).
   • Insert the new method into the existing Fake* class (or create the class if the Fake is entirely missing).
3. For each missing Real method (optional, only if the user explicitly asked to fix Real too):
   • Add a method that implements the interface, calls external API or real I/O as needed, and returns null or a safe default on failure, consistent with other Real providers.
4. After editing, suggest or run a build (e.g. dotnet build src/Plugins/Plugins.csproj) to confirm no compile errors.
5. Summarize what was added and offer to run tests if relevant (e.g. run-tests.ps1 -t <tag> for the affected plugin).

If the user only said “sync providers” or “check provider sync” without “--fix” or “apply fixes”, do not modify files — report only and show [Apply Fixes] [Review] [Skip].

Naming and paths reference

Artifact	Path	Naming
Interface	src/Plugins/Providers/Interfaces/I[Feature]DataProvider.cs or I[Feature]Provider.cs	I*Provider / I*DataProvider
Fake	src/Plugins/Providers/Fake/Fake[Feature]DataProvider.cs or Fake[Feature]Provider.cs	Implements I*; name = Fake + interface name without I
Real	src/Plugins/Providers/Real/Real[Feature]DataProvider.cs or Real[Feature]Provider.cs	Same rule as Fake

Examples: IWeatherDataProvider → FakeWeatherDataProvider, RealWeatherDataProvider; IOutlookEmailProvider → FakeOutlookEmailProvider, RealOutlookEmailProvider.

Stub style (Fake)

Follow the same patterns as in the create-provider skill and existing Fakes:

• One class per file; class implements the interface.
• Use Task.FromResult(...) for sync-style returns.
• Use static readonly dictionaries or lists for keyed/data-driven fakes.
• Round or normalize inputs (e.g. coordinates) to a small set of keys; provide a sensible default for unknown keys.
• No HttpClient, no file I/O, no network.

Related

• create-provider (.cursor/skills/create-provider/SKILL.md): templates and conventions for new interfaces and Fake/Real implementations.
• Reference implementations: IWeatherDataProvider, FakeWeatherDataProvider, RealWeatherDataProvider; IOutlookEmailProvider, FakeOutlookEmailProvider, RealOutlookEmailProvider.

Summary checklist

Before finishing a sync-providers run:

• All interfaces under src/Plugins/Providers/Interfaces/ were considered (or the single requested one).
• For each interface, Fake and Real implementation names were resolved and checked.
• Every interface method is accounted for (implemented or reported as missing).
• Suggested implementations use AnimalAI.Plugins.Providers and match existing Fake style.
• With --fix, only missing stubs were added and the solution still builds.
• Output uses ✓/⚠️/✗ and ends with [Apply Fixes] [Review] [Skip] when there are fixes to apply.