Repository navigation
docs(collaboration): record attribution and information flow as an unowned gap - #88
Merged
Merged
Conversation
…owned gap The umbrella inventory lists the parts a task needs. Who is responsible for a part nobody is working on, and where the reason a part exists is carried, were neither a part nor a gap: attribution exists per entry and per claim, the two responsibilities did not exist anywhere. Both are now recorded. A table row, "Attribution and information flow", whose state says the responsibility is unassigned and whose owner column points at gap 8; and gap 8, which names the concepts - context, not control, and the orphan reaper / restart responsibility already named in gap 1 - and states the three scopes the principle is asserted for (one agent handing to another, a human directing an agent, a human team), of which only the first has machinery this umbrella could attach it to. This records an absence, not a rule. Binding it needs a decision record as its owner, which is what naming that machinery in gap 8 would produce. The bilingual pair carries the same row, gap and cross-references. Verified through the routed blocking set for the documentation route - check, docs:check, format:check, glossary:check, lint, package:check, rtm:check and node-test:documentation all passed, and the RCP receipt decision is "verified".
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
变更描述
What（改了什么）：协作清单文档
docs/design/protocol-governed-collaboration.md新增一行部件「归属与信息流」和一个空缺 8，中文语对同步同样的行、空缺与交叉引用。Why（为什么改 / 解决什么问题）：这份清单本来就在列「一件任务不能缺的那几样」，也已经有两行在说「机制完整、责任没有归属」（拥有与时间、恢复与重放的自举部分）。但「没人管的某一块由谁负责」以及「一块活的理由放在哪里」这两件事，既不是一行部件、也不是一个空缺，因此既不会被读到，也不会被关掉——它只存在于被交办者的上下文里。这次把这份缺失写下来：谁写下了这一块、谁承担「去发现」、交办要不要带走为什么。按用户的说法，这是「Context, not Control」——让身处上下游的人具备发现遗漏的上下文，而不是靠上级检查；遗漏在变成大炸弹之前就被直说。
明确不做的事：这是记录一份缺失，不是新增一条规则。 文档自己写着「它是一份索引，不是第二份规格」，而
skills/doc-maintenance/SKILL.md的元规则要求规则变更必须在其归属记录里写明改了什么、替代什么、为什么。所以新增行的 State 写的是「责任没有归属」、Owner 写的是「尚无归属——见空缺 8」，而不是一条被悄悄接受的规范。要让它具备约束力，需要一份 decision record 作为归属方——空缺 8 里「把那个机制点名」指的就是这件事。Changes（关键改动点，按文件或模块列出）：
docs/design/protocol-governed-collaboration.mdAttribution and information flow，位置在Handoff之后：State = 条目与认领各有归因，但「发现无人认领的那块」与「把一块活的理由带下去」这两份责任没有归属；Owner =no owner yet - see gap 8。docs/design/protocol-governed-collaboration.zh-CN.md：同一行、同一空缺、同样的交叉引用。未验证项
Not verified（没验证什么）：
documentation，因此没跑test:product、mutation:teeth、evals/**。这正是--narrow的语义（「被单一非共享路由干净拥有」），不是跳过了本该跑的东西。npm run verify:static与路由集合不是同一件事：前者在专用 worktree 内完整跑过（exit 0，见完成检查项），但它测的是1f3c24d3这棵树；本 PR 之后若再改动，这份证据需要重跑。git worktree里连续跑同一条npm run agent:verify -- docs/design/protocol-governed-collaboration.md docs/design/protocol-governed-collaboration.zh-CN.md，第 1 次npm run check失败（收据无 diagnostics）、第 2 次npm run rtm:check退出 1（收据无 diagnostics）、第 3 次 8 项阻塞检查全绿、收据 decision 为verified。同一条npm run rtm:check单独运行退出 0，在共享工作树里也通过。本 PR 没有定位原因，也不把它记成「flaky」——按docs/postmortem/0004-flaky-was-a-clock-boundary.md，一个不能复现的失败要么带着复现尝试与发生率记录，要么留着，不能用标签关掉一个没人回答的问题。怀疑方向（未验证）：新 worktree 的生成物未就绪，以及rtm:check读上一次验证记录时的时序，但两者都只是怀疑，没有证据。完成检查项
本地质量检查
npm run verify:static通过（exit 0，detached 运行，snapshot1f3c24d3）：build/package:check/check/check:tests/mutation:anchors/check:lock/lint/format:check/docs:check/agent:context:check/complexity:gate/verify:packages/glossary:check/check:policy-words/rtm:check全部通过npm run test:product—— 不适用：按改动路由跑的是npm run agent:verify -- docs/design/protocol-governed-collaboration.md docs/design/protocol-governed-collaboration.zh-CN.md，路由为
documentation，其阻塞集合是check / docs:check / format:check / glossary:check / lint / package:check / rtm:check / node-test:documentation（8/8 通过）。纯文档改动不进test:product的路由。git show --stat只有 2 个.md）。dsh/dsh-nmg等）—— 不适用。npm run docs:check（通过）；改动遵循 doc-maintenance 规范：更新既有归属方而非新建摘要、一份规则一个家、双语语对同步、未在正文里叙写变更史。## 未验证项已填写（含一个未复现的检查差异与复现步骤）。Why与文档空缺 8 里。complexity:gate在verify:static内照跑）。git show --stat HEAD只有docs/design/*.md两个文件。RCP（Repository Control Plane）
repo-development黑板登记 in-flight goal：entry01a125d3-caab-7754-9a01-df265b280530（kind=goal，goal/approach/scope三项）。诚实标注：登记发生在第一次文件写入之后，不是在写入之前——这一点没有按 skill 要求的时序执行。npm run agent:verify -- <两个路径>→ 收据agent-verify-narrow-documentation，decisionverified，证据
.nmg/verification/latest.json（在专用 worktreeNodeMemoryGraph-attribution-gap内，tree 只含本 PR 的两个文件）。C:\Documents\GitHub\NodeMemoryGraph当时有他人未跟踪的docs/experiments/retrieval-quality/*.html、一份他人笔记与package-lock.json的改动——这些都没有进入本 PR，这也是本改动改用专用 worktree 提交的原因（共享工作树里第一次agent:verify的收据 decision 正是因此为failed，diagnostics 是one or more changed files fall outside declared scope，而 8 项检查本身全绿）。node bin/nmg-rcp.mjs forge-status --pr 88→Static and package contracts :: COMPLETED SUCCESS、Product tests and coverage :: COMPLETED SUCCESS、Research characterization (non-blocking) :: COMPLETED SUCCESS、Node 22 compatibility :: COMPLETED SUCCESS、All checks passed :: COMPLETED SUCCESS、CodeFactor :: COMPLETED SUCCESS，Windows chaos tests :: COMPLETED SKIPPED（见未验证项）。观察，不是合并决定。CI 完成确认
nmg-rcp forge-status --pr 88的All checks passed为COMPLETED SUCCESSCOMPLETED SUCCESS）Static and package contracts :: COMPLETED SUCCESS；含verify:static全部子检查 + Dependency audit，本 PR 未改依赖）