[antoinetoussaint-byte]

Two changes to one repo, one PR.

1. fixture-composition is merged by the platform

The local authority's fixture-composition document is merged from one fragment per composed module, never typed per playground.

• pkg/fixturefragments: finds each workspace module's configurations/<profile>/fixture-composition.yaml (profile chain resolved by core's configurations.ProfileDirectory, in the module's own directory), merges them with the authority's library (codefly-dev/authority/libraries/fixture-composition/go: one source per (org, role, kind) grant / installation / stand-in, conflicts refused naming both fragments), and writes the workspace's configurations/<profile>/fixture-composition.yaml with a generated marker and the list of sources.
• codefly run (newRunFlow, before the flow reads any configuration — the same seam as the generated service-secrets): writes it when a composed service declares the group. No Makefile step.
• codefly generate fixture-composition --env local: the same, on its own (materializes pinned modules first, like a run).
• Hand-written file: never overwritten. generate refuses it by name; run reads it as it stands and warns that no module's fragment is applied, which keeps the not-yet-migrated playgrounds (authority/playground, core-solutions wiki/proposals) booting.
• docs/cli-reference.md regenerated.

Reuse: core already delivers each composed module's configurations/<profile>/*, and a workspace's own document already resolves an ambiguity between composed modules (composeModuleWorkspaceConfigurations). The generated file uses exactly that precedence, so core is unchanged and the authority's reader is unchanged. The merge rules are the schema owner's library, which this repo already depends on.

2. hop-routes is delivered empty where no module is named

A host that stands a hop on some compositions and not others declares hop-routes always — saas's auth-gateway is the hop on a cell and stands none where the composition names no module, which its own service.codefly.yaml documents: "A local run composes the authority module's hop instead and states no hop/MODULES for this service." generatedHopRoutes returned no group at all for that composition, and core's GetWorkspaceDependenciesConfigurations refuses a declared group that resolves to nothing: the service failed at runtime-init, from the declaration, before any of its code ran, so it could not degrade — and it could not stop declaring the group either, since generation requires a declaring service. This blocks saas #1265.

The group is now delivered with an empty ROUTES. Verified safe:

• nothing decodes it — the gateway stands its hop only where hop/MODULES names modules, and freezeDeliveredHopAddresses skips an empty value, so routing.DecodeRouting is unreachable;
• the routing snapshot of an empty value equals that of no group, so no run is told its routes changed;
• the declaring-service check runs before the empty return, so a workspace no service of which declares the group still receives nothing;
• a composition that names modules still receives its generated routes, unchanged.

Why an empty value satisfies the resolver at all: core's Manager.GetWorkspaceDependenciesConfigurations keys group presence by name, not by content.

Why the empty string, specifically. routing.Validate requires at least one endpoint, and authority's own work_test.go asserts that even {"schema":…,"endpoints":[]} is refused. There is deliberately no "no routes" document in hop-routes/v1, so the empty string is the only available spelling for "no table". If that should be hardened, the fix belongs at authority — whether the schema gains a legitimate empty document — and it is a follow-up, not this PR.

The shape I considered and rejected: OptionalWorkspaceConfiguration

The alternative is to leave generatedHopRoutes returning nothing and add hop-routes to environments.OptionalWorkspaceConfiguration, whose doc comment states this contract word for word: a service that declares such a group reads the keys it needs and treats an absent one as not configured, so every path that resolves a service's declared groups delivers nothing for one the workspace does not provide. Both hop consumers do read their group that way — saas's standHop reads hop/MODULES with the tolerant accessor and returns before it mentions hop-routes, and the authority module's own hop refuses by name on the same read. On the reuse rule alone that is the better-looking fix, and I built it before rejecting it.

It is rejected because that seam is two halves and only the run half is generic. checkRequiredWorkspaceConfiguration dispatches every optional group into checkRunnableBindingsGroup, which calls generate.SelectRunnableBindings unconditionally and judges the group against the runnable bindings the environment selects. Added to that list as it stands, hop-routes gets judged about runnable bindings:

• locally, status=ok with environment local prepares no runnable binding, so "hop-routes" holds none — green about an entirely different thing;
• in a workspace that declares hop-routes and selects runnable bindings, held is empty so every selected binding key counts as missing and the doctor emits a spurious hard configuration_missing: "workspace configuration "hop-routes" lacks N runnable binding(s) environment local selects".

Making it right means splitting that dispatch and writing a checkHopRoutesGroup — more work than this fix and a change to a shared seam runnable-bindings depends on. The two shapes are behaviourally equivalent at both known consumers (the refusal was never raised in gateway code; both make the declaration resolve), so the doctor defect is the only thing separating them.

Can a composition that should name modules resolve to nothing and fail later?

No. The group is delivered only where a service declares it, and the empty table only when hop/MODULES is empty — a documented, legitimate composition. Where modules are named nothing is weakened: an uncomposed module, an unreadable catalog or a disagreeing principal still fails the reader, which codefly doctor workspace reports as configuration_invalid ("not checked"), and a new case in the refusal test proves it.

What neither shape can catch is an operator who meant to name modules and left hop/MODULES empty: to the CLI that is indistinguishable from "stand no hop". That was equally true before — the old behaviour did not catch the mistake, it crashed every composition that legitimately stands no hop.

The doctor is the same seam, not a second fix

checkConfigurationSources already takes generated groups from this inventory — its own comment says "never from a name exemption" — so once the group is delivered the doctor reports it as supplied by the invocation instead of configuration_missing. No name list was touched.

One deliberate test change. TestDoctorWorkspaceStillRefusesInvalidHopInputs carried {"no selected modules", …, codeConfigurationMissing, "hop-routes"}, asserting that this composition must fail the doctor. That was the symptom, not a rule — the consumer repo documents the composition as legitimate — so it is replaced by TestDoctorWorkspaceAcceptsAHopThatSelectsNoModule rather than kept green. The sibling {"missing ordinary group", …} case still proves the doctor reports a genuinely missing non-generated group, so the weakening is scoped.

Evidence

• go test ./pkg/fixturefragments/ ./pkg/orchestration/ ./cmd/ ./cmd/run/ ./cmd/generate/ green. Fragment merge of the authority's, two modules' and the playground's; conflict naming both fragments; hand-written file kept; nothing declared without a declaring service; the run hook writes before load. For hop-routes: the empty delivery for an empty and an absent hop group, a composition naming modules still generating routes, and a workspace declaring nothing still receiving nothing.
• golangci-lint run (v2.14.0, make lint) clean on the changed packages.
• Live with this branch's binary, module-document-store playground (authority de0deb68): the run printed merged …/configurations/local/fixture-composition.yaml from 3 fragment(s), the authority logged the same 8 grants as before except Maya's collection read is now id: derived\x1fdocuments-playground; Maya then lists Rémi's document in that collection (200), and every other verified call is unchanged. Robin's playground: see obin-ai/module-robin#562.

Fix or hack

Both are fixes at the owner: the platform generates the fixture document from its one source per module, and the CLI delivers the group its own generation owns.

🤖 Generated with Claude Code