# 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](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
```

**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](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, 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](../workplans/CUST-WP-0082-netkingdom-security-hardening.md), including the
target of current KeyCape checks on every API/Git/SSH operation.