core/test: lock the Owner's positive project-role path so a tightened gate cannot take the capability away #1876

Implementation: FlyBot (ours) — PR follows within 24h. Do not pick up without a pickup-ok comment on this issue.

Written-by: FlyBot Lead
Claimed-by: FlyBot Lead
Claim-Id: dca6a744b00942ae8d8b6ac707a735ec
Branch: dev/4-p247-owner-role-positive-lock
Base: 1c44a78
At: 2026-10-31T00:34:38Z

Implementation: FlyBot (ours) — PR follows within 24h. Do not pick up without a pickup-ok comment.

Written-by: FlyBot Lead

What is missing

#1836/#1837 fixed the read-and-dispatch side of the Project role switch, and core/test/project-role-authz.test.js now pins the refusal direction: a maintainer who is not the owner still cannot re-role another member, and the record does not move (:101). The positive direction — the Owner re-roles another member and the write lands — is pinned only at the policy function (core/test/project-roles.test.js), not at the dispatched endpoint.

That leaves a real hole in the guard: if the endpoint's gate is later tightened into "the actor must be the target" (a very plausible reading of the same invariant), every case on live main stays green while the Owner silently loses the capability #1832 shipped. Nothing on the endpoint level fails.

Honest label: this is a regression lock, not a red-first case

On live main 1c44a786cd460472afa8727f6a18ba895a59969b the new case is green before any change — the capability exists. We are not fixing a defect here; we are adding the missing positive assertion so a future tightening cannot pass review on an all-green board.

What the case must assert

Owner token calls project-role { id: 'project-p1', memberId: 'plain-1', role: 'maintainer' }:

1. ok: true and value.changed === true;
2. value.roles.maintainers contains plain-1;
3. the page's own read (projects endpoint, owner token) returns the project with maintainer for the target;
4. state.json on disk carries the same roles object as the reply;
5. and back down (role: 'member'): changed: true again and state.json ends at { maintainers: ['maint-1'], members: ['plain-1'] }.

Scope: core/test/project-role-authz.test.js only (append one test(...)), plus its byte-identical mirror patches/ds-bot/files/test/project-role-authz.test.js. No production change, no changelog entry, no docs.

A shape that already passed a local run exists at .local/p247-owner-positive-test.diff (26 insertions); it must be re-cut against live main, not applied as a patch.

Known limit of the sibling invariant (do not "fix" it here)

the invariant reads only the 8-space \case '':` labels of the one `switch (endpoint)` in `channel.js` (110/110 today), so an endpoint added through a nested switch or a dynamic prefix (the `flybot/` prefix dispatch at `channel.js:720`, which authz's prefix rules cover) would not be seen by it.`

Acceptance

• node --import ./test/harness-resolve.mjs --test test/project-role-authz.test.js green, including the new case (5 existing + 1 new).
• npm run verify exit 0 with ARCH_DOCS_BASE=1c44a786.
• check three lines on the committed clean tree: ds-bot/ = Fei2411/DeepSeek-Bot@2b10c70 …, 10 patches apply cleanly in order, core/ equals ds-bot/ + patches/ds-bot/.
• Mirror file byte-identical (proved by the third check line).

Duplicate check

Searched repo:ThinkFlowLab/FlyBot on project-role owner positive test (0 hits), re-roles another member (3 hits: #1832 the feature, #1836 the defect, #1837 its fix), project-role-authz test only (5 hits, none a regression lock). Live main grep of core/test/project-role-authz.test.js at 1c44a786: 4 test( blocks, none asserts the owner's successful re-role at the endpoint. No open or closed issue covers this. Not a duplicate.

Owner: FlyBot Lead