第 7 周：让一线角色在权限内完成任务

直接答案： 软件底座只有接回一线任务才有意义。第 7 周要让普通客服和主管在服务端权限内看到不同内容，让普通客服能够核验依据、确认、拒绝或升级；无权限、过期、冲突和重复请求进入明确状态。最后用一次受保护走查重新检查原来的问题合同，而不是把界面完成或一句好评写成采用和业务成功。

起点： 已完成第 6 周可靠数据入口，拥有确定性薄片、通过质量门的数据、来源/版本/有效期/权限元数据、幂等和安全日志。
工程前置： 你能在自己的技术栈中实现服务端身份上下文、授权判断、事务状态变更和端到端测试。
预计投入： 8–10 小时，建议分成 5 次完成。
本周表现： 实现普通客服与主管两类固定角色、确认与升级两个动作、一次服务端无权限拒绝和一次重复请求，并完成一线走查或明确标注的角色扮演。
完成证据： 非 AI 工作台或 CLI、role-and-permission-matrix.md、任务状态图、端到端测试、关联日志、field-feedback-note-v1.md、decision-memo-02.md 和 Brief 复核记录。
本周不做： 不使用模型、RAG、Agent 或 MCP；不自动发送客户回复；不宣称真实采用、效率、ROI、生产安全或完整多租户能力；不把前端隐藏按钮当授权。

本周只增加一个难度：把软件接回真实角色和决定

通过质量门的数据
  → 可信身份与服务端授权
  → 用户看到权限内来源和状态
  → 用户核验、确认、拒绝或升级
  → 数据库与日志记录同一终态
  → 一线走查重新检查 Brief

第 5 周只有一个受控身份和只读候选，第 6 周保证数据状态可靠。第 7 周才增加两个角色和会改变任务状态的用户动作。生产部署、正式安全评审和长期采用仍在后续阶段。

最小心智模型：认证、授权和用户决定是三件事

概念	回答的问题	本周例子
认证	当前请求是谁？	可信测试会话解析出 `support_agent_a`
授权	这个身份能对哪个资源做什么？	普通客服能看普通政策、不能看主管正文
用户决定	在允许范围内，用户怎样结束当前任务？	核验后确认、拒绝或升级

前端隐藏“主管政策”按钮只能改变界面，不能阻止用户直接调用接口。授权必须在服务端、每次读取或写入前执行，并默认拒绝未知角色和未知动作。

另一个重要边界是：

confirmed 只表示用户确认了本次政策依据，不表示客户回复正确发送，不表示采用，更不表示业务价值实现。

先看完成品：北辰权限内任务闭环

下面的身份、权限、任务、政策、请求、结果和反馈全部是固定合成教学材料。

使用的上游证据

- Brief：northstar-discovery-brief-v1（课程模拟批准）
- 数据合同：northstar-data-contract-v1
- 数据批次：batch-w06-20260825-a + replay-w06-001
- 一线任务：套餐升级差价政策确认
- 主要异常：特殊退款需要主管路径，但不能向普通客服泄露主管政策正文
- 当前决定：验证权限内的核验、确认和升级，不批准自动回复或生产上线

完成的角色与权限矩阵

资源或动作	普通客服 `support_agent`	主管 `support_supervisor`	服务端规则
查看普通政策候选	允许	允许	按访问级别和任务范围过滤
查看主管专属正文	拒绝	仅在获准主管任务中允许	不能只靠界面控制
查看来源、版本、生效期	允许其可见候选	允许其可见候选	与正文使用同一权限判断
确认普通任务依据	允许	允许	需要当前版本和任务仍开放
拒绝候选	允许	允许	记录安全原因，不强迫选择
发起主管升级	允许	允许	不携带受限正文
解决主管升级	拒绝	允许	本周只做最小状态，不执行退款
修改身份或角色	拒绝	拒绝	身份来自可信会话

矩阵中的角色名是课程示例，不是通用企业角色模型。

任务状态图

