Next.js app

Next.js app 在当前 playbook 中表示 Next.js 仍承担项目的 current runtime、API、preview 或 compatibility surface。它不一定意味着整个项目是纯 Next.js；在 Ivan 博客项目中，它是 legacy internal runtime，与 Astro public site 和 React admin SPA 共存。

这个 Topic 的价值是保留 staged migration 中还没有退场的 Next 边界。后续 Agent 不能因为项目已经有 Astro public site 或 React admin SPA，就假设 Next 依赖只是历史残留；只要 next.config.ts、scripts、gateway 或项目快照表明 Next 仍服务 API/preview/compatibility path，它就仍是当前系统的一部分（projects/blog-26.md）。

因此，Next.js app 在这个知识库里更像“剩余 runtime responsibility”而不是“技术选型偏好”。它回答的是哪些请求路径、预览行为、内容兼容逻辑和迁移风险仍由 Next 承担；如果这些边界没写清，后续维护者会过早删除它，或者反过来一直不敢删它。

当 next.config.*、Next scripts 或项目文档表明 Next runtime 仍被开发、测试或部署使用时使用。若 Next 只是历史依赖但已不在 runtime path，不应打标签。

如果改动触及 legacy API、preview route、gateway fallback、content compatibility 或从 Next 迁移到 Astro/React 的边界，应使用本 Topic。若仓库只是依赖树残留、没有运行脚本、没有 current route 或项目快照明确说明已废弃，则不应继续保留 Next.js app（projects/blog-26.md）。

• 迁移期项目要同时标注 Astro/React/Next，避免后续 Agent 只验证一个 runtime。
• Next runtime 的 API/preview/compatibility paths 属于高风险遗留面，重构时需要 e2e 或 gateway 验证。
• README 和 scripts 若与 current config 冲突，应优先看 next.config.ts、package.json 和 workflow。
• 项目摘要必须说明 Next 在 hybrid 架构中的角色：public reader surface 可能是 Astro，admin surface 可能是 Vite/React，但内部 API 或 preview 仍可能由 Next 负责（projects/blog-26.md）。
• 删除或替换 Next 前，需要把 route、env、data access、preview 行为和 gateway 转发全部列入验证范围；只看前端 build 通过不足以证明 migration 完成（projects/blog-26.md）。
• 维护 hybrid runtime 时，默认把 Next 相关变更与 Astro public build、React admin build、gateway smoke test 一起列入检查清单，避免只验证一个 surface（projects/blog-26.md）。
• 默认把 Next 视作“需要被精确说明的遗留面”，而不是一句“legacy runtime”带过。只要还在 current path 上，就要写明消费方是谁、哪些路由仍在走它、删除成功的判据是什么。

• projects/blog-26.md：公开镜像，legacy Next 仍服务内部 API/preview/compatibility。
• projects/blog-26.md：Astro public site、Vite/React admin 和 legacy Next runtime 共存，说明 Topic 应按仍在承担的 runtime responsibility，而不是按单一框架归类。
• 与 Astro site、React app 同时出现时，Next.js app 代表的是剩余 runtime responsibility，而不是 UI 栈偏好。

• 把 hybrid blog 归成纯 Next，会漏掉 Astro public site。
• 删除 legacy Next 前没有覆盖 API/preview，会造成迁移回归。
• 把 Next package 名当项目名会导致 display title 草率。
• 反向误判也很常见：看到 Astro 后直接移除 Next 标签，会让维护者忘记 legacy API/preview 仍在服务流量。修正方式是回到 projects/blog-26.md 的 Repository map 和 Runtime sections 核对边界。
• 把 Next 相关风险写成“旧代码待清理”而不写当前消费路径，会导致后续 Agent 重构时缺少验收标准；必须写明哪些路径仍要兼容、哪些验证能证明可删除（projects/blog-26.md）。
• 把 Next.js app 当成普通 frontend Topic 来回答，也会漏掉它最重要的部分：迁移判据。这个 Topic 的关键不是“如何写组件”，而是“哪些责任还没迁走、迁走后怎样证明不回归”。

• projects/blog-26.md