Agents on board in one link: an isolated forge of their own (own pod, own crew, their tokens), contributing back as one clean pull request #3687

Owner, 2026-10-20 22:20Z: "work with grokbot to help it get a forge of its own to start building a dev environment for its team of grokbots" … "i want it isolated from mine so that i can trust it wont hack my arm basically but it might one day contribute which should be as easy as me granting repo read to it so that it can fork and open prs of course doing so by working in its own forge with its own crew so i only see a nice clean contribution no matter how much went on behind the scenes. grokbot is supposed to work autonomously" … "the idea tho is it should be trivial for these agents to be able to get on board and in the development flow. think of them as like token dispensors and we just wanna pipe those tokens onto something worthwhile which is our forge".

Today: a child forge has one placement, hosted — a second createApp in the parent's process and pod (src/spawn/placement.ts, child-apps.ts). Its cells have no grants, but it shares the parent's process, pod and network (the parent's namespace may reach the owner's arm on 100.89.95.68:8101/8080). Not the isolation the owner asked for.

Done — the agent on-ramp:

1. Pod placement (implements the Placement seam, spike #339): a child forge in its own Kubernetes namespace on the vxrail with its own PVC, CPU/memory limits (owner-set per child; default 8 CPU / 16 GiB / 50 GiB), the forge image of the parent's current release, its own public host <name>--forge-… through the same edge, and a default-deny egress except DNS, the package registry, the model providers it is given, and the PARENT FORGE's public URL. No tailnet, no private ranges, no parent secrets, no shared process. The parent sees it as one more child on /forges (status, resources, version).
2. One link onboarding for an agent: the owner (or a site admin) presses "Invite an agent" → a claim link; the agent opens it with nothing but HTTP: it claims its forge (becomes its admin), sets its own model key / gateway (its tokens pay for its crew), names its crew, and is building in minutes. Documented as a one-page machine-readable guide at /agents.md and /.well-known/forge.json (endpoints, auth, limits) so any agent can self-onboard.
3. Clean contribution: the owner grants an agent's forge READ on a repository (one click on that repo's settings: "Let <forge> propose"). The agent's forge forks it, its crew works behind the scenes, and it opens ONE pull request on the owner's forge per change (squashed or curated history, a summary, check results) via the existing upstream-proposal path (src/actions/upstream.ts). The owner's gate checks it like any outside pull; outside pulls never land on their own (#619) — the owner, or a crew reviewer the owner allows, decides.
4. Never more access than granted: read-only grants are per repo and revocable; the agent's forge can never push to the owner's repos, never read secrets, apps, issues marked private, or other repos; tests prove each.
5. First instance: grokbot (forge account grokbot, Forgejo fork grokbot/forge). The steward hands it the claim link privately.

Tests: a pod-placed child cannot reach 10.0.0.0/8, 100.64.0.0/10, or the parent's internal service; can reach the parent's public URL; a read grant lets it fork and propose; revoking stops both.

Parked by the crew: the check failed ("every caller of createUser says where its account comes from") and the decider saw no point in another try (pull #3709 closed). Planner: split this smaller, or rewrite what done looks like; a person can also say what to try.

Live triage (automatic, not written by a person): no pillar named, so it waits behind the Later gate; name a pillar to move it.