What the tracker holds
Explanation: the registry, its two workflows and how it ties to Jira. Setup and the API are in the tracker README.
apps/migration-tracker (Next.js on Vercel, Supabase) holds the registry: items of kind widget or content_type with pipeline stages as data, a settable priority, a migration action (rebuild, create from scratch, don't migrate or combine), the Software Factory job number (set by the skill when a run starts), pages, dependencies, artifacts (fixtures, HARs, specs, requirements, stories, data models), field mappings, test runs, status history and rebuilds (each re-run of a widget, with its reason and the ticket it reused; the item's History panel interleaves them with status changes, and GET /api/reports/regeneration groups them by Optimizely content model). It also imports the Pulse widget registry and usage from the backlog spreadsheet (apps/migration-tracker/data/backlog) so coverage of in-use Pulse widgets is visible. POST /api/items/:id/ticket creates the factory's Jira ticket. Its Docs tab shows the flow, framework and parity diagrams. Setup and API are in apps/migration-tracker/README.md. The Article page's 35 widgets are in apps/migration-tracker/data/seed.json.
The content-model workflow (understand the Pulse model → design the Optimizely model → implement → migrate content) uses the same schema with kind content_type and stages understood → designed → implemented → migrated; its Excel models, Confluence requirements and Jira stories are artifacts, and Pulse-to-Optimizely field mappings live in field_mappings.
Setup and the API: Migration tracker.