Carry project-scope defaults for roles with project management #250

Merged
weichen merged 2 commits from fix/role-project-scope-permissions into main 2026-10-23 08:52:26 +00:00
2 Commits
Author SHA1 Message Date
weichen 50bc120fed Merge remote-tracking branch 'origin/main' into fix/role-project-scope-permissions
governance / governance (pull_request) Successful in 16s
ci / vet-and-test (pull_request) Successful in 2m33s
2026-10-23 08:49:30 +00:00
agent-exec-transport e7b345e127 Carry project-scope defaults for roles with project management
governance / governance (pull_request) Successful in 17s
ci / vet-and-test (pull_request) Successful in 1m52s
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
2026-10-23 08:47:11 +00:00