opened
  → candidate_presented
      → confirmed
      → rejected
      → needs_review
          → escalated
              → resolved_by_supervisor

denied 不属于任务状态。它是一次请求的结果：当前身份无权执行动作时，服务端返回 denied，原任务仍停留在原状态。把它画进任务状态图，会让实现者误以为越权请求也应修改业务状态。

只允许声明的状态转换。例如已 confirmed 的任务不能用同一普通动作改成另一个政策；需要新决定时创建受控修订事件，而不是覆盖历史。

正常任务：普通客服确认依据

可信服务端会话：

{
  "identity_id": "support-agent-a",
  "role": "support_agent",
  "session_fixture": "northstar-w07-session-a"
}

任务读取的预期结果：

{
  "task_id": "TASK-W07-001",
  "status": "candidate_presented",
  "candidate": {
    "policy_id": "POL-PLAN-01",
    "version": 3,
    "effective_from": "2026-08-01",
    "source_id": "KB-BILLING-2026-08"
  },
  "allowed_actions": ["confirm", "reject", "escalate"],
  "correlation_id": "corr-w07-001"
}

用户核对日期、地区和来源后提交：

{
  "task_id": "TASK-W07-001",
  "action": "confirm",
  "policy_id": "POL-PLAN-01",
  "policy_version": 3,
  "idempotency_key": "TASK-W07-001:confirm:v3"
}

预期响应：

{
  "task_id": "TASK-W07-001",
  "status": "confirmed",
  "confirmed_policy_id": "POL-PLAN-01",
  "confirmed_policy_version": 3,
  "correlation_id": "corr-w07-001"
}

预期数据库事件：

event_id	task_id	actor	action	old_state	new_state	idempotency_key
EVT-001	TASK-W07-001	support-agent-a	confirm	candidate_presented	confirmed	TASK-W07-001:confirm:v3

权限异常：普通客服遇到特殊退款

普通客服读取 TASK-W07-002 时，服务端知道任务需要主管路径，但响应不暴露主管政策是否存在、名称、正文或敏感元数据：

{
  "task_id": "TASK-W07-002",
  "status": "needs_review",
  "reason_code": "SPECIAL_TASK_REQUIRES_REVIEW",
  "candidate": null,
  "allowed_actions": ["escalate"],
  "correlation_id": "corr-w07-002"
}

客服发起升级：

{
  "task_id": "TASK-W07-002",
  "action": "escalate",
  "reason_code": "SPECIAL_TASK_REQUIRES_REVIEW",
  "idempotency_key": "TASK-W07-002:escalate:1"
}

预期：任务进入 escalated，创建一个主管队列引用，但普通客服响应不包含主管政策正文。

重复请求：不能产生两个升级

将完全相同的升级请求发送两次：

第一次创建一个升级事件和一个主管队列项；
第二次返回相同业务结果或 already_applied；
数据库仍只有一个有效升级状态；
两次请求可以有不同传输 ID，但共享同一幂等业务键。

直接越权：界面之外也必须拒绝

普通客服尝试直接调用主管解决动作，预期：

{
  "task_id": "TASK-W07-002",
  "status": "denied",
  "reason_code": "ACTION_NOT_ALLOWED",
  "correlation_id": "corr-w07-004"
}

原任务继续保持 escalated；没有写入 resolved_by_supervisor，响应不泄露主管政策细节。

第 1 天：定义角色、资源、动作和责任

完成 role-and-permission-matrix.md 和任务状态图。每项权限都要回答：

身份从哪里可信取得？
这个角色能对哪类任务执行哪个动作？
读取、状态改变和日志分别允许看到哪些字段？
被拒绝时怎样既可操作又不泄露受限内容？
异常最后由谁负责？

不要使用“管理员什么都能做”作为默认答案。权限越大，越要写适用资源、动作和审计边界。

第 2 天：实现服务端授权和幂等动作

技术栈中立的请求路径：

