satisfactory: server.storage stays the documented exception (#39)

Walks back the one part of the previous commit that changed rendered output:
storage was pulled into the server fallback, so an erased size fell back to
20Gi instead of rendering a PVC without one.

values.schema.json had documented the opposite decision - "an erased value
yields an invalid PVC rather than a silently degraded workload" - and that is
someone's reasoned trade, not collateral of the nil-pointer bug next to it.
Overturning it inside a patch would have made this the only release where
valid values render differently, and it would have settled an open design
question in a PR nobody opened for that. It goes to #39 instead.

So storage is out of the defaults again and the schema note is restored
verbatim, extended only by where the exception is argued. values.yaml marks
it as the one key of the block that is deliberately not null-safe. The
README rule that had leaned on this example now says the thing that actually
holds: an exception is fine, an unmarked one is not.

Everything else stands - dev and server null-safe, the single-key findings on
the ports, formatNumber against exponential notation, 7.0.1.

Re-measured after the walk-back: rendered output against the chart defaults
and against a full override set is byte-identical to 7.0.0, NOTES.txt
included, and "--set server=null" now renders exactly the sizeless PVC that
"--set server.storage=null" rendered on 7.0.0.

README.md

@@ -344,7 +344,9 @@ Reference implementation: `template-chart/values.schema.json` and `template-char
 
 **2. Probes, security contexts and resources go through the null-safe helper, never behind an `if`.** An override written without children is YAML null and erases the block: the container renders `securityContext: null` (unhardened, healthy, silent), a probe disappears, or `resources` loses its requests and computed limits. The `defaultedDict` helper defines the opposite semantics — an empty block means "chart defaults apply" — while an explicitly set value still wins, **including `false` and `0`** (hence the `kindIs "invalid"` check; `default` and `mergeOverwrite` both swallow zero values). Do **not** wrap these blocks in `{{- if }}`: a guard does not render a visible `null`, it removes the probe entirely, which is the same bug with no evidence left.
 
-  The rule is about the **shape, not about those three block kinds**. `satisfactory` shipped 7.0.0 with `game` null-safe and its two neighbours not (Gitea #16): `--set server=null` aborted the render, and a single erased key was the worse half — a nulled `server.gamePort` rendered `port:` and `nodePort:` empty, a nulled `server.storage` a PVC asking for no size, and both are rejected by nothing until the API server sees them. Every chart-owned block a template dereferences belongs behind the helper, and a chart where only *some* of them do is worse than one where none do: whoever sees `game=null` fall back cleanly assumes `server=null` does too. A block that is deliberately left un-defaulted has to say so in the schema *and* survive the check that the erased form still renders something an operator can read — `satisfactory.storage` carried exactly such a note ("an erased value yields an invalid PVC rather than a silently degraded workload") and it did not hold, because it made the *whole block* being erased produce a sizeless PVC.
+  The rule is about the **shape, not about those three block kinds**. `satisfactory` shipped 7.0.0 with `game` null-safe and its two neighbours not (Gitea #16): `--set server=null` aborted the render, and a single erased key was the quieter half — a nulled `server.gamePort` rendered `port:` and `nodePort:` empty into the Service and an empty `containerPort` into the StatefulSet, rejected by nothing until the API server saw it. Every chart-owned block a template dereferences belongs behind the helper, and a chart where only *some* of them do is worse than one where none do: whoever sees `game=null` fall back cleanly assumes `server=null` does too.
+
+  **A deliberate exception is fine; an undocumented one is the bug.** `satisfactory.storage` is left un-defaulted on purpose — an erased size yields an invalid PVC that fails at apply time rather than a volume quietly sized by the chart — so `server: null` still renders a PVC without a size. That is a defensible trade and it is *not* the null-safety bug next to it; what makes it safe to leave standing is that the schema, `values.yaml` and the chart page all name it as an exception and point at the issue where it is argued (Gitea #39). Note also where the trade actually bites: only on a **new** install. For an existing release a fallback to the default size would fail too, because a PVC cannot shrink. Do not overturn a reasoned exception inside a bugfix patch — the patch then stops being one.
 
   **And `helm template` does not render `NOTES.txt`.** A value read there — `server` is read in four files in that chart — stays broken after a fix that looks green in every render, until someone runs a real `helm install`. `helm install --dry-run=client` is not the way around it either: it still wants a reachable API server (measured on helm v3.22.0). What works without a cluster: in a throwaway copy of the chart, wrap the verbatim `NOTES.txt` body in a `{{- define }}` and `include` it into a scratch ConfigMap, which `helm template` *does* render — same engine, same root context, only the sink differs.
 

satisfactory/templates/_helpers.tpl

@@ -333,15 +333,25 @@ The effective server block (Gitea issue #16, the rest of #99).
 single erased sub-key was worse than that: it rendered silently. A nulled
 server.gamePort produced a Service with "port:" and "nodePort:" empty and a
 StatefulSet with an empty containerPort — a manifest the API server rejects
-only at apply time — and a nulled server.storage produced a PVC asking for no
-size at all. Both now fall back to the documented defaults instead.
+only at apply time. Those now fall back to the documented defaults instead.
 
-Note what is NOT defaulted here: server.resources. That block already runs
-through satisfactory.effectiveResources, which carries its own defaults and is
+TWO keys are deliberately NOT defaulted here.
+
+server.resources, because it already runs through
+satisfactory.effectiveResources, which carries its own defaults and is
 null-safe on its own; repeating limitFactor/4Gi/1/5Gi here would create a
-third place for them to drift apart. Keys the defaults do not mention are
-passed through by satisfactory.defaultedDict unchanged, so an erased
-"server:" simply leaves resources unset and effectiveResources supplies them.
+third place for them to drift apart.
+
+server.storage, because values.schema.json documents the opposite decision
+for it on purpose: an erased size must yield an invalid PVC that fails at
+apply time rather than a workload quietly sized by the chart. An erased
+"server:" therefore still renders a PVC without a size — deliberately, not by
+oversight. That exception is worth re-examining, but it is someone's reasoned
+decision and not a bugfix's to overturn; it is negotiated in Gitea issue #39.
+
+Both rely on the same mechanic: keys the defaults do not mention are passed
+through by satisfactory.defaultedDict unchanged, so an erased "server:" leaves
+them unset and whatever consumes them downstream decides what that means.
 
 The defaults below MUST stay in sync with the server block in values.yaml,
 which stays the documented, user-facing place for them; this copy is only the
@@ -351,8 +361,7 @@ fallback for the case where an override has erased the block.
 {{- $defaults := dict
       "replicas" 1
       "gamePort" 30777
-      "messagingPort" 30888
-      "storage" "20Gi" -}}
+      "messagingPort" 30888 -}}
 {{- include "satisfactory.defaultedDict" (dict "defaults" $defaults "given" . "path" "server") -}}
 {{- end -}}
 

satisfactory/values.schema.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://json-schema.org/draft-07/schema#",
   "title": "satisfactory values",
-  "description": "Strict values schema (issue #68). additionalProperties is false on every chart-owned object level, so a key that the chart does not read is rejected at render time instead of being silently ignored. The only objects that stay open are the ones passed verbatim into the Kubernetes pod spec (probes, security contexts, global) - the chart does not interpret their contents, so it cannot judge which keys are meaningful. The hardening, probe and resources blocks additionally accept null, because an erased block falls back to the chart defaults (issue #99); since 7.0.1 that holds for every chart-owned block, dev, game and server included (Gitea issue #16), so no block is half-safe any more. Note that this chart keeps env, probes and securityContext at the TOP level rather than under a chart-named key.",
+  "description": "Strict values schema (issue #68). additionalProperties is false on every chart-owned object level, so a key that the chart does not read is rejected at render time instead of being silently ignored. The only objects that stay open are the ones passed verbatim into the Kubernetes pod spec (probes, security contexts, global) - the chart does not interpret their contents, so it cannot judge which keys are meaningful. The hardening, probe and resources blocks additionally accept null, because an erased block falls back to the chart defaults (issue #99); since 7.0.1 that holds for every chart-owned block, dev, game and server included (Gitea issue #16), so no block aborts the render any more. The one key that stays un-defaulted is server.storage, and it says so itself (Gitea issue #39). Note that this chart keeps env, probes and securityContext at the TOP level rather than under a chart-named key.",
   "type": "object",
   "additionalProperties": false,
   "properties": {
@@ -42,7 +42,7 @@
       }
     },
     "server": {
-      "description": "May be null / empty: the chart then falls back to its documented server defaults (Gitea issue #16, the rest of issue #99) instead of aborting the render with a nil-pointer error, which is what an erased block used to do. server.resources is the exception - it is not defaulted here but passed through to the resources fallback, which carries the defaults for it.",
+      "description": "May be null / empty: the chart then falls back to its documented server defaults (Gitea issue #16, the rest of issue #99) instead of aborting the render with a nil-pointer error, which is what an erased block used to do. Two keys are exceptions. server.resources is not defaulted here but passed through to the resources fallback, which carries the defaults for it. server.storage is not defaulted at all, deliberately - see its own description.",
       "type": ["object", "null"],
       "additionalProperties": false,
       "properties": {
@@ -64,7 +64,7 @@
           "maximum": 65535
         },
         "storage": {
-          "description": "Size of the data PVC. Null means the chart default (20Gi). Up to 7.0.0 this was deliberately not null-safe, on the reasoning that an erased value should yield an invalid PVC rather than a silently degraded workload; that reasoning did not survive Gitea issue #16, because it made \"server: null\" render a sizeless PVC instead of falling back like every other block. The chart default is not a degradation - it is the documented size.",
+          "description": "Size of the data PVC. Not null-safe on purpose: an erased value yields an invalid PVC rather than a silently degraded workload. This stays the documented exception after Gitea issue #16 made every other block in this chart null-safe, so \"server: null\" still renders a PVC without a size; whether failing loudly at apply time beats falling back to 20Gi is negotiated in Gitea issue #39, not inside a bugfix patch.",
           "type": ["string", "null"]
         },
         "resources": {

satisfactory/values.yaml

@@ -32,18 +32,22 @@ game:
   enableSeasonalEvents: false
 
 # Erasing this block, or any single key in it, falls back to the defaults below
-# (Gitea issue #16). Before 7.0.1 "server: null" aborted the render and a single
-# erased key was worse: a nulled gamePort rendered an empty port number into the
-# Service and the StatefulSet, and a nulled storage a PVC without a size — both
-# rejected by the API server at apply time, not by the render.
+# (Gitea issue #16) — with the documented exception of storage, see there.
+# Before 7.0.1 "server: null" aborted the render, and a single erased key was
+# the quieter half: a nulled gamePort rendered an empty port number into the
+# Service and the StatefulSet, rejected by the API server at apply time and by
+# nothing before it.
 server:
   # Replica count for this workload; 0 is allowed and scales it down.
   # The chart-global scaleDown flag takes precedence.
   replicas: 1
   gamePort: 30777
   messagingPort: 30888
-  # The size of the data PVC. An erased value falls back to this default; up to
-  # 7.0.0 it rendered a PVC asking for no size at all.
+  # The size of the data PVC, and the ONE key of this block that is NOT
+  # null-safe — deliberately, not by oversight. An erased storage (including
+  # "server: null") renders a PVC without a size, which fails at apply time
+  # instead of quietly sizing the volume from the chart. Whether that is still
+  # the right trade is negotiated in Gitea issue #39, not here.
   storage: 20Gi
   resources:
     # Limits are optional: memory and ephemeral-storage limits default to