From cc10f82204074a4738d2eddb2270983e752fab60 Mon Sep 17 00:00:00 2001 From: "Jonathan D.A. Jewell" <6759885+hyperpolymath@users.noreply.github.com> Date: Fri, 31 Jul 2026 09:23:28 +0100 Subject: [PATCH 1/4] docs: add ZIGZAG-TESTING.md methodology standard --- ZIGZAG-TESTING.md | 37 +++++++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) create mode 100755 ZIGZAG-TESTING.md diff --git a/ZIGZAG-TESTING.md b/ZIGZAG-TESTING.md new file mode 100755 index 000000000..ccb585735 --- /dev/null +++ b/ZIGZAG-TESTING.md @@ -0,0 +1,37 @@ +# Zigzag Testing: Aspect-Oriented Analysis and Synthesis + +## 1. Introduction +Zigzag Testing is an advanced testing methodology designed to perform aspect-oriented analysis and synthesis by charting a collection of meandering routes through a system's design. + +Unlike traditional linear integration testing (which verifies a single end-to-end happy path) or pure property-based testing (which verifies invariants on a single component), Zigzag testing deliberately crosses horizontal and vertical boundaries. It validates that cross-cutting concerns (e.g., authentication, telemetry, state persistence, failure recovery) interact correctly under chaotic, stateful traversal. + +## 2. Core Concepts + +### 2.1 Aspect-Oriented Analysis and Synthesis +Systems are composed of overlapping "aspects" (security, networking, DB logic, domain logic). Zigzag testing analyzes these aspects individually and synthesizes tests that verify their intersections. +- **Analysis**: Decompose the system into orthogonal aspects. +- **Synthesis**: Recombine these aspects into meandering operational routes that cross boundaries. + +### 2.2 Meandering Routes +A meandering route is a non-linear test execution path. Instead of `A -> B -> C`, a meandering route might trace `A -> trigger aspect X -> induce failure in B -> verify aspect Y -> C`. +- **State-Machine Traversal**: Tests are modeled as state machines where transitions represent API calls or events. +- **Random Walks**: Property-based testing engines execute random walks through the state machine. +- **Cross-Cutting Verification**: After each step, global invariants (like "no orphaned database connections" or "telemetry was emitted") are asserted. + +## 3. Implementation in the Estate +The preferred languages for implementing Zigzag Tests across the estate are **Idris2** and **Elixir**. + +### 3.1 Idris2 (Algebraic Modeling) +Idris2 is used to rigorously model the state machine and aspects using dependent types. +- **Algebras**: Define the system aspects as algebraic data types. +- **Proofs**: Use dependent types to prove that invalid states cannot be represented. +- **Code Generation**: Idris2 models can generate test sequences or API payloads that are guaranteed to be structurally valid. + +### 3.2 Elixir (Concurrency and Fault Tolerance) +Elixir (running on the BEAM) is used as the execution engine for the meandering routes. +- **PropEr / StreamData**: Use Elixir's property-based testing libraries to generate random walks through the state transitions. +- **OTP Processes**: Spawn concurrent actors to simulate meandering routes in parallel, stress-testing aspects like race conditions and distributed state. +- **Fault Injection**: Intentionally crash GenServers (aspect failure) during a route to verify self-healing (synthesis). + +## 4. Requirement (CRG Grading) +To achieve a Code Review Guidelines (CRG) Grade of **A** or **B**, core infrastructure and high-criticality services MUST implement Zigzag Testing for their critical paths. From 7ba3d467ecffd61fc5d6da4ef4e073b6a33738f7 Mon Sep 17 00:00:00 2001 From: "Jonathan D.A. Jewell" <6759885+hyperpolymath@users.noreply.github.com> Date: Fri, 31 Jul 2026 09:24:14 +0100 Subject: [PATCH 2/4] docs: require Zigzag Testing for CRG Grade B/A --- TEST-NEEDS.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/TEST-NEEDS.md b/TEST-NEEDS.md index cbf4293c9..737dfe22c 100644 --- a/TEST-NEEDS.md +++ b/TEST-NEEDS.md @@ -1,5 +1,8 @@ # TEST-NEEDS: standards +## CRG Grade: B/A (Targeting) +To achieve CRG Grades B and above, projects MUST implement **Zigzag Testing** for their critical paths, following the [ZIGZAG-TESTING.md](./ZIGZAG-TESTING.md) methodology. + ## CRG Grade: C — ACHIEVED 2026-04-04 All CRG C categories are present and passing. See breakdown below. From 9ed1acde64f4ea54d19fae0e9c0590b6947c452b Mon Sep 17 00:00:00 2001 From: "Jonathan D.A. Jewell" <6759885+hyperpolymath@users.noreply.github.com> Date: Sat, 1 Aug 2026 01:42:31 +0100 Subject: [PATCH 3/4] docs: update zigzag testing with spatial/temporal locality and dependencies --- ZIGZAG-TESTING.adoc | 49 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 49 insertions(+) create mode 100644 ZIGZAG-TESTING.adoc diff --git a/ZIGZAG-TESTING.adoc b/ZIGZAG-TESTING.adoc new file mode 100644 index 000000000..cefbc0997 --- /dev/null +++ b/ZIGZAG-TESTING.adoc @@ -0,0 +1,49 @@ += Zigzag Testing: Aspect-Oriented Analysis and Synthesis + +== 1. Introduction +Zigzag Testing is an advanced testing methodology designed to perform aspect-oriented analysis and synthesis by charting a collection of meandering routes through a system's design. + +Unlike traditional linear integration testing (which verifies a single end-to-end happy path) or pure property-based testing (which verifies invariants on a single component), Zigzag testing deliberately crosses horizontal and vertical boundaries. It validates that cross-cutting concerns (e.g., authentication, telemetry, state persistence, failure recovery) interact correctly under chaotic, stateful traversal. + +== 2. Core Concepts + +=== 2.1 Aspect-Oriented Analysis and Synthesis +Systems are composed of overlapping "aspects" (security, networking, DB logic, domain logic). Zigzag testing analyzes these aspects individually and synthesizes tests that verify their intersections. + +* **Analysis**: Decompose the system into orthogonal aspects. +* **Synthesis**: Recombine these aspects into meandering operational routes that cross boundaries. + +=== 2.2 Meandering Routes +A meandering route is a non-linear test execution path. Instead of `A -> B -> C`, a meandering route might trace `A -> trigger aspect X -> induce failure in B -> verify aspect Y -> C`. + +* **State-Machine Traversal**: Tests are modeled as state machines where transitions represent API calls or events. +* **Random Walks**: Property-based testing engines execute random walks through the state machine. +* **Cross-Cutting Verification**: After each step, global invariants (like "no orphaned database connections" or "telemetry was emitted") are asserted. + +=== 2.3 Scope, Locality, and Effects Analysis +A proper Zigzag Test must comprehensively map the inputs, outputs, and their ripple effects across the system. This requires tracking the state in the immediate locality of the place and time of the test, as well as the broader impact: + +* **Upstream and Downstream Dependencies**: Explicitly track systems or components that feed data into the aspect (upstream) and those that consume its outputs (downstream), including strict versioning of these dependencies. +* **Inputs and Outputs**: Map the full scope of things consumed (inputs) and things outputted (outputs) at each node of the meandering route. +* **Locality (Spatial & Temporal)**: Ensure the test context accounts for the immediate locality of the operation—both where it happens (spatial/network locality) and when it happens (temporal locality/timing). +* **Side-Effect Tracing**: Measure and verify any secondary effects felt by the system (e.g., side-channels, caching behavior, rate-limiting triggers) resulting from the primary inputs and outputs. + +== 3. Implementation in the Estate +The preferred languages for implementing Zigzag Tests across the estate are **Idris2** and **Elixir**. Additionally, reference aspects can be seen implemented natively in **Rust** (e.g., in the `patch-bridge` repository). + +=== 3.1 Idris2 (Algebraic Modeling) +Idris2 is used to rigorously model the state machine and aspects using dependent types. + +* **Algebras**: Define the system aspects as algebraic data types. +* **Proofs**: Use dependent types to prove that invalid states cannot be represented. +* **Code Generation**: Idris2 models can generate test sequences or API payloads that are guaranteed to be structurally valid. + +=== 3.2 Elixir (Concurrency and Fault Tolerance) +Elixir (running on the BEAM) is used as the execution engine for the meandering routes. + +* **PropEr / StreamData**: Use Elixir's property-based testing libraries to generate random walks through the state transitions. +* **OTP Processes**: Spawn concurrent actors to simulate meandering routes in parallel, stress-testing aspects like race conditions and distributed state. +* **Fault Injection**: Intentionally crash GenServers (aspect failure) during a route to verify self-healing (synthesis). + +== 4. Requirement (CRG Grading) +To achieve a Code Review Guidelines (CRG) Grade of **A** or **B**, core infrastructure and high-criticality services MUST implement Zigzag Testing for their critical paths. From be4ebe4facf7f9f3feac997b759532a735c7eb11 Mon Sep 17 00:00:00 2001 From: "Jonathan D.A. Jewell" <6759885+hyperpolymath@users.noreply.github.com> Date: Thu, 13 Aug 2026 03:53:07 +0100 Subject: [PATCH 4/4] fix(ci): update reusable workflow SHAs to @7fdc2705df74b4e352d2a1cde3e87a5923fdf329 Part of estate-wide standards#426 remediation - Batch 11 SHA update. Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe --- .claude/worktrees/a2ml-design | 1 + .claude/worktrees/nix-references-clause | 1 + .github/workflows/changelog-reusable.yml | 2 +- .github/workflows/deno-ci-reusable.yml | 2 +- .github/workflows/elixir-ci-reusable.yml | 6 +- .github/workflows/main-estate-audit.yml | 91 ++++++++++++++++++++++++ .github/workflows/mirror.yml | 2 +- .github/workflows/rust-ci-reusable.yml | 8 +-- 8 files changed, 103 insertions(+), 10 deletions(-) create mode 160000 .claude/worktrees/a2ml-design create mode 160000 .claude/worktrees/nix-references-clause create mode 100755 .github/workflows/main-estate-audit.yml diff --git a/.claude/worktrees/a2ml-design b/.claude/worktrees/a2ml-design new file mode 160000 index 000000000..3a8745afe --- /dev/null +++ b/.claude/worktrees/a2ml-design @@ -0,0 +1 @@ +Subproject commit 3a8745afe62032d9327e74e662c717d4d4b6f800 diff --git a/.claude/worktrees/nix-references-clause b/.claude/worktrees/nix-references-clause new file mode 160000 index 000000000..eac2f52bc --- /dev/null +++ b/.claude/worktrees/nix-references-clause @@ -0,0 +1 @@ +Subproject commit eac2f52bcd9ff1e7d10c2365e316c80a7b340e7a diff --git a/.github/workflows/changelog-reusable.yml b/.github/workflows/changelog-reusable.yml index 98b456771..e712d584a 100644 --- a/.github/workflows/changelog-reusable.yml +++ b/.github/workflows/changelog-reusable.yml @@ -10,7 +10,7 @@ # Caller example (auto-update CHANGELOG.md on every push to main): # jobs: # changelog: -# uses: hyperpolymath/standards/.github/workflows/changelog-reusable.yml@d135b05bfc647d0c0fbfedc7e80f37ea50f49236 +# uses: hyperpolymath/standards/.github/workflows/changelog-reusable.yml@7fdc2705df74b4e352d2a1cde3e87a5923fdf329 # permissions: # contents: write # pull-requests: write diff --git a/.github/workflows/deno-ci-reusable.yml b/.github/workflows/deno-ci-reusable.yml index 7232051d0..c10906596 100644 --- a/.github/workflows/deno-ci-reusable.yml +++ b/.github/workflows/deno-ci-reusable.yml @@ -23,7 +23,7 @@ # # jobs: # deno-ci: -# uses: hyperpolymath/standards/.github/workflows/deno-ci-reusable.yml@d135b05bfc647d0c0fbfedc7e80f37ea50f49236 +# uses: hyperpolymath/standards/.github/workflows/deno-ci-reusable.yml@7fdc2705df74b4e352d2a1cde3e87a5923fdf329 name: Deno CI (reusable) diff --git a/.github/workflows/elixir-ci-reusable.yml b/.github/workflows/elixir-ci-reusable.yml index 23d6a76b0..73fa649da 100644 --- a/.github/workflows/elixir-ci-reusable.yml +++ b/.github/workflows/elixir-ci-reusable.yml @@ -33,13 +33,13 @@ # # jobs: # elixir-ci: -# uses: hyperpolymath/standards/.github/workflows/elixir-ci-reusable.yml@d135b05bfc647d0c0fbfedc7e80f37ea50f49236 +# uses: hyperpolymath/standards/.github/workflows/elixir-ci-reusable.yml@7fdc2705df74b4e352d2a1cde3e87a5923fdf329 # # With dialyzer + customised versions: # # jobs: # elixir-ci: -# uses: hyperpolymath/standards/.github/workflows/elixir-ci-reusable.yml@d135b05bfc647d0c0fbfedc7e80f37ea50f49236 +# uses: hyperpolymath/standards/.github/workflows/elixir-ci-reusable.yml@7fdc2705df74b4e352d2a1cde3e87a5923fdf329 # with: # elixir-version: "1.18" # enable_dialyzer: true @@ -49,7 +49,7 @@ # # jobs: # elixir-ci: -# uses: hyperpolymath/standards/.github/workflows/elixir-ci-reusable.yml@d135b05bfc647d0c0fbfedc7e80f37ea50f49236 +# uses: hyperpolymath/standards/.github/workflows/elixir-ci-reusable.yml@7fdc2705df74b4e352d2a1cde3e87a5923fdf329 # with: # working_directory: server diff --git a/.github/workflows/main-estate-audit.yml b/.github/workflows/main-estate-audit.yml new file mode 100755 index 000000000..b602e975a --- /dev/null +++ b/.github/workflows/main-estate-audit.yml @@ -0,0 +1,91 @@ +name: Central Estate CI/CD Audit + +on: + push: + branches: [ "main" ] + pull_request: + branches: [ "main" ] + +jobs: + estate-audit: + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v4 + + - name: Required Files Gate + uses: hyperpolymath/cicd-suite/actions/required-files-check@main + + - name: Code Hygiene Gate + uses: hyperpolymath/cicd-suite/actions/code-hygiene-check@main + + - name: Manifest Validation Gate + uses: hyperpolymath/cicd-suite/actions/manifest-check@main + + - name: Idris2 ABI Purity Gate + uses: hyperpolymath/cicd-suite/actions/idris2-abi-check@main + + - name: Zig Hexadeca API Gate + uses: hyperpolymath/cicd-suite/actions/zig-hexadeca-check@main + + - name: Contractile Validation Gate + uses: hyperpolymath/cicd-suite/actions/contractile-validation-check@main + + - name: Recipes Set Validation Gate + uses: hyperpolymath/cicd-suite/actions/recipes-set-check@main + + - name: Affirmation Document Gate + uses: hyperpolymath/cicd-suite/actions/affirmation-check@main + + - name: Academic Referencing Gate + uses: hyperpolymath/cicd-suite/actions/referencing-check@main + + - name: Semantic Audit Gate + uses: hyperpolymath/cicd-suite/actions/semantic-audit-check@main + + - name: SPDX License Gate + uses: hyperpolymath/cicd-suite/actions/spdx-license-check@main + + - name: Proof Runner Gate + uses: hyperpolymath/cicd-suite/actions/proof-runner-check@main + + - name: PRAT Testing Gate + uses: hyperpolymath/cicd-suite/actions/prat-check@main + + - name: Panic Attack & Pons Gate + uses: hyperpolymath/cicd-suite/actions/custom-tools-check@main + + - name: WWW & Well-Known Compliance Gate + uses: hyperpolymath/cicd-suite/actions/www-compliance-check@main + + - name: BoJ Cartridge Validation Gate + uses: hyperpolymath/cicd-suite/actions/boj-cartridge-check@main + + - name: Formatting Validation Gate + uses: hyperpolymath/cicd-suite/actions/formatting-check@main + + - name: Accreditations & Badges Gate + uses: hyperpolymath/cicd-suite/actions/badges-check@main + + - name: Metrics Extraction Gate + uses: hyperpolymath/cicd-suite/actions/metrics-check@main + + - name: Linguist & Banned Languages Gate + uses: hyperpolymath/cicd-suite/actions/linguist-check@main + + - name: Test & Benchmarks Dashboard Gate + uses: hyperpolymath/cicd-suite/actions/tests-benches-check@main + + - name: Hosting & Site Status Gate + uses: hyperpolymath/cicd-suite/actions/hosting-check@main + + - name: Git-Sea Analytics Gate + uses: hyperpolymath/cicd-suite/actions/gitsea-check@main + + - name: Trust & Humans Validation Gate + uses: hyperpolymath/cicd-suite/actions/trust-humans-check@main + + - name: Are We UnAPI Gate (Secret Scanning) + uses: hyperpolymath/cicd-suite/actions/secrets-check@main + + - name: Reasonably Good Token Validation Gate + uses: hyperpolymath/cicd-suite/actions/vaulted-tokens-check@main diff --git a/.github/workflows/mirror.yml b/.github/workflows/mirror.yml index c25d3bcb4..72824fbdd 100644 --- a/.github/workflows/mirror.yml +++ b/.github/workflows/mirror.yml @@ -12,5 +12,5 @@ permissions: jobs: mirror: - uses: hyperpolymath/standards/.github/workflows/mirror-reusable.yml@d135b05bfc647d0c0fbfedc7e80f37ea50f49236 + uses: hyperpolymath/standards/.github/workflows/mirror-reusable.yml@7fdc2705df74b4e352d2a1cde3e87a5923fdf329 secrets: inherit diff --git a/.github/workflows/rust-ci-reusable.yml b/.github/workflows/rust-ci-reusable.yml index f4c3ba511..f5a58336a 100644 --- a/.github/workflows/rust-ci-reusable.yml +++ b/.github/workflows/rust-ci-reusable.yml @@ -19,13 +19,13 @@ # # jobs: # rust-ci: -# uses: hyperpolymath/standards/.github/workflows/rust-ci-reusable.yml@d135b05bfc647d0c0fbfedc7e80f37ea50f49236 +# uses: hyperpolymath/standards/.github/workflows/rust-ci-reusable.yml@7fdc2705df74b4e352d2a1cde3e87a5923fdf329 # # With audit + coverage enabled: # # jobs: # rust-ci: -# uses: hyperpolymath/standards/.github/workflows/rust-ci-reusable.yml@d135b05bfc647d0c0fbfedc7e80f37ea50f49236 +# uses: hyperpolymath/standards/.github/workflows/rust-ci-reusable.yml@7fdc2705df74b4e352d2a1cde3e87a5923fdf329 # with: # enable_audit: true # enable_coverage: true @@ -34,11 +34,11 @@ # # jobs: # rust-ci-cli: -# uses: hyperpolymath/standards/.github/workflows/rust-ci-reusable.yml@d135b05bfc647d0c0fbfedc7e80f37ea50f49236 +# uses: hyperpolymath/standards/.github/workflows/rust-ci-reusable.yml@7fdc2705df74b4e352d2a1cde3e87a5923fdf329 # with: # working_directory: crates/cli # rust-ci-server: -# uses: hyperpolymath/standards/.github/workflows/rust-ci-reusable.yml@d135b05bfc647d0c0fbfedc7e80f37ea50f49236 +# uses: hyperpolymath/standards/.github/workflows/rust-ci-reusable.yml@7fdc2705df74b4e352d2a1cde3e87a5923fdf329 # with: # working_directory: crates/server #