# Working development entrypoints Verified 19 October 2026 for CUST-WP-0080. Use the existing owner implementations below; the table distinguishes working paths from remaining acceptance. | Flow | Verified result | Still required | | --- | --- | --- | | Playwright, human and coding agent | Both real fixture trials passed, with keyboard interaction and desktop/mobile screenshots | Independent per-caller identity is deferred to WP-82 | | Forgejo Git | Existing workstation SSH read and ordinary source publication work | Supervised workstation profile; independent agent identity remains WP-82 | | Forgejo authenticated API | Founder-reported authenticated identity/repository reads passed; Tea configuration removed; outer Warden code 0 | Independent per-operation identity remains WP-82 | | Forgejo through NetKingdom | Native activation and HTTPS/PKCE redirect passed; local login preserved | Human existing-account linking/sign-in passed; full per-operation hardening remains WP-82 | ## Playwright Use the provider-owned [consumer contract](https://forgejo.coulomb.social/coulomb/rapp-playwright/src/commit/8831a05aeba5ce588f3b395ade676dde2a151c5d/docs/consumer-contract.md) and standalone Python client. No local Playwright or browser installation is needed. The verified client is `client/rapp_playwright.py` at commit `8831a05aeba5ce588f3b395ade676dde2a151c5d`, SHA-256 `9967a0831ed04e27fde419098af707722d5c81c993e4c294b3677ffb75729c12`. With the existing supervised workstation Kubernetes connection to railiance01, start the documented loopback connection if one is not already running: ```sh kubectl -n playwright port-forward deployment/playwright 18081:8080 --address 127.0.0.1 ``` Leave it running. In another terminal: ```sh python3 /home/worsch/rapp-playwright/client/rapp_playwright.py preflight python3 /home/worsch/rapp-playwright/client/rapp_playwright.py trial --out /tmp/wp80-playwright-new-trial ``` Choose a **new output directory** on every trial. Preflight should report `available: true` and execution location `railiance01/playwright`; the trial should report `status: passed`, four downloaded PNGs and their SHA-256 hashes. The private `run.json` is a capability handle and must stay out of Git and chat. The [actual human and agent receipts](changes/netkingdom-target-2026-10-18/wp80-build-mode-r1/README.md) prove this supervised profile. The provider contract governs supported scenarios and target origins; the remote browser's localhost is the provider's localhost. Discovery uses the existing `capability.infotech.headless-browser` record in reuse-surface. Its [published owner card](https://forgejo.coulomb.social/coulomb/reuse-surface/src/commit/ed3c900efbe96b931747dee336bf30e92744764f/registry/capabilities/capability.infotech.headless-browser.md) now points to this working managed entrypoint. The local query and hosted federation both returned it. Availability remains A5: the supervised pilot does not establish independent managed admission for every caller. ## Forgejo Git and API Use the existing repository remote and normal source publication process: ```sh git -C /home/worsch/the-custodian ls-remote origin refs/heads/main ``` The measured read succeeded in 0.629 seconds at revision `17635cb0a76e5595ec06421ab7419ae889f6d731`. That revision's ordinary commit, scanner, publication and primary projection receipts provide the existing write sample. Use the repository's normal commit and `statehub fix-consistency` path. Discover the API credential owner first: ```sh warden route find 'Forgejo API access with existing tea coding-agent client' --json warden plan 'forgejo admin api token' --json ``` The reviewed probe uses installed Tea 0.9.2 and a disposable isolated configuration. It reads the authenticated identity and `coulomb/the-custodian`, prints metadata only and removes its temporary configuration. Run through the existing owner transport after its caller prerequisites are satisfied: ```sh warden access forgejo-admin-api-token --exec --field API_TOKEN -- python3 /home/worsch/the-custodian/docs/changes/netkingdom-target-2026-10-18/wp80-development-entrypoints-r1/check_forgejo_cli.py ``` **Initial attempt: failed.** The owner transport returned OpenBao 403 before the probe received a credential or invoked the API. The installed Tea default points at a retired Gitea host; that credential was not used against the current forge. The subsequent founder-run check passed identity and repository reads as `tegwick`; see the [reported result](changes/netkingdom-target-2026-10-18/wp80-development-entrypoints-r1/founder-api-check-2026-10-19.json). The founder reported outer Warden code 0; the current implementation returns 0 only after confirmed revocation and cleanup. `warden plan 'oidc login forgejo admin' --json` identifies the existing founder-required KeyCape OIDC/MFA login lane. Its existing role for reading this credential is `forgejo-admin-workload-kv-read`, documented by the credential owner. The founder can run the following in their own interactive terminal: ```sh wp80_api_receipt_dir=$(mktemp -d /tmp/wp80-forgejo-api.XXXXXX) BAO_ADDR=http://127.0.0.1:18200 VAULT_ADDR=http://127.0.0.1:18200 warden access key-cape-oidc-login --domain forgejo-admin-workload-kv-read --exec -- sh -c 'umask 077; exec warden access forgejo-admin-api-token --exec --field API_TOKEN -- python3 /home/worsch/the-custodian/docs/changes/netkingdom-target-2026-10-18/wp80-development-entrypoints-r1/check_forgejo_cli.py > "$1" 2>/dev/null' sh "$wp80_api_receipt_dir/report.json" wp80_api_login_status=$? printf 'Warden outcome code: %s\n' "$wp80_api_login_status" python3 -m json.tool "$wp80_api_receipt_dir/report.json" ``` This reuses Warden's contained login and existing credential route. The inner command emits only the reviewed probe's metadata JSON into a private receipt; both child streams stay silent to the outer login envelope. Warden revokes the temporary OpenBao session and removes its helper, while the probe removes its isolated Tea configuration. No API credential or login token is printed or retained in that receipt. **Founder-run API check passed:** the report confirms API reads and Tea configuration cleanup. Do not repeat the successful check merely to recover its outer outcome. Retain the outer Warden outcome as well as the receipt. A missing/empty report means the API check has not produced evidence. A report with `passed: true` must include successful identity and repository reads; a revocation/cleanup failure remains a separate unresolved outcome even if those reads succeeded. Do not rerun a failed command unchanged or broaden the role to obtain a pass. This read check does not activate the separate Forgejo sign-in rollout. The recorded route plans and closed failure markers are in the [entrypoint evidence](changes/netkingdom-target-2026-10-18/wp80-development-entrypoints-r1/README.md). ## Forgejo NetKingdom sign-in and repository privacy The [prepared rollout](changes/netkingdom-target-2026-10-18/forgejo-good-case-preparation-r1/README.md) is revision 2. The founder approved it and all three independent owner reviews approved the exact proposal; see the [recorded approval](changes/netkingdom-target-2026-10-18/forgejo-good-case-preparation-r1/activation-r2/README.md). It proposes using the existing KeyCape issuer and upstream Forgejo OIDC/PKCE support, with local account linking. It was activated in the attended window on 19 October. Both services are Ready and the live login option/HTTPS/PKCE redirect passed. The founder subsequently completed the human sign-in/account-continuity test successfully. For the actual existing-account trial: 1. Sign in locally at https://forgejo.coulomb.social/user/login. 2. Open https://forgejo.coulomb.social/user/settings/security and choose **Link account → netkingdom**; complete KeyCape sign-in/MFA. 3. Sign out, choose **netkingdom** on the login page, and verify the same username, repositories, organisations and expected rights. Do not create a second account. The founder completed these steps and confirmed existing-account continuity on 19 October, reporting under one minute total. Making repositories private is owned by ORGREF-WP-0002 in `prj-forgejo-org-refactor`. WP-80 establishes working development access first. The closure workplan separately proves service readers, rehearses visibility changes and obtains approval for production waves. The proposed login rollout changes no repository visibility. ## Implementation ownership | Need | Existing implementation to reuse | | --- | --- | | Browser execution and job protocol | rapp-playwright service and standalone Python client | | Capability discovery | reuse-surface capability card and existing federation | | Git and API | Existing Git/SSH path, Tea CLI and warden-routed Platform custody | | Identity and client registration | KeyCape issuer and NetKingdom's maintained registration helper | | Forgejo configuration | Apps Helm declarations and upstream Forgejo auth-source command | | Source-to-Hub publication | Existing file-scoped publication, fix-consistency and repo-manager projection | | Repository visibility | ORGREF-WP-0002 and its consumer-readiness/closure evidence | Custodian records acceptance and integration evidence. Missing producer features belong in the existing owner's work record. Security acceptance remains in [WP-82](../workplans/CUST-WP-0082-netkingdom-security-hardening.md), including the target of current KeyCape checks on every API/Git/SSH operation.