Context: Multiple migration tickets were triggered via Cursor Cloud outside the planned phase order. This audit maps each PR/branch to the migration plan and recommends use vs. delete-and-rerun.
Plan reference:knowledge/plans/brainforge-website-webflow-to-code-migration-2026/brainforge-website-webflow-to-code-migration-2026.md (Phases 1–5).
Current state
Phase 1 (Foundation): PR #334 (Astro marketing site setup, cursor/AI-834-astro-marketing-site-setup-c1d7) is MERGED → base Astro app in apps/marketing-site/ is on main.
All other migration PRs are DRAFT, from Cursor Cloud runs on 2026-03-10. Their branches are based off a common ancestor with main; full-diff stats are noisy (knowledge/binaries, transcript churn). The relevant changes are confined to apps/marketing-site/ and .github/.
Phase mapping and recommendation by PR
Phase 1 (Foundation) – use first
PR
Branch
Ticket
What it does
Recommendation
387
cursor/PLT-835-railway-ci-cd-configuration-ed23
Railway CI/CD configuration
Adds marketing-site-cicd.yml, nixpacks.toml, deployment-promotion-flow.md, CI tweaks (~6 files)
USE – Merge first. Completes BF-WEB-2 (CI/CD).
Phase 1 / early Phase 2 (design tokens + stub pages) – use next
PR
Branch
Ticket
What it does
Recommendation
388
cursor/PLT-1147-gradient-token-system-1561
Gradient token system
tokens.css, MarketingPageShell.astro, stubs for about-us, pricing, services, index updates (~11 files)
USE – Merge after PLT-835. Covers design tokens (BF-WEB-3) and early page shells.
Phase 2 / 3 – QA and design (use when doing those phases)
USE – Merge when starting blog migration. Script + schema.
384
cursor/PLT-1138-astro-blog-content-templates-0129
Astro blog content templates
Blog index/slug pages, RichContentBlocks.astro, content config, sample posts (~15 files)
USE – After or with 1137. Templates + content structure.
390
cursor/PLT-1139-blog-posts-media-migration-11b6
Blog posts media migration
~280 files: many blog images (binaries) + stub markdown posts, manifest, reports
CAUTION – Large. Either (a) merge when ready for full blog content and resolve conflicts, or (b) re-run a single “blog content + media” job in phase and use 1137/1138 as reference.
OVERLAP – Same space as 1141/1142/1143. Either merge 846 and then add 1142 (Cal.com) + 1143 (telemetry) on top, or use 1142 + 1141 + 1143 and skip 846.
USE – When blog URLs are final. Phase 4 redirects.
Conflicts to expect
.github/workflows/ci.yml and .github/scripts/document-council-pr.js are modified in almost every branch (each run added or adjusted something for marketing-site). When merging in sequence, keep one coherent CI shape (e.g. from PLT-835) and for other PRs either drop their ci.yml/document-council-pr.js hunks or resolve manually.
apps/marketing-site/README.md and package.json / package-lock.json are touched by many branches – resolve in merge order.
index.astro / global.css / Layout: 1147, 1145, 1146, 1143, 846 all touch these – merge in small batches and resolve.
Suggested merge order (to use code without full rerun)
PLT-1146 (Icons) – then PLT-1145 (Animations); resolve index/global.css if needed.
PLT-1142 (Cal.com).
PLT-1137 then PLT-1138 (Blog transform + templates).
PLT-1139 (Blog media + posts) – only if you want to keep the current bulk import; else re-run in phase.
Forms: either PLT-846 then PLT-1142 + PLT-1143, or PLT-1141 + PLT-1142 + PLT-1143 (and skip 846). Then PLT-1144 (QA doc).
PLT-1136 (Indexing/SEO), then PLT-1140 (Blog redirects).
PLT-1135 (Visual regression) – after core pages are stable; regenerate baselines if needed.
PLT-1134 (A11y) – when doing QA.
What to delete / re-run in phase
Don’t delete the branches above unless you decide to re-run those tickets from scratch. You can close the DRAFT PRs and still cherry-pick or merge the branches in the order above.
PLT-1139 (blog media): only re-run if you prefer a single clean “blog content + media” run in Phase 3 instead of merging the large 280-file PR.
If you want a strict phase-by-phase run with no cross-phase mixing, then close all DRAFT PRs, don’t merge the branches, and re-trigger Cursor Cloud (or local agents) per phase: 1 → 2 → 3 → 4 → 5. The merged Phase 1 (AI-834) stays; everything else would be redone in order.
Summary
Outcome
Action
Reuse most code
Merge branches in the suggested order; resolve CI and shared files (README, package.json, index.astro, global.css) at each step.
Reuse only Phase 1 + a few
Merge PLT-835 and PLT-1147; then do Phase 2 (core pages) properly; then pick specific PRs (e.g. 1137, 1138, 1142, 1146, 1136) as you reach each phase.
Strict phases, no reuse
Leave all DRAFT PRs closed; re-run migration tickets in phase order (Phase 2, then 3, then 4). Keep only AI-834 (already merged).
If you tell me which of these you prefer (reuse all / reuse Phase 1 + selected / strict rerun), I can outline the exact git steps (e.g. branch order, which PRs to close, and how to resolve the shared-file conflicts).