Next.js Upgrade Board

• 升级排查从逐仓库翻查，变成按风险和关联状态快速筛选。
• 执行方可以直接从看板拿命令推进升级动作。

• 将版本分布、Vercel 关联、升级命令放入同一看板，减少跨工具切换。
• 以规则层直接产出命令模板，降低手工判断和复制错误。

• 可公开体验的静态 board snapshot：/projects/nextupgrade/live.html。
• 看板包含 major 分布、项目级详情、linked/high-risk 过滤等核心证据。

• Owner / Product Engineer：定义升级规则，搭建扫描管线，设计可执行的升级面板。

• 多仓库并行时，Next.js 版本分散且线上关联不透明，升级优先级难以统一。

• 数据源来自本地仓库扫描，输出要足够轻便以便持续复用。
• 结果必须可执行，避免只做“报告式审计”。

Next.js 项目一多，升级不再是单仓库问题，而是“哪些在 13、哪些在 15、哪些已经绑了 Vercel、哪些应该优先动”。这个项目把升级判断从零散记忆变成一张面板。

• 盘点当前代码库里有哪些 Next.js 项目、分别卡在哪个 major 版本。
• 识别哪些项目已经绑定 Vercel，升级时需要先关注线上影响。
• 给每个仓库直接生成升级命令，减少人工翻 package.json 的成本。

• 升级总览：项目总数、按 major 版本分布、Vercel 绑定情况。
• 项目级表格：路径、Next 版本、router 类型、包管理器、Vercel 关联、建议命令。
• 过滤器：快速只看 linked 项目或高风险旧版本项目。

• 输出必须可执行，而不是只做审计：建议命令要能直接复制。
• 让版本问题可视化：先看分布，再钻到单项目。
• 工程治理做成轻量 dashboard，不搞重型平台。

• 扫描本地 package.json / lockfile / .vercel/project.json，提取版本与关联信息。
• 把扫描结果静态渲染为单页 HTML，便于分享、归档和再次运行。
• 规则层负责输出升级命令模板，减少人工判断与复制错误。

• 官网里展示的是静态 demo，看板本身可以直接打开体验。
• 真实数据来源仍是本地仓库扫描，因此公共版本只展示可安全公开的结果快照。