Why: After the role-authority cutover a role could only carry the single
project.create boolean, so every project-scope action resolved as undefined and
project conversations plus member collaboration were rejected. Owner product
intent: a role carries one project-management toggle, and holding it grants the
in-project defaults (read, write, members, traces, stage, archive, audit);
three-duty and knowledge publishing stay duty-gated.
Evidence: go test ./internal/store ./internal/app ./internal/server -count=1
passes; TestRoleCarriesProjectScopeDefaults covers the write, the snapshot
projection and the unchanged invariant that a role enabling project.create may
not deny a linked management action. The agent-exec transport diff is identical
to the owner-accepted revision deployed on imc-tx-ecs (binary 941f8eef).
Impact: ReplaceRolePermissions accepts project-scope actions while protected
system actions stay refused, RolePermissions projects project-scope rows plus
the project-management implied defaults into the role policy snapshot, and an
explicit capability-association gate runs before each write.
Refs: feature/role-project-scope-permissions
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Why
角色权威切换后角色只能带 project.create 一个布尔，项目内动作一律判为未定义，项目内会话与成员协作全被拒。owner 产品口径：角色只有一个「项目管理」开关，开启即带出项目内默认；三权与知识发布仍按职责分配。
Evidence
Impact
ReplaceRolePermissions 接受项目范围动作（系统范围仍整批拒绝）；RolePermissions 把项目范围行与项目管理蕴含默认投影进快照；每次写入前跑能力关联一致性门。
Refs
feature/role-project-scope-permissions