feat: add Atomizer HQ multi-agent cluster infrastructure

- 8-agent OpenClaw cluster (Manager, Tech-Lead, Secretary, Auditor,
  Optimizer, Study-Builder, NX-Expert, Webster)
- Orchestration engine: orchestrate.py (sync delegation + handoffs)
- Workflow engine: YAML-defined multi-step pipelines
- Agent workspaces: SOUL.md, AGENTS.md, MEMORY.md per agent
- Shared skills: delegate, orchestrate, atomizer-protocols
- Capability registry (AGENTS_REGISTRY.json)
- Cluster management: cluster.sh, systemd template
- All secrets replaced with env var references

hq/workspaces/technical-lead/memory/2025-02-09.md

@@ -0,0 +1,24 @@
+# 2025-02-09 — Technical Lead Log
+
+## Hydrotech Beam — Technical Breakdown Complete
+
+**Task:** OP_10 Step 2 — Technical breakdown for beam structural optimization  
+**Output:** `/home/papa/atomizer/projects/hydrotech-beam/1_breakdown/TECHNICAL_BREAKDOWN.md`
+
+### Key Findings
+1. **Baseline violates displacement constraint** (22mm vs 10mm limit) — this is the #1 risk. Feasible region may be narrow.
+2. Recommended **single-objective** formulation: minimize mass, constrain displacement and stress
+3. Recommended **two-phase approach**: LHS DoE (40-50 trials) → TPE optimization (60-100 trials)
+4. `hole_count` should be treated as true integer — TPE handles natively
+5. Identified **9 critical gaps** that need clarification from Antoine before proceeding
+
+### Gaps Flagged
+- Beam geometry details (length, supports, loading)
+- Displacement/stress measurement specifics
+- Geometric feasibility at extreme parameter combos
+- Result sensor availability in the sim
+- Mesh convergence verification needed
+
+### Risk Assessment: MEDIUM-HIGH
+- Main risk: conflicting requirements (lighter AND stiffer simultaneously)
+- Sandwich theory provides the lever arm effect, but feasible region needs DoE confirmation

hq/workspaces/technical-lead/memory/2025-07-17.md

@@ -0,0 +1,36 @@
+# 2025-07-17 — Technical Lead Log
+
+## OP_09: NXOpenSolver Implementation for Hydrotech Beam
+
+**Status:** COMPLETED — committed as `390ffed`
+
+### What was done
+Completed `NXOpenSolver.evaluate()` and `close()` in `projects/hydrotech-beam/studies/01_doe_landscape/nx_interface.py`.
+
+### Implementation pattern
+Follows M1_Mirror/SAT3_Trajectory_V7 FEARunner pattern exactly:
+1. `create_iteration_folder()` — HEEDS-style isolation, copies model + writes params.exp
+2. `run_simulation()` — journal handles expression import, geometry rebuild, FEM update, solve
+3. Extractor pipeline: displacement → stress → mass
+
+### Key technical decisions
+
+1. **Element type auto-detection**: Used `element_type=None` for stress extraction instead of hardcoding CQUAD4. The extractor checks all solid types (CTETRA, CHEXA, CPENTA, CPYRAM) then falls back to shell if needed. This is safer since we haven't confirmed the beam's mesh type.
+
+2. **Mass extraction fallback chain**: `_temp_mass.txt` → `_temp_part_properties.json`. The solve journal writes both files. The fallback handles edge cases where the primary file is missing.
+
+3. **OP2 naming convention**: `beam_sim1-solution_1.op2` (lowercase sim stem + lowercase solution name with spaces→underscores). Verified from `NXSolver.run_simulation()` logic.
+
+4. **Expression unit mapping**: All 4 DVs default to `mm` in `_write_expression_file()` which is correct for beam_half_core_thickness, beam_face_thickness, holes_diameter. `hole_count` is unitless but the NX journal's ImportFromFile handles this correctly.
+
+5. **LAC compliance**: `close()` only calls `session_manager.cleanup_stale_locks()`, never kills NX processes. This follows the LAC critical lesson.
+
+### Files changed
+- `projects/hydrotech-beam/studies/01_doe_landscape/nx_interface.py` — +254/-149 lines
+
+### Testing
+- Syntax validation: ✓
+- Stub solver smoke test: ✓
+- Factory pattern test: ✓
+- All required methods present: ✓
+- Real NX testing requires Windows/dalidou — not possible from this sandbox

hq/workspaces/technical-lead/memory/2026-02-10.md

