Requalify remaining catalogue acceptance and management ownership

Assistant: codex
Assistant-Model: gpt-6.1-sol
Assistant-Session: 01a126e1-76f8-7643-8cf3-e93336539ade

docs/evidence/2026-10-11-one-app-catalogue-native-acceptance/README.md

@@ -23,9 +23,11 @@ Native labelled policy fixtures independently pass allow/deny, stale MFA deny,
 30-second TTL, expired answer, unavailable transport and tenant cache checks.
 These fixtures are advisory policy inputs, not a real human session or MFA
 proof. The SERVICE account-reader projection likewise does not verify a
-signed-in human account page. USER-WP-0026-T03 and USER-WP-0028-T02 remain wait
-for their actual supported scoped grant/revocation and human account projection
-acceptance. USER-WP-0028-T03 real OTP journeys remain separately open.
+signed-in human account page. USER-WP-0026-T03 remains wait for real signed-in account projection, with a
+separate ordinary management restoration obligation before customers. U09 in
+USER-WP-0028-T02 reuses that readback acceptance; T05 separately needs exact
+authoritative mutation-fact/owner selection and scoped input-specific
+revocation acceptance. A generic Access grant API is not owed by readback. USER-WP-0028-T03 real OTP journeys remain separately open.
 
 Event evt_7690c83144a0469891598dee5c1d38e1 was unclaimed, undelivered, not failed
 and not dead-lettered at verification, with zero delivery attempts. Its ID
@@ -51,3 +53,30 @@ worker authored and statically checked the verifier and then reviewed root's
 returned receipts; it performed no native commands, credential reads or replay.
 Original16/21 PostgreSQL checks, failed initial5 assertions and transport guard
 proofs remain unchanged in the accepted human packet and owner review evidence.
+
+
+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.

docs/evidence/2026-10-11-one-app-catalogue-native-acceptance/acceptance-criteria.md

@@ -16,10 +16,37 @@ Event state is reported by counts only. Already claimed/delivered events prohibi
 
 ## USER-WP-0026-T03
 
-After successful created metadata proof, fresh KeyCape check and existing actual entry URL evidence, record the concrete one-app catalogue/admitted-readback integration milestone as achieved. Task text asks current access decisions for a signed-in identity, allow/deny/unavailable separation and registered HTTPS entry points; it also retains broader supported scoped grant/revocation acceptance. This SERVICE projection alone cannot close the task. Closure requires independently evidenced actual signed-in account-page projection and owner-supported scope/action/tenant contract, applicable grant/revocation acceptance or an explicit governed scope split into live residual records before finishing. Preserve absent-provider/stale/expiry/cache/fail-closed evidence and do not infer user access from app creation or memberships. If that evidence is not already present, keep T03 open with the remaining exact boundary, while removing the missing-catalogue blocker.
+After successful created metadata proof, fresh KeyCape check and existing actual entry URL evidence, record the concrete one-app catalogue/admitted-readback integration milestone as achieved. Task text asks current access decisions for a signed-in identity, allow/deny/unavailable separation and registered HTTPS entry points. This SERVICE projection alone cannot close initial discovery acceptance: independently evidence a real signed-in account-page projection using the accepted scope/action/tenant readback contract. Initial discovery does not wait for a new generic Access grant API. Track ordinary catalogue-management restoration separately on this existing task with bounded Access policy/claims proposal FLEX-IN-0003 before customer production, without reopening finished FLEX-WP-0035. Preserve absent-provider/stale/expiry/cache/fail-closed evidence and do not infer user access from app creation or memberships. If that evidence is not already present, keep T03 open with the remaining exact boundary, while removing the missing-catalogue blocker.
 
 ## USER-WP-0028-T02
 
-U09/T05 explicitly includes supported scoped grants/revocation, not solely a catalogue row or advisory policy evaluation. It cannot be marked done from this helper; actual owner-supported grant/revocation semantics and resulting authoritative access/readback/UI acceptance are still needed. A scope split requires explicit governance and live handoff records; no prose-only residual. Reuse T03 integration evidence and avoid duplicate implementation.
+U09 is advisory application discovery and reuses T03 signed-in readback acceptance. T05 is a different product mutation goal: first name the authoritative fact being changed and select its owner (User application membership, IAM coarse group/role, Tenant tenant-role grant, or Access policy/registry). Then accept that supported scoped mutation with Access evaluation and input-class-specific revocation visibility. A generic grant/revoke endpoint is new design, not owed by the accepted readback contract §8. Keep T05 open until that owner/scope selection and actual acceptance; do not expose unsupported self-entitlement administration. A scope split requires explicit governance and live handoff records; no prose-only residual. Reuse T03 evidence and avoid duplicate implementation.
 
 The real human MFA journey U05-U08 belongs to USER-WP-0028-T03 and related human tasks. It remains open regardless of catalogue success. Catalogue acceptance must not accidentally inherit this separate MFA gate, and must not falsely satisfy it. Root records exact applied/verified/refused/unknown outcome under the original R1 trial and active conditional close-down obligation; no second scored success or autopilot promotion.
+
+
+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.

docs/reviews/2026-10-11-catalogue-continuation-user-ownership.md

@@ -0,0 +1,24 @@
+# User Engine owner continuation wording review
+
+reviewer: user-engine-owner (agent user-engine, codex)
+decision: approved
+work_item: USER-WP-0026-T03 / USER-WP-0028-T02
+
+INTENT Engine/PIP responsibility and binding rules retain User's product
+membership facts and protected catalogue mutation, while Access alone
+evaluates policy. Agrees with Access owner review
+`access-engine/docs/reviews/2026-10-11-user-catalogue-continuation.md` and accepted
+readback contract §§2/8: advisory begin-use readback is not an inside-app grant
+and delivers no generic grant/revoke API. FLEX35 stays finished. Ordinary
+management restoration remains a bounded policy/claims response FLEX-IN-0003
+and existing User T03 obligation before customers. U09 is signed-in discovery;
+T05 first selects the exact authoritative fact and owner, then scoped mutation
+and input-class revocation acceptance. Real signed-in and MFA evidence stays
+a human decision commitment; SERVICE/synthetic results are never relabelled.
+
+Exact reviewed workplan/evidence revisions are the four staged SHA256 entries
+in this preparation's manifest, rooted in current User source cd89091. This
+review approves wording/source preparation only, changes no authority, records
+no new founder decision and performs no native command or replay. No extra
+User work record is created; both tasks remain wait. Custodian alone projects
+the schema-correct cross-owner obligor-response case after Access intake apply.