/apollo-check

Apollo Repository Investigation

> **Project context:** Values in angle brackets below (e.g. `<scheme>`, `<JIRA_KEY>`, `<flag-key-enum>`) are resolved at runtime — detect them from the project (`xcodebuild -list -json` for the scheme, `git`/`gh` for repo & owner, the branch name for the Jira key, a codebase search for flag/font files), or ask if they cannot be inferred. This plugin ships no per-project config.

Investigate the Apollo repository **$ARGUMENTS** and produce a detailed investigation for migration.

**Output:** This command creates an investigation file at `docs/apollo-removal/issues/$ARGUMENTS.md` that serves as the "issue" for this migration. The `/apollo-migrate` command will read this investigation before executing the fixed migration steps.

Steps

1. Find All Related Files

Search for all files related to this repository:

Glob: **/$ARGUMENTS*
Glob: **/Network$ARGUMENTS*
Grep: "$ARGUMENTS" in *.swift files

Look specifically for:

• `.graphql` file (query definition) - usually in `<scheme>/Repositories/<Name>/` or `<scheme>/Modules/<Feature>/Repository/`
• `.graphql.swift` file (Apollo-generated types) - usually in `<scheme>/Services/Apollo/API/`
• `Network*Repository.swift` (old implementation using Apollo)
• Any existing new-pattern files (`*GraphQLDataSource.swift`, `*Query.swift`, etc.)
• Fragment extension files (`*+Fragments.swift`)

2. Read the Implementation

Read the old `Network*Repository.swift` file to understand:

• What queries/mutations does it perform?
• What Apollo types does it use?
• What protocol does it conform to?
• What domain models does it return?
• What cache policies does it use?

Read the `.graphql` file to get the query string.

Read the `.graphql.swift` file to understand nullability of fields (`.nonNull` vs optional).

3. Find All Consumers

Search for all files that import or use this repository:

Grep: protocol name (e.g., "<Name>RepositoryProtocol" or "<Name>Repository")
Grep: class instantiation (e.g., "Network<Name>Repository(")
Grep: factory usage if exists

Check in:

• ViewModels (`*ViewModel.swift`)
• Managers (`*Manager.swift`)
• Coordinators (`*Coordinator.swift`)
• Factories (`*Factory.swift`)
• Other repositories that might depend on it

**For each consumer**, note:

• The file path
• How it instantiates the repository (inline GraphQLClient? Network.shared? factory?)
• Which methods it calls
• Whether it uses Apollo types directly (fragments, query data types)

4. Check for Feature Flags

Check if the repository's consumers are gated behind Firebase Remote Config flags or feature toggles that may indicate dead code:

Grep: RemoteConfig / remoteConfig / FeatureToggle in each consumer file
Grep: the consumer's class name in coordinator/factory files to trace the full call chain

For each consumer, trace the full instantiation chain back to the entry point (Coordinator → Factory → ViewModel → Repository). At any point in that chain, check if a feature flag controls whether the code path is reached.

**For each feature flag found**, document:

• The flag key (e.g., `is_<feature>_available`)
• Which `<flag-key-enum>` case it maps to
• What the default value is (check `<flag-defaults-file>`)
• Which code branch uses the repository (the `true` or `false` path)

> **Why this matters:** If a repository is only used behind a feature flag that has been permanently disabled, the entire repository + consumer chain may be dead code. The user can validate this in Firebase Remote Config before deciding to **delete** instead of **migrate**, saving the full migration effort.

5. Check for Shared Fragments

Search if this repository's `.graphql` file defines fragments used by other repositories:

Grep: fragment names from the .graphql file across all other .graphql files

If fragments are shared, note which repos depend on them — the `.graphql` file may need to be kept.

**IMPORTANT:** Also check the reverse: do OTHER `.graphql` files have queries that reference fragments defined in THIS repo's `.graphql` file? If so, deleting this `.graphql` will cause Apollo codegen to fail with "Unknown fragment". In the investigation, note whether the referencing query is dead after migration (can be removed from the other `.graphql` file) or still live (fragment must be kept or inlined).

6. Check if Already Partially Migrated

Look for signs of existing migration:

• `*GraphQLDataSource.swift` files
• `*Query.swift` files in Queries/ subfolder
• Usage of `GraphQLClientProtocol` instead of `Network.shared`
• Existing `MigrationModel` structs in SharedModels

7. Write the Plan File

Create the file `docs/apollo-removal/issues/$ARGUMENTS.md` using the Write tool with this structure:

# Migration Plan: $ARGUMENTS

> Generated: <date>
> Status: planned

## Summary

- **Repository:** <full class name>
- **Location:** <path>
- **Tier:** <1-5>
- **Consumers:** <count>
- **Operation type:** query / mutation / mixed
- **Recommendation:** migrate / delete / already-done

## Current State

### Files
| File | Path | Purpose |
|------|------|---------|
| .graphql | <path> | Query definition |
| .graphql.swift | <path> | Apollo-generated types |
| Network impl | <path> | Old Apollo implementation |
| Fragment extensions | <path or N/A> | Apollo fragment helpers |

### Queries/Mutations
| Operation | Name | Variables | Cache Policy |
|-----------|------|-----------|--------------|
| query/mutation | <OperationName> | <list or none> | <policy> |

### Response Shape
<Describe the response structure based on .graphql.swift analysis, including nullability>

### Shared Fragments
| Fragment | Defined in | Used by |
|----------|-----------|---------|
| <name> | <this repo's .graphql> | <list of other repos> |

(or "None — .graphql can be safely deleted")

### Consumers
| # | File | Instantiation | Methods Used | Uses Apollo Types? |
|---|------|---------------|--------------|-------------------|
| 1 | <path> |