员工身份与客户上下文：同一个 customer_id 为什么还不够
W04-D04 首讲，W05-D01 用于会话隔离，W07-D02/D04 用于工具权限与审批。案例为教学数据。
先区分三个“谁”
| 对象 | 回答的问题 | 当前代码边界 | 企业接入时由谁保证 |
|---|---|---|---|
| 员工身份 actor | 谁登录后台、拥有什么角色 | W03 已有 viewer/support/admin 与服务端会话校验 | 登录服务与 API 权限层 |
| 客户 customer | 当前服务哪个客户、订单归谁 | W04–W08 的 TrustedCustomerContext 来自 FIXTURE/课堂会话 | 服务端从已验证关系查得，不能照收模型参数 |
| 服务身份 service | 哪个应用在调用商城 | 课堂适配器不等于完成生产服务鉴权 | 服务凭证、最小 scope、轮换及审计 |
W03 运营后台允许员工管理订单，不等于客户可以查看别人的订单；support 是员工角色，customer_id 是业务对象。不能把两者一一对应。公开商品读取也不能推出订单读取公开。
一次查询或写操作经过哪些门
- 入口验证员工会话，得到 actor；请求里自称 admin 不算。
- 检查该 actor 是否有当前动作权限，以及是否有权服务这个客户/租户。
- 宿主据可信关系构造客户上下文。模型只提议 order_id 等业务参数，不能提交 actor、role、customer_id 替换宿主字段。
- 工具查询实际订单归属，再判断数据范围。权限不足在返回订单内容前拒绝；不能先泄漏再提示无权。
- 写操作另经明确人工批准。审批者 approver 需要资格；员工已登录不等于这一次载荷已经被批准。审批绑定 request_id、pending_call_id、载荷摘要和幂等键；变更后旧批准失效。
- 内部调用携带服务身份，记录 actor、customer、服务、approver（如有）、correlation_id、动作及结果；审计存必要标识，不能存密码、Cookie、密钥或审批原令牌。
员工会话 → 动作权限/客户范围 → 宿主客户上下文 → 工具数据归属 → 写前审批 → 业务幂等
模型提议只进入业务参数 ↑ ↓ 审计关联本课练习：补一个权限判断，不重写登录系统
阅读现有工具合同，完成下表的“允许/拒绝、阻断层、证据”三列。每人自行设计一个未见越界输入。
| 场景 | 需要检查的边界 |
|---|---|
| viewer 在界面隐藏按钮后，直接发修改请求 | 服务端动作权限是否仍拒绝 |
| 合法员工请求不在可服务范围的客户订单 | 员工身份有效与客户范围授权分开 |
| 模型 arguments 新增 customer_id 或 role | Schema 拒绝 extra，宿主身份不被覆盖 |
| 订单号存在，但所属客户与可信上下文不同 | 数据归属检查，零订单正文泄漏 |
| 员工有操作角色，但待审批载荷发生变化 | 旧批准不可复用，写次数为 0 |
| 服务凭证有读权限但无写权限 | 工具是否可调用还受服务 scope 限制 |
交付 identity_boundary.md：画上述身份流，标出当前已实现、课堂模拟和待生产接入，并选模型篡改身份或错订单归属做一个本人负向测试。不要用 fake token 或固定 customer_id 声称完成真实鉴权。
答辩自测
- session_id、conversation_id、task_id、customer_id 分别标识什么？哪一个单独就能证明授权？
- “可信”是谁验证的？Fixture 可信是否代表真实用户已经登录？
- 为什么查订单前和创建工单前都要做检查？角色、归属、审批和幂等各挡住什么不同错误？
正确解释应指出：这些 ID 本身都不是权限证明；生产需要可信身份来源及服务端授权。当前衔接练习交付的是边界设计与负例，未完成跨周生产身份系统合并。