51 lines
3.3 KiB
Markdown
51 lines
3.3 KiB
Markdown
# PSP Etunel 交接
|
||
|
||
仅在当前 Hook、Etunel 角色契约和入站任务确认本会话是嵌入式底层角色时执行正式交接。成员结果只交给 Hub；不直接向应用层 AI 派任务或索取结论。没有有效 WORK_ID、SUBTASK_ID 或工具时只生成 handoff 文件并标记“尚未正式发送”。
|
||
|
||
## packaged candidate 交接
|
||
|
||
底层自检、固定组包和负责人确认完成后，依次处理：
|
||
|
||
1. 展示远端、分支和 candidate commit，取得 Git 上传确认；
|
||
2. push 后由 `render_psp_handoff.py --verify-remote` 使用只读 `git ls-remote` 验证团队共享地址的 heads/tags 能取得精确完整 commit；验证失败、超时或只有本地路径时不能形成 Etunel 交接；
|
||
3. 生成并展示 Etunel handoff，取得独立发送确认；
|
||
4. 向 Hub 提交本角色正式结果，由 Hub 给应用层创建集成任务。
|
||
|
||
交接至少包含：
|
||
|
||
- WORK_ID、SUBTASK_ID、阶段、波次和嵌入式底层主责；
|
||
- 项目、芯片、硬件/系统形态；
|
||
- PSP 共享仓库地址、完整 commit 和 candidate/packaged 状态；
|
||
- 参考 PSP 及来源版本；
|
||
- BSP handoff、BSP commit/build ID、Media/AIPlugin 基线；
|
||
- 烧录包绝对路径/hash；
|
||
- 静态检查、打包、设备和应用验证的真实状态/证据；
|
||
- 未执行项、警告、例外、依赖和剩余风险；
|
||
- 应用集成步骤及必须检查的项目；
|
||
- `self_check_result`、`internal_approved`、确认负责人/时间/范围/条件。
|
||
|
||
Git 地址和 SHA 是交付主体；Etunel 引用 PSP 内的 `psp.json`、`metadata/bsp.lock.json` 和精简适配结果。`--for-etunel` 只接受 `packaged` 或 `accepted`，还必须有与当前 URL/SHA 一致且通过的远端可达性证据。不要重复传输仓库、BSP IMG、大模型和公共库。
|
||
|
||
## 应用集成
|
||
|
||
Hub 交给应用层的任务至少要求：
|
||
|
||
- 在应用 `psp/` submodule 获取完整 PSP SHA；
|
||
- 生成应用侧 `psp.lock.json` 并检查 gitlink/HEAD/lock 一致；
|
||
- 完成应用编译和完整固件打包；
|
||
- 验证 BSP、Media 库、模型按配置找到并复制；
|
||
- 检查 PSP 覆盖清单；
|
||
- 返回应用 commit、PSP commit、命令、结果、证据和负责人确认。
|
||
|
||
PSP 可以在 packaged 后交付，设备验证与应用集成并行。两条证据必须对应同一 PSP commit，之后 Hub 创建独立 PSP 验收收尾任务。底层负责人确认并取得用户发布确认后，才创建/push accepted tag。
|
||
|
||
应用长期未完成时，原底层实现任务可以以 device_verified 或 packaged 的真实状态结束，PSP 不提前 accepted；收到应用结果后另建收尾任务。
|
||
|
||
## 问题返工
|
||
|
||
应用层经 Hub 返回问题，输入应包含 PSP SHA、应用仓库/commit、芯片/板卡、BSP build、复现步骤、期望/实际、日志、涉及配置、阻塞影响和应用负责人确认状态。
|
||
|
||
Hub 创建新的嵌入式底层 SUBTASK_ID。PSP 在职责内修正并产生新 candidate；旧 commit 和证据保留。问题属于 BSP/DTS/驱动/内存、应用业务、硬件、公共 Media/AIPlugin 或测试环境时，只提供事实、证据和归属建议，由 Hub 路由，不越界修复。
|
||
|
||
已经 accepted 的缺陷按[项目与 Git 规则](project-and-git.md)创建 revoked 状态、通知已知引用方，并为修复重新走完整流程。Git/Etunel 发送和状态发布分别确认。
|