Resolve the runtime plan and apply it, first thing at boot.

Reads the live posture and the cgroup, resolves the plan against the given config values, and then:

• plan already in force: log the posture lines and return;
• only the capability count differs: apply it in-process (setNumCapabilities), log, and return;
• a heap ceiling must be enforced: append the required flags to GHCRTS and exec this binary in place (same PID, same arguments), once, guarded by reexecMarker. The re-launched process resolves the same plan, finds it in force, and logs the posture lines as normal.

When the marker is already set and the posture still diverges (an operator's GHCRTS contradicting the config, or a flag the RTS rejected), the divergence is logged as a warning and the process continues with what the RTS gave it -- boot never loops and never aborts over tuning.

The returned plan is the effective one: the live posture is re-read after the apply attempt and reconciled with the desire, so every downstream sizing (the admission capacity, the memory plan) computes from what the RTS actually runs with. An axis the apply failed to enforce is warned per axis, naming desired and observed.

The RTS posture the process is actually running with, in bytes. Read once at boot (currentRtsPosture); the plan is resolved against it and the log renders it.

What the cgroup (v2) grants this process: the CPU quota in cores (cpu.max, quota over period) and the memory ceiling in bytes (memory.max). Nothing per axis when the file is absent (not a cgroup-v2 environment) or the value is the unlimited max sentinel.

Where a resolved value came from, for the boot log's provenance clause.

The resolved runtime posture: the capability count to run with and the heap ceiling to enforce, each with its provenance. A FromRts entry means "leave it alone": the plan never overrides a posture it has no better information than.

The provenance as a bare clause, for consumers composing their own lines (the memory plan's, beside this module's posture lines).

Resolve the runtime plan from the three layers, strongest first: explicit config, then the cgroup, then the live RTS posture.

Capabilities: an explicit cores wins; else the cgroup CPU quota rounded up (a 0.5-CPU pod still needs one capability) and clamped to the visible processors; else the RTS's own count stands. Always at least 1.

Heap ceiling: an explicit maxHeapBytes wins; else deriveMaxHeapBytes over the cgroup memory limit and the planned capability count (the nursery the process will actually run with); else the RTS posture stands -- notably, an operator's GHCRTS -M is never overridden by mere derivation, and an absent limit is left absent rather than fabricated.

The heap ceiling derived from a cgroup memory limit: the limit less the nursery budget (capabilities x allocation area -- memory the process spends over and above the heap) less 10% slack for stacks, buffers, and the RTS itself, floored at half the limit so a nursery mis-sized for a tiny pod still yields a sane ceiling rather than a vanishing (or negative) one.

The RTS flags the plan requires beyond the live posture, in GHCRTS syntax: a -N when the capability count must change, a -M when a ceiling must be enforced that is not already in force. Empty when the process is already running the plan. A FromRts entry never contributes a flag (it is the live posture).

One axis of the runtime posture after the boot applied the plan: the value the resolution wanted, the value the RTS is actually running with, and where the desired value came from. Downstream sizings read only the effective projections (effectiveCapabilities, effectiveHeapCeiling), never the merely desired plan: an apply can fail (a rejected flag, a failed exec, an operator GHCRTS fighting the config), and a budget computed from a posture the process does not run with would be wrong in the direction that matters.

The runtime plan reconciled with the posture the RTS actually runs: the two planned axes as desired/observed pairs, plus the observed-only datapoints downstream sizing needs (the allocation area for nursery arithmetic, the container memory limit for the small-pod diagnosis).

Whether an axis is backed by the live RTS (desired and observed agree).

Pair the desired plan with the posture the RTS reports, axis by axis.

The effective plan a successful application would produce: observed equals desired on both axes. check-config sizes from this -- it applies nothing, so prediction, not observation, is its honest datapoint (its own process posture says nothing about the boot it is checking); the boot itself always reconciles against the re-read posture instead (applyRuntimePosture).

The live capability count: parallelism budgets must never exceed (or trail) what the RTS actually runs with, so the observed side is authoritative. When the desired count did not take, the provenance degrades to FromRts: the value in force is the RTS's own, whatever the plan wanted.

The sizing ceiling: the tighter of desired and observed. An observed -M below the plan binds (the RTS enforces it, so budgeting above it would over-commit); an absent observed -M leaves the desired ceiling standing as the sizing datapoint (the cgroup limit still backstops it through the OOM killer, so sizing to the desired ceiling stays honest even unenforced -- the divergence is warned, not silently absorbed).

The boot log's posture lines, one decision per line with its provenance, plus the allocation-area line (always RTS-sourced; it is deliberately not config-surfaced). Rendered from the effective plan, so the lines describe what the process actually runs with (and sizes from), never a desire that failed to take; an unenforced axis additionally warns through unenforcedWarnings.

Parse a cgroup-v2 cpu.max body: "quota period" yields the granted cores (quota over period); the "max ..." sentinel (no quota) yields Nothing. A malformed body yields Nothing -- no limit is inferred from noise.

Parse a cgroup-v2 memory.max body: a byte count, or the unlimited max sentinel (Nothing). A malformed body yields Nothing.

The process's cgroup-v2 path from a /proc/self/cgroup body: the 0:: line's path ("0::/a/b" yields "/a/b"). Nothing when no v2 entry is present (a pure cgroup-v1 host).

A cgroup path and its ancestors, leaf first, ending at the root (the empty suffix): "/a/b" yields ["/a/b", "/a", ""]; the root path "/" yields just [""].