# 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 계약은 아래 의미를 제공해야 한다.

```cpp
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를 남긴다.

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

구현 후 GREEN/VERIFY:

```powershell
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가 담당한다.