2026-09-15 23:38:48 +02:00
# FLEX-WP-0020-T04 — consumer inventory and handoff requests
Status: requests sent. Owner work-record IDs are not invented here.
Handoff JSON cannot be schema-valid until each owner creates a live
workplan/task; those IDs fill `handoff_id` / `owning_work_record` .
Do not mark external work done from this repository.
Shared identity for every request:
- renamed_repository_id: `fda8ad85-a7d7-4055-8f21-902a533e59df`
- old_slug: `flex-auth`
- new_slug: `access-engine`
- Forge ID stays `42`
- runtime/product names stay `flex-auth` (FLEX-DEC-2026-013)
| Owner | Surface | Required change / verification | Owner work-record |
| --- | --- | --- | --- |
| `railiance-fabric` | fabric-projection | Update `registry/local-repos.yaml` , `registry/railiance-repos.yaml` , live `fabric/**` `repo: flex-auth` ; re-ingest; keep `flex-auth.*` runtime graph IDs | pending |
| `ops-warden` | credential-route | Review `registry/routing/catalog.yaml` owner repository field; routing must still resolve; no secret in the reply | pending |
Record the first returned rename handoff and re-ask the tenant-scope question.
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
2026-09-20 23:52:31 +02:00
| `reuse-surface` | other | Update federation source URL/path, re-ingest, verify capability continuity | `REUSE-WP-0023` / `65c03b24-4349-5a60-b7d6-79cf54931d06` |
2026-09-15 23:38:48 +02:00
| `policy-nexus` | other | Update `source-inventory.config.json` remote URL; re-ingest same publication lineage | pending |
| `user-engine` | documentation | Update `wiki/ArchitectureBlueprint.md` absolute source path; adapter/runtime vocabulary stays `flex-auth` | pending |
| `net-kingdom` | deployment | Verify three live `flex-auth-*` Deployments and `sso-mfa/k8s/**` ; no runtime rename | pending |
State tenant-engine's tenant relation in the write-api package, v3.
tenant-engine named the relation in TEN-DEC-2026-002: `tenant` is the target
tenant record and always equals `resource.id`; the write API is cross-tenant
by design and `tenant.guardrail.read` does not differ. v2 carried no tenant
rule and a constant fixture tenant, so the deliberate scope and an omitted
rule were indistinguishable.
tenant-engine.write-api.mutate v3 (FLEX-DEC-2026-016):
- allowed requires tenant_is_target; a mismatch or absent tenant is denied
tenant_not_target (object.get, so an absent key names the right cause).
- the cross-tenant scope is stated in the package and quantified by
test_tenant_never_changes_effect over every action, three subjects and
four tenants, with guards against passing by denying everything.
- fixtures rotate tenant across four tenants; five cross-tenant allows and
two tenant_not_target denies added (42 fixtures, 33 tests, all pass).
- user-engine's tenant:platform exclusion is named as a fixed-record rule,
not a subject/tenant relation, and tested separately.
Closes FLEX-WP-0022 (T01, T02 done). Also records TEN-IN-0004 and
SECRETS-IN-0002 on FLEX-WP-0020 and acknowledges the GH-DEC-2026-017
replies on FLEX-WP-0030-T04.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 63291@bnt-lap001
Assistant-Session: 8bd77868-ca68-4f49-bb1e-d539ecc0d703
2026-09-21 07:39:57 +02:00
| `tenant-engine` | consumer | Verify docs/client config keep the retained product/runtime contract | `TEN-IN-0004` / intake `01a0c14b-b2f7-78f1-8f6c-e36c952fe004` |
2026-09-15 23:38:48 +02:00
| `sbom-nexus` | sbom | Re-ingest new canonical checkout; snapshots remain related to the UUID above | pending |
| `repo-manager` | other | Reconcile new canonical path; do not rewrite archived UUID-migration evidence | pending |
| `railiance-platform` , `markitect-tool` , `gate-house` , `approval-engine` , `secrets-engine` , `zone-engine` | consumer | Confirm no live repository URL/path remains; retain product/runtime terminology | pending |
| `flex-auth` + Forgejo operator | ci / package | `.forgejo/workflows/image.yaml` , charts, deploy, releases, packages, hooks, Actions, deploy keys, branch protection, redirects, clone URLs. Only repository coordinates change. Image name stays `coulomb/flex-auth` . | this plan |
Request message IDs (not owner work-records):
| Owner | Message ID |
| --- | --- |
| tenant-engine (T01 question) | `e8ba6a53-0093-4dc0-ad70-01f6b8c8e76b` |
| tenant-engine (0020 verify) | `08b3edfa-c478-45c9-9b2f-4c0fcdf471e7` |
| railiance-fabric | `10d4b1a2-8976-42a5-8d76-6fc1ce54fe87` |
| ops-warden | `0a1956c5-9fd2-4e52-837e-5bfa8e47e83d` |
| reuse-surface | `08919217-1d82-4600-a2e8-e3d9949fabab` |
| policy-nexus | `d861dc4f-11b5-4c73-a98c-8d261e65d65e` |
| user-engine | `94fd6ef0-28b5-4481-a207-2adabab93893` |
| net-kingdom | `3bc95c76-abac-4f20-95ff-a74dcc1d6fd9` |
| sbom-nexus | `08540a29-ecd4-47bc-a87c-7eecf80f166a` |
| repo-manager | `0a4b1825-99b1-4e1e-a4a0-448b0347b744` |
| railiance-platform | `b55a40cb-eb03-4972-a9bc-aac6e131a63e` |
| markitect-tool | `0dd0d6af-12fd-4b3e-af4e-1f294d615039` |
| gate-house | `231460c6-0235-4c22-9f7d-cff3959496ed` |
| approval-engine | `2523510b-79d6-4123-b550-6386dae4d464` |
| secrets-engine | `15cf351a-bad8-4259-9b6f-b21d183a20ab` |
| zone-engine | `40adbd61-0155-44f8-b6a7-621ff1629c46` |
Record the first returned rename handoff and re-ask the tenant-scope question.
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
2026-09-20 23:52:31 +02:00
## Owner work-records returned
2026-09-20 — `reuse-surface` is the first owner to return a live work-record.
| Field | Value |
| --- | --- |
| Owning workplan | `REUSE-WP-0023` — `65c03b24-4349-5a60-b7d6-79cf54931d06` (`active` , file-backed at `workplans/REUSE-WP-0023-access-engine-source-rename.md` ) |
| Tasks | `REUSE-WP-0023-T01` `d97094d4-4cad-5b35-aa88-eb952215937a` (federation source coordinates); `REUSE-WP-0023-T02` `77b1eb56-bbf6-5454-892f-bf60e32b864a` (hosted hub registration) |
| Task status | both `wait` , deliberately |
| Reply message | `82bfe60f-1258-4d5d-9b81-9596b5fedd9e` |
Their sequencing constraint is recorded here because it is the plan's, not only
theirs: flipping a federation source URL before the forge rename lands breaks an
enabled, publish-passing source and drops its capability from the composed
federated index. So the source rewrite is **after** T06, not before it, and
`flex-auth` owes them a ping on that thread when
`access-engine` serves `/raw/main/registry/indexes/capabilities.yaml` .
Verified here rather than taken on report (2026-09-20):
- `GET .../coulomb/access-engine/raw/main/registry/indexes/capabilities.yaml` — `404`
- `GET .../coulomb/flex-auth/raw/main/registry/indexes/capabilities.yaml` — `303`
- `GET /workplans/65c03b24-...` — present, `active`
They also confirm the three identity invariants unchanged: Forge ID `42` , repo
UUID `fda8ad85-a7d7-4055-8f21-902a533e59df` , and runtime names staying
`flex-auth` per `FLEX-DEC-2026-013` . A repository rename does not redefine a
published capability identifier.
Still pending, and T05 stays blocked on them: `railiance-fabric` , `ops-warden` ,
`policy-nexus` , `user-engine` , `net-kingdom` , `tenant-engine` , `sbom-nexus` ,
`repo-manager` , and the named semantic-consumer verifiers.
State tenant-engine's tenant relation in the write-api package, v3.
tenant-engine named the relation in TEN-DEC-2026-002: `tenant` is the target
tenant record and always equals `resource.id`; the write API is cross-tenant
by design and `tenant.guardrail.read` does not differ. v2 carried no tenant
rule and a constant fixture tenant, so the deliberate scope and an omitted
rule were indistinguishable.
tenant-engine.write-api.mutate v3 (FLEX-DEC-2026-016):
- allowed requires tenant_is_target; a mismatch or absent tenant is denied
tenant_not_target (object.get, so an absent key names the right cause).
- the cross-tenant scope is stated in the package and quantified by
test_tenant_never_changes_effect over every action, three subjects and
four tenants, with guards against passing by denying everything.
- fixtures rotate tenant across four tenants; five cross-tenant allows and
two tenant_not_target denies added (42 fixtures, 33 tests, all pass).
- user-engine's tenant:platform exclusion is named as a fixed-record rule,
not a subject/tenant relation, and tested separately.
Closes FLEX-WP-0022 (T01, T02 done). Also records TEN-IN-0004 and
SECRETS-IN-0002 on FLEX-WP-0020 and acknowledges the GH-DEC-2026-017
replies on FLEX-WP-0030-T04.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 63291@bnt-lap001
Assistant-Session: 8bd77868-ca68-4f49-bb1e-d539ecc0d703
2026-09-21 07:39:57 +02:00
2026-09-21 — two more owner records returned, acknowledged, not closed from here.
| Owner | Record | Reply message | What stays open on their side |
| --- | --- | --- | --- |
| `tenant-engine` | `TEN-IN-0004` (`intakes/intakes.md` , commit `d132db0` ; hub intake `01a0c14b-b2f7-78f1-8f6c-e36c952fe004` ), `open` | `588df1c4-28d9-4887-807c-4950590a2359` | Runtime contract verified retained (cluster DNS `flex-auth-tenant-engine.flex-auth.svc` , audience `flex-auth` , NetworkPolicy, `railiance/app.toml` ). Five repository-path cross-references in `docs/flex-auth-integration.md` are repointed after T06 lands; `flex-auth` owes them a "rename landed" notice. |
| `secrets-engine` | `SECRETS-IN-0002` (`intakes/intakes.md` , commit `ba73dba` ), `open` | `8539206e-4443-4cec-8736-0efb6d45ef67` | One live repository path, `docs/approval-service-auth.md` line 56 (`--flex-auth-source /home/worsch/flex-auth` ), held until the rename lands; every other `flex-auth` string is retained runtime/contract vocabulary. `flex-auth` owes them a "rename landed" notice. |
Both record ids were confirmed present in the owners' committed intake files.
