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 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.

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).

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 plan, so the lines describe what the process runs with after the plan is applied.

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 [""].