Merge remote-tracking branch 'origin/master' into claude/splat3d-cpu-simd-renderer-MAOO0

Author: claude

.cargo/config-apple-m2.toml

@@ -0,0 +1,20 @@
+[build]
+# Apple M2 / M3 / M4 — ARMv8.6-A+ with BF16, dotprod, fp16, i8mm.
+# Use with:
+#   cargo --config .cargo/config-apple-m2.toml build --target=aarch64-apple-darwin
+#
+# Targets the BF16 tier — see `src/simd_neon_bf16.rs` for the silicon
+# table, runtime detection (`sysctl hw.optional.arm.FEAT_BF16`), the
+# BFMMLA / BFDOT intrinsic family, and the asm-byte fallback path that
+# stable Rust 1.95 must use until `vbfdotq_f32` stabilizes (issue
+# #117222).
+#
+# Also works on:
+#   - Apple M3 (target-cpu=apple-m3) — same ARMv8.6-A baseline
+#   - Apple M4 — adds SVE2, can override with -Ctarget-cpu=apple-m4
+#   - Snapdragon X Elite / X Plus on macOS-like targets (use cortex-x4)
+#
+# DOES NOT target Apple M1 — M1 is ARMv8.5-A and lacks BF16. M1 should
+# use the dotprod tier (config-pi5.toml-shaped, target-cpu=apple-m1).
+[target.aarch64-apple-darwin]
+rustflags = ["-Ctarget-cpu=apple-m2", "-Ctarget-feature=+bf16,+dotprod,+fp16,+i8mm"]

.cargo/config-avx512.toml

@@ -0,0 +1,50 @@
+[build]
+# Explicit AVX-512 config — Sapphire Rapids baseline. Use with:
+#   cargo --config .cargo/config-avx512.toml build
+#   cargo --config .cargo/config-avx512.toml test
+#
+# `-Ctarget-cpu=sapphirerapids` enables, in addition to the
+# `x86-64-v4` AVX-512 baseline (F + BW + CD + DQ + VL):
+#
+#   - AVX-512 VNNI       (VPDPBUSD u8×i8 → i32)
+#   - AVX-512 BF16       (VDPBF16PS, VCVTNE2PS2BF16)
+#   - AVX-512 FP16       (16-wide native FP16 arithmetic)
+#   - AVX-512 VBMI / VBMI2 (byte permute)
+#   - AVX-512 IFMA, BITALG, VPOPCNTDQ, GFNI, VAES, VPCLMUL
+#   - AVX-VNNI           (ymm VPDPBUSD on Alder/Sapphire client)
+#   - AMX-TILE + AMX-INT8 + AMX-BF16 (16×16×k tile kernels)
+#
+# Effect on the agnostic surfaces in `src/simd_*ops.rs`:
+#
+#   - `simd_int_ops::gemm_u8_i8` resolves to the AVX-512 VNNI `VPDPBUSD`
+#     zmm kernel (`hpc::vnni_gemm::int8_gemm_vnni_avx512`). When the
+#     planned `amx-int8` arm lands, it will preempt this one and route
+#     to `TDPBUSD` instead — same source, no caller changes.
+#   - BF16 / FP16 lane ops in `src/simd_avx512.rs` light up.
+#   - `simd_amx::*` tile primitives are usable without further gating.
+#
+# Pure `x86-64-v4` is NOT used here — Skylake-X is the only AVX-512 CPU
+# without VNNI and the project's design pins VNNI as the lowest common
+# denominator above the scalar reference. SKX users either build with
+# `-Ctarget-cpu=x86-64-v4` explicitly (and accept the scalar arm for
+# `gemm_u8_i8`) or run a runtime-LazyLock dispatch binary.
+#
+# Binary produced here will SIGILL on CPUs that lack any of the
+# enabled feature sets — i.e. anything pre-Sapphire-Rapids on x86_64:
+#
+#   - Cooper Lake / Cascade Lake / Ice Lake-SP    (no BF16+FP16+AMX)
+#   - Skylake-X / Skylake-SP / Skylake-W          (no VNNI either)
+#   - Zen 4 / Zen 5                               (no AMX)
+#   - Alder Lake / Arrow Lake                     (no AVX-512 at all)
+#   - Haswell ⇢ Coffee Lake                       (AVX2 only)
+#
+# Only deploy artifacts built with this config to hosts that report
+# `amx_int8 amx_bf16 avx512_bf16 avx512_fp16 avx512_vnni` in
+# `/proc/cpuinfo`. For Cascade Lake → Ice Lake-SP → Zen 4 silicon
+# (AVX-512 + VNNI but no AMX/BF16/FP16), build with
+# `-Ctarget-cpu=cascadelake` or `-Ctarget-cpu=znver4` instead. For
+# shipping a single release artifact that adapts at process start,
+# see the LazyLock runtime dispatch path in § 7.1 of the architecture
+# doc instead.
+[target.'cfg(target_arch = "x86_64")']
+rustflags = ["-Ctarget-cpu=sapphirerapids"]

