project-onboard —— 基线验证

基线（baseline）是"onboarding 开始时，这个 ref 在这个环境中的已知状态"。它不是修复清单，也不是质量评分。必须在任何源码变更之前获取，才能把原有失败与后续改坏区分开。

六个步骤

按顺序、在适用时验证：

Build → Existing Tests → Smoke Test → Application Startup → Frontend Build → Frontend Tests

每一步记录：精确命令、工作目录、环境与版本、依赖/服务条件、commit/ref、结果、关键输出、耗时。

结果状态

结果	定义
PASS	精确命令在记录的环境中以预期 exit/result 完成
FAIL	命令可执行但返回错误、测试失败、启动失败或结果违背自身断言
UNAVAILABLE	因缺少工具、依赖、服务、平台或凭据而无法执行
SKIPPED	有意不执行（风险、成本、范围、权限或缺授权）

PASS 绝不表示"大概能跑"；FAIL 绝不表示"没装工具"。命令只覆盖部分工作区时，须明确 scope。UNAVAILABLE 与 SKIPPED 都记录具体原因与恢复条件。

命令安全分类

可直接运行——仅限已确认不会写文件、不改环境、不访问外部系统的只读检查与编译器/linter dry check。隔离测试与本地构建仍需本地副作用授权并声明输出边界。

先问或跳过——连接生产/预发或共享数据库；迁移、种子、重置、清除、部署、发布；发送邮件/短信或调用付费 API；需要 secrets 或敏感数据；明显昂贵或不可控的全量 E2E/性能套件；行为不明的脚本。测试、冒烟与启动必须使用一次性/隔离的本地数据；无法确认隔离时先询问。

每条命令后检查完整工作区（tracked、相关 untracked、预期 ignored 输出）与派生的进程/服务。预期的 build/coverage 产物要记录；意外的快照、codegen 或未知持久化写入须暂停——绝不自动回滚、删除或并入文档变更。

既有失败

基线时已存在的失败标记为 pre-existing failure 并附复现细节，以免日后被改写为新的回归。基线文档是不可变的历史快照：即便后续 Feature 交付，原始基线与原始 AS-IS/证据段也保留，规范文档转为 Perspective: CURRENT 并回链基线。

输出

结果写入 docs/onboarding/BASELINE.md，记录 ref、环境、命令、结果、既有失败、语言策略状态与授权边界。