chore(release): 1.0.1

明确 BSP 的 RES 开发范围和 SDK 构建写入边界；调整 CV184X 强制补丁预检并补齐构建交接测试。

skills/firmware-lowlevel-bsp-development/references/build-and-evidence.md

@@ -20,6 +20,10 @@ doc/bsp_adaptation/
 
 CSV 只有从原理图提取或重新映射 Pinmux 时才作为派生审核证据写入 `inputs/`；它不是唯一事实源。
 
+## 开发改动与构建写入
+
+按 [RES、SDK 与表述边界](res-sdk-boundary.md) 将当前 RES 项目的开发改动、SDK 只读核对映射和原生构建实际写入分开记录。构建授权覆盖标准工具已说明的配置同步及生成物写入，不授权额外编辑 SDK、替换 SDK 软链接或备份后恢复 SDK 配置。SDK 中出现差异时，先确定是否影响本次同步；不要把调查结果直接变成 SDK 修复方案。
+
 ## 本地 Git
 
 `EmxRes` 已有 Git worktree 只用于只读状态、参考项目脏文件发现和差异证据。不得执行 `git init`、`add`、`commit`、`stash`、清理、分支切换、历史改写或 `push`。
@@ -57,9 +61,9 @@ python3 <BSP Skill>/scripts/bsp/bsp_preflight.py build \
   --version <YYYYMMDD_N>
 ```
 
-`passed=true` 只是构建的必要条件。执行前把工具返回的精确工作目录、完整命令、项目与 SDK 路径、构建范围、最终 imgs 版本路径、工作区状态、配置同步副作用，以及统一脚本中的远端 `git fetch origin` 写入记录。CV184X 还须按下文检查 `requires_patch_precheck`；不能把这一字段当成普通提示后继续自动构建。不得从 `EmxRes` 的父目录启动，也不得依赖登录 Shell 的偶然当前目录。
+`passed=true` 是构建的必要条件。执行前把工具返回的精确工作目录、完整命令、项目与 SDK 路径、构建范围、最终 imgs 版本路径、工作区状态、配置同步副作用，以及统一脚本中的远端 `git fetch origin` 写入记录。不得从 `EmxRes` 的父目录启动，也不得依赖登录 Shell 的偶然当前目录。
 
-CV184X 还要执行 [CV184X 板级配置与构建链](cv184x-sdk-readonly-review.md)中的补丁门禁。其统一脚本在补丁检查失败后会尝试 `--applypatch --force`，可能重置多个 SDK 子仓库；这不属于上述自动构建授权。相关仓库存在未确认改动、补丁检查未通过或无法证明不会进入强制重置分支时，停止自动构建并向用户展示精确风险，不能静默运行或代替用户批准丢弃改动。CV181X 不套用这个补丁流程。
+CV184X 的补丁检查和失败诊断交给原生构建脚本；Skill 不单独检查补丁完整性，也不进入 SDK 仓库。预检仅查看本轮精确构建脚本是否仍可能自动调用 `--applypatch --force`；若有则停止，交构建脚本所有者改为失败即退出，禁止用静默替换脚本、跳过补丁检查或注入拦截命令来继续。安全脚本就绪后直接执行统一编译，按实际退出码和日志报告结果；CV181X 不套用 CV184X 的补丁逻辑。
 
 下列情况不自动处理：预检失败、统一脚本或路径与固定规则不符、输出版本已存在、参考或目标出现新的重叠改动、需要直接运行同步脚本、需要组件构建、需要改变构建参数、需要修改统一脚本，或者构建失败后需要清理和重试。此时停止并向用户说明异常、影响和可选处理方式。
 

skills/firmware-lowlevel-bsp-development/references/cv181x-sdk-readonly-review.md

@@ -5,7 +5,7 @@
 ## 先确定改哪里
 
 - `configs/uboot/<board_build_type>_defconfig` 确定板型；同目录的 `cvitek_<board_build_type>_defconfig` 和 `configs/kernel/` 中的对应 defconfig 必须成组存在。
-- U-Boot 板级初始化、分区表在 `configs/uboot/`；Kernel defconfig、DTS/DTSI、`memmap.py` 在 `configs/kernel/`。先从需求和生效引用找真正的源文件，再改项目配置；不要直接改 SDK 公共默认文件。
+- U-Boot 板级初始化、分区表在当前 RES 项目的 `configs/uboot/`；Kernel defconfig、DTS/DTSI、`memmap.py` 在 `configs/kernel/`。开发只修改这些 RES 源文件；SDK 对应文件用于只读核对和原生构建同步，不直接编辑。范围说明按 [RES、SDK 与表述边界](res-sdk-boundary.md) 执行。
 - `CONFIG_ENABLE_FREERTOS=y` 只说明启用了 FreeRTOS 相关配置，不能单凭这一项认定交付形态是双系统。
 - 参考项目 `CV1815JA_F36` 只能作为已知实现的例子，不代表所有 CV181X 产品的分区、内存、GPIO 或传感器配置。
 
@@ -19,7 +19,7 @@ python3 <BSP Skill>/scripts/bsp/inspect_cv181x_sdk.py \
   --sdk-root <用户明确指定的 SDK 根目录绝对路径>
 ```
 
