fix(gen): document the customer flavour in --help and expand the flavours docs

[TheoBrigitte]

Problem

devctl gen makefile --help and devctl gen workflows --help print the supported --flavour values twice, from two different sources that had drifted apart:

1. The flag usage line — generated from gen.AllFlavours(), so always complete (7 values).
2. The command long description — a hand-typed bullet list in cmd/gen/{makefile,workflows}/command.go, listing only 6.

When FlavourCustomer was added to pkg/gen/flavour.go, the flag line picked it up automatically and the prose lists did not. The result: customer is a perfectly valid flavour that does something real (it adds the Add issue to general customer board workflow, cmd/gen/workflows/runner.go:109), but reading the command description you'd conclude it isn't supported. Nothing tied the prose to the constants and no test compared them, so the drift was invisible.

Before:

There are different generation flavours:

  - app - project containing a helm chart
  - cli - project released with a downloadable binary
  - generic - everything else, i.e a project which simply needs to be released
  ...
                             ^ no customer

  -f, --flavour flavourSlice   ... Possible values: <app|cli|customer|generic|k8sapi|cluster-app|fleet>
                                                            ^ but it's here

Change

• pkg/gen/flavour.go: add flavourDescriptions (one entry per flavour) and FlavourDescriptionList(), which renders the bullet list from AllFlavours().
• cmd/gen/{makefile,workflows}/command.go: drop the hand-typed lists; build longDescription from gen.FlavourDescriptionList() (const → var, since it's now computed).
• pkg/gen/flavour_test.go: fail if any AllFlavours() entry lacks a description, if a described flavour isn't valid, or if a flavour is missing from the rendered list.

Both lists now come from one source and render in the same order, so adding a flavour can't silently leave the help behind.

The customer wording is derived from what the flavour actually does — happy to reword.

Follow-up: docs/flavours.md

Fixing the help text surfaced the same gap one level up. docs/flavours.md named each repository type but never said what picking it does, and never mentioned that --flavour and --language are two axes you choose together. A one-line "an app, by the definition of the app platform" doesn't help someone decide between app and app,cluster-app.

The doc now carries, for each flavour, the files it actually generates per gen command:

Flavour	e.g.
app	Makefile.gen.app.mk, zz_generated.check_values_schema.yaml, the CircleCI build-chart/push-to-app-catalog jobs
cluster-app	Makefile.gen.cluster_app.mk, zz_generated.documentation_validation.yaml, zz_generated.json_schema_validation.yaml, zz_generated.diff_helm_render_templates.yaml
cli	the package-* targets in Makefile.gen.go.mk, .github/zz_generated.windows-code-signing.sh, the six-arch go-build + upload-release-assets jobs
k8sapi	Makefile.gen.k8sapi.mk, hack/boilerplate.go.txt
fleet	zz_generated.cluster_app_values_validation_schema.yaml
customer	zz_generated.add_customer_board_automation.yaml
generic	nothing flavour-specific — stated explicitly, since it reads like a fallback and isn't one

Plus a "which flavour do I need" table, a --language section (go, node, python, generic, kyverno-policy and what each emits), the cli requires go rule, and a table of common pairings (-f app,k8sapi -l go for an operator, -f app,cluster-app for a cluster app, …).

It also records three things that are easy to get wrong:

• Only gen makefile and gen circleci validate --language against the enum. gen workflows, gen llm and gen precommit take a plain string, so -l golang silently drops the language-specific output rather than erroring.
• gen renovate --language is a different list — Renovate ecosystems (go, docker), not this enum.
• gen precommit --flavors (US spelling, bash/md/helmchart) is an unrelated flag that selects extra checkers.

Every path and constraint in the doc was read out of the generators rather than inferred.

One thing found while writing it, not changed here: create_release.go:28 passes IsFlavourCLI into the template, but create_release.yaml.template never reads it. Dead template data — the cli flavour has no effect on the release workflow. The doc reflects the real behaviour; happy to drop the unused param in a separate PR.

🤖 Generated with Claude Code