Org credentials: delete the box credential wire, one org plane behind an allowlist, agent-proposed grants with human approval

[pythonlearner1025]

What this does

Implements plans/ORG-CREDENTIALS.md (design locked 2026-09-02) end to end, in nine commits, one per wave:

1. plans — the design and the interactive approval-dialog mock (plans/mockups/grant-approval.html).
2. box — the blitz-cred credential verbs (list|get|env|import|put|git-helper), their Go wire decoders, and the three fixture corpora are deleted (~3,900 lines). One schema-free primitive remains: blitz-cred api-token prints a machine bearer the CP currently accepts (validate-by-use, one flock-serialized refresh on 401). The git credential helper is a POSIX-sh script over the agent API + jq; jq joins the pinned image packages.
3. control-plane — migration 0047 creates org_credentials + org_credential_grants and drops workspace_credentials (a stated, unmigrated deletion). core/org-credentials.ts holds the store and the one access function: org admins read and write everything; any member creates and receives write; write ⊇ read; grants cover the org, a workspace, or a membership; reads need a resolved active membership. core/agent-routes.ts is the box-authed /agent/* plane (list, two-tier token resolution — personal connection grant, then org credential — put, dotenv) with no closed-set wire for a box to bake in. Session routes under /orgs/:id/credentials*. WorkspaceView/CreateWorkspaceRequest lose their credential fields.
4. agent rules — the CP-served rules doc teaches curl + api-token against /agent/*, GET /agent/api as the always-current endpoint list, the org store, and the grant-proposal loop; the last blitz-cred verb mentions retire.
5. grant proposals — core/grant-proposals.ts: an in-memory store (no row, ~1 h TTL) behind four routes. The machine proposes an explicit change list with a reason and polls; the session feed lists what targets the acting member; resolve applies the edited set under the same write-authority check as any grant write. Changes are validated at propose time and revalidated at apply time, so an approval never half-applies.
6. webapp — Settings → Credentials panel, the workspace Credentials tab as a filtered view, and the grant-approval dialog built to the mock (one merged list per credential, inline diff rows with kind tags, per-row edit/skip, live approve count, close-to-defer).
7. OpenAPI — GET /agent/api serves a document generated from the schema types plus a route manifest (ts-json-schema-generator; nothing hand-written), checked in at packages/schema/openapi/agent-api.json, pinned by a bidirectional route-coverage test, a conformance test that drives every route and validates responses against the doc, and a byte-identical regeneration test.
8. connections — migration 0048 drops connections.root_ciphertext / usable_by; legacyRootMint, usableByAllows, the static root minter, the proxy root branch, the orgCredential flag, and PUT/DELETE /connections/:name are deleted. Connections keep only what is provider-shaped (catalog, per-user grants, GitHub app, manifest enablement).
9. gates — lint baseline lowered (no-unknown-parameters 31 → 23; anti-slop 74 → 66), CLAUDE.md debt numbers and max-lines list corrected to reality.

Verification

• npm run typecheck: green, all workspaces.
• npm run lint:gate: passed at the new baseline (66 anti-slop / 0 blitz-house); tools/oxlint/anti-slop diff empty.
• npm test: control-plane vitest 673 passed (python/bash/host/scripts/openapi sub-suites all green), box guest tests 108 passed, house-rule and microvm node tests green, provision-broker.test.sh green, webapp 773 passed. Two lody real-daemon suites timed out only while another worktree ran the same suites on the machine-wide harness lock; both pass in isolation (9/9) and are byte-identical to main.
• Go (packages/broker, packages/box/gateway): build, vet, test all ok.
• npm run openapi:generate is idempotent; the artifact is current.

Deliberate data deletions (read before merging)

• Migration 0047 drops every stored workspace credential value. Nothing is migrated: same-name collisions across workspaces made an automatic lift ambiguous, the store was days old, and the org dotenv import re-creates a workspace's keys in one paste.
• Migration 0048 drops every org root stored on a connection row. Paste once into the org Credentials panel.

Post-merge runbook (not done here — cutting a tag from a box is off-limits)

The legacy /workspaces/self/* credential routes are gone, so field boxes must cycle onto the new image in the same release train: rebake canary per docs/BOX-IMAGE.md (the image gains jq, the new blitz-cred, and blitz-git-credential), cut the client-prod tag, roll cloud-VM boxes via blitz-box-update and recreate microVM incarnations (volumes survive). A straggler box's blitz-cred get fails loudly with a 404; the fix is updating it, never a server-side shim.

For the reviewer

• New dev dependencies (control-plane): ts-json-schema-generator (brings a nested typescript@5.9 because the repo's TS 7 native compiler has no JS API) and @cfworker/json-schema (ajv compiles with new Function, which workerd forbids).
• Commit attribution via the GitHub token (git user.name/email auto-config, gitidentity.go) died with the old wire and nothing replaces it — the plan's survivor list did not keep it.
• Pre-existing latent bug surfaced, not fixed (out of scope): connections.name is still UNIQUE (migration 0003) while ensureCatalogConnection writes name = provider, so the same provider cannot be declared in two orgs.
• A recycled or unknown proposal id answers 404 on the agent poll; the rules tell the agent to read it as expired.

🤖 Generated with Claude Code

[pythonlearner1025]

why is there a special route for github token??? i thought github token is received through the connections path via the user oauth on the blitzos platform gh app installed in their acc, which mints a temp token. if not through the connections path, then user can save a gh PAT in the credentials. but if given that PAT, just use it directly, whats with the special treatmnet?

[pythonlearner1025]

isn't this redundant with agent-routes? could we, instead of having two separate routes (one for agents and one for human use) just unify to 1 api?