the-custodian/docs/netkingdom-development.md

Working development entrypoints

Verified 18 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	T44 must accept the complete agent Git/API flow
Forgejo authenticated API	Owner-routed check stopped at OpenBao 403 before Tea ran	Supported caller login, then the actual API check
Forgejo through NetKingdom	Candidate preparation and local interoperability proofs passed	T42 approval/reviews/activation, then T43 actual human sign-in

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

Current result: not passed. 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. No authenticated API result has been accepted.

warden plan 'oidc login forgejo admin' --json identifies the existing founder-required KeyCape OIDC/MFA login lane. That human login is still a prerequisite to resolve through the owner path. 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, pending actual founder disposition and independent owner reviews. It proposes using the existing KeyCape issuer and upstream Forgejo OIDC/PKCE support, with local account linking. It has not been activated. The human sign-in/account-continuity test follows activation.

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.