[antoinetoussaint-byte]

Fixes the boot half of #1074.

What was wrong

A service that verifies an inbound Work Context loads its key set from an endpoint. workcontext.AdmitEndpoint — the single transport rule for every key set — already admits "plaintext http to a loopback host, on a local run only". Nothing served one.

So a module whose identity comes from the host could not boot on its own. In obin-ai/module-record-store, codefly run service record-store/playground resolved the dependency graph, started Postgres natively, and then:

action runtime-init on record-store/records failed: cannot get workspace
dependencies configurations: no configuration found for work-context

A developer with only that repository could start no service at all.

The change

The native run mints an Ed25519 key for itself, serves the public half as a JWKS over that admitted loopback hop, and hands the work-context group to any service declaring the dependency.

The group stays authored and is never render-owned, exactly as FederationConfiguration is. A composition with a host declares it, pointing at the host's key set; this answers only for the composition that has none, and is handed last so it settles over what an authored group leaves empty rather than displacing one. Making it render-owned would have forbidden authoring it and broken production composition.

Nothing is relaxed

• the service boots on its unchanged FromJWKS path — no second verifier, no FromKeys test door
• the KeySet invariant holds: keys still come from an admitted endpoint, with admission and fetch as one operation
• the run issues under its own issuer, so a capability minted here is structurally unacceptable to a deployed service, which pins the host's
• each run's issuer names the run, so two runs on one machine never accept each other's capabilities
• the listener lives exactly as long as the run

Tests

pkg/run/workcontext/authority_test.go covers the shape a verifier admits (OKP/Ed25519, raw-URL base64, a 32-byte key — a padded encoding or wrong curve fails), that the published half verifies what the signer signs, that each run issues under its own issuer, and that a run with no identity serves nothing.

go build ./cmd/... ./pkg/..., go vet and the touched packages' tests are green.

What this does not do

It does not mint capabilities for callers. Serving the key set unblocks boot; a call still needs a token. The natural source is the fixture, which already declares the local principals and their grants (pkg/run/fixture: ReadAdministrator, ReadCompositionGrants) — so the run would assert what the fixture declares rather than anything invented. That half is a product decision and is left for you; it is the remaining item on #1074.

🤖 Generated with Claude Code

[antoinetoussaint-byte]

A lazybox agent is working on this. claude (Opus 5) started at 2026-11-04 03:12 UTC, last renewed the claim at 2026-11-04 04:32 UTC, and the claim lapses at 2026-11-04 05:32 UTC unless it is renewed again. A claim is an assertion with an expiry, not proof that a process is alive.

claim detail

Lazybox-Claim-Device: effacd542b611010656e
Lazybox-Claim-Session: 79b2f88ed1
Lazybox-Claim-Workspace: github-codefly-dev-cli-1075
Lazybox-Claim-Agent: claude
Lazybox-Claim-Model: Opus 5
Lazybox-Claim-Started: 2026-11-04T03:12:44Z
Lazybox-Claim-Heartbeat: 2026-11-04T04:32:18Z
Lazybox-Claim-Expires: 2026-11-04T05:32:18Z

[antoinetoussaint-byte]

Verification failed — this does not fix boot as written. Converting to draft.

I built this branch and ran it against obin-ai/module-record-store:

/tmp/codefly-patched run service record-store/records
→ Runner.Init: cannot get workspace dependencies configurations:
  no configuration found for work-context

The same error as before the change. The key set is served, but the group never reaches the service.

Why

The group is appended in (*launcher).renderOwnedGroups, which feeds the per-service configurations handed to the runtime. The refusal comes from somewhere else entirely — core's configurations.Manager.GetWorkspaceDependenciesConfigurations:

conf, ok := manager.worspaceConfigurations[dep]
if !ok {
    return nil, w.NewError("no configuration found for %s", dep)
}

That map is the manager's own, populated from authored workspace configuration files through its Loader. renderOwnedGroups is not consulted by it. This is consistent with RenderOwnedWorkspaceConfiguration's own documentation — render-owned groups "are never dependencies of the configuration manager". work-context is a manager dependency, because services declare it in workspace-configuration-dependencies, so it has to be visible to the manager rather than handed alongside it.

So my placement was wrong: I followed the federation precedent, but federation is handed to the host as an extra configuration, whereas work-context is resolved as a declared dependency.

Where it likely belongs instead

pkg/orchestration/flow.go:495-504 builds the manager and calls WithLoader(localReader) — so the CLI already owns the loader the manager reads through. Layering the run-derived group there would make it visible to GetWorkspaceDependenciesConfigurations without a core change.

The ordering needs thought: the authority currently starts in attachLauncher, which runs after the flow is constructed, so either it moves earlier or the loader binds to it late.

What still stands

pkg/run/workcontext is independent of the placement bug and its tests pass: it serves a key set in the exact shape the verifier admits (OKP/Ed25519, raw-URL base64, 32 bytes), the published half verifies what the signer signs, each run gets its own issuer, and a run with no identity serves nothing. The argument in #1074 is unchanged — AdmitEndpoint already admits a loopback key set on a local run, and nothing serves one.

I would rather have this marked draft than merged on an unverified claim. Happy to move the wiring to the loader if that is the direction you want.

[antoinetoussaint-byte]

Resolved — verified working, back out of draft

The placement was wrong and is fixed. Re-verified against obin-ai/module-record-store:

before:  no configuration found for work-context
after:   no configuration found for platform      ← the NEXT group it declares

work-context now resolves. With that module's own host couplings also handled, codefly run service record-store/records reaches:

>> record-store/records: Running in 2.7s
   gRPC :36383 · REST :49532 · Connect :50620

and the full composition — store, records and a Next.js frontend — runs with no host composed.

What changed since the draft

The group is layered onto the configuration manager's loader, not appended beside the per-service configurations. A declared workspace-configuration dependency is resolved from manager.worspaceConfigurations, which only the Loader populates; renderOwnedGroups feeds a list that lookup never reads. RenderOwnedWorkspaceConfiguration says as much — render-owned groups are "never dependencies of the configuration manager". federation is an extra handed to the host; work-context is a declared dependency. Following the federation precedent put it in the wrong half.

Two constraints the decorator respects: Configurations() returns the same instances on every call, because the manager resolves secret references in those objects in place and reads them back; and the local reader's two optional capabilities (CompositionRootWorkspaceConfigurationNames, ambiguous-group reporting) are forwarded rather than swallowed.

The run also routes declared-but-unsupplied groups in empty, read from what the workspace's services declare. Each service then applies its own documented rule about absence rather than failing at the manager before it can.

An authored group always wins, so a composition with a host is untouched.

Lint

govet's shadow check flagged the key set's err shadowing the one from NewServiceDependencies. Named separately.

[antoinetoussaint-byte]

Closed: superseded by the authority interface design. The CLI no longer holds authority knowledge such as serving key sets or deriving grants. Authority lives in codefly-dev/authority, and the CLI only delivers through codefly.dev/composition (#1128).

🤖 Generated with Claude Code