-脚本先核对 `EP_CHIP`、SDK 版本、分目录布局和已知同步脚本，再比较项目文件与 SDK 对应文件。报告中的 `sdk_copy_differs` 表示当前内容不一致，不说明哪一份正确；`shared_sdk_target` 表示 SDK 板型文件实际是指向公共默认文件的软链接，后续复制可能影响别的板型；`generated_config_differs` 表示 SDK `build/.config` 与项目板级配置不一致，也可能只是 SDK 上次用于别的项目。对这些提示先确认使用的是哪个 SDK 和哪个构建版本，不擅自同步。
+脚本先核对 `EP_CHIP`、SDK 版本、分目录布局和已知同步脚本，再比较项目文件与 SDK 对应文件。报告中的 `sdk_copy_differs` 表示当前内容不一致，不说明哪一份正确；`shared_sdk_target` 表示 SDK 板型文件实际是指向公共默认文件的软链接，后续复制可能影响别的板型；`generated_config_differs` 表示 SDK `build/.config` 与项目板级配置不一致，也可能只是 SDK 上次用于别的项目。对这些提示先核对使用的是哪个 SDK 和哪个构建版本，不擅自同步。软链接提示不能转化为默认替换链接、改写公共目标或备份恢复 SDK 的方案；先报告原生同步的实际目标和影响。
 
 尤其要核对统一构建脚本里 `defconfig` 与 `Ep_Uboot_Config_Func`、`Ep_Kernel_Config_Func` 的先后。若先生成 `.config` 再同步项目配置，本次顶层配置可能仍是旧值；脚本会提示顺序风险，但不会代替真实构建。`ep_kernel.sh`、`ep_uboot.sh` 末尾若固定 `exit 0`，也不能只凭返回码宣称所有文件复制成功，应逐项核对源与 SDK 目标。
 

skills/firmware-lowlevel-bsp-development/references/cv184x-sdk-readonly-review.md

@@ -4,6 +4,8 @@
 
 ## 配置如何生效
 
+开发源文件与配置只修改当前 RES 项目。SDK 只读调查和原生构建同步按 [RES、SDK 与表述边界](res-sdk-boundary.md) 分开说明；本节中的 SDK 路径均为同步或生成目标，不授予人工编辑权限。
+
 专用工具按 `EP_CHIP` 和 `EP_FLASH_TYPE` 选定 `CV_BUILD_TYPE`。`EPSYNCSDKConfig.sh` 将项目单板卡目录用 `rsync -av` 写到 SDK `build/boards/cv184x/<CV_BUILD_TYPE>/`，然后工具执行 SDK `defconfig`、`clean_all` 和分项构建。先核对工具选出的 build type 与项目目录一致；若不一致，停止，不让同步脚本猜目标。同步脚本末尾固定 `exit 0`，单看脚本退出码不够，需比较每个映射文件及实际构建日志。
 
 项目板卡目录至少应结合真实需求检查顶层 `<board>_defconfig`、Kernel/U-Boot defconfig、`dts_arm/<board>.dts`、`u-boot/cvi_board_init.c` 与分区 XML。顶层 defconfig 经 `build/common_functions.sh:defconfig` 生成 SDK `build/.config`；`build/envsetup_soc.sh` 根据该配置选实际生效的分区 XML。`CONFIG_DUAL_OS` 还影响 `build/Makefile` 选用哪组模块加载顺序。DTS 的 GPIO 使用要追到 `cv184x_base_arm.dtsi`、封装 DTSI、存储 DTSI、`cv184x_default_memmap.dtsi` 以及最终 DTB；只检查项目顶层 DTS 不足以证明引脚已释放。媒体内存还要看 `cvi_board_memmap.h` 的生成值、Kernel reserved-memory 和 RTOS 占用。
