coulomb/flex-auth
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Record the first returned rename handoff and re-ask the tenant-scope question.
All checks were successful
CI Smoke / host-smoke (push) Successful in 2s
Details
CI Smoke / container-smoke (push) Successful in 5s
Details

Browse source 
FLEX-WP-0020-T04: reuse-surface is the first owner to return a live work-record
(REUSE-WP-0023, two tasks, both deliberately in wait). Recorded in the handoff
evidence and verified rather than taken on report — the hub record is active,
access-engine raw returns 404, flex-auth returns 303, so the rename has not
landed and their refusal to pre-rewrite the federation source URL is correct.

That refusal changed the plan rather than only their side: flipping an enabled,
publish-passing source before the rename drops a live capability from the
composed federated index, so the source rewrite is ordered after T06, and
flex-auth owes them a ping when access-engine serves the capabilities index.
Nine owners remain pending; T05 stays blocked.

FLEX-WP-0022-T01: re-asked tenant-engine what CheckRequest.tenant denotes on the
write API, stating that "none" is a complete answer. Their code copies tenant_id
onto both tenant and resource.id, but that is observation, not admission, and
encoding a rule from it would make flex-auth the author of their tenancy model.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 28468@bnt-lap001
Assistant-Session: c76569b2-6056-4dad-aea4-49cd7a018f5d
This commit is contained in:
tegwick 2026-09-20 23:52:31 +02:00
parent f85479c668
commit 3f60797c0a
3 changed files with 54 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

13
workplans/FLEX-WP-0020-repository-identity-migration.md
View file

@ -253,6 +253,19 @@ durable handoff ID; unknown ownership blocks the live rename.
Owner work-record IDs are requested, not invented. T06 stays blocked on those
IDs plus the human confirm string.
2026-09-20: first owner work-record returned. `reuse-surface` created
`REUSE-WP-0023` (`65c03b24-4349-5a60-b7d6-79cf54931d06`, `active`) with
`T01` `d97094d4-4cad-5b35-aa88-eb952215937a` and `T02`
`77b1eb56-bbf6-5454-892f-bf60e32b864a`, both deliberately in `wait`. Recorded
in the evidence file; not marked done from here. Verified independently: the
hub record exists and is active, `access-engine` raw returns `404` while
`flex-auth` returns `303`, so the rename has not landed and their refusal to
pre-rewrite the source URL is correct. It adds an ordering constraint this plan
now owns — the federation source rewrite follows T06 rather than preceding it,
and `flex-auth` owes them a ping on message thread
`82bfe60f-1258-4d5d-9b81-9596b5fedd9e` once `access-engine` serves
`/raw/main/registry/indexes/capabilities.yaml`. Nine owners remain pending.
Reviewed inventory baseline:
| Owner | Required source/verification surface |

6
workplans/FLEX-WP-0022-tenant-scope-coverage.md
View file

@ -80,6 +80,12 @@ Gate: the relation is named by `tenant-engine`, not inferred here. This is the
`FlexAuthWriteAuthorizer.authorize` copies `tenant_id` onto both
`CheckRequest.tenant` and `resource.id`. That is observation, not admission.
2026-09-20: re-asked after five days of silence, restating the three questions
and saying plainly that "none" is a complete answer. The gate is unchanged: a
policy rule inferred from reading their code would make `flex-auth` the author
of their tenancy model, which is the boundary `FLEX-WP-0021-T01` exists to hold.
T02 stays `wait` rather than being guessed forward.
## 2. Encode the relation, or record that there is none
```task