preflight should check the four adopter-set values and name Variable vs Secret

[charlesgreen]

The problem

Nothing checks the four values an adopter must set until a real run fails, and the one thing that does check gets deleted at the end of install.

simplycubed preflight (cmd/simplycubed/main.go:377) loads .github/simplycubed.yml and validates engine settings. It does not look at any of:

Section	Name
Variables	SIMPLYCUBED_GH_APP_CLIENT_ID
Secrets	SIMPLYCUBED_GH_APP_PRIVATE_KEY
Variables	SIMPLYCUBED_AZURE_OPENAI_ENDPOINT
Secrets	SIMPLYCUBED_AZURE_OPENAI_API_KEY

The install self-test does check, and names the section when one is missing:

FAIL: AZURE_OPENAI_ENDPOINT is not set (repository VARIABLE).

That is the right message. It is also thrown away: the self-test is a one-time diagnostic and init tells the adopter to delete it once it passes. The only check that catches a wrong-section value does not survive the install that introduces it.

Why it matters

Two of the four go in Variables and two in Secrets, and the names give no signal which. A Client ID looks credential-shaped, so putting it in Secrets is the natural instinct, and then vars.SIMPLYCUBED_GH_APP_CLIENT_ID resolves to an empty string rather than erroring.

This is not hypothetical. During a real install AZURE_OPENAI_ENDPOINT was set as a secret. Nothing reads secrets.AZURE_OPENAI_ENDPOINT, so it sat inert, no output anywhere said so, and it was found by reading the caller workflow. A first-time adopter has no such recourse.

Work

Give preflight the check the self-test is discarding, so the capability outlives the diagnostic.

• Check all four values, in whichever place preflight is running (locally the two Azure values come from the environment; in Actions all four arrive as workflow inputs and secrets).
• On a miss, name which section it belongs in, the way the self-test already does. "not set" alone sends someone to the wrong settings page.
• An empty-string value must fail the same as an unset one. That is the actual failure mode when a variable was filed as a secret, and it is silent today.

Acceptance

• preflight fails, naming the value and its section, when any of the four is missing or empty
• A value set to the empty string fails identically to one that is unset
• Exit code distinguishes a configuration miss from an internal error
• make check green

#114 has landed, so the names above are current. engineEnv in cmd/simplycubed/main.go already checks the two Azure values and names their section; the gap is the two App values, and the fact that nothing checks any of them outside a run.

Note the self-test message quoted above predates #114 and names the old variable.

[simplycubed-code]

Blocked: the change touches .github/workflows/simplycubed.yml, but this run is authenticated as the simplycubed-code[bot] GitHub App, which deliberately lacks workflows permission. GitHub will refuse that push. Commit the workflow change as a human, or rerun the CLI under your own GitHub auth.

What the agent reported

Implemented the preflight change in cmd/simplycubed/main.go: preflight now classifies adopter-set configuration misses separately, checks the Azure pair through a shared section-aware helper, and, when explicitly invoked from the reusable workflow, also checks SIMPLYCUBED_GH_APP_CLIENT_ID and SIMPLYCUBED_GH_APP_PRIVATE_KEY. Missing and empty values fail identically, and dispatch returns exit code 3 for these preflight configuration misses. I also updated the reusable workflow preflight step in .github/workflows/simplycubed.yml and .github/workflows/simplycubed.yml so Actions actually exposes the App pair to simplycubed preflight.

Verification: TMPDIR=$PWD/.tmp go test ./cmd/simplycubed passed.

make check still does not complete in this environment. It fails at go build ./... before reaching repo code with:

error obtaining VCS status: exit status 128
Use -buildvcs=false to disable VCS stamping.

This worktree lives under /tmp/..., and Go 1.26 is attempting VCS stamping from /tmp, so the gate is blocked by the checkout environment rather than by the code change. I did not modify tests, the gate, or CI files to force a green result.