Atomizer/projects/hydrotech-beam/DECISIONS.md

DECISIONS.md — Hydrotech Beam

Numbered decision log. Check here before proposing anything that contradicts a prior decision.

---

DEC-HB-001: Single-objective formulation

• Date: 2026-02-08
• By: Technical Lead 🔧
• Decision: Minimize mass as sole objective. Tip displacement (≤ 10 mm) and von Mises stress (≤ 130 MPa) as hard constraints.
• Rationale: Mass is Antoine's clear priority. Displacement and stress are pass/fail limits, not competing objectives to trade off. Single-objective converges faster and is appropriate for 4 design variables.
• Status: Proposed — awaiting CEO confirmation

DEC-HB-002: Two-phase optimization strategy

• Date: 2026-02-08
• By: Technical Lead 🔧
• Decision: Phase 1 = Latin Hypercube DoE (40–50 trials) to map landscape. Phase 2 = TPE via Optuna (60–100 trials) to converge.
• Rationale: DoE first catches model failures, maps feasibility, reveals sensitivities. TPE handles mixed integer/continuous natively and is sample-efficient.
• Status: Proposed — awaiting CEO confirmation

DEC-HB-003: Integer handling for hole_count

• Date: 2026-02-08
• By: Technical Lead 🔧
• Decision: Treat hole_count as true integer throughout (not continuous + rounding).
• Rationale: Only 11 levels (5–15). NX model must rebuild with integer count anyway. TPE handles mixed types natively.
• Status: Proposed — awaiting CEO confirmation

DEC-HB-004: Project structure — KB-integrated layout

• Date: 2026-02-09
• By: Manager 🎯 + CEO
• Decision: Projects use KB-integrated structure with models/, kb/, studies/, deliverables/. Knowledge base follows accumulation principle from shared KB skill. Studies are self-contained with own model copy and introspection.
• Rationale: Centralizes project knowledge, supports multiple studies per project, enables CDR compilation from KB, keeps everything in Gitea.
• Status: Approved

DEC-HB-005: No Notion — Gitea + .md as source of truth

• Date: 2026-02-09
• By: CEO
• Decision: All project documentation lives as .md files in the Atomizer Gitea repo. No external project management tools.
• Rationale: CEO preference. Efficient, version-controlled, browseable on Gitea, accessible to all agents.
• Status: Approved

DEC-HB-006: KB skill — extension pattern, no fork

• Date: 2026-02-09
• By: Manager 🎯 + CEO
• Decision: Use Mario's shared knowledge-base skill as-is. Atomizer maintains an extension file (knowledge-base-atomizer-ext.md) for agent-specific workflows. No fork of the shared repo.
• Rationale: Avoids merge conflicts, gets upstream improvements automatically, clean separation between general toolbox and Atomizer playbook.
• Status: Approved

DEC-HB-007: Single source of truth — repo projects folder

• Date: 2026-02-09
• By: CEO
• Decision: All project data lives in /repos/Atomizer/projects/. This is the single source of truth for all current and future projects. Synced to Windows (dalidou) via Syncthing. No duplicate local folders.
• Rationale: One place for everything — agents, CEO, and Windows all reference the same files. Version-controlled via Gitea, bidirectional sync via Syncthing.
• Status: Approved

DEC-HB-008: Backup/restore in-place solving (not iteration copies)

• Date: 2026-02-11
• By: CEO + Technical Lead 🔧
• Decision: Solve on master model files in-place (in models/ directory) using backup/restore for iteration isolation. Do NOT copy .sim/.fem/.prt files to per-iteration folders.
• Rationale: NX .sim files store absolute internal references to .fem and .prt files. Copying model files to iteration folders breaks these references (Parts.Open returns None). Backup/restore preserves all internal references while still providing isolation between trials.
• Workflow per trial:
  1. Restore master model files from backup
  2. Write .exp file with trial DVs, open .sim, rebuild, solve
  3. Archive outputs (OP2, F06, params.json, results.json) to iterations/iterNNN/
  4. Iteration folders contain outputs only — NOT model files
• Status: Approved — implemented and tested

DEC-HB-009: Iteration folder architecture

• Date: 2026-02-11
• By: CEO + Technical Lead 🔧
• Decision: Each trial archived to studies/01_doe_landscape/iterations/iterNNN/ with: params.json, params.exp, results.json, OP2, F06.
• Rationale: Full traceability per trial. Any result can be audited, re-examined, or debugged. Smart retention policy keeps last 10 + best 3 with full data, strips the rest to save space.
• Status: Approved — implemented in iteration_manager.py

DEC-HB-010: Persistent history database

• Date: 2026-02-11
• By: Technical Lead 🔧
• Decision: Maintain history.db (SQLite, append-only) + history.csv that survives --clean and Optuna resets. Logs all DVs, results, feasibility, timestamps across all studies.
• Rationale: Optuna DB is study-scoped and can be cleaned/reset. History DB provides permanent record across studies, enabling cross-study learning, debugging, and auditability. Append-only means no data loss.
• Status: Approved — implemented and tested

DEC-HB-011: Git-only development workflow (Syncthing paused)

• Date: 2026-02-11
• By: CEO
• Decision: During active development, use Git (push/pull) exclusively for code sync between server and dalidou. Syncthing paused to avoid conflicts.
• Rationale: Syncthing's bidirectional sync creates conflicts when both sides edit files simultaneously during development. Git provides explicit merge control.
• Status: Active — resume Syncthing for production/delivery phases