@cubis/foundry 0.3.67 → 0.3.68

package/workflows/skills/api-patterns/SKILL.md

@@ -1,80 +1,66 @@
 ---
 name: api-patterns
-description: API design principles and decision-making. REST vs GraphQL vs tRPC selection, response formats, versioning, pagination.
-allowed-tools: Read, Write, Edit, Glob, Grep
+description: "Use when choosing between REST, GraphQL, and type-safe RPC patterns, or when standardizing response envelopes, versioning, pagination, auth shape, and API protection strategy."
+license: MIT
+metadata:
+  author: cubis-foundry
+  version: "3.0"
+compatibility: Claude Code, Codex, GitHub Copilot
 ---
 
 # API Patterns
 
-> API design principles and decision-making for 2025.
-> **Learn to THINK, not copy fixed patterns.**
+## Purpose
 
-## 🎯 Selective Reading Rule
+Use when choosing between REST, GraphQL, and type-safe RPC patterns, or when standardizing response envelopes, versioning, pagination, auth shape, and API protection strategy.
 
-**Read ONLY files relevant to the request!** Check the content map, find what you need.
+## When to Use
 
----
+- Choosing REST vs GraphQL vs type-safe RPC for a new surface.
+- Standardizing response envelopes, pagination, filtering, and error format.
+- Planning auth, rate limits, and evolution strategy for an API surface.
+- Reviewing whether an API design matches client and organizational constraints.
 
-## 📑 Content Map
-
-| File | Description | When to Read |
-|------|-------------|--------------|
-| `references/api-style.md` | REST vs GraphQL vs tRPC decision tree | Choosing API type |
-| `references/rest.md` | Resource naming, HTTP methods, status codes | Designing REST API |
-| `references/response.md` | Envelope pattern, error format, pagination | Response structure |
-| `references/graphql.md` | Schema design, when to use, security | Considering GraphQL |
-| `references/trpc.md` | TypeScript monorepo, type safety | TS fullstack projects |
-| `references/versioning.md` | URI/Header/Query versioning | API evolution planning |
-| `references/auth.md` | JWT, OAuth, Passkey, API Keys | Auth pattern selection |
-| `references/rate-limiting.md` | Token bucket, sliding window | API protection |
-| `references/documentation.md` | OpenAPI/Swagger best practices | Documentation |
-| `references/security-testing.md` | OWASP API Top 10, auth/authz testing | Security audits |
+## Instructions
 
----
+1. Clarify clients, latency needs, ownership model, and compatibility constraints.
+2. Choose transport shape based on product and team context, not habit.
+3. Standardize response and error patterns before implementation fans out.
+4. Define pagination, filtering, and auth strategy explicitly.
+5. Make versioning and operational protections part of the design, not an afterthought.
 
-## 🔗 Related Skills
+### Baseline standards
 
-| Need | Skill |
-|------|-------|
-| API implementation | `@[skills/backend-development]` |
-| Data structure | `@[skills/database-design]` |
-| Security details | `@[skills/security-hardening]` |
+- Use one consistent response and error vocabulary per API surface.
+- Prefer explicit evolution strategy over “we will figure it out later.”
+- Match the pattern to client needs and team capability.
+- Treat rate limiting and abuse controls as part of API design.
+- Keep auth semantics visible and documented.
 
----
+### Constraints
 
-## ✅ Decision Checklist
+- Avoid defaulting to REST, GraphQL, or RPC by trend alone.
+- Avoid inconsistent envelopes across related endpoints.
+- Avoid mixing public and internal conventions into one confused surface.
+- Avoid delaying versioning and pagination decisions until after rollout.
 
-Before designing an API:
+## Output Format
 
-- [ ] **Asked user about API consumers?**
-- [ ] **Chosen API style for THIS context?** (REST/GraphQL/tRPC)
-- [ ] **Defined consistent response format?**
-- [ ] **Planned versioning strategy?**
-- [ ] **Considered authentication needs?**
-- [ ] **Planned rate limiting?**
-- [ ] **Documentation approach defined?**
+Provide implementation guidance, code examples, and configuration as appropriate to the task.
 
