TL;DR
agent_teams_update_task 的 changedPaths 校验器会拒绝明明在 inScope 里的路径，同时要求登记 inScope 之外的路径，并且对自动生成的 In scope 列表不去重。结果是 changedPaths 与实际改动几乎总是对不上，每个下游 verification/review 成员都被迫改用 git status + mtime 自行核对——而它们并不知道该这么做。
Environment
| Item |
Value |
| Plugin |
@nanmicoder/dsh-agent-teams@0.1.18 |
| DSH host |
@deepseek-ai/dsh@0.1.5-rc.2, web profile, Linux |
| Team |
4 members, 6 quality-gated tasks, 4 repair rounds, 5 review rounds |
| Task kinds |
mixed implementation / verification / review / repair |
Three observed cases (all on real task submissions)
1 · A path listed in In scope is rejected as out_of_scope. A repair task's In scope explicitly contained deploy/compose/postfix/master.cf.inc, and one of its acceptance criteria required editing exactly that file. Declaring it returned out_of_scope. The same submission also had to declare 9 further files that the auto-generated acceptance criteria required editing — each was rejected as undeclared. After trying every combination, the member could register only 2 paths while having actually changed 13 files.
2 · A file the fix must touch is not in In scope, so it cannot be declared at all. A later repair had acceptance criteria requiring a SQL fix inside internal/model/mail_quarantine_deliver_model.go, but that path was absent from its In scope. The member could register 2 paths; the real change set was 7 files.
3 · A newly created file can never be registered. A repair created internal/model/mail_quarantine_deliver_model_test.go (the first test file in that package). Because In scope listed only the existing file, the new one was rejected as undeclared; 7 of 8 changed files could be registered.
Additionally: one auto-generated In scope list contained the same path three times, and also listed test/e2e/zz_t12_window_tmp_test.go — a scratch file the previous repair had already deleted, while the acceptance criteria still instructed the member to "delete it or merge it".
Impact
changedPaths is not merely incomplete, it is misleading in both directions, and the failure is silent: the member has to discover empirically which of its real changes the validator will accept. Downstream, the only workaround is to ignore the field and diff the workspace manually. A verifier that trusted changedPaths would audit the wrong file set, and a reviewer checking "was anything changed out of scope?" gets no signal at all.
Suggested direction
- Match
In scope entries as path prefixes, not as an exact allow-list.
- Allow registering paths outside
In scope — with a stated reason — instead of refusing them; an unexpected path is a finding for the reviewer, not a submission error.
- Deduplicate the generated
In scope list, and drop entries whose files no longer exist.
- Make the rejection explain itself (which rule matched, which path), so a member can tell a real scope violation from a validator artifact.
TL;DR
agent_teams_update_task的changedPaths校验器会拒绝明明在inScope里的路径，同时要求登记inScope之外的路径，并且对自动生成的In scope列表不去重。结果是changedPaths与实际改动几乎总是对不上，每个下游verification/review成员都被迫改用git status+ mtime 自行核对——而它们并不知道该这么做。Environment
@nanmicoder/dsh-agent-teams@0.1.18@deepseek-ai/dsh@0.1.5-rc.2, web profile, Linuximplementation/verification/review/repairThree observed cases (all on real task submissions)
1 · A path listed in
In scopeis rejected asout_of_scope. Arepairtask'sIn scopeexplicitly containeddeploy/compose/postfix/master.cf.inc, and one of its acceptance criteria required editing exactly that file. Declaring it returnedout_of_scope. The same submission also had to declare 9 further files that the auto-generated acceptance criteria required editing — each was rejected asundeclared. After trying every combination, the member could register only 2 paths while having actually changed 13 files.2 · A file the fix must touch is not in
In scope, so it cannot be declared at all. A laterrepairhad acceptance criteria requiring a SQL fix insideinternal/model/mail_quarantine_deliver_model.go, but that path was absent from itsIn scope. The member could register 2 paths; the real change set was 7 files.3 · A newly created file can never be registered. A
repaircreatedinternal/model/mail_quarantine_deliver_model_test.go(the first test file in that package). BecauseIn scopelisted only the existing file, the new one was rejected asundeclared; 7 of 8 changed files could be registered.Additionally: one auto-generated
In scopelist contained the same path three times, and also listedtest/e2e/zz_t12_window_tmp_test.go— a scratch file the previous repair had already deleted, while the acceptance criteria still instructed the member to "delete it or merge it".Impact
changedPathsis not merely incomplete, it is misleading in both directions, and the failure is silent: the member has to discover empirically which of its real changes the validator will accept. Downstream, the only workaround is to ignore the field and diff the workspace manually. A verifier that trustedchangedPathswould audit the wrong file set, and a reviewer checking "was anything changed out of scope?" gets no signal at all.Suggested direction
In scopeentries as path prefixes, not as an exact allow-list.In scope— with a stated reason — instead of refusing them; an unexpected path is a finding for the reviewer, not a submission error.In scopelist, and drop entries whose files no longer exist.