David Arnold

Ok, convincing. Let's be super specific then. And decently motivate things (though not from first principles, people better read documentation about first principles than a policy).

Small semantic improvement: > to support SRE. "to become _operable_". It's not about SRE, _actually_.

The things that are a bit github specific are the cache interactions - Save during Discovery https://github.com/divnix/std-action/blob/main/discover%2Faction.yml#L46-L51 - Retrieval during Run: https://github.com/divnix/std-action/blob/main/run%2Faction.yaml#L55-L61 From a quick review of the code, the...

https://blog.cachix.org/posts/2022-12-19-zstd-compression/

> Is this something you have observed in practice? Yes, this had reportedly happend in some scenarios. Although, now, on second thought, I doubt it since the discovery is the...

> redundancies I assume you mean #12, right? We'll have to assess cost impacts a bit ahead of time.

> making sure low-level stuff is built A often used pattern in standard is: ``` ./automation/toolchain.nix ./foo/packages.nix ``` It's actually trivial via the top level composition of Block Types in...

- we know `build` action is a no-op - we can leverage this at the very least to collaps `build` type matrices into a single command & control job per...

 The problem is the red arrow.

> not constantly breaking things One aspect to balance though, we should be free of known technical debt, before we stabilize the interface. The practical question will be if #2,...