Sentinel: Setting crew.concurrency has been away from its default for 1 days #2504

Setting crew.concurrency has been away from its default for 1 days

Evidence

• crew.concurrency = "10", default "4"
• set by trevato at 2026-10-15T18:03:27.742Z

Pillar: Trust: a setting is a decision, not a leftover

What to look for when fixed: crew.concurrency is back at "4", or a person says why it stays: the owner is asked in the inbox, Keep or Put back, and a person's close or comment keeps it, reported again only if its value changes. No agent is assigned; a run cannot change a setting.

Mechanical fix: Put it back: clear crew.concurrency on the capacity page (it is recorded and reversible).

Found by the sentinel at 2026-10-16T18:03:47.887Z.

State: split into #2548. A run cannot change a setting, but the owner set 10 on purpose for the vxrail, so the fix is the default. #2548 derives it from the pod's memory, the way children.max already does, and it comes to 10 on 32 GiB. Once that lands, clearing the override on the capacity page leaves the value unchanged, and the sentinel has nothing to report.

For the owner: #2548 has landed, so the default now follows the pod's memory (10 on 32 GiB). Once that release is live, clear crew.concurrency on the capacity page. Nothing changes, and this can be closed.

Kept on purpose (trevato, 2026-10-15: "you can raise the limits!"): crew.concurrency stays at 10.