Files
2026-08-15 03:14:34 +09:00

4.1 KiB

Step 8: Core Diagnostics

담당 역할과 필수 스킬

  • 담당 역할: implementation-agent
  • 필수 스킬: fesa-cpp-msvc-tdd

읽어야 할 파일

  • /AGENTS.md
  • /docs/ARCHITECTURE.md
  • /docs/ADR.md
  • /docs/linear-static-3d-euler-beam/requirements.md
  • /docs/linear-static-3d-euler-beam/io.md
  • /docs/linear-static-3d-euler-beam/implementation-plan.md
  • /include/fesa/build_info.hpp
  • /src/fesa/CMakeLists.txt
  • /tests/CMakeLists.txt

소유 파일

  • Create: /include/fesa/core/source_identity.hpp
  • Create: /include/fesa/core/diagnostic.hpp
  • Create: /include/fesa/core/status.hpp
  • Create: /src/fesa/core/diagnostic.cpp
  • Create: /src/fesa/core/status.cpp
  • Create: /tests/unit/core/source_identity_test.cpp
  • Create: /tests/unit/core/diagnostic_test.cpp
  • Create: /tests/unit/core/status_test.cpp
  • Modify: /src/fesa/CMakeLists.txt
  • Modify: /tests/CMakeLists.txt

작업

Step 6의 file plan을 따르며 core ID, source location, diagnostic, status/result type만 구현하라. 최소 public 계약은 아래 의미를 제공해야 한다.

struct SourceLocation { std::filesystem::path file; std::size_t line; };
struct SourceEntityId { std::string instanceName; std::int64_t sourceLabel; };
enum class Severity { warning, error };
struct Diagnostic {
    Severity severity;
    std::string code;
    SourceLocation location;
    std::string keyword;
    std::string entityIdentity;
    std::string message;
};
class Status {
public:
    static Status ok();
    static Status failure(std::vector<Diagnostic> diagnostics);
    bool isOk() const noexcept;
    const std::vector<Diagnostic>& diagnostics() const noexcept;
};
template<class T> class Result;

Result<T>는 성공 value 또는 실패 Status를 소유하고 실패 value access를 거부한다. Diagnostic ordering helper는 file, line, keyword, entity identity, code 순으로 stable하게 정렬한다. core public header는 MKL/TBB/HDF5에 의존하지 않는다.

위 exact 파일을 생성하고 각 production stem에 대응하는 test를 먼저 작성하라. Test suite label/regex는 CoreDiagnostics로 식별 가능해야 한다.

Acceptance Criteria

RED에서는 production 파일을 만들기 전에 다음 targeted command가 missing header/symbol로 실패하는 것을 확인하고 구현 report 또는 step summary용 evidence를 남긴다.

cmake --build .harness/build --config Debug --target fesa_tests
ctest --test-dir .harness/build -C Debug -R CoreDiagnostics --output-on-failure

구현 후 GREEN/VERIFY:

cmake -S . -B .harness/build -A x64 `
  -DFESA_GTEST_SOURCE_DIR=C:/git/googletest `
  "-DMKL_DIR=C:/Program Files (x86)/Intel/oneAPI/mkl/2026.1/lib/cmake/mkl" `
  "-DTBB_DIR=C:/Program Files (x86)/Intel/oneAPI/tbb/2023.1/lib/cmake/tbb" `
  "-DHDF5_DIR=C:/Program Files/HDF_Group/HDF5/2.1.1/cmake"
cmake --build .harness/build --config Debug
ctest --test-dir .harness/build -C Debug -R CoreDiagnostics --output-on-failure
ctest --test-dir .harness/build -C Debug --show-only=json-v1
ctest --test-dir .harness/build -C Debug --output-on-failure

Tests는 value/error exclusivity, move/copy, failed access, exact diagnostic fields와 deterministic ordering을 검증해야 한다.

검증 절차

  1. GoogleTest를 먼저 추가하고 targeted RED를 관찰한다.
  2. 최소 production 구현으로 targeted GREEN을 만든다.
  3. 전체 MSVC x64 Debug build/CTest VERIFY를 실행한다.
  4. /docs/linear-static-3d-euler-beam/implementation-report.md의 Step 8 section에 실제 RED/GREEN/VERIFY command, exit code, 핵심 output과 변경 파일을 기록한다.
  5. public header dependency를 검토하고 Step 8에 completed와 RED/GREEN/VERIFY 요약을 기록한다.

금지사항

  • parser-specific keyword policy를 core에 넣지 마라. 이유: layer dependency를 역전시킨다.
  • exception text에 backend-specific detail을 노출하지 마라. 이유: structured diagnostic이 계약이다.
  • 기존 build/test 동작을 재구성하지 마라. 이유: Step 7 범위다.
  • 직접 commit하지 마라. 이유: Harness executor가 담당한다.