A solution-go service agent: codefly add solution writes the paperwork, nothing writes the code #1217

Follow-up to #1215 / #1216. codefly add solution now writes the five documents a solution is installed from. It does not write a single line of solution code, and that is the remaining half.

What is missing

add solution --agent go dispatches to the generic go service agent, which scaffolds a plain Go service: a main.go, a go.mod, nothing else. It knows nothing about:

• solution-runtime-go — the runtime every solution backend is built on, and the pin check-consumed-apis requires
• consumes.go — the per-module clients derived from the manifest's api.consumes
• the CODEFLY__API_CONSUMES projection the runtime boots against
• the Work Context plumbing: the projected token, the authority's hop, the viewer's own context
• ./Page, the Module Federation remote, and the services/web shell that serves it

So every solution in obin-ai/core-solutions has that code hand-written, and the friction log of the last one scaffolded by hand put it at 1.5–2 hours.

This is a SERVICE agent, not an executor

Issue #1215 offered a second option: an executor protocol in core plus a codefly:solution agent. That is not what this needs.

Service agents already have a protocol — services.Add drives the agent's own Create flow — and the fleet already publishes several:

~/.codefly/agents/services/codefly.dev/
  go__0.0.46   generic__0.0.40   clickhouse__0.0.26   nextjs__…

solution-go is one more of those. It needs no core change and no new wire protocol. codefly add solution already takes it:

codefly add solution wiki --agent solution-go --package-id obin/wiki

That works the day the agent is published; the CLI then flips its default from go to solution-go. Nothing in #1216 changes.

The recipe already exists

templates/solution on obin-ai/core-solutions' scaffold/new-solution branch, whose own scripts/new-solution.sh says so:

It is a generator here rather than codefly add solution because there is no such verb … and the schema's codefly:solution agent kind has no published executor to dispatch to. templates/solution is shaped so it can become that agent's recipe rather than being thrown away.

That branch is the agent's contents waiting for a repo. It also already holds four rules worth carrying over: one canonical template, consumption declared once (api.consumes → generated client, with a drift check), no installation UUID in source, and green on every gate at generation.

Scope

• A new repo in the codefly-dev org publishing a codefly:service agent named solution-go, built and released like the existing service agents.
• Its Create flow scaffolds a solution backend: the runtime dependency, consumes.go generated from the manifest beside it, the health endpoint, and the ./Page/fe-remote npm package add solution deliberately does not write.
• A solution-python twin is the same shape with a different language, exactly as go/python are today — not a separate design.

Blocks

Conforming the existing solutions' backend code to one shape (obin-ai/core-solutions). Their documents can be conformed independently and are tracked separately.

🤖 Generated with Claude Code