@@ -22,8 +24,8 @@ python3 <BSP Skill>/scripts/bsp/inspect_cv184x_sdk.py \
 
 例如 `CV1841CP-LY-SM-YT70_dualos` 使用 `cv1841cp_wevb_0015a_spinand`。截至本次分析，项目与 SDK 当前的顶层 defconfig、DTS、分区 XML、U-Boot 初始化文件内容不同；项目分区的 APP/APP2 为 32768 KiB，SDK 当前表为 19456 KiB 并另有 DATA 分区。这是“当前 SDK 快照不可当作该项目已同步基线”的证据，不是要把 SDK 改成项目值的授权。其他 CV184X 项目不能套用这组容量。
 
-## 编译前的补丁门禁
+## 补丁检查的职责与构建安全
 
-`BuildCvitek184XSDKTool.sh` 在同步配置之前先运行 `cvitek_cv184x_patch/scripts/repos --check-env`；若失败，会自动调用 `--applypatch --force`。该补丁工具在部分仓库有未提交的已跟踪改动或提交不匹配时，可能运行 `git reset --hard`。SDK 顶层本身不是一个 Git 仓库，而是多个子仓库；需要逐个确认补丁作用范围、相关仓库状态和 `--check-env` 的真实结果。只读文件比对不能代替补丁检查。若检查不通过或会进入强制重置分支，停止自动构建，说明哪些改动可能丢失，再请用户决定；不要自行运行 `--applypatch --force`。
+`BuildCvitek184XSDKTool.sh` 应自行处理补丁检查，失败时返回错误。Skill 不额外运行 `--check-env`、扫描 SDK 子仓库或判断补丁完整性，只记录原生脚本的退出码和必要错误日志。编译前仅核对精确的项目构建入口不会在检查失败时自动执行 `--applypatch --force`；这不是补丁完整性检查。旧脚本仍包含自动强制打补丁时，不能以“失败后报告”代替禁止执行：先停止，让构建脚本所有者将失败分支改为返回非零；Skill 不自行改共享构建脚本或覆盖其行为。
 
 `EmxRes/tools/BuildGitCheck.sh` 会执行远端 `git fetch origin`，但对非 Git 顶层目录的错误不一定可靠传播，因此它显示“检查通过”不能单独证明所有 SDK 子仓库干净或版本一致。构建成功之后仍要核对实际生效分区表、`kernel.bin`/`rootfs.bin` 余量，以及 `fip.bin`、`boot.bin`、`yoc.bin`、驱动和 rootfs 是否按需求出现。单凭配置同步、命令零退出码或某个文件存在，不能声称 BSP 已通过板上验证。

skills/firmware-lowlevel-bsp-development/references/res-sdk-boundary.md

