zig-abstractions

# Zig Abstractions ## Operating Mode Use this skill to keep Zig APIs concrete until abstraction earns its cost. First verify the project version: ```bash zig version test -f build.zig.zon && sed -n '1,120p' build.zig.zon ``` Default to the repo-pinned Zig version. As of 2026-05-13, upstream stable is Zig `0.16.0`, but Orca-style repos may still target `0.15.2`; mark 0.16-only patterns as migration notes. ## Decision Rule Prefer concrete structs and functions first. Add an abstraction only when at least one is true: - There are two or more real call sites with the same stable contract. - Tests need to substitute behavior at a boundary that cannot be tested cleanly otherwise. - The abstraction removes meaningful duplication without hiding allocation, errors, ownership, or control flow. - The public API is more stable with a small explicit contract than with leaking internal implementation types. If a proposed abstraction mainly creates names like `Manager`, `Context`, `Value`, `Data`, or `utils`, simplify it. ## Comptime Generics - Use `comptime T: type` for type-parametric algorithms and type factories. - Keep constraints close to use sites with `@hasDecl`, `@hasField`, `@typeInfo`, and clear `@compileError` messages. - Prefer a small generic helper over a trait framework when the helper has one job. - Avoid exporting broad comptime-heavy APIs unless compile-time configuration is the product value. - Test at least two concrete type instantiations when behavior depend...