Repository navigation
Description
范围、基线与去重
基线:476e64f04ed1d9c7dcab4a41c4f3cdb72faad6a7。只检查类的方法职责、模块归属和调用边界,不审计 token 算法、SQL 条件或恢复协议的具体实现。
与已有问题的区别:
- [P2][架构] OperationExecutor 反向依赖插件与 Application,执行内核缺少清晰的依赖边界 #156 是执行内核对插件和整个 Application 的反向依赖;本项是 Application 自己实现了身份业务。即使删除执行器的 application 回指,业务仍会留在装配类中。
- [P2][架构] 独立 hosting 进程复用完整写服务运行时,缺少只读角色的能力与密钥边界 #161 是 hosting 进程的只读装配与权限边界;本项适用于正常写服务,也不要求改变进程部署。
- 已关闭 [P1] 凭据一次交付与恢复丢响应全矩阵 #67 是一次释放与恢复丢响应协议的功能验收。本项不把已完成的协议当作未实现,不重开其功能待办,也不再设计第二套发行/恢复机制。
- 对照 [P2] 跨模块代码质量与测试债:拆分长路径、统一不变量 #85 的复用约束:只调整现有能力的归属,不新增通用 Manager/Factory/工作流框架。
结构证据
src/msg/application.py 的模块说明将其定位为网络服务的显式装配入口。Application 确实负责 Registry/插件安装、存储初始化、认证授权与执行器装配,但同时直接提供:
class Application:
def issued_token(self, request, subject): ...
@staticmethod
def recovery_verifier(value): ...
def record_token_delivery(self, tx, request, credential, now,
*, recovery_deadline=None): ...
async def _secrets_for_caller(self, request, result): ...这些方法共同负责 token 生成、恢复材料绑定、交付事实登记及成功结果中的一次性秘密释放。load() 又将 _secrets_for_caller 绑定为执行器的响应回调。这里列出的是业务责任和装配关系,不评价其算法或条件判断是否正确。
src/msg/plugins/identity.py 的凭据创建路径调用 app.record_token_delivery(...),所以 Application 不只是保存已经装配好的依赖,而是身份业务真实依赖的服务实现者。
Application
├─ Registry / 插件 / 存储 / 认证 / 执行器装配
└─ token 发行、恢复绑定、交付登记、秘密释放规则
↑ ↓
identity 插件直接调用 执行器响应阶段调用
架构问题
“如何启动整个服务”和“一个凭据何时能够交付”具有不同的变更原因,却由同一个类负责。身份模块的部分生命周期因此隐藏在顶层装配文件中,维护者从身份/安全模块边界无法完整识别其所有者;改动凭据交付协议也会触及所有运行角色共享的装配类。
本问题不取决于 Application 的行数,也不要求所有业务都改成类。需要的是让身份业务有一个明确的模块边界,而装配层只负责把它接到必要的入口上。
建议边界
把已有凭据交付能力收敛到身份/安全领域内的一个窄模块或服务,显式接收所需的密钥能力、clock、有限配置以及事务依赖。Application 负责构造和接线,不再包含交付规则或直接管理交付事实。
保留现有两个时点的区别:请求事务内的发行/恢复绑定,与业务提交后响应阶段的一次性释放。移动模块不能把它们合并成错误的单一事务,也不能把秘密放进持久 OperationResult、事件、日志或普通幂等重放结果。现有完成状态与恢复期限必须原义保留。
不要通过新增任意 before/after hook 系统解决这个问题;只为已经存在的受控交付能力提供明确接入点。该领域模块不得反向依赖完整 Application,也不得借机获得 Root 或其他无关密钥。
验收
- 明确上述四项业务能力的唯一所有者与输入/输出;Application 保留装配职责,不再实现 token 交付规则或持久交付事实操作。
- identity 插件和响应释放阶段消费同一个受控能力,而不是分别复制生成、恢复或领取逻辑;临时兼容转发不再承载业务政策。
- 新边界可以只用明确依赖进行装配/契约测试,不需要构造全套插件、HTTP 服务或整个 Application。
- 明确业务提交、释放资格消耗、响应交付和恢复的时序边界;保持 [P1] 凭据一次交付与恢复丢响应全矩阵 #67 的一次释放、丢响应、过期、并发、重试与重启回归。
- 已发表操作版本、签署字节、凭据标识、恢复绑定、持久 receipt/结果及秘密不落库/日志的语义不变;不把重构当作重新发放既有秘密的理由。
本项是行为保持的职责调整,不要求代码重写、公开协议升级或部署;没有运行测试或据此宣称存在凭据泄露。
Activity
test(identity): expose credential delivery ownership without changing…
refactor(identity): give one-time credential delivery a single domain…
test(identity): inspect persisted event JSON for one-time delivery ev…
Merge #175: promote verified token-delivery boundary into main
LIghtJUNction commentedon Sep 29, 2026
已通过 #175 真正进入 main,merge edbfbae,Git树 ebe1facca432803854d0c04aaa93519a589ff93f 与已验证PR checkout一致。此前 #172 只合到旧功能分支,不能作为主线完成证据;本次补齐目标,不重新实现#67。
验收:
security.token_delivery.TokenDelivery唯一拥有生成、绑定、交付登记和释放四项政策;Application只构造和转发。精确promotion head b0b5120:专项36551495692 122通过;完整36551495771 1901通过(465/496/483/457),下载四份产物逐个msg.nodeid核对全量union,无漏跑/重复/额外/失败/错误/跳过;conformance8通过,实际tokenizer测量与wheel/sdist构建齐全;Architecture/Storage/Recovery对应head成功。独立SHA256与原TDD笔记在#175正文、docs/TOKEN_DELIVERY_BOUNDARY_PROGRESS.md。
本项仅关闭架构职责问题;不涉及生产部署/Root/PIN/真实资金/外发/恢复promotion,不关闭#64/#65/#68–70/#84等现场验收。