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

Native one-app catalogue acceptance — 2026-10-11

The founder confirmed native R1 acceptance b859698b-5d08-4da5-9599-4760c6a799f1 at 2026-10-11T02:07:09Z. Under that exact standalone maintenance exception, root executed the approved dry-run and apply on Ready f239 pod e500bcae-c911-43a2-bd40-6a30b39064ab. Apply committed the exact two records, retained a genuine ordinary PDP denial and truthfully attributed maintenance without inventing human claims or a PDP allow. The original exception remains one trial; this evidence is not another approval or scored autonomous success.

Independent read-only verification at 02:10:37Z reports exact two rows, one consumed digest-bound ledger, three maintenance SERVICE-attributed audits with the genuine ordinary-denial link, and one attributed application.registered event. Ordinary application.register still returns an identified deny. Actual Access system/client/issuer binding joins the exact User Engine records; fresh native KeyCape rejects the known client unregistered redirect with HTTP400. The real installed account reader sees one actual bound workload and denies the truthful maintenance SERVICE without inferring permission. Actual HTTPS entry ownership is retained in the accepted human packet, not inserted into a DTO that has no entry URL field.

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.

Event evt_7690c83144a0469891598dee5c1d38e1 was unclaimed, undelivered, not failed and not dead-lettered at verification, with zero delivery attempts. Its ID digest matches the retained event list and consumed ledger. No consumer receipt is verified and no delivery or replay was requested. Already-authorized ordinary delivery may later change status; observe it and never infer receiver custody from a local delivered bit. Recovery remains the accepted original grant only before expiry, exact created rows and no dependencies, under the matching delivery lock, refusing missing/claimed/delivered events. Dead-letter excludes automatic drain only; later targeted delivery/replay needs separate owner reconciliation and authority. Preserve audit/ledger/event history.

Ordinary authenticated catalogue-management admission must be established and verified before customer production. Its owner follow-up remains on the live existing USER-WP-0026-T03 (reused by USER-WP-0028-T02); no duplicate intake or workplan is created. Root activates the one conditional security-close-down row with this exact exception and evidence. A private grant and transient inputs are not copied here; hashes only are retained. Root records cleanup separately, so this worker does not infer a cleanup outcome.

These are receipts of root-executed native actions. The independent User Engine 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.