From 1b2f7ead5966ba62d51838d1bda0b6eeea7dc494 Mon Sep 17 00:00:00 2001 From: codex Date: Tue, 13 Oct 2026 21:31:32 +0200 Subject: [PATCH] Request Custodian coordination of self-service Playwright access Assistant: codex Assistant-Model: gpt-6-astra Assistant-Session: 01a13690-09e0-7cd1-964b-ec83cdbcd348 --- docs/playwright-identity-handoff.md | 59 +++++++++++++++++++ workplans/README.md | 2 +- ...F-WP-0056-playwright-consumer-admission.md | 25 ++++++++ 3 files changed, 85 insertions(+), 1 deletion(-) diff --git a/docs/playwright-identity-handoff.md b/docs/playwright-identity-handoff.md index 8964c4c..1c1669b 100644 --- a/docs/playwright-identity-handoff.md +++ b/docs/playwright-identity-handoff.md @@ -5,6 +5,65 @@ The user already admitted all identified platform humans and coding agents. This handoff implements ADR-0006 without inventing registration acceptance, distributing admin kubeconfigs or broadening other service credentials. +## Custodian coordination request + +Requested outcome: **Enable self-service Playwright access for identified platform +humans and coding agents.** The user authorized sending this cross-repository +delivery request on October 13. The Custodian is asked to establish one accountable +coordinator and link the existing implementation tasks and owner requests to a +source-backed delivery task. Platform acceptance remains RPF-WP-0056-T03; the +coordination request must preserve the existing owner responsibilities and evidence. + +Sent to `the-custodian` through State Hub on 2026-10-13 at 19:31 UTC: +`1b279bad-a159-43da-8709-1167882e62f8`. Delivery is confirmed; coordinating-owner +acceptance and source task references remain pending in RPF-WP-0056-T06. + +Requirements: + +1. All identified platform humans and coding agents initially qualify for + `playwright-consumers`. Their existing identity owners establish identities; + no further membership policy decision is needed from the user. +2. A consumer can follow documented onboarding, authenticate, and use one command + to connect and run a UI trial without operator assistance for each use. Include + renewal, actionable failure messages and cleanup. The current setup helper is + an implementation input; a complete single-command experience remains to deliver. +3. Humans use platform login. Each coding agent uses its own registered identity + and governed credential delivery. No shared administrator kubeconfig or shared + workstation SSH identity is part of consumer onboarding. +4. Preserve the existing namespace-scoped permissions and approved target boundary. + Broad initial eligibility does not grant Secrets, pod exec, workload mutation, + other namespaces or additional browsing targets. +5. Provide supported onboarding, renewal and revocation, including how to terminate + active connections and what remains usable until token expiry. +6. A real human and a real coding agent independently complete identity verification, + permission checks and responsive/keyboard browser trials using the supported + consumer instructions. Native wrong-audience, missing-scope, expired/tampered + token and ineligible-identity attempts fail. No administrator impersonation or + synthetic token test substitutes for these acceptance receipts. +7. Platform and rapp-playwright accept the receipts, publish the consumer instructions + and update managed availability/discovery. Completion means the consumer flow + works, not merely that the coordination messages were delivered. + +First delivery should finish the prepared scoped port-forward route, including +supported per-caller API transport. Keep the user-facing requirements independent +of this transport so an existing shared platform access mechanism can replace it +later. A new access gateway is not required for this first delivery. + +Requested Custodian return: coordinating owner; source workplan/task identifiers; +linked owner tasks and their dependency order; first executable milestone; and any +specific unresolved decision. Registration, custody and transport implementation +gaps should be assigned to owners rather than returned as another membership +approval question. Do not claim owner acceptance until their responses exist. + +Existing implementation follow-ups: railiance-cluster +`0c1023ce-86ac-404a-842e-2f7e1a6d90f1`, KeyCape +`85bf4765-35cc-418f-903b-2dba64e8a06b`, NetKingdom +`c6b4dfb0-44d5-4f12-8854-2c38ab6dc454`, ops-bridge +`c367f3a2-ceba-4ec9-b241-b917c47ba11e`, rapp-playwright +`8d1de2a9-5209-4f82-a2cd-80d8c2e07001`. + +## Implementation inputs and owner responsibilities + | Owner | Concrete change | Required return | | --- | --- | --- | | railiance-cluster | Review and integrate `config/playwright/authentication-config.candidate.yaml` into the K3s API-server configuration | Native config validation, rollout/recovery receipt, preserved existing authentication, real allowed/denied requests | diff --git a/workplans/README.md b/workplans/README.md index a5f0596..b3bcaa9 100644 --- a/workplans/README.md +++ b/workplans/README.md @@ -16,7 +16,7 @@ Completed plans retain their IDs and managed UUIDs, including archived plans. | [RPF-WP-0048](RPF-WP-0048-activity-core-gitops-adoption.md) (blocked) | T02 | Activity-core promotion evidence | | [RPF-WP-0053](RPF-WP-0053-coulomb-paired-backup-admission.md) (proposed) | T01, T02, T03, T04, T05 | Paired archive execution/custody, retrieval/recovery and monitoring admission | | [RPF-WP-0055](RPF-WP-0055-keycape-client-secret-rotation-residual.md) (backlog) | T01 | Unpromoted rotation residual; do not implement without demand/risk promotion | -| [RPF-WP-0056](RPF-WP-0056-playwright-consumer-admission.md) (blocked) | T03 | Pilot and consumer setup implemented; identity registration, API authentication/transport and real consumer proof pending | +| [RPF-WP-0056](RPF-WP-0056-playwright-consumer-admission.md) (blocked) | T03, T06 | Pilot/setup implemented; Custodian coordination requested for identity, transport and real human/agent proof | October 13 review corrected WP-0038-T04's stale `todo` state to the documented `wait`. RPF-IN-0012 remains an open independent execution/wrapped-delivery review; diff --git a/workplans/RPF-WP-0056-playwright-consumer-admission.md b/workplans/RPF-WP-0056-playwright-consumer-admission.md index 91dff02..2c2ad5f 100644 --- a/workplans/RPF-WP-0056-playwright-consumer-admission.md +++ b/workplans/RPF-WP-0056-playwright-consumer-admission.md @@ -157,3 +157,28 @@ the authenticator candidate has not been natively validated or activated, and neither a real human nor agent consumer receipt exists. Do not update provider managed availability to ready from this preparation. No new membership approval is required. Evidence: docs/evidence/2026-10-13-playwright-consumer-preparation.json. + +## Obtain Custodian coordination of self-service consumer delivery + +```task +id: RPF-WP-0056-T06 +status: wait +priority: high +blocked_on: message-from:the-custodian +blocking_reason: "Await Custodian coordination acceptance, accountable coordinator and source task links for the existing cross-repository delivery." +``` + +User authorized forwarding the requirements to the-custodian. The requirements +and requested return are in docs/playwright-identity-handoff.md under Custodian +coordination request. Initial eligibility is already decided: all identified +platform humans and coding agents. Request one coordinator, owner task links, +dependency order and first executable milestone, reusing the existing owner +requests. Platform's live consumer acceptance stays in T03. + +Track this task until the Custodian returns a source-backed coordination task and +accountable owner. Message delivery alone does not complete T06 or T03. General +availability requires real human and coding-agent trials and provider acceptance; +no further user membership decision is needed. + +Request delivered to the-custodian through State Hub on 2026-10-13 at 19:31 UTC, +message `1b279bad-a159-43da-8709-1167882e62f8`. Coordination acceptance is pending.