FESADev/phases/cpp-object-oriented-modular-refactoring/step5.md

Step 5: Solver Workflow Google Style

과거 개발 계획이다. 아래 작업·상태·예시는 현재 실행 지시가 아니다. 현재 구현과 검증 한계는 기능 요약을 따른다.

읽어야 할 파일

• /AGENTS.md
• ../../docs/solver-core/README.md
• ../../docs/solver-core/README.md
• ../../docs/solver-core/README.md
• ../../docs/cpp-object-oriented-modular-refactoring/README.md
• /include/fesa/analysis/analysis_model.hpp, /include/fesa/analysis/analysis_state.hpp, /include/fesa/analysis/linear_static_analysis.hpp
• /src/fesa/analysis/analysis_model.cpp, /src/fesa/analysis/analysis_state.cpp, /src/fesa/analysis/linear_static_analysis.cpp
• /include/fesa/assembly/load_assembler.hpp, /include/fesa/assembly/parallel_for.hpp, /include/fesa/assembly/sparse_assembler.hpp
• /src/fesa/assembly/load_assembler.cpp, /src/fesa/assembly/parallel_for.cpp, /src/fesa/assembly/sparse_assembler.cpp
• /include/fesa/constraints/essential_constraints.hpp, /src/fesa/constraints/essential_constraints.cpp
• /include/fesa/fem/dof_manager.hpp, /src/fesa/fem/dof_manager.cpp
• /include/fesa/results/result_records.hpp, /include/fesa/results/result_recovery.hpp, /include/fesa/results/results_writer.hpp
• /src/fesa/results/result_recovery.cpp
• /tests/unit/analysis/analysis_model_test.cpp, /tests/unit/analysis/analysis_state_test.cpp
• /tests/unit/assembly/load_assembler_test.cpp, /tests/unit/assembly/parallel_for_test.cpp, /tests/unit/assembly/sparse_assembler_test.cpp
• /tests/unit/constraints/essential_constraints_test.cpp, /tests/unit/fem/dof_manager_test.cpp
• /tests/unit/results/result_records_test.cpp, /tests/unit/results/result_recovery_test.cpp, /tests/unit/results/results_writer_test.cpp
• /tests/integration/analysis/linear_static_analysis_test.cpp
• Step 3–4에서 생성한 .h foundation/model/element headers
• /phases/cpp-object-oriented-modular-refactoring/index.json
• /phases/cpp-object-oriented-modular-refactoring/step5.md

작업

Requirement R-STYLE-001의 solver workflow slice와 R-DOC-001을 구현한다.

1. Matching unit/integration tests를 .h include와 PascalCase calls로 먼저 바꿔 RED compile failure를 기록한다.
2. Analysis, assembly, constraints, fem, results production headers를 .h와 full-path include guards로 전환한다.
3. Function/accessor, enum, constants, members와 repository callsites를 CODINGSTYLE에 맞춘다. Type names와 diagnostic text는 의미를 바꾸지 않는다.
4. Production public/protected declarations와 ordering, partition, factorization, deterministic reduction, candidate commit에 관한 internal helpers에 Doxygen를 작성한다.
5. 다음 approved order를 변경하지 않는다: stiffness/partition, Kff factorization, load/effective RHS, substitute/reconstruct, recovery/write.
6. Full residual K*d-F, source-order accumulation, 0x0 Kff validity, atomic state commit을 그대로 유지한다.

Acceptance Criteria

과거 도구 실행·출력 지시는 정리했으며, 현재 검증 방법은 기능 요약을 따른다.

검증 및 상태 갱신

• RED compile failure, focused/full GREEN과 formatting 결과를 summary에 기록한다.
• 성공 시 현재 Step만 completed로 갱신한다.
• lifecycle or numeric regression이면 error로 기록하고 다른 Step으로 진행하지 않는다.
• timestamp, retry, commit, advancement는 Executor 소유다.

금지사항

• Analysis/Load/Boundary/Element 추상화를 추가하지 마라. 이유: Step 14–20 소유다.
• sparse ordering, factorization order, result signs를 바꾸지 마라.
• Test에 Doxygen를 추가하지 마라.
• 직접 commit하거나 hook script를 수동 실행하지 마라.