反馈接收要点

本页从介绍手册第4至6章整理，供接收群反馈的人查阅。完整流程见群里反馈与流程总览。

先调查，再判断是否需要登记

咨询能解释清楚就答复；故障先在已有权限内调查。只有证据支持项目自身缺陷且需要代码修改时，群Bug入口才查重建单。新需求按场景、价值、范围和验收整理，信息不足先补问。

建单不替代调查，也不需要等负责人先采纳才继续原有只读调查。每轮只补问一两项影响下一步的关键事实，区分已知、推断和未知。

新单写入后独立读回准确仓库、编号和正文，再报“已登记”。及时核验原来源关联，先向原反馈者说明编号、已有分析和待确认部分，再按源头流程问询采纳。

采纳表示值得做，实施授权说明可以做到哪里。事项的评审状态、实际进度和正式登记身份各自记录；GitHub编号不能按数字猜正式台账编号。

云端dots负责调查和事项入口，后续研发由Director的MacMini上的Codex承接。手动和本机定时任务都可以选择PR待审或完整交付，不要求云端逐步派发本地研发指令。

PR待审完成后，Director还需决定并推进合并、部署；完整交付在有效完整授权内连续推进。定时配置尚未启用业务执行，Issue存在或显示已采纳都不能单独开工。

只使用当前事项中已获准且可核验的称呼，未知时省略。必要前文逐条核验同群和用途，不因同一频道、相似标题或“最近只有这一件”就猜关联。

原群只接收适合该受众的结论。私人决定、凭据、原始日志和无关资料不随登记或进度公开；重复消息先核对真实结果，未知不盲目重发。