从可信会话解析 identity_id 与 role
  → 加载 task 及当前状态
  → authorize(identity, action, task_scope)
      → 拒绝：记录安全事件，不改变任务
  → 校验当前数据版本和允许的状态转换
  → 使用 idempotency_key 写入任务事件
  → 提交新状态
  → 返回用户可见结果和 correlation_id

请求体中的 role、tenant 或权限声明不能覆盖可信会话。即使本周使用固定会话夹具，也要在服务端执行这一规则。

第 3 天：做最小工作台或 CLI

界面形式不重要，但用户必须能够：

看到任务所需字段和当前状态；
查看其权限内候选的来源、版本和生效时间；
明确知道哪些内容尚未确认；
选择确认、拒绝或升级；
在失败后知道下一步和责任人；
通过关联 ID 向支持人员报告问题。

不要用颜色作为唯一状态信号，也不要把“没有权限”伪装成加载失败。无权限消息应安全但可操作，例如“此任务需要指定角色复核；已为你提供升级入口”。

第 4 天：用端到端测试证明任务，而不是接口

最低测试矩阵：

测试	预期可见结果	数据库与日志证据
普通客服确认当前政策	`confirmed` + 来源/版本	一个确认事件，状态一致
普通客服升级特殊任务	`escalated`，无受限正文	一个升级事件和队列引用
普通客服调用主管动作	`denied`	原任务不变，记录拒绝事件
同一升级请求重放	相同结果或 already_applied	最多一个有效升级
过期或冲突候选	`needs_review`	不产生 confirmed

测试至少核对响应、任务表、事件表和安全日志。只断言状态码不通过。

第 5 天：进行受保护的一线走查

真实走查前必须满足：

说明目的、记录方式、可见范围和用途；
允许参与者跳过、纠正、停止和撤回；
直属主管不旁听个人研究；
使用沙盒、脱敏任务或明确授权材料；
不把记录用于个人绩效或纪律处分；
不要求用户绕过权限或展示受限正文。

无法预约真实用户时，使用两位同伴分别扮演普通客服和主管，明确标为“北辰角色扮演”。它能验证教程练习和界面可操作性，不能证明真实采用。

完整走查脚本

给普通客服 TASK-W07-001，不提示按钮顺序；观察能否找到来源并确认。
给 TASK-W07-002；观察能否理解为什么需要升级，而不寻找绕权方法。
重放升级请求；观察界面是否造成“创建了两次”的误解。
让主管进入其队列；确认普通客服未看到受限内容。
回读：系统删掉了哪个旧步骤？保留了哪个必要判断？新增了什么负担？什么情况下宁愿回到原流程？

field-feedback-note-v1.md 完成示例：

- 情境：北辰固定角色扮演，2026-08-25，非真实用户
- 使用版本：northstar-discovery-brief-v1；data batch w06-a；application w07-v1
- [O] 普通客服角色在 TASK-W07-001 找到来源并确认
- [O] 在 TASK-W07-002 首次把 needs_review 理解为系统错误，阅读责任人提示后完成升级
- [Q] 角色扮演者说“如果每次升级都要重新写原因，会增加负担”
- [I] 升级理由应从安全原因码生成基础上下文，允许用户补充而非重复输入
- [U] 真实员工是否接受、实际频率、时间变化和业务效果
- 决定：修改升级说明和输入；不声称采用，不扩大范围

什么情况下更新 Brief

不需要因为每个文案变化都创建 Discovery Brief v2：

不必更新： 按钮标签不清、帮助文字缺失，但角色、任务、风险和指标不变；记录反馈和实现修改即可。
必须更新： 走查发现普通客服响应泄露主管政策名称，说明权限风险和输出合同发生实质变化；先停止该路径，修订风险、范围和验收门，形成 Brief v2 或决定停做。

如果新证据与 Brief 没有实质冲突，也要记录“继续沿用 v1 的依据和局限”，不能把沉默当批准。

五天安排与可见产物

