Files
FESADev/phases/cpp-object-oriented-modular-refactoring/step4.md
T

3.2 KiB
Raw Blame History

Step 4: Model and Element Google Style

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

읽어야 할 파일

  • /AGENTS.md
  • ../../docs/solver-core/README.md
  • ../../docs/solver-core/README.md
  • ../../docs/solver-core/README.md
  • ../../docs/linear-static-3d-euler-beam/formulation.md
  • ../../docs/linear-static-mitc4-shell/formulation.md
  • ../../docs/cpp-object-oriented-modular-refactoring/README.md
  • /include/fesa/model/domain.hpp, /include/fesa/model/model_types.hpp, /include/fesa/model/shell_geometry.hpp
  • /src/fesa/model/domain.cpp, /src/fesa/model/shell_geometry.cpp
  • /include/fesa/elements/euler_beam_3d.hpp, /include/fesa/elements/mitc4_shell.hpp
  • /src/fesa/elements/euler_beam_3d.cpp, /src/fesa/elements/mitc4_shell.cpp
  • /tests/unit/model/domain_test.cpp, /tests/unit/model/model_types_test.cpp, /tests/unit/model/shell_geometry_test.cpp
  • /tests/unit/elements/euler_beam_3d_test.cpp, /tests/unit/elements/mitc4_shell_test.cpp
  • Step 3에서 전환한 foundation .h headers와 callsites
  • /phases/cpp-object-oriented-modular-refactoring/index.json
  • /phases/cpp-object-oriented-modular-refactoring/step4.md

작업

Requirement R-STYLE-001의 model/element slice와 R-DOC-001을 구현한다.

  1. Model/element tests를 .h include와 PascalCase calls로 먼저 바꿔 RED compile failure를 확인한다.
  2. analysis_model.hpp는 아직 analysis slice이므로 건드리지 않는다. 다음 소유 범위만 .h와 header guard로 전환한다: model/domain, model/model_types, model/shell_geometry, elements/euler_beam_3d, elements/mitc4_shell.
  3. Production function/accessor, enum, constant, member naming을 CODINGSTYLE에 맞추고 repository callsites를 갱신한다.
  4. Production public/protected declarations와 비자명한 local-axis, director, stiffness, recovery, sign/order helper에 Doxygen를 추가한다. Tests에는 추가하지 않는다.
  5. B33/MITC4 formula, quadrature, physical/drilling separation, scale-aware validation, result signs와 floating-point operation order를 그대로 유지한다.

Acceptance Criteria

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

RED에서는 updated test callsite가 old production API와 불일치해야 한다. GREEN에서는 focused suites와 전체 CTest가 통과해야 한다.

검증 및 상태 갱신

  • RED/Green commands와 test inventory를 현재 Step summary에 기록한다.
  • 성공 시 현재 Step만 completed로 갱신한다.
  • upstream formulation과 충돌하면 구현하지 말고 blocked로 기록한다.
  • timestamp, retry, commit, advancement는 Executor 소유다.

금지사항

  • 추상 element/material/property hierarchy를 추가하지 마라. 이유: Step 12–14 소유다.
  • duplicate vector helper를 제거하지 마라. 이유: Step 7–9에서 test-first로 수행한다.
  • formulation 또는 reference tolerance를 수정하지 마라.
  • 직접 commit하거나 hook script를 수동 실행하지 마라.