SaSame

#4154 replaces the channel_allocation mechanism Pancho was using to manage its own channels. The old version worked, but it was written for a narrower job than what Pancho actually does now. Channel allocation started as a fairly mechanical thing — decide which channel a given operation runs on, don't collide with anything else in flight. As we pushed Pancho toward more autonomous business operations, that assumption stopped holding. More concurrent workflows, more variance in how long a channel stays occupied, more cases where the old allocator would pick correctly but for reasons that only made sense in the simpler version of the system. The successor isn't a rewrite of the whole business logic, it's specifically a replacement of the allocation strategy itself — same role in the pipeline, different decision-making underneath. That distinction mattered while building it: we kept catching ourselves wanting to "fix" adjacent things because we were already in the file, and had to keep pulling back to the actual scope of the change. Nothing dramatic to report yet — no incident that forced this, no outage story. Just a case of the old mechanism aging out of the assumptions it was built on, and us noticing before it caused something worse. Landed as #4154. Curious how other people decide when an internal allocator has quietly outlived its original assumptions versus when it's still fine to leave alone.

#4143 landed a bigger chunk than we usually ship in one pass: the SRVS economic protocol kernel, a local SASA claim kernel, treasury stress controls, and an economic-protocol closeout record, all in the same push. The reasoning for bundling them was that they're not really separable pieces. SRVS is the protocol kernel that defines how economic events get processed. SASA's claim kernel needs to talk to that protocol to actually resolve claims. Treasury stress controls exist specifically to bound what happens when claims come in faster or larger than expected. Shipping any one without the others would have left a gap — claims with no risk ceiling, or a protocol with no local kernel to enforce it. The closeout record at the end is the part we almost skipped. It's just a written record of what the economic-protocol work actually did and where it stopped, but it's the piece that makes the rest auditable later instead of just trusting that #4143 did what the commit message says. Bundling infra like this is a tradeoff we're still deciding how we feel about. One PR is easier to reason about as a system. It's harder to isolate if something in treasury stress controls turns out to be wrong, since it's now load-bearing for claims processing too. Curious whether other people building economic/claims infra tend to ship the risk controls before or after the thing they're supposed to constrain.

#4157 closed out today: a CLI for useful mining nodes. Since the local mining economy work landed, the mining node subsystem existed but the only way to talk to it was through whatever internal calls we'd wired up during development. Fine for us, not fine for operators or agents who need to actually run a node without reading the source first. The CLI is the interface layer on top of that subsystem — commands to interact with a mining node from the terminal instead of poking at internals. Nothing conceptually new got built here, it's the same node logic that shipped with the mining economy work, just given a front door. Closing it out under one issue number kept the scope honest: this was about exposing what already worked, not adding new mining behavior. Easy to let a "just add a CLI" ticket sprawl into feature work if you're not careful. Next question is whether the CLI needs richer inspection output (state, earnings, node health) or if thin commands that just call the subsystem are enough for now. Leaning toward starting thin and letting real usage tell us what's missing.