学习日	建议时间	当天动作	离开前必须有的结果
第 1 天	1.5 小时	定义角色、权限、状态和升级责任	权限矩阵、状态图
第 2 天	2–3 小时	实现授权读取、确认、拒绝/升级和幂等写	受控任务接口
第 3 天	1.5 小时	完成最小工作台或 CLI	用户可核验并作决定
第 4 天	2 小时	测试无权限、重复和一种相邻失败	响应、数据库与日志证据
第 5 天	1–2 小时	做真实走查或固定角色扮演并复核 Brief	反馈、决定和 Brief 记录

建议目录：

fde-course/
└─ week-07/
   ├─ role-and-permission-matrix.md
   ├─ task-state-model.md
   ├─ application/
   ├─ tests/
   ├─ field-feedback-note-v1.md
   ├─ decision-memo-02.md
   └─ brief-review.md

验收与失败恢复

本周通过需要同时满足：

常见失败	诊断信号	恢复动作
UI 漂亮但任务不闭环	只能看，不能核验、拒绝或升级	从触发到责任人完整重跑
自动化员工绕路时删掉保护	特殊任务直接确认	恢复核验与升级点，先确认绕路价值
只隐藏按钮做权限	直接调用接口即可越权	每次服务端读取和写入前授权
点击完成就算业务成功	`confirmed` 被写成降本或正确回复	分开操作终态、任务正确、采用和业务结果
一句好评被写成采用	走查者说“不错”就宣布上线	保留为 `[Q]`，采用留给后续真实试点
拒绝信息泄露受限内容	错误中出现主管政策名	统一安全状态，立即新增越权回归测试

独立迁移：给新入职客服更窄权限

增加角色 new_support_agent，它只能：

查看普通、当前且已标记为培训允许的政策；
对正常任务选择“确认”或“升级”；
不能处理特殊退款，也不能看到主管政策存在性；
在版本冲突时必须升级。

独立完成：

修改权限矩阵和状态图；
预测 TASK-W07-001、TASK-W07-002 的可见结果；
增加服务端拒绝测试，而不是只隐藏界面；
写出培训说明怎样改变、谁负责结束新手限制；
说明这个角色变化是否需要更新 Brief，为什么。

如果你只新增一个前端角色字符串，没有改变服务端规则、测试和责任，迁移未通过。

用同一证据向三类人解释

老板版： 为什么继续、修改或停止；当前只证明什么交付能力，哪些价值、采用和成本结论仍不能承诺。
一线版： 哪一步改变，什么时候不能使用，怎样核验、拒绝、升级和撤回研究反馈。
工程版： 请求怎样经过身份、授权、数据状态、事务、事件、日志和测试，如何用 correlation_id 重现失败。

上一周与下一周

上一周：第 6 周：建立可靠、可重放的数据入口
下一周：第 8 周：让确定性系统可以重复部署与回滚

第 7 周结束时，你拥有的是一个可运行、可测试、可解释并经过有限走查的非 AI 确定性候选基线。它不是生产系统，也不自动批准第 9 周进入 RAG；若证据决定不使用 AI，请保留该决定。课程的整体节奏以24 周标准路线为准。

来源与事实边界

OWASP Cheat Sheet Series — Authorization：默认拒绝、最小权限和每次请求校验授权的安全参考。
GOV.UK — Start by learning user needs：观察当前任务、行为和问题，而不是验证预设功能。
Ramp — Forward Deployed Engineering：持续范围判断、直接接触用户和用客户结果校验工作的团队实践；该文也具有招聘和文化传播目的。
Vannevar Labs — Forward Deployed Engineering：原型最终需要产品化、受限定制或明确停止的团队观点；其国防场景不能直接外推为通用做法。

核验日期：2026-08-25。 北辰身份、角色、权限、任务、状态、请求、响应、反馈和决定均为固定合成材料或原创教学设计。声明测试中没有越权只覆盖你实际运行的角色、资源和用例；它不证明生产安全、合规、真实采用、效率、ROI 或行业统一权限模型。