@@ -0,0 +1,36 @@
+# 2026-02-10 — Technical Lead Daily Log
+
+## Assignment: KB Gen 002 — KBS Session Processing
+
+Received from Manager via OP_09 handoff. Processed 3 KBS capture sessions from Antoine.
+
+### Key Findings
+
+1. **Mass discrepancy resolved:** 974 kg → 11.33 kg. Expression is `p1`, not `p173`. The intake data was wrong — KBS session is ground truth.
+
+2. **Major confirmed parameters:**
+   - Beam: 5,000 mm cantilever, I-beam cross-section
+   - Load: 10,000 kgf downward at free end
+   - Material: AISI Steel 1005, ρ = 7.3 g/cm³
+   - Mesh: CQUAD4 thin shell, 33.7 mm elements
+   - Holes: 10 count, 300 mm dia, 4,000 mm span, 500 mm offsets
+
+3. **Gap status:** Closed G1, G2, G8. Opened G10-G15. Most critical: G10 (baseline displacement re-verification) and G11 (baseline stress — never measured).
+
+4. **New expression names discovered:** `beam_half_height`, `beam_half_width`, `beam_length`, `p6` (hole span), `p1` (mass)
+
+5. **Antoine's directive:** "Please optimize" — but we need baseline re-verification first.
+
+### Concerns
+
+- The 11.33 kg vs 974 kg mass difference is a factor of ~86×. This fundamentally changes the optimization landscape. The old displacement value (22 mm) is almost certainly from a different model state.
+- Baseline displacement and stress must be measured fresh before optimization begins.
+- At DV extremes, holes WILL overlap. Need geometric feasibility constraint.
+- The `p6` hole span as a potential 5th DV needs a decision.
+
+### Deliverables
+- ✅ All KB files updated (7 files, 642 insertions)
+- ✅ Git commit: `b88657b` — pushed to Gitea
+- ✅ Gen 002 document with full transcript analysis
+- ✅ Mass discrepancy analysis and resolution
+- ✅ Gap resolution summary

hq/workspaces/technical-lead/memory/reviews/2025-02-10_optimization_strategy_review.md