----
+## References
 
-## ❌ Anti-Patterns
+Load on demand. Do not preload all reference files.
 
-**DON'T:**
-- Default to REST for everything
-- Use verbs in REST endpoints (/getUsers)
-- Return inconsistent response formats
-- Expose internal errors to clients
-- Skip rate limiting
+| File | Load when |
+| --- | --- |
+| `references/pattern-selection-checklist.md` | You need a sharper decision aid for REST vs GraphQL vs RPC, response envelopes, auth shape, and versioning tradeoffs. |
 
-**DO:**
-- Choose API style based on context
-- Ask about client requirements
-- Document thoroughly
-- Use appropriate status codes
+## Scripts
 
----
+No helper scripts are required for this skill right now. Keep execution in `SKILL.md` and `references/` unless repeated automation becomes necessary.
 
-## Script
+## Examples
 
-| Script | Purpose | Command |
-|--------|---------|---------|
-| `scripts/api_validator.py` | API endpoint validation | `python scripts/api_validator.py <project_path>` |
+- "Help me with api patterns best practices in this project"
+- "Review my api patterns implementation for issues"

package/workflows/skills/api-patterns/references/pattern-selection-checklist.md

@@ -0,0 +1,21 @@
+# Pattern Selection Checklist
+
+Load this when API pattern choice is the core decision.
+
+## Pick the shape from the problem
+
+- REST when broad compatibility, cache semantics, and public familiarity matter.
+- GraphQL when clients need flexible graph reads and schema-first evolution is justified.
+- Type-safe RPC when clients and server share a typed codebase and internal velocity is the main constraint.
+
+## Standardize the surface
+
+- Keep one response and error vocabulary per API family.
+- Make auth, rate limit, and retry semantics explicit.
+- Decide pagination and filtering style before implementation spreads.
+
+## Evolution
+
+- Write versioning policy up front.
+- Separate internal transport shortcuts from public contract guarantees.
+- Keep operational protections part of the API decision, not separate work.

package/workflows/skills/architecture-designer/SKILL.md

@@ -1,77 +1,66 @@
 ---
-name: "architecture-designer"
-description: "Use when designing new system architecture, reviewing existing designs, or making architectural decisions. Invoke for system design, architecture review, design patterns, ADRs, scalability planning."
+name: architecture-designer
+description: "Use when designing or reviewing system architecture, interface boundaries, tradeoffs, ADRs, scalability posture, and the smallest durable target shape for a product or platform."
+license: MIT
+metadata:
+  author: cubis-foundry
+  version: "3.0"
+compatibility: Claude Code, Codex, GitHub Copilot
 ---
 
-
 # Architecture Designer
 
-## Overview
-
-Senior software architect specializing in system design, design patterns, and architectural decision-making.
-
-## Role Definition
+## Purpose
 
-You are a principal architect with 15+ years of experience designing scalable systems. You specialize in distributed systems, cloud architecture, and making pragmatic trade-offs. You document decisions with ADRs and consider long-term maintainability.
+Use when designing or reviewing system architecture, interface boundaries, tradeoffs, ADRs, scalability posture, and the smallest durable target shape for a product or platform.
 
-## When to Use This Skill
+## When to Use
 
-- Designing new system architecture
-- Choosing between architectural patterns
-- Reviewing existing architecture
-- Creating Architecture Decision Records (ADRs)
-- Planning for scalability
-- Evaluating technology choices
+- Designing a new system or reshaping an existing one.
+- Making boundary, ownership, integration, or deployment tradeoffs explicit.
+- Writing or reviewing architectural decisions and ADR-style reasoning.
+- Deciding how much architecture is actually justified for the product stage.
 
-## Core Workflow
+## Instructions
 
