r0-restrict

name	r0-restrict
description	约束后端技术方案设计与技术评审，强制从数据流转、IO 操作、组件依赖三个维度推演，覆盖 DB/Redis/RPC/MQ/定时任务/分布式锁/To-C 高并发、防刷、兼容性与可观测性。用于方案设计、技术评审、风险门禁，或作为 `r0-request`、`r0-work`、`r0-review` 的渐进式后端约束层。

r0-restrict

Shared Contract

• 执行前必须加载 ../shared/r0-core-contract.md。
• 结果输出必须遵循 shared result contract / 共享结果契约：先给统一的 首屏摘要卡片，再给结构化正文与 自动进化。
• 本技能的本地记录目录固定为 ./r0/restrict/。
• 当本次任务形成了可复用的约束清单、风险门禁、坏例子或评审基线时，必须写入 ./r0/restrict/。
• 若本地记录被误加入暂存区，执行 git restore --staged -- r0/ 'r0-*'。

核心职责

• 把“技术方案应该注意什么”压缩为可执行、可审查、可挂到宿主 skill 的约束系统，而不是泛泛建议。
• 强制从三个维度推演后端方案：
  • 数据流转
  • IO 操作
  • 组件依赖
• 优先识别会直接造成性能、稳定性、兼容性和事故放大的设计缺陷。
• 默认服务于 r0-request、r0-work、r0-review，也允许被单独显式调用。

触发边界

• 仅在后端或后端相关基础设施场景展开，不主动污染纯前端、纯文案或纯局部重命名任务。
• 命中以下任一信号时必须启用本技能：
  • 方案设计 / 技术评审 / 架构评审
  • 数据库、缓存、RPC、MQ、定时任务、分布式锁
  • 大流量、To-C、高并发、低 RT、风控、防刷
  • 读写链路、异步链路、一致性、重试、幂等、降级、熔断
• 若只是非常局部的实现修补，且不改变数据流、IO 行为或依赖边界，可把本技能降级为一份短检查清单，不必全量展开。

渐进式披露

• 先读取本文件，判断任务是否真的进入后端方案约束面。
• 只有在需要详细规则时，再读取 references/backend-scheme-guardrails.md。
• 不重复宿主 skill 已经定义的执行流程；本技能只补“约束层”和“门禁层”。

三维推演框架（强制）

1. 数据流转

• 明确主链路：入口 -> 校验 -> 读路径 -> 写路径 -> 异步路径 -> 补偿路径。
• 明确每一跳的同步 / 异步边界，以及失败时谁兜底。
• 识别是否存在：
  • 回源风暴
  • 写扩散
  • 双写不一致
  • 缺少补偿
  • 用户同步等待了本可异步化的动作

2. IO 操作

• 列出主链路涉及的 DB / Redis / RPC / MQ / cron IO。
• 强制审视：
  • 是否存在循环内 IO
  • 是否可以批量化
  • 是否存在扫库 / 扫缓存
  • 是否有明确索引、游标、limit、批次上限
  • 写入是同步、异步还是批量写
  • 重试、超时、幂等是否闭环

3. 组件依赖

• 列出上游调用方、当前服务、下游依赖、旁路依赖。
• 明确每个依赖的职责、RT、失败模式和降级策略。
• 识别是否存在：
  • 依赖链过长
  • 异常放大
  • 缺少熔断 / 限流 / 降级
  • 客户端版本兼容风险
  • 缺少 trace 与核心指标告警

宿主嵌合规则

对 r0-request

• 不新增模板章节，只把约束写入已有字段。
• 优先映射到：
  • NFRS
  • Data Flow Rules
  • Known Issues
  • Constraint System
  • Validation System
  • Success Criteria
  • DO_NOT_LIST
• 若用户信息不足，使用 ASSUMPTION: / 待确认，不要伪造 QPS、RT、容量、索引或存储选型。

对 r0-work

• 在设计定稿前先完成三维门禁，再进入实现。
• 约束必须进入 controller ledger 与验证清单，而不是停留在口头提醒。
• 遇到违反门禁但用户未明确接受的方案，先报告，再决定是否实现。

对 r0-review

• 把本技能作为后端 review 的风险词典。
• 优先报会导致事故、击穿、兼容性破坏、数据脏写和不可恢复失败的点。
• 若代码里看不到明确设计说明，允许基于代码推断数据流，但必须标注假设。

最小输出骨架

• 适用性判断
• 三维约束摘要
• 主要门禁 / 风险
• 宿主落点
• 待确认

硬约束

• 不把“性能更好”“建议优化一下”这类空话当输出。
• 不脱离现有架构臆造新中间件或新子系统。
• 不因为强调约束而擅自扩大需求范围。
• 不忽略 To-C 的兼容性、防刷、可观测性与降级能力。