@@ -0,0 +1,33 @@
+# RES、SDK 与表述边界
+
+## 开发源文件
+
+BSP 工作包的人工开发改动只写入当前 `EmxRes/<项目名>` 及其 staging 项目。Pinmux、GPIO、DTS/DTSI、defconfig、媒体内存、分区和项目同步脚本均在 RES 中维护；参考项目只读。SDK 文件、SDK 软链接和 `EmxRes/tools` 共享构建脚本不属于该修改范围。
+
+确需修改 SDK 驱动、公共配置或共享构建工具时，先说明已确认的原因、所有权、精确文件和验证方式，作为独立工作包处理。读取 SDK 的授权和当前 BSP 工作包的批准均不自动授予这些编辑权限。
+
+## SDK 只读调查
+
+用户明确给出 SDK 根目录后，只读取与当前板型和问题相关的映射文件、必要 include 链及实现。调查所得的 SDK 路径用于证明映射或解释行为，不放入人工开发修改清单。
+
+项目与 SDK 内容不同可能来自上次构建、已有工作或基线差异。先说明证据及对当前任务的影响，不能仅凭内容不同认定 SDK 需要修复。发现软链接指向公共文件时，报告原生同步会写到哪里；不默认提出替换 SDK 软链接、重建目录、清理、恢复或备份后覆盖的方案。若未确认的已有改动将被本次同步覆盖，停止该构建并请用户决定，继续不依赖该问题的 RES 工作。
+
+## 原生编译的实际写入
+
+已确认工作包中的标准全量编译会执行项目原生配置同步，并写入 SDK 板级目标、生成配置、头文件、DTB、缓存和编译产物。配置同步可能穿过软链接写入公共目标；这些也是 SDK 的真实文件写入，必须按已核对的构建链如实说明。源文件的维护位置仍为 RES。
+
+这项构建授权只覆盖原生工具已说明的动作。不得为了编译顺利或让 SDK 看起来没有变化，额外编辑 SDK、改造软链接、注入同步逻辑、做完后恢复 SDK 配置，或修改共享构建脚本。项目同步脚本的修改也须列入 RES 实施方案，并说明其 SDK 写入效果；不能利用 RES 脚本扩大 SDK 修改范围。
+
+按用户已确认的语义处理“只改 RES”：若指开发改动只在 RES，保留已授权的原生编译，不为标准同步重复请求确认；若用户明确要求 SDK 在整个过程严格只读，而现有原生工具必须写入 SDK，则停止该构建，说明具体冲突并让用户选择继续 RES 静态工作或另行处理构建环境。不能自行改造 SDK 来消除冲突。
+
+## 方案与结果的说法
+
+方案和报告分别列出三项：当前 RES 项目的开发改动、SDK 的只读核对映射、原生构建将执行或已经执行的文件写入。SDK 存在多份同名文件时，使用精确路径，并标明软链接及其真实目标。
+
+- 开发阶段可以说“开发改动只写入 RES；SDK 仅用于只读核对”。
+- 构建阶段应说“原生编译会将 RES 配置同步到 SDK，并生成编译文件”。不能笼统承诺“SDK 不会发生任何修改”。
+- 不能将“构建同步到 SDK 的六个目标文件”说成“需要人工修改 SDK 的六个文件”。
+- 区分计划、已经执行和检查通过；只有读取证据时不能说已经同步，命令或复制成功不能代替生效配置、镜像和设备验证。
+- 用户纠正范围时，立即更新受影响的方案及记录；已知的路径、决定和授权继续使用。不要把一次范围澄清变成重复索要整套信息或重新审批已授权的标准构建。
+
+报告原生构建写入时，说明实际命令、配置来源、同步目标和生成物；没有执行的同步、编译及设备验证明确标为未执行。只有确认整个过程没有 SDK 写入时，才可以声称 SDK 目录未变化。

skills/firmware-lowlevel-bsp-development/references/scope-and-validation-modes.md

@@ -1,5 +1,7 @@
 # BSP 调查范围与验证模式
 
+调查、开发修改与原生构建写入按 [RES、SDK 与表述边界](res-sdk-boundary.md) 分开说明。下列读取范围不授予 SDK 编辑权限。
+
 ## 默认范围
 
 默认只读取：
@@ -37,7 +39,7 @@ CV184X 有独立的 [单目录 SDK 只读核对](cv184x-sdk-readonly-review.md)
 1. 从实际板级 DTS 开始递归解析有效 DTS/DTSI include 链和条件编译上下文。
 2. 读取范围限于为该 build type 解析出的精确文件和必要的 Pinmux 定义；仍禁止扫描整个 SDK。
 3. include 无法解析或上下文不唯一时，目标 GPIO 占用检查不得判为通过。
-4. 本模式只授予只读分析；只有任务明确进入构建产物交付级别时，才按 BSP 构建规则自动执行标准全量编译。其他 SDK 写入仍需用户确认。
+4. 本模式只授予只读分析；只有任务明确进入构建产物交付级别时，才按 BSP 构建规则自动执行标准全量编译。原生构建以外的 SDK 编辑不属于本工作包；确有需要时，先明确所有权及精确范围，另行确认。
 
 ## 模式记录
 

skills/firmware-lowlevel-bsp-development/references/workflow.md

@@ -59,7 +59,7 @@
 - 芯片、SDK、Flash、系统形态、布局和板卡版本；
 - 最终项目名；
 - GPIO、内存、分区差量和继承项；
-- 候选修改文件；
+- 当前 RES/staging 项目内的候选修改文件；SDK 同步映射和构建写入另列，按 [RES、SDK 与表述边界](res-sdk-boundary.md) 说明；
 - `imgs` 链接变化；
 - 输入证据和 `doc/` 计划；
 - 交付级别、调查范围、验证模式及结论上限；