@@ -0,0 +1,170 @@
+# Auditor Review — Optimization Strategy: Hydrotech Beam DoE & Landscape
+
+**Protocol:** OP_09 — Auditor Review Gate  
+**Reviewer:** Technical Lead 🔧 (acting as Auditor)  
+**Date:** 2026-02-10  
+**Document:** `/projects/hydrotech-beam/studies/01_doe_landscape/OPTIMIZATION_STRATEGY.md`  
+**Author:** Optimizer Agent  
+
+---
+
+## VERDICT: APPROVED WITH CONDITIONS
+
+The strategy is well-structured, thorough, and shows excellent application of LAC lessons. The two-phase LHS → TPE approach is sound. However, there are **2 blockers** and **3 warnings** that must be addressed before Study Builder proceeds.
+
+---
+
+## Issues Found
+
+### 🔴 BLOCKER 1 — Mass Expression & Value Conflict
+
+**The optimization strategy uses mass = 1,133.01 kg (expression `p173`).**  
+**The KB (Gen 002 from KBS sessions) says mass = 11.33 kg (expression `p1`).**  
+**CONTEXT.md says 1,133.01 kg (`p173`) citing "binary introspection".**
+
+These are contradictory. The Gen 002 KB entry (dev/gen-002.md) explicitly resolved this, stating:
+> *"Intake reported ~974 kg (expression `p173`). Antoine's live session confirms 11.33 kg (expression `p1`). The confirmed baseline mass is 11.33 kg."*
+
+But CONTEXT.md was updated *after* the KB gen-002 (21:57 vs 21:46) with "binary introspection" data claiming `p173 = 1,133.01 kg`. This creates confusion:
+- Is `p173` a DIFFERENT mass expression (e.g., assembly-level mass) than `p1` (component mass)?
+- Or was the binary introspection wrong?
+- The factor is ~100× (11.33 vs 1,133.01) — this is NOT a unit error (kg vs g would be 1000×).
+
+The DV baselines also conflict:
+- **KB (KBS session):** face = 20 mm, core = 20 mm (round numbers Antoine stated live)
+- **CONTEXT.md (introspection):** face = 21.504 mm, core = 25.162 mm (from binary read)
+
+**REQUIRED ACTION:** CEO must clarify which mass expression and baselines are authoritative. The strategy cannot proceed with ambiguous baselines. If both `p1` and `p173` exist and are different expressions, document what each measures. The binary introspection values (21.504, 25.162) are more precise and may represent the actual current model state vs. Antoine's rounded description — but this must be confirmed.
+
+### 🔴 BLOCKER 2 — Hole Spacing Formula is Wrong
+
+**Section 4.2** uses the formula:
+```
+Spacing = L_web / (n + 1)
+```
+
+This is **incorrect**. The NX model uses:
+```
+Spacing = hole_span / (hole_count - 1)
+```
+
+Evidence: `Pattern_p8 = 444.444 mm = 4000 / (10-1) = 4000/9`. This is confirmed in CONTEXT.md's expression map.
+
+The `(n+1)` formula assumes holes are inset from both ends (like fence posts between two rails). The actual NX pattern uses `(n-1)` — holes are placed AT the start and end of the span, with `n-1` intervals between them.
+
+This changes the overlap analysis:
+- **Strategy says worst case:** `L/(n+1) = 4000/16 = 250mm`, ligament = `250 - 450 = -200mm`
+- **Actual worst case:** `L/(n-1) = 4000/14 = 285.7mm`, ligament = `285.7 - 450 = -164.3mm`
+
+Both still show overlap, but the **feasibility boundary is different**. The correct feasibility constraint is:
+
+```
+hole_span / (hole_count - 1) - holes_diameter ≥ min_ligament
+```
+
+And the ligament formula in §4.2 and the sandwich-beam.md KB component both need correction.
+
+**REQUIRED ACTION:** Fix the spacing formula everywhere. Update the geometric feasibility pre-check to use `span / (count - 1)`.
+
+---
+
+### 🟡 WARNING 1 — Web Height vs. Hole Diameter Interaction
+
+**Section 4.3** incorrectly calculates web height as `2 × half_core + 2 × face = 40mm` at DV extremes, then notes that 450mm holes don't fit.
+
+The actual I-beam geometry has:
+- Total beam height = `2 × beam_half_height = 2 × 250 = 500 mm` (fixed)
+- Web clear height ≈ `total_height - 2 × face_thickness = 500 - 2 × face`
+- At baseline (face=21.5mm): web height ≈ 457 mm — holes of 450mm barely fit
+- At face=40mm: web height ≈ 420 mm — holes of 450mm **do NOT fit**
+
+This means `beam_face_thickness` and `holes_diameter` interact geometrically. The strategy should add a geometric feasibility constraint:
+```
+holes_diameter < 2 × beam_half_height - 2 × beam_face_thickness - clearance
+```
+
+The Section 4.3 analysis is correct in spirit (holes might not fit) but wrong in the geometric formula. The conclusion actually changes: the constraint is tighter than the strategy realizes.
+
+**REQUIRED ACTION:** Correct the web height formula. Add an explicit pre-check constraint G5b (hole-to-web-height feasibility) alongside the existing G5 (hole overlap).
+
+### 🟡 WARNING 2 — KB _index.md Has Stale Data
+
+The KB `_index.md` overview section states: *"minimize mass from 11.33 kg baseline"* and *"Baseline mass: 11.33 kg (expression `p1`)"*. But the optimization strategy uses 1,133.01 kg (`p173`). There are now TWO conflicting "sources of truth" in the same repo.
+
+Additionally, some KB files have DV baselines as round numbers (20, 20) while CONTEXT.md has precise values (21.504, 25.162). The Gen 002 KB files were NOT updated with the later introspection data.
+
+**REQUIRED ACTION:** After Blocker 1 is resolved, update all KB files to use consistent, authoritative values. Single source of truth.
+
+### 🟡 WARNING 3 — Baseline "Likely FAILS" Displacement is Poorly Sourced
+
+Section 1.5 states: *"~22 mm (unverified — awaiting baseline re-run)"* and *"The baseline design likely violates the displacement constraint (~22 mm vs 10 mm limit)."*
+
+The 22mm figure comes from Gen 001 intake when the mass was supposedly ~974 kg. Since the mass baseline is now disputed (11.33 vs 1,133.01 kg), the displacement estimate is even less reliable. The entire strategy narrative — "optimizer must first find the feasible region" — hinges on the baseline being infeasible.
+
+If the baseline is actually feasible (displacement < 10mm), the strategy is still valid but the emphasis shifts from "find feasibility" to "minimize mass within feasible region." The Phase 1→2 gate criteria and risk mitigations are correctly written to handle either case — this is good planning. But the narrative framing should not over-commit to the infeasible-baseline scenario.
+
+**REQUIRED ACTION:** Await baseline solve results before finalizing strategy narrative. The algorithmic approach is sound either way, but the gate criteria at §6.4 should explicitly handle the case where the baseline is feasible.
+
+---
+
+## Suggestions (Non-Blocking)
+
+### 💡 SUGGESTION 1 — Add Pre-Flight Geometric Feasibility Filter
+
+Before sending any trial to NX, compute:
+1. `ligament = hole_span / (hole_count - 1) - holes_diameter` → must be ≥ 30mm
+2. `web_clear = 2 * beam_half_height - 2 * beam_face_thickness - holes_diameter` → must be > 0
+
+If either fails, skip the NX evaluation and record as infeasible with max constraint violation. This saves compute and avoids NX geometry crashes.
+
+### 💡 SUGGESTION 2 — Constraint Margin vs. Hard Limits in Deb's Rules
+
+Section 3.5 proposes using 9.5mm / 123.5 MPa as optimizer targets while keeping 10mm / 130 MPa as hard limits. This is fine, but the implementation needs care: Deb's rules should use the **margin targets** for constraint calculation, not the hard limits. Otherwise the margin has no effect on the optimization.
+
+Alternatively, run the optimization on hard limits and apply the margin only during final validation (re-run best design and confirm it has ≥5% margin). This is simpler.
+
+### 💡 SUGGESTION 3 — Document `n_startup_trials=0` Risk
+
+Setting `n_startup_trials=0` in Phase 2 TPE (warm-started from Phase 1) is correct and efficient, but it means TPE immediately starts modeling from trial 1. If the Phase 1 data has uneven coverage (e.g., many infeasible points clustered in one region), TPE may develop a biased model early. Consider keeping `n_startup_trials=5-10` as insurance, or at minimum document this decision and the reasoning.
+
+### 💡 SUGGESTION 4 — Convergence Criteria Should Track Feasible-Only
+
+Section 6.2 convergence criteria ("best feasible objective unchanged for 20 trials") are correct. But ensure the implementation tracks ONLY feasible trials for the improvement check. If 20 trials all land infeasible, that's not "no improvement" — that's "still searching for feasibility."
+
+### 💡 SUGGESTION 5 — Phase 1 Corner Tests
+
+Section 7.2 proposes 16 corner tests (2⁴). With the corrected spacing formula, we know some corners are geometrically infeasible (e.g., DV3=450 + DV4=15). The corner tests should include the geometric pre-check so only physically possible corners are sent to NX. Expected: ~10-12 valid corners out of 16.
+
+---
+
+## Checklist Responses
+
+| # | Question | Verdict | Notes |
+|---|----------|---------|-------|
+| 1 | Problem formulation correct? | ✅ **YES** | Objective, constraints, DVs are well-formulated. Minor: mass expression needs resolution (Blocker 1) |
+| 2 | Algorithm choices justified? | ✅ **YES** | LHS → TPE is well-reasoned with strong LAC backing. CMA-ES/surrogate rejection is properly justified |
+| 3 | Trial budgets reasonable? | ✅ **YES** | 50 LHS + 60-100 TPE is appropriate for 4 DVs with unknown landscape |
+| 4 | Constraint handling sound? | ✅ **YES** | Deb's rules via Optuna is the right call for an infeasible baseline |
+| 5 | Integer handling correct? | ✅ **YES** | True integer via `IntDistribution(5,15)` + stratified LHS is correct |
+| 6 | Any gaps blocking Study Builder? | ⚠️ **YES** | Blockers 1-2 must be resolved. Warnings 1-3 should be addressed |
+| 7 | Hole collision feasibility (G5)? | ⚠️ **PARTIALLY** | Recognized but spacing formula is wrong (Blocker 2). Web height interaction missed |
+| 8 | LAC lessons applied? | ✅ **YES** | Excellent LAC application — surrogate avoidance, baseline enqueue, copy-not-rewrite, kPa→MPa |
+
+---
+
+## Summary
+
+The Optimizer produced an excellent, thorough strategy. The algorithm selection, constraint handling, risk mitigation, and LAC integration are all strong. The two blockers are data-integrity issues (mass/expression conflict, spacing formula) not architectural problems — they're fixable without redesigning the strategy.
+
+**Path forward:**
+1. Resolve Blocker 1 (CEO confirms authoritative mass expression and DV baselines)
+2. Fix Blocker 2 (correct spacing formula to `span / (count - 1)`)
+3. Address Warning 1 (add web-height feasibility constraint)
+4. Sync KB files (Warning 2)
+5. Await baseline solve (Warning 3) — can proceed with code in parallel
+
+Once blockers are cleared, the strategy is ready for Study Builder.
+
+---
+
+*Technical Lead 🔧 — The physics is the boss.*