-1. **Understand requirements** - Functional, non-functional, constraints
-2. **Identify patterns** - Match requirements to architectural patterns
-3. **Design** - Create architecture with trade-offs documented
-4. **Document** - Write ADRs for key decisions
-5. **Review** - Validate with stakeholders
+1. Clarify product goals, constraints, and failure tolerance.
+2. Identify the few architectural decisions that materially change risk or cost.
+3. Compare viable shapes and document tradeoffs, not just the favorite option.
+4. Choose the smallest architecture that safely supports the current target.
+5. Hand off explicit boundaries, risks, and follow-up validation points.
 
-## Available Steering Files
+### Baseline standards
 
-Load detailed guidance on-demand:
+- Start from product outcomes, not architecture fashion.
+- Make ownership and interfaces explicit.
+- Consider security, observability, and operations as part of the design.
+- Prefer reversible decisions when uncertainty is high.
+- Keep ADR-style reasoning concrete and testable.
 
-| Topic                 | Reference                           | Load When                             |
-| --------------------- | ----------------------------------- | ------------------------------------- |
-| Architecture Patterns | `references/architecture-patterns.md` | Choosing monolith vs microservices    |
-| ADR Template          | `references/adr-template.md`          | Documenting decisions                 |
-| System Design         | `references/system-design.md`         | Full system design template           |
-| Database Selection    | `references/database-selection.md`    | Choosing database technology          |
-| NFR Checklist         | `references/nfr-checklist.md`         | Gathering non-functional requirements |
+### Constraints
 
-## Constraints
+- Avoid over-engineering for hypothetical future scale.
+- Avoid treating diagrams as a substitute for boundary decisions.
+- Avoid choosing technology before identifying the real constraints.
+- Avoid hiding unresolved risk behind vague architectural language.
 
-### MUST DO
+## Output Format
 
-- Document all significant decisions with ADRs
-- Consider non-functional requirements explicitly
-- Evaluate trade-offs, not just benefits
-- Plan for failure modes
-- Consider operational complexity
-- Review with stakeholders before finalizing
+Provide implementation guidance, code examples, and configuration as appropriate to the task.
 
-### MUST NOT DO
+## References
 
-- Over-engineer for hypothetical scale
-- Choose technology without evaluating alternatives
-- Ignore operational costs
-- Design without understanding requirements
-- Skip security considerations
+Load on demand. Do not preload all reference files.
 
-## Output Templates
+| File | Load when |
+| --- | --- |
+| `references/system-tradeoff-checklist.md` | You need a sharper system-design checklist for boundaries, ADRs, integration shape, resilience, and rollout risk. |
 
-When designing architecture, provide:
+## Scripts
 
-1. Requirements summary (functional + non-functional)
-2. High-level architecture diagram
-3. Key decisions with trade-offs (ADR format)
-4. Technology recommendations with rationale
-5. Risks and mitigation strategies
+No helper scripts are required for this skill right now. Keep execution in `SKILL.md` and `references/` unless repeated automation becomes necessary.
 
-## Knowledge Reference
+## Examples
 
-Distributed systems, microservices, event-driven architecture, CQRS, DDD, CAP theorem, cloud platforms (AWS, GCP, Azure), containers, Kubernetes, message queues, caching, database design
+- "Help me with architecture designer best practices in this project"
+- "Review my architecture designer implementation for issues"

package/workflows/skills/architecture-designer/references/system-tradeoff-checklist.md

@@ -0,0 +1,26 @@
+# System Tradeoff Checklist
+
+Load this when architecture design needs a sharper decision frame.
+
+## Core framing
+
+- Start from product goals, scale expectations, and failure tolerance.
+- Identify which decisions are expensive to reverse and which are not.
+- Keep non-goals explicit so the system is not over-designed.
+
+## Boundaries
+
+- Define ownership, interfaces, and data movement clearly.
+- Decide what belongs in-process, behind a service boundary, or in async flow.
+- Keep observability, security, and operations inside the architecture discussion.
+
+## Decision quality
+
+- Compare a small number of viable shapes instead of arguing from a favorite stack.
+- Document tradeoffs in concrete cost, risk, and team-operability terms.
+- Prefer the smallest durable architecture that meets the current target.
+
+## Handoff
+
+- Leave explicit constraints, open risks, and validation checkpoints.
+- Make rollout and rollback posture visible when architecture changes production behavior.

package/workflows/skills/auth-architect/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: auth-architect
+description: "Use when designing or reviewing authentication and authorization for backend systems, including sessions, tokens, OAuth or OIDC, RBAC or ABAC, passkeys, service-to-service auth, and policy enforcement boundaries."
+license: MIT
+metadata:
+  author: cubis-foundry
+  version: "3.0"
+compatibility: Claude Code, Codex, GitHub Copilot, Gemini CLI
+---
+
+# Auth Architect
+
+## Purpose
+
+Use when designing or reviewing authentication and authorization for backend systems, including sessions, tokens, OAuth or OIDC, RBAC or ABAC, passkeys, service-to-service auth, and policy enforcement boundaries.
+
+## When to Use
+
+- Designing or reviewing login, session, token, and policy architecture.
+- Choosing between session-based auth, JWTs, OAuth or OIDC, passkeys, or service credentials.
+- Defining RBAC, ABAC, tenant isolation, or field-level authorization boundaries.
+- Hardening auth flows in REST, GraphQL, NestJS, FastAPI, Node, or managed-platform backends.
+
+## Instructions
+
+1. Clarify actors, trust boundaries, clients, and the assets each flow protects.
+2. Choose the credential and session model that fits the product and operational constraints.
+3. Separate authentication, authorization, and audit responsibilities instead of blending them together.
+4. Make token, session, policy, and recovery behavior explicit at service boundaries.
+5. Verify revocation, rotation, least privilege, and failure behavior before shipping.
+
+### Baseline standards
+
+- Prefer server-owned sessions when revocation simplicity matters more than statelessness.
+- Treat OAuth or OIDC as delegated identity plumbing, not a substitute for local authorization rules.
+- Keep authorization policy close to the resource or resolver that owns the decision.
+- Design service-to-service identity and secret rotation as first-class operational concerns.
+- Make account recovery, MFA, and passkey fallback behavior explicit.
+
+### Constraints
+
+- Avoid mixing authentication and authorization into one vague middleware concept.
+- Avoid issuing long-lived bearer tokens with no rotation or revocation story.
+- Avoid duplicating policy rules across clients, gateways, and services with no clear owner.
+- Avoid treating passkeys, sessions, or JWTs as universal defaults independent of product constraints.
+
+## Output Format
+
+Provide implementation guidance, code examples, and configuration as appropriate to the task.
+
+## References
+
+Load on demand. Do not preload all reference files.
+
+| File                                           | Load when                                                                                                                                            |
+| ---------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `references/session-token-policy-checklist.md` | You need a deeper checklist for session vs token choice, OAuth or OIDC, passkeys, tenant isolation, service auth, and policy enforcement boundaries. |
+
+## Scripts
+
+No helper scripts are required for this skill right now. Keep execution in `SKILL.md` and `references/` unless repeated automation becomes necessary.
+
+## Examples
+
+- "Help me with auth architect best practices in this project"
+- "Review my auth architect implementation for issues"

package/workflows/skills/auth-architect/references/session-token-policy-checklist.md

@@ -0,0 +1,45 @@
+# Session, Token, And Policy Checklist
+
+Load this when auth work needs more depth than the root skill.
+
+## Boundary and threat framing
+
+- List actors, clients, trust boundaries, and the assets each flow protects.
+- Decide where authentication ends and authorization begins.
+- Make audit and incident-response requirements explicit for privileged flows.
+
+## Session vs token choice
+
+- Prefer server-owned sessions when revocation, rotation simplicity, or browser ergonomics matter most.
+- Prefer short-lived access tokens plus refresh controls only when stateless distribution or delegated clients justify the complexity.
+- Avoid bearer-token sprawl across browser, mobile, and service clients without separate threat assumptions.
+
+## OAuth, OIDC, and delegated identity
+
+- Use OAuth for delegated access and OIDC for identity; do not collapse them conceptually.
+- Scope tokens narrowly and document token audience, issuer, and rotation behavior.
+- Keep provider callbacks, consent, and account-linking behavior explicit.
+
+## Authorization and policy
+
+- Keep RBAC, ABAC, tenant boundaries, and field-level policy checks close to the owning service or resolver.
+- Avoid duplicating policy logic in frontend code as the only enforcement layer.
+- Make authorization failure semantics predictable and observable.
+
+## Passkeys, MFA, and recovery
+
+- Treat passkeys as a primary sign-in option where product fit exists, not just a marketing add-on.
+- Make MFA enrollment, recovery, device loss, and fallback channels explicit.
+- Keep recovery flows at least as hardened as the primary sign-in flow.
+
+## Service-to-service auth
+
+- Use dedicated service identities, narrow scopes, and explicit secret or key rotation.
+- Keep human auth, machine auth, and webhook verification separate.
+- Make internal trust assumptions visible instead of implied by network location.
+
+## Operational safety
+
+- Log auth decisions without leaking secrets or raw tokens.
+- Verify revocation, logout, secret rotation, and key rollover behavior.
+- Recheck caching, GraphQL field policy, and background-job privilege boundaries before finishing.

package/workflows/skills/c-pro/SKILL.md

@@ -0,0 +1,102 @@
+---
+name: c-pro
+description: "Use for modern C23-era systems and embedded engineering with memory safety discipline, build reproducibility, and low-level debugging awareness."
+license: MIT
+metadata:
+  author: cubis-foundry
+  version: "2.0"
+compatibility: Claude Code, Codex, GitHub Copilot
+---
+
+# C Pro
+
+## Purpose
+
+Use for modern C23-era systems and embedded engineering with memory safety discipline, build reproducibility, and low-level debugging awareness.
+
+## When to Use
+
+- Writing or refactoring C systems, embedded, or low-level runtime code.
+- Tightening memory ownership, ABI boundaries, and build hygiene.
+- Debugging undefined behavior, portability, or toolchain-sensitive code.
+
+## Instructions
+
+1. Confirm platform, compiler, and ABI constraints before writing code.
+2. Make ownership, lifetime, and error handling explicit at every interface.
+3. Prefer simple control flow over macro-heavy indirection.
+4. Validate assumptions with warnings, sanitizers, or focused repros.
+5. Keep portability and deterministic builds in view throughout the change.
+
+### Baseline standards
+
+- Compile with `-Wall -Wextra -Werror` (or equivalent) in CI. Treat warnings as defects.
+- Enable sanitizers (`-fsanitize=address,undefined`) in debug and test builds.
+- Use `static` for file-scoped functions and variables. Minimize public symbols.
+- Declare `const` by default. Mutable state must be justified.
+- Keep headers self-contained: every `.h` must compile on its own.
+- Prefer fixed-width integers (`uint32_t`, `int64_t`) over bare `int` for data structures and protocols.
+
+### Memory safety discipline
+
+- Every allocation must have a single, clear owner and a documented free path.
+- Prefer stack allocation and arena allocators over scattered `malloc`/`free`.
+- Initialize all variables at declaration. Never rely on implicit zero-initialization.
+- Bounds-check array and buffer access at trust boundaries (user input, file I/O, network).
+- Use `memset`/`memcpy` with explicit size — never assume buffer sizes from context.
+- After `free`, set pointer to `NULL` to catch use-after-free during debugging.
+
+### Build reproducibility
+
+- Pin compiler version and flags in the build system. Builds must produce identical output across machines.
+- Prefer CMake, Meson, or a Makefile with explicit dependency tracking over ad-hoc scripts.
+- Declare all external dependencies with exact versions. Avoid system-installed headers for portable projects.
+- Run CI on at least two compilers (GCC + Clang) and two platforms where applicable.
+- Enable Link-Time Optimization (LTO) for release builds but verify correctness with sanitizers first.
+
+### Debugging and diagnostics
+
+- Compile debug builds with `-g -O0` for accurate stack traces and variable inspection.
+- Use AddressSanitizer for memory errors, UndefinedBehaviorSanitizer for UB, and ThreadSanitizer for data races.
+- Add `assert()` for invariants that must never be violated — strip in release builds.
+- Prefer structured error codes with context over errno alone. Return error structs from functions that can fail.
+- When debugging crashes: reproduce with sanitizers first, then gdb/lldb with watchpoints.
+
+### Performance
+
+- Profile with `perf`, `Instruments`, or `gprof` before micro-optimizing. Measure, don't guess.
+- Prefer cache-friendly data layouts (arrays of structs vs. structs of arrays depending on access pattern).
+- Minimize heap allocations in hot paths. Pre-allocate where the upper bound is known.
+- Avoid premature inline — let the compiler decide, then verify with benchmarks.
+
+### Constraints
+
+- Avoid `void*` casts without size tracking — type-unsafe and bug-prone.
+- Avoid variable-length arrays (VLAs) in production code — stack overflow risk.
+- Avoid macro-heavy logic that hides control flow (`goto` cleanup patterns are acceptable when simple).
+- Avoid ignoring compiler warnings — every warning is a potential bug.
+- Avoid global mutable state without synchronization.
+- Avoid relying on implementation-defined or undefined behavior for correctness.
+
+## Output Format
+
+Provide implementation guidance, code examples, and configuration as appropriate to the task.
+
+## References
+
+| File                                              | Load when                                                                                                      |
+| ------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- |
+| `references/memory-safety-and-build-checklist.md` | Memory ownership patterns, sanitizer configuration, build system hygiene, or ABI boundary review is needed.    |
+| `references/common-ub-and-portability.md`         | Undefined behavior patterns, implementation-defined traps, or cross-platform portability decisions are needed. |
+| `references/build-systems-and-toolchains.md`      | CMake/Meson setup, cross-compilation, CI matrix configuration, or toolchain pinning is needed.                 |
+| `references/posix-and-platform-apis.md`           | POSIX system calls, file I/O, signal handling, or platform abstraction layer design is needed.                 |
+| `references/debugging-with-sanitizers.md`         | AddressSanitizer, UBSan, ThreadSanitizer configuration, or crash diagnosis workflow is needed.                 |
+
+## Scripts
+
+No helper scripts are required for this skill right now. Keep execution in `SKILL.md` and `references/` unless repeated automation becomes necessary.
+
+## Examples
+
+- "Help me with c pro best practices in this project"
+- "Review my c pro implementation for issues"

package/workflows/skills/c-pro/references/build-systems-and-toolchains.md

@@ -0,0 +1,148 @@
+# Build Systems and Toolchains
+
+## CMake Modern Practices
+
+```cmake
+# CMakeLists.txt — modern CMake (3.21+)
+cmake_minimum_required(VERSION 3.21)
+project(mylib VERSION 1.0.0 LANGUAGES C)
+
+# Set C standard project-wide
+set(CMAKE_C_STANDARD 23)
+set(CMAKE_C_STANDARD_REQUIRED ON)
+set(CMAKE_C_EXTENSIONS OFF)  # disable GNU extensions for portability
+
+# Library target
+add_library(mylib
+    src/core.c
+    src/parser.c
+    src/util.c
+)
+
+target_include_directories(mylib
+    PUBLIC  $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/include>
+    PRIVATE src/
+)
+
+# Compiler warnings as errors
+target_compile_options(mylib PRIVATE
+    $<$<C_COMPILER_ID:GNU,Clang>:-Wall -Wextra -Wpedantic -Werror>
+    $<$<C_COMPILER_ID:MSVC>:/W4 /WX>
+)
+
+# Sanitizers for debug builds
+if(CMAKE_BUILD_TYPE STREQUAL "Debug")
+    target_compile_options(mylib PRIVATE -fsanitize=address,undefined -fno-omit-frame-pointer)
+    target_link_options(mylib PRIVATE -fsanitize=address,undefined)
+endif()
+
+# Tests
+enable_testing()
+add_executable(test_core tests/test_core.c)
+target_link_libraries(test_core PRIVATE mylib)
+add_test(NAME test_core COMMAND test_core)
+
+# Install rules
+install(TARGETS mylib EXPORT mylibTargets)
+install(DIRECTORY include/ DESTINATION include)
+```
+
+## Meson Build System
+
+```meson
+# meson.build — lightweight alternative to CMake
+project('mylib', 'c',
+    version: '1.0.0',
+    default_options: ['c_std=c23', 'warning_level=3', 'werror=true']
+)
+
+src = files('src/core.c', 'src/parser.c', 'src/util.c')
+inc = include_directories('include')
+
+mylib = library('mylib', src, include_directories: inc)
+mylib_dep = declare_dependency(link_with: mylib, include_directories: inc)
+
+# Tests
+test_core = executable('test_core', 'tests/test_core.c', dependencies: mylib_dep)
+test('core', test_core)
+```
+
+## Cross-Compilation
+
+```cmake
+# toolchain-arm.cmake — cross-compile for ARM
+set(CMAKE_SYSTEM_NAME Linux)
+set(CMAKE_SYSTEM_PROCESSOR arm)
+
+set(CMAKE_C_COMPILER arm-linux-gnueabihf-gcc)
+set(CMAKE_CXX_COMPILER arm-linux-gnueabihf-g++)
+
+set(CMAKE_FIND_ROOT_PATH /usr/arm-linux-gnueabihf)
+set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
+set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
+set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
+```
+
+```bash
+# Build with cross-compilation toolchain
+cmake -B build-arm -DCMAKE_TOOLCHAIN_FILE=toolchain-arm.cmake
+cmake --build build-arm
+```
+
+## CI Matrix Configuration
+
+```yaml
+# GitHub Actions — multi-compiler, multi-platform
+jobs:
+  build:
+    strategy:
+      matrix:
+        os: [ubuntu-latest, macos-latest]
+        compiler: [gcc-13, clang-17]
+    runs-on: ${{ matrix.os }}
+    steps:
+      - uses: actions/checkout@v4
+      - name: Configure
+        run: |
+          cmake -B build \
+            -DCMAKE_C_COMPILER=${{ matrix.compiler }} \
+            -DCMAKE_BUILD_TYPE=Debug
+      - name: Build
+        run: cmake --build build
+      - name: Test
+        run: ctest --test-dir build --output-on-failure
+      - name: Sanitizer build
+        run: |
+          cmake -B build-san \
+            -DCMAKE_C_COMPILER=${{ matrix.compiler }} \
+            -DCMAKE_BUILD_TYPE=Debug \
+            -DENABLE_SANITIZERS=ON
+          cmake --build build-san
+          ctest --test-dir build-san
+```
+
+## Dependency Management
+
+```cmake
+# FetchContent for pinned dependencies
+include(FetchContent)
+
+FetchContent_Declare(cjson
+    GIT_REPOSITORY https://github.com/DaveGamble/cJSON.git
+    GIT_TAG        v1.7.17  # pin exact version
+)
+FetchContent_MakeAvailable(cjson)
+target_link_libraries(mylib PRIVATE cjson)
+
+# vcpkg for larger dependency sets
+# Install: cmake -B build -DCMAKE_TOOLCHAIN_FILE=$VCPKG_ROOT/scripts/buildsystems/vcpkg.cmake
+```
+
+## Reproducible Builds Checklist
+
+1. Pin compiler version in CI (e.g., `gcc-13`, not `gcc`).
+2. Pin all external dependencies to exact versions or commit hashes.
+3. Use deterministic build flags (`-frandom-seed=`, `-ffile-prefix-map=`).
+4. Commit `CMakePresets.json` or equivalent for consistent local/CI builds.
+5. Disable compiler plugins and extensions that vary by environment.
+6. Verify with two independent builds and `diffoscope` or binary hash comparison.