Files
FESADev/phases/linear-static-mitc4-shell/step0.md
T

3.6 KiB

Step 0: Shell Semantic Model

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

읽어야 할 파일

  • /AGENTS.md
  • ../../docs/solver-core/README.md
  • ../../docs/solver-core/README.md
  • ../../docs/solver-core/README.md
  • ../../docs/solver-core/README.md
  • ../../docs/solver-core/README.md
  • /.codex/hooks.json
  • ../../docs/linear-static-mitc4-shell/README.md
  • ../../docs/linear-static-mitc4-shell/README.md
  • ../../docs/linear-static-mitc4-shell/README.md
  • ../../docs/linear-static-mitc4-shell/formulation.md
  • ../../docs/linear-static-mitc4-shell/README.md
  • ../../docs/linear-static-mitc4-shell/README.md
  • ../../docs/linear-static-mitc4-shell/README.md
  • /phases/index.json
  • /phases/linear-static-mitc4-shell/index.json
  • /phases/linear-static-mitc4-shell/step0.md
  • /include/fesa/model/model_types.hpp
  • /include/fesa/model/domain.hpp
  • /src/fesa/model/domain.cpp
  • /tests/unit/model/model_types_test.cpp
  • /tests/unit/model/domain_test.cpp

필수 파일이 없거나 승인 계약과 충돌하면 현재 Step을 blocked로 기록하고 중단한다.

작업

Requirements 002-016, 024의 semantic ownership만 구현한다.

  1. 먼저 MITC4-MODEL-001과 MITC4-MODEL-002를 기존 model tests에 추가한다.
  2. Tests는 four-node connectivity, stable SourceEntityId, source type S4|S4R와 internal FESA-MITC4 identity 분리, finite positive thickness와 material/section indices, optional initial nodal director/frame storage, declaration order를 검증한다.
  3. Production은 model_types.hpp와 필요한 Domain const accessor에만 최소 추가한다. Candidate records are ShellSourceElementType, ShellSection, Mitc4ShellDefinition and a shell-only node director/frame record.
  4. 기존 EulerBeam3DDefinition, GeneralBeamSection, B33 accessors를 보존한다.
  5. Node/Element에 equation id를 넣지 않는다. Director는 dimensionless unit vector이고 thickness와 별도다.

Acceptance Criteria

먼저 다음 configure를 실행한다.

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

RED test를 작성한 뒤 아래 build/test가 missing shell semantic behavior 때문에 실패함을 기록한다. Compile failure면 그 expected failure를 기록하고 CTest는 GREEN 뒤 실행한다.

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

GREEN 뒤 focused와 full VERIFY:

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

검증 및 상태 갱신

  • RED command와 예상 failure, GREEN/focused/full 결과를 다음 Step summary에 남긴다.
  • 성공 시 현재 Step만 completed와 한 줄 summary로 갱신한다.
  • 3회 후 실패면 error/error_message, 사용자 결정이 필요하면 blocked/blocked_reason을 기록한다.
  • timestamp, retry, commit, 다음 Step 선택은 Executor 소유다.

금지사항

  • Parser, element kernel, DOF, assembly를 수정하지 마라. 이유: Step 0은 model layer만 소유한다.
  • 공통 public Element hierarchy를 만들지 마라. 이유: 승인된 아키텍처 범위가 아니다.
  • 기존 B33 record를 제거하거나 의미를 바꾸지 마라. 이유: V0 회귀를 막는다.
  • 직접 commit하거나 hook script를 수동 실행하지 마라. 이유: Executor/hook 소유권이다.
  • reference/ 파일을 수정하거나 Abaqus를 실행하지 마라.