flaglint-js's ScanResult carries an optional `migrationInventory` field — a richer, migration-focused record of each call site (raw expression text, source ranges, value-type inference, `safelyAutomatable`/`manualReviewReason` classification) meant to drive a future `migrate` rewriter. The cross-tool spec marks this field optional for other implementations "until spec v1.2," but since flaglint-js already emits it and flaglint-go otherwise mirrors its `FlagUsage`/`ScanResult` shape closely (ADR 003), it's worth implementing now for real cross-tool parity rather than waiting.
flaglint-go has no `migrate`/`--apply` command yet (ADR 002's Phase 1 scope) — this is building the data foundation a future migrate command would need, not the command itself.
flaglint-js's ScanResult carries an optional `migrationInventory` field — a richer, migration-focused record of each call site (raw expression text, source ranges, value-type inference, `safelyAutomatable`/`manualReviewReason` classification) meant to drive a future `migrate` rewriter. The cross-tool spec marks this field optional for other implementations "until spec v1.2," but since flaglint-js already emits it and flaglint-go otherwise mirrors its `FlagUsage`/`ScanResult` shape closely (ADR 003), it's worth implementing now for real cross-tool parity rather than waiting.
flaglint-go has no `migrate`/`--apply` command yet (ADR 002's Phase 1 scope) — this is building the data foundation a future migrate command would need, not the command itself.