bootstrap-admin does not print the farm code, so first-run login is blocked #589

Amendment (2026-08-24): this body's claim that no test asserts bootstrap-admin's stdout is
false — BootstrapAdminCommandTests.cs has a stdout harness and asserts on it. The real
diagnosis, and a correction to the "mirror provision-account" instruction (the two outcome
records diverge on nullability and the no-op path), are in the first comment below. Read that
before planning. Body left as written for history.

Found by the owner running the documented first-run flow on a fresh database.

Problem

bootstrap-admin prints the email and the generated temporary password, then says "Log in with this now — the app requires a new password before anything else works."

The operator cannot log in. Since #532, the sign-in form requires a farm code, and bootstrap-admin never prints one. Actual output:

First-run admin provisioned: admin@cluckwork.local (account 0000000a-0000-0000-0000-000000000001).
Temporary password: <generated>
Log in with this now — the app requires a new password before anything else works.

The value they need is default-farm, and the only ways to discover it are reading 20260818235944_AddAccountSlug.cs, querying Accounts."Slug" directly, or reading the k6/Playwright fixtures. None of those is a first-run operator's job — and this is the first command anyone runs against a new deployment.

The sibling verb already does it right

ProvisionAccountCliCommand.cs:66 — written after farm-code login landed:

$"Farm provisioned: {outcome.Slug} (account {outcome.AccountId}); Owner {outcome.OwnerEmail}."

BootstrapAdminCliCommand.cs:69 — predates it, never swept:

$"First-run admin provisioned: {outcome.Email} (account {outcome.AccountId})."

Why it slipped

This is exactly what AGENTS.md's write-contract callers rule (#394) exists to catch: "A write-contract change must update its non-CI callers... Verify the request/status contract by reading the callers, not by running." #532 made farmCode a required part of the login contract. provision-account was authored with that contract in view; bootstrap-admin was not revisited, and no test asserts what it prints, so nothing went red.

Scope

• Print the farm code in bootstrap-admin's success output, matching provision-account's shape. The account id is far less useful to the operator than the slug — keep both, but lead with what they must type.
• Check whether BootstrapAdminOutcome already carries the slug; if not, thread it through from the account rather than re-deriving or hardcoding "default-farm" at the call site. The literal must not be duplicated into the CLI — it lives in the migration, and a second copy is a drift hazard.
• Not in scope: changing the slug value, or the provisioning behaviour itself.

Tests

A CLI-level test asserting the success output contains the farm code. There is currently no test asserting bootstrap-admin's stdout at all, which is why this shipped — so the test is the point of the issue as much as the fix is.

Mutation to verify the guard is real: remove the slug from the output string and confirm that named test goes red. A test that only asserts "output is non-empty" or greps for "provisioned" would not catch this.

Docs

bootstrap-admin is described in AGENTS.md and in the first-run docs. If any of those show sample output, update it in the same PR per the docs-in-sync directive. The SPA Help page's first-run copy (signingInFirstRun in web/src/i18n/en.ts) tells the operator an administrator runs a command — check whether it should also say the command prints the farm code they will need.

Acceptance

• A first-run operator can complete sign-in using only what bootstrap-admin printed, with no access to the database, the migrations, or the test fixtures.