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
- **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.
- **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.
## DEC-HB-012: Relax displacement constraint to 20mm
- **Date:** 2026-02-13
- **By:** CEO
- **Decision:** Relax max tip displacement constraint from 10 mm to 20 mm. Stress constraint unchanged (≤ 130 MPa).
- **Rationale:** Hydrotech Beam is a dummy/proving case — goal is to validate the full optimization pipeline end-to-end, not achieve a real engineering target. 10mm was unreachable in the current design space (baseline 19.6mm, 0/51 DOE trials feasible). 20mm makes feasibility achievable.
## 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