.cargo/config-graviton.toml

@@ -0,0 +1,19 @@
+[build]
+# AWS Graviton 3 / 3E / 4 (Neoverse V1 / V2) — ARMv8.4-A+ with BF16
+# (V1: optional, V2: mandatory) + SVE / SVE2.
+# Use with:
+#   cargo --config .cargo/config-graviton.toml build --target=aarch64-unknown-linux-gnu
+#
+# Targets the BF16 tier — see `src/simd_neon_bf16.rs`. Graviton 3 (V1)
+# also adds SVE 256-bit; Graviton 4 (V2) adds SVE2 + BFMMLA + i8mm.
+#
+# Also works on:
+#   - Cortex-X3 / X4 / X925 generic Linux servers
+#   - Ampere Altra (V1-class — same baseline)
+#   - NVIDIA Grace (V2 — same as Graviton 4)
+#
+# For ARMv9 cores with SVE2 you may want a separate config-sve2.toml
+# later that adds `+sve2` and routes through a future
+# `src/simd_neon_sve2.rs` (not in Phase 3 scope).
+[target.aarch64-unknown-linux-gnu]
+rustflags = ["-Ctarget-cpu=neoverse-v2", "-Ctarget-feature=+bf16,+dotprod,+fp16,+i8mm"]

.cargo/config-native.toml

@@ -0,0 +1,13 @@
+[build]
+# Native build config — `target-cpu = "native"`. Use with:
+#   cargo --config .cargo/config-native.toml build
+#   cargo --config .cargo/config-native.toml test
+#
+# rustc resolves the build host's CPUID at invocation and enables every
+# `target_feature` the host CPU advertises. `simd.rs` then picks the
+# matching backend (typically `simd_avx512` on modern dev machines).
+#
+# Produces a binary tuned for the developer's exact silicon. The result
+# is NOT portable: do not distribute artifacts built with this config.
+[target.'cfg(target_arch = "x86_64")']
+rustflags = ["-Ctarget-cpu=native"]

.cargo/config-pi5.toml

@@ -0,0 +1,15 @@
+[build]
+# Raspberry Pi 5 (BCM2712, Cortex-A76) — ARMv8.2-A with dotprod + fp16.
+# Use with:
+#   cargo --config .cargo/config-pi5.toml build --target=aarch64-unknown-linux-gnu
+#
+# Targets the dotprod/fp16 tier — see `src/simd_neon_dotprod.rs` for the
+# silicon table, runtime detection, and stub map. Also works on:
+#   - Orange Pi 5 (Rockchip RK3588, Cortex-A76)
+#   - Anything reporting `Features: ... asimddp asimdhp ...` in
+#     /proc/cpuinfo without `bf16`.
+#
+# For Apple M2+ / Snapdragon X / Graviton 4, use config-apple-m2.toml
+# (BF16 tier — see src/simd_neon_bf16.rs).
+[target.aarch64-unknown-linux-gnu]
+rustflags = ["-Ctarget-cpu=cortex-a76", "-Ctarget-feature=+dotprod,+fp16"]

.cargo/config.toml

@@ -1,4 +1,26 @@
 [build]
-# No global target-cpu. Each kernel uses #[target_feature(enable = "avx512f")]
-# per-function, with LazyLock runtime detection. One binary, all ISAs.
-# Railway (AVX-512) and GitHub CI (AVX2) use the same binary.
+# Default cargo config — x86-64-v3 (AVX2) baseline. Portable across all
+# x86_64 silicon shipping since ~2013 (Haswell+). This is what GitHub CI
+# runs against and what `cargo build` produces for general distribution.
+#
+# Why v3 and not "no target-cpu":
+#   `src/simd_avx2.rs` composes `F32x16` as two `__m256` halves (AVX
+#   intrinsics), and the `simd_avx2_*` op funcs use `__m256i` (AVX2).
+#   Without a global v3 baseline, rustc compiles to x86-64 generic (SSE2)
+#   and those intrinsics emit instructions the CPU never executes →
+#   SIGILL at run time, exactly the PR #170 CI failure mode.
+#
+# AVX-512 builds: use `--config .cargo/config-avx512.toml` (or
+# `CARGO_BUILD_RUSTFLAGS='-Ctarget-cpu=x86-64-v4'`). The simd.rs dispatch
+# arms key off `target_feature = "avx512f"`; under v4 they pick the
+# `simd_avx512` backend (native `__m512` / `__m512d` / `__m512i`).
+#
+# Build-machine-tuned binaries: use `--config .cargo/config-native.toml`
+# (`target-cpu = "native"`); rustc resolves the host CPUID at compile.
+#
+# Runtime LazyLock dispatch (one release binary, heterogeneous deployment
+# silicon) is a fifth opt-in mode — see § 7.1 of
+# .claude/knowledge/simd-dispatch-architecture.md. Reserved for the
+# release-binary distribution path; never the dev / CI default.
+[target.'cfg(target_arch = "x86_64")']
+rustflags = ["-Ctarget-cpu=x86-64-v3"]

.claude/ATT/DE/README.md

@@ -0,0 +1,91 @@
+> **Sprache:** Deutsch · siehe `../README.md` für die englische Quellfassung.
+
+# `.claude/ATT/` — NLSpecs unseres Kits im Attractor-Stil
+
+> **Status:** DRAFT  ·  **Version:** 0.1.0  ·  **Stand:** 2026-05-17
+>
+> **Was das ist.** Die Ideen unseres `.claude/EN/`-Kits, neu formuliert
+> im [strongdm/attractor](https://github.com/strongdm/attractor) NLSpec-Format,
+> damit ein Coding-Agent sie direkt umsetzen kann.
+> [NLSpec](https://github.com/strongdm/attractor#terminology) =
+> "human-readable spec intended to be directly usable by coding agents
+> to implement/validate behavior."
+>
+> **Was das NICHT ist.** Kein Ersatz für `.claude/EN/`. Die beiden sind
+> komplementär: `.claude/EN/` ist der Cheat-Sheet für Operatoren
+> (Prosa, in-session-Use); `.claude/ATT/` ist die Engineering-Spec
+> (NLSpec, build-time-Use).
+
+## Die drei Specs
+
+| Datei | Spiegelt Attractors | Ergänzt unsere Innovation |
+|---|---|---|
+| [`autoattended-orchestrator-spec.md`](./autoattended-orchestrator-spec.md) | [`attractor-spec.md`](https://github.com/strongdm/attractor/blob/main/attractor-spec.md) (DOT-Graph-Pipeline-Runner) | Wave-basierter 12-Worker-Fan-out; 4-savant Verdict-Gates (PP-13/14/15/16); 6 Worker-Iron-Rules; Sprint-Token-Budget (~300k/Wave); Multi-File-Board-Pattern mit single-mutable-file-Invariante |
+| [`anti-skim-agent-spec.md`](./anti-skim-agent-spec.md) | [`coding-agent-loop-spec.md`](https://github.com/strongdm/attractor/blob/main/coding-agent-loop-spec.md) (die Per-LLM-Call-Agent-Library) | Reading-Depth-Ladder (grep→read→thorough→fan-out); Lie-Detector LD-1..5 (Sentinel-Token / Proof-of-Read SHA / 3-Section-Challenge / Negative-Knowledge-Test / Line-Range-Quote); typisierte Stuck-Protocol-Blocker (AMBIGUITY / MISSING_INVARIANT / SPEC_SOURCE_MISMATCH / BEHAVIOUR_QUESTION / EXTERNAL_DEPENDENCY) |
+| [`agent-coordination-mcp-spec.md`](./agent-coordination-mcp-spec.md) | [`unified-llm-spec.md`](https://github.com/strongdm/attractor/blob/main/unified-llm-spec.md) (Provider-agnostisches LLM-SDK) | Drei Koordinations-Layer (Role-Teleport / File-Blackboard / Branch-Pub-Sub) so wie sie ein nativer A2A-MCP-Server exponieren sollte; strukturiertes Handover-Schema; Decision-Matrix dafür, wann welcher Layer passt |
+
+## Was wir von Attractor übernommen haben (die fünf Wins)
+
+Das sind konkrete Dinge, die Attractors Specs festnageln und die unseren
+Prosa-Docs in `.claude/EN/` gefehlt haben — jetzt eingearbeitet:
+
+| # | Attractor-Konzept | Landet in unserer NLSpec | Übernahme |
+|---|---|---|---|
+| 1 | Typisiertes `status.json`-Schema + 5-Wert-`StageStatus`-Enum (Attractor Appendix C: `{outcome, preferred_label, suggested_next_ids, context_updates, notes}`) | [`autoattended-orchestrator-spec.md` §9](./autoattended-orchestrator-spec.md#9-status-file-schema) | Übernommen **mit verpflichtendem `auto_status=false`** (siehe "Wo es kollidiert" unten). |
+| 2 | DOT-Graph-DSL für den Workflow + Lint-Regeln (Attractor §2 Grammatik + §7 Validierung: `reachability`, `start_no_incoming`, `goal_gate_has_retry`, `condition_syntax`) | [`autoattended-orchestrator-spec.md` §6](./autoattended-orchestrator-spec.md#6-sprint-plan-format) (DOT + YAML-Mirror) + [§7](./autoattended-orchestrator-spec.md#7-validation-rules) (WAVE-001..WAVE-017 mit ERROR/WARNING-Severity) | Übernommen mit drei Wave-spezifischen Zusätzen: `unique-write`, `declared-shared`, `auto-status-false`. |
+| 3 | Context-Fidelity-Ladder (Attractor §5.4: `full` / `truncate` / `compact` / `summary:low/medium/high` mit Token-Budgets + Vorrang edge > node > graph > default) | [`autoattended-orchestrator-spec.md` §11](./autoattended-orchestrator-spec.md#11-context-fidelity) | Übernommen mit einer Verschärfung: `fidelity=truncate` entbindet einen Worker NICHT von der §3.3-Reading-Depth-Ladder aus `anti-skim-agent-spec.md`. |
+| 4 | In-Loop-Tool-Call-Loop-Detection (Attractor coding-agent §2.10: letzte 10 Calls scannen auf wiederholende Patterns der Länge 1/2/3 → Steering-Warning einspielen) | [`anti-skim-agent-spec.md` §6](./anti-skim-agent-spec.md#6-tool-call-loop-detection) + AP9 in [§9](./anti-skim-agent-spec.md#9-anti-pattern-catalog-ap1ap9) | Wortgleich übernommen; auf System-Level-Invariante erhoben. PP-13s Post-hoc-AP9 fängt, was der In-Loop-Detector verpasst. |
+| 5 | Definition-of-Done-Checklisten + Cross-Provider-Parity-Matrix pro Spec (Konformanz-Tabellen im Stil von Attractor §10) | Jede NLSpec endet mit `§ Definition von Fertig` + `§ Cross-{Language,Provider}-Parity-Matrix` | Als strukturelles Template übernommen. Der 26-Repo-Rollout ist jetzt maschinell prüfbar. |
+
+## Warum dieses Format
+
+Drei Eigenschaften, die wir aus Attractors NLSpec-Format bekommen und
+die unseren Prosa-Docs in `.claude/EN/` fehlen:
+
+1. **Definition-von-Fertig-Checklisten** am Ende jeder Spec — gibt uns
+   einen Konformanz-Test für "ist diese Implementierung fertig?"
+2. **Cross-Provider-Parity-Matrix**-Tabellen — geben uns ein Per-Language /
+   Per-Runtime-Mapping, sodass dieselbe NLSpec in Rust, Python, TypeScript,
+   Go landen kann ohne Drei-Wege-Drift.
+3. **Validierungs-Regeln mit ERROR/WARNING/INFO-Severity** — macht aus
+   Linting einen deterministischen Prozess, kein Bauchgefühl.
+
+## Wo es mit Attractors Haltung kollidiert (und warum wir bei unserer Position bleiben)
+
+| Attractors Default | Unsere Position | Warum |
+|---|---|---|
+| `auto_status=true` (§4.5 + Appendix C: "wenn der Handler keinen Status schreibt, auto-generiere SUCCESS") | `auto_status=false` ist Pflicht | Genau das ist der Silent-Skim-Failure-Mode, gegen den unser Lie-Detector LD-1..5 existiert. Fehlender Status = FAIL, nicht SUCCESS. |
+| Single-Threaded Graph-Traversal (§3.8: "Nur ein Node läuft zur Zeit") | Wave-Fan-out ist die Baseline, kein Spezial-Fall `parallel`-Node | Unser Token-Budget ist pro Wave (~300k für 12 Workers), nicht pro Node. Waves als einen riesigen `parallel`-Node zu modellieren ist syntaktisch hässlich. |
+| Engine-Level-Retries mit Exponential-Backoff (§3.5-3.6) | Stuck-Agents filen typisierte Blocker in REQUESTS-FROM-AGENTS.md; Meta-Agent entscheidet | Retries sollen kontextuell und inspiziert sein, nicht silent und uniform. |
+| `wait.human` als Default; LLM-Gates sind Test-Fixtures (§6.4: `AutoApproveInterviewer` "Used for automated testing") | LLM-Meta-Agent ist das Production-Gate | Unser Meta-Agent macht Plan-Review + P0/P1-PR-Review + Inbox-Drain als Production-Rolle, nicht als Test-Fixture. |
+| Subagent-Tiefe = 1 Default (coding-agent §7.3) | Wave-Fan-out fährt routinemäßig 12 Workers aus einem Orchestrator | Wir überschreiben die Tiefe auf ≥2 — Workers sollen Sub-Investigations spawnen dürfen. |
+
+## Konformanz
+
+Ein Repo, das diese NLSpecs einbindet, ist konform, wenn es die
+"Definition von Fertig"-Checkliste am Ende jeder Spec erfüllt. Die
+lance-graph-Implementierung (siehe [`AdaWorldAPI/lance-graph` `.claude/agents/`](https://github.com/AdaWorldAPI/lance-graph/tree/main/.claude/agents))
+ist die reifste Referenz; die WoA + woa-rs-Implementierungen sind die
+Wave-basierte Referenz.
+
+## Provenienz
+
+- Quell-Kit: `.claude/EN/` in diesem Repo (siehe [`.claude/EN/README.md`](../../EN/README.md))
+- Format-Inspiration: [strongdm/attractor](https://github.com/strongdm/attractor) (NLSpecs im MIT-Stil)
+- Distillation-Handover: [`META/HANDOVER-AGENTKIT-CONSOLIDATION-2026-05-17.md`](https://github.com/AdaWorldAPI/WoA/blob/main/META%2FHANDOVER-AGENTKIT-CONSOLIDATION-2026-05-17.md)  (in `AdaWorldAPI/WoA`)
+- Schwester-Handover (Rust-Hardening-Pass): [`META/HANDOVER-WOA-RS-AGENT-HARDENING-2026-05-17.md`](https://github.com/AdaWorldAPI/WoA/blob/main/META%2FHANDOVER-WOA-RS-AGENT-HARDENING-2026-05-17.md)
+
+## Build
+
+Um diese NLSpecs in eine lauffähige Implementierung zu verwandeln,
+gib einem modernen Coding-Agent (Claude Code, Codex, OpenCode, Amp,
+Cursor, ...) diesen Prompt:
+
+```
+codeagent> Implement the Autoattended Orchestrator + Anti-Skim Agent
+           + Agent Coordination MCP as described by
+           https://github.com/AdaWorldAPI/<repo>/tree/main/.claude/ATT
+           together with strongdm/attractor as the substrate.
+```
+
+*Ende der Datei README.md.*