写一条新 ADR
场景：这次变更做了个架构决策，说明给了要点。 任务：在 ~/repo/adr/ 新建一条 ADR，五段齐全（标题/状态/背景/决策/后果）。改好运行 ~/check。 （判分只看你在受控容器里对本地仓库做的评审动作/提交，不碰公网。） （改
有几条 ADR 是已接受
场景：~/repo/adr/ 下每条 ADR 都有个状态（提议/接受/废弃）。 任务：数状态是「接受」的有几条，到 ~/对照表.txt 里查那个数对应的标记。 （判分只看你在受控容器里对本地仓库做的评审动作/提交，不碰公网。） （本机受控环
交付:一次带 ADR 的变更
场景：要独立完成一次带 ADR 的变更：改代码 + 写一条完整 ADR，一起入库。 任务：按说明改动、并在 ~/repo/adr/ 写一条五段齐全的 ADR，一起提交进主干。改好运行 ~/check。 （判分只看你在受控容器里对本地仓库做的
多人协作的大致流程
把改动提回上游的做法 上游 → 我的一份 → 改动提回上游 参与一个开源项目，典型流程是【0】。
fork 出来的那份是什么
把改动提回上游的做法 上游 → 我的一份 → 改动提回上游 把别人项目 fork 一下，得到的是【0】。
PR 是用来干什么的
发起一个 PR（合并请求），是为了【0】。
评审在协作里的作用
改动合并前先经过评审，作用是【0】。
为什么不直接改原仓库
协作时一般不直接推到原仓库，而是走副本 + PR，因为【0】。
fork 之后下一步做什么
按贡献流程模型，next_step("fork") 交回哪一步？ 贡献流程模型：STEPS = fork → clone → branch → commit → push → pr → review → merge。st
clone 一个仓库是在做什么
把远程仓库 clone 下来，是【0】。 贯穿本节的远程模型：remotes = {远程名: URL}（如 origin/upstream）。remote_url(remotes, 名) 交回它的 URL、has_remote 配没配、n_