the-custodian/docs/netkingdom-development.md

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 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:

kubectl -n playwright port-forward deployment/playwright 18081:8080 --address 127.0.0.1

Leave it running. In another terminal:

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 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 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:

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:

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:

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. 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:

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.

Forgejo NetKingdom sign-in and repository privacy

The prepared rollout is revision 2. The founder approved it and all three independent owner reviews approved the exact proposal; see the recorded approval. 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, including the target of current KeyCape checks on every API/Git/SSH operation.