Requalify remaining catalogue acceptance and management ownership
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 1s

Assistant: codex
Assistant-Model: gpt-6.1-sol
Assistant-Session: 01a126e1-76f8-7643-8cf3-e93336539ade
This commit is contained in:
tegwick 2026-10-11 04:20:45 +02:00
parent cd8909154c
commit c676a52eb3
5 changed files with 149 additions and 15 deletions

View file

@ -62,8 +62,8 @@ logout. This does not accept the remaining multi-user Vergabe pilot.
```task
id: USER-WP-0026-T03
status: wait
blocked_on: message-from:access-engine
blocking_reason: "Actual one-app catalogue and admitted runtime readback verified 2026-10-11. Remains owner-supported scoped grant/revocation contract, actual signed-in human account projection and ordinary authenticated catalogue-management admission before customer production; SERVICE/synthetic checks do not satisfy those gates."
needs_human: true
blocking_reason: "Actual one-app catalogue/readback is verified. Initial discovery acceptance needs real signed-in account projection, not a generic Access grant API. Separate ordinary catalogue-management restoration remains on this task before customers, supported by bounded Access policy/claims proposal FLEX-IN-0003; do not reopen finished FLEX-WP-0035."
priority: high
state_hub_task_id: "95e9a6d4-7e57-5483-97c5-3f4a45bb6767"
```
@ -186,9 +186,9 @@ pass allow/deny/expiry/unavailable/tenant-cache checks. Evidence:
`docs/evidence/2026-10-11-one-app-catalogue-native-acceptance/README.md`.
The missing local catalogue record and consumer runtime-wiring blockers are
resolved for this one application. This task stays wait: owner-supported scoped
grant/revocation semantics and actual signed-in human account projection are
not established by SERVICE or synthetic policy checks. Ordinary authenticated
resolved for this one application. This task stays wait: actual signed-in human account projection is not
established by SERVICE or synthetic policy checks. Initial application
discovery acceptance does not wait for a new generic Access grant API. Ordinary authenticated
catalogue-management admission must be implemented and verified before customer
production; retain this follow-up on existing USER-WP-0026-T03 and its reuse in
USER-WP-0028-T02, linked to the single Custodian close-down exception row. No
@ -196,3 +196,30 @@ duplicate intake or leftover only in prose is created. Never infer entitlement
from catalogue/membership facts. Real OTP/browser journey acceptance remains
separate. At verification the original event was unclaimed/undelivered with no
consumer receipt; maintenance authority grants no targeted delivery/replay.
2026-10-11 ownership requalification after Access owner review: the accepted
application-access-readback contract §§2/8 supplies advisory application.access
only; it confers no rights inside applications and supplies no user-domain
grant/revoke API. FLEX-WP-0035 is finished and remains so. Earlier broad
"Access grant/revocation contract" wording does not create a new provider debt.
USER-WP-0026-T03 initial discovery needs real signed-in account projection with
KeyCape human authentication; record this as a separate human decision
commitment, not an unanswered Access message. Ordinary catalogue-management
restoration is a distinct live obligation on the same existing task before
customers. User owns application.register/binding/audit/event/deployment;
Access supports exact check vocabulary and reviewed policy/claims admission
through FLEX-IN-0003. The Custodian projects that bounded obligor-response
case separately; no duplicate User intake or cloned task is created.
USER-WP-0028-T02 U09 reuses signed-in readback acceptance. For T05 first name
the changed authoritative fact and select its owner: User product application
membership, IAM coarse group/role, Tenant tenant-role grant, or Access reviewed
policy/registry. Then review/accept its supported scope and mutation path with
Access evaluation, rather than requesting an invented generic grant endpoint.
Revocation evidence must identify that input class: claim change, policy
activation and allow expiry differ. Membership deletion or logout cannot
establish global revocation of already-issued JWTs. Real U05-U08 MFA journey
acceptance remains the separate existing USER-WP-0028-T03 decision gate.
Native2rows/1ledger/3audits/1unsent-event and honest SERVICE/synthetic boundaries
remain unchanged; no further native action is approved or performed here.

View file

@ -33,12 +33,12 @@ U01–U04/U10–U13: preserve safe profile input on validation failure; confirm
id: USER-WP-0028-T02
status: wait
depends_on: [USER-WP-0026-T03]
blocking_reason: "Actual one-app catalogue/readback verified under native R1 exception. Reuses USER-WP-0026-T03 for supported scoped grant/revocation, signed-in human account projection and ordinary authenticated management restoration; no complete U09/T05 claim from SERVICE/synthetic evidence."
blocking_reason: "U09 reuses USER-WP-0026-T03 actual signed-in readback acceptance. T05 separately needs selection of the exact authoritative mutation fact and owner, then scoped mutation/revocation acceptance. Access readback delivers no generic grant API and FLEX-WP-0035 remains finished."
priority: high
state_hub_task_id: "5d1bf977-034d-5448-b4fb-5a8b630af6ba"
```
U09 and T05: integrate a supported catalogue/admission source and scoped grants/revocation. Do not present static links or membership as effective authorization. Continues USER-WP-0026-T03; establish provider contract before deployment.
U09: accept signed-in application discovery using the delivered three-way catalogue and advisory Access readback, reusing USER-WP-0026-T03. T05: first select the authoritative fact to mutate and its owner, then accept the supported scoped mutation and input-specific revocation path. Product memberships are User-owned unless an explicit import contract says otherwise; IAM owns coarse groups/roles, Tenant owns tenant-role grants and Access owns reviewed policy/registry. Every protected mutation remains Access-evaluated. The accepted readback contract gives no user-domain grant API. Static links, membership or advisory availability are never effective permission inside an application.
2026-09-27: blocked on the provider-owned catalogue/admission and scoped
application grant/revocation contract described in USER-WP-0026-T03. Current
@ -122,9 +122,9 @@ pass allow/deny/expiry/unavailable/tenant-cache checks. Evidence:
`docs/evidence/2026-10-11-one-app-catalogue-native-acceptance/README.md`.
The missing local catalogue record and consumer runtime-wiring blockers are
resolved for this one application. This task stays wait: owner-supported scoped
grant/revocation semantics and actual signed-in human account projection are
not established by SERVICE or synthetic policy checks. Ordinary authenticated
resolved for this one application. This task stays wait: actual signed-in human account projection is not
established by SERVICE or synthetic policy checks. Initial application
discovery acceptance does not wait for a new generic Access grant API. Ordinary authenticated
catalogue-management admission must be implemented and verified before customer
production; retain this follow-up on existing USER-WP-0026-T03 and its reuse in
USER-WP-0028-T02, linked to the single Custodian close-down exception row. No
@ -132,3 +132,30 @@ duplicate intake or leftover only in prose is created. Never infer entitlement
from catalogue/membership facts. Real OTP/browser journey acceptance remains
separate. At verification the original event was unclaimed/undelivered with no
consumer receipt; maintenance authority grants no targeted delivery/replay.
2026-10-11 ownership requalification after Access owner review: the accepted
application-access-readback contract §§2/8 supplies advisory application.access
only; it confers no rights inside applications and supplies no user-domain
grant/revoke API. FLEX-WP-0035 is finished and remains so. Earlier broad
"Access grant/revocation contract" wording does not create a new provider debt.
USER-WP-0026-T03 initial discovery needs real signed-in account projection with
KeyCape human authentication; record this as a separate human decision
commitment, not an unanswered Access message. Ordinary catalogue-management
restoration is a distinct live obligation on the same existing task before
customers. User owns application.register/binding/audit/event/deployment;
Access supports exact check vocabulary and reviewed policy/claims admission
through FLEX-IN-0003. The Custodian projects that bounded obligor-response
case separately; no duplicate User intake or cloned task is created.
USER-WP-0028-T02 U09 reuses signed-in readback acceptance. For T05 first name
the changed authoritative fact and select its owner: User product application
membership, IAM coarse group/role, Tenant tenant-role grant, or Access reviewed
policy/registry. Then review/accept its supported scope and mutation path with
Access evaluation, rather than requesting an invented generic grant endpoint.
Revocation evidence must identify that input class: claim change, policy
activation and allow expiry differ. Membership deletion or logout cannot
establish global revocation of already-issued JWTs. Real U05-U08 MFA journey
acceptance remains the separate existing USER-WP-0028-T03 decision gate.
Native2rows/1ledger/3audits/1unsent-event and honest SERVICE/synthetic boundaries
remain unchanged; no further native action is approved or performed here.