New agent kind: codefly:solution — registry entry, proto enum, manifest schema, proto service

[antoinetoussaint-byte]

Context

obin's v2 platform (obin-ai/lodestar) proposes Solution as a first-class codefly kind: the executor that scaffolds a solution, packages it (OCI), and renders its manifests into a gitops repo — while the SolutionSpec itself stays codefly-agnostic. Design: lodestar docs/design/solution-delivery.md + docs/findings-v2-repo-topology.md.

Shape: copy the codefly:provider precedent

Provider is the worked example of adding a new dynamically-installable kind while staying out of the app graph (docs/provider-plugins.md):

• 7th entry in agentKindRegistry (resources/agent.go) + proto enum value (proto/codefly/base/v0/agent.proto) — genuinely small.
• Own manifest schema (cf. provider/manifest/manifest.go): identity, services (optional — descriptor-only solutions have none), api exposes/consumes, events, ui extensions, needs, permissions, lifecycle.
• Own proto contract (cf. provider.proto): Create/Update/Package/Render at minimum.
• Own CLI command group (companion issue in codefly-dev/cli).

Cautionary precedent

Job and Application both got the cheap 20% (YAML struct + loader case + add command) and never reached the deploy path. The acceptance bar for this kind is an end-to-end tracer bullet reaching an ArgoCD-synced namespace: obin-ai/lodestar#17.

Related: renderer generalization (cli companion issue) — the gitops inventory/bootstrap are parameterized on Service today.