a successful just up prints eleven lines of warning before it says it worked

[lex00]

just up works and ends on a clear success line. Getting there, a first-time user reads eleven lines of warning first.

What a clean run actually prints

Seven grey [fold:run] notes:

[fold:run] observability/monitoring.ts — "serviceMonitor" is not foldable: 10:12 - unresolved
  identifier: seams (2:42 - "backupRetentionDays" is not foldable: 38:21 - function call as a
  value is not foldable: resolveTier(...))
[fold:run] params.ts — "backupRetentionDays" is not foldable: ...
[fold:run] secrets/infisical.ts — "infisicalSecret" is not foldable: ...

then four yellow warnings:

warning: Container "dump" in CronJob has no explicit imagePullPolicy
warning: Container "dump" in CronJob does not drop ALL capabilities
warning: Deployment "fountain" has 1 replica(s) — consider at least 2 for high availability
warning: 4 post-synth finding(s) suppressed via lint.rules (severity "off")

then the thing you actually wanted:

  ✓ /health answered
fountain is up. Reach it with:  just forward   →  http://localhost:4000

Why it is worth fixing rather than ignoring

Every one of those lines is either expected or deliberate, and none of them says so. A first-time user has no way to distinguish "this is fine" from "this is the reason it will not work", so the honest reading of a successful deploy is that something went wrong.

It also trains people to ignore the warnings, which is worse than not printing them — the two CronJob findings are real and unaddressed, and they are now camouflaged by the noise around them.

The fold notes have one root cause

All seven trace to the same line: resolveTier(...) is a function call, so backupRetentionDays is unfoldable, so everything downstream of it is too. It is one fact reported seven times from seven call sites.

Whether that is worth fixing structurally (a const table instead of a call, at some cost to readability) or worth suppressing on the up path is a real choice. What is not defensible is printing it seven times on every successful deploy.

The 1 replica warning is wrong here, specifically

light is single-replica by design, and the README explains why more than one replica needs an Erlang cluster. Warning about it on every run of the tier whose whole point is one replica is noise that the repo has already answered.

Options

• Quiet the build inside just up and keep the full output on just build, so the loud version is one command away when something is actually wrong.
• Suppress the replica warning at tiers that are single-replica by design, the way WK8201 and WK8203 are already switched off in chant.config.ts with reasons.
• Fix the two real CronJob findings so they stop being noise: an explicit imagePullPolicy and a drop: ["ALL"] on the dump container.
• Address the fold chain at its root so the seven notes become zero.

The last two are worth doing on their own merits regardless of what happens to the output.

[lex00]

Split by where the fix has to live.

Fixed in #30 — the 13 [fold:run] lines and 4 of the 5 warnings. build: { fold: false } states the intent (every module here reads a value out of a function, so folding always falls back to running), the backup CronJob gets the imagePullPolicy and capability drop the other two containers already had, and WK8302 is off because "consider at least 2 replicas" asks for the one thing resolveTier refuses.

Not fixable here — the 23 [param] ... (default) lines. There is no verbosity flag on chant build; -v/--verbose only affects stack traces on errors. Filed as INTENTIUS/chant#1424, with the suggestion that the default should print parameters whose value was actually supplied and leave the defaults behind a flag.

Measured on a clean build, not through just up, which is why the count here is 41 rather than the eleven this issue reports — the [param] block does not appear in the just up path the same way. Worth keeping this open until #1424 lands.

[lex00]

Re-checked this against 085dd42 on a fresh just up. The problem is still real; the specifics in the description have moved.

Gone: the seven [fold:run] notes, and three of the four yellow warnings. Only one warning survives:

warning: 11 post-synth finding(s) suppressed via lint.rules (severity "off")

New, and now the bulk of it: chant build prints one grey line per resolved parameter, and there are 26 of them.

[param] env = "local" (env)
[param] namespace = "fountain" (default)
[param] host = "localhost:4000" (default)
... 23 more

So the count is worse than eleven, not better — a successful just up prints 27 lines of build chatter before the first thing anyone wanted to read. The reasoning in the description holds unchanged: none of it says whether it is fine, and a first-time reader has no way to tell.

One difference worth noting for whoever picks this up: the param dump is arguably useful when a build did something surprising, which the fold notes never were. --quiet on the build and apply recipes, with the full output still available by running npx chant build directly, may be a better shape than suppressing it.

Found while auditing the new-user path end to end; the surrounding findings are #57–#63.