baram2584/FESADev
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

modify documents

Browse Source
This commit is contained in:
김경종
2026-06-05 16:58:13 +09:00
parent 5a23502570
commit 92a5cb19c0
38 changed files with 268 additions and 45 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/AGENT_RULES.md
+92
View File
@@ -0,0 +1,92 @@
# FESA Agent Rules
## Purpose
This document contains the common rules every FESA AI Agent must read before doing project work. The broader solver agent design document is background material, not a required per-run rules file.
## Required Startup Context
Before changing code or documents, every Agent must read:
1. `AGENTS.md`
2. `docs/PLAN.md`
3. `docs/PROGRESS.md`
4. `docs/WORKNOTE.md`
5. `docs/AGENT_RULES.md`
6. The task-specific upstream documents under `docs/requirements/`, `docs/research/`, `docs/formulations/`, `docs/io-definitions/`, `docs/reference-models/`, `docs/implementation-plans/`, or related phase folders.
## Global Solver Workflow
All solver features follow this stage-gated workflow:
1. Define solver feature requirements.
2. Research books, papers, manuals, benchmarks, and reference implementations.
3. Write FEM formulation for implementation.
4. Define solver input and output data.
5. Prepare TDD test models and reference solver artifact contracts.
6. Implement code test-first.
7. Compare FESA results against stored reference solver results.
8. Mark implementation complete only when the tolerance policy passes.
9. Prepare release evidence.
Do not skip upstream gates by inventing missing requirements, formulations, tolerances, I/O schemas, or reference artifacts during implementation.
## Common Boundaries
- Do not run Abaqus, Nastran, or any reference solver unless the user explicitly authorizes a separate reference-generation phase.
- Do not generate or edit reference artifacts unless the current task is explicitly a reference artifact preparation task.
- Do not approve release readiness from build success alone.
- Do not treat successful execution as numerical correctness.
- Do not change tolerance policies, formulations, I/O contracts, or reference model contracts from an implementation or correction task.
- Do not hide gaps behind words like accurate, Abaqus-like, robust, or production-ready. Convert them into measurable criteria or open issues.
## Required Verification Standard
- Default validation command: `python scripts/validate_workspace.py`.
- Harness self-test command: `python -m unittest discover -s scripts -p "test_*.py"`.
- C++ validation target: CMake + MSVC + x64 + Debug + CTest.
- C++ production changes require related C++ tests.
- New behavior must follow RED -> GREEN -> VERIFY unless the task is documentation-only.
- Current MITC4 comparison tolerance is a single value `1e-5`; each compared scalar passes when `abs(error) <= 1e-5` or `relative(error) <= 1e-5`.
## Handoff Files
Use the shared handoff files:
- `docs/PLAN.md`: overall plan, sequencing, acceptance criteria, and blockers.
- `docs/PROGRESS.md`: completed work, current state, next tasks, and latest validation.
- `docs/WORKNOTE.md`: mistakes, failed approaches, environment traps, and lessons for future Agents.
Update rules:
- Update `docs/PLAN.md` when scope, ordering, acceptance criteria, or blockers change.
- Update `docs/PROGRESS.md` after meaningful completion or validation.
- Update `docs/WORKNOTE.md` after mistakes, failed approaches, repeated failures, environment traps, or decisions that future Agents should not rediscover.
- Do not delete another Agent's dated note unless the user explicitly requests it.
- If handoff files conflict with the newest user instruction, follow the newest user instruction and record the conflict.
## Failure Routing
When work fails, classify the failure before fixing:
- requirements ambiguity
- research/evidence gap
- formulation defect
- numerical review issue
- I/O schema mismatch
- missing or invalid reference artifact
- implementation defect
- build/configuration failure
- reference comparison tolerance failure
- physics plausibility failure
- release readiness gap
Repeated failures must be routed back to the owning upstream stage instead of continuing an unbounded correction loop.
## Agent Output Discipline
- Each Agent writes the artifact for its stage and records downstream handoff items.
- Every must requirement needs a verification method and acceptance criteria.
- Every formulation needs clear DOF, coordinate, unit, sign, Jacobian, integration, and recovery rules.
- Every I/O contract needs supported syntax, unsupported behavior, internal mapping, schema, units, component names, and matching rules.
- Every reference model contract needs model purpose, compared quantities, artifacts, provenance, and limitations.
- Every implementation plan needs test-first tasks, target commands, candidate files, and traceability to upstream requirements.
- Every verification report needs compared rows, missing/extra rows, max absolute error, max relative error, worst id/component, pass/fail, and failure classification.
## Current Project Defaults
- Initial feature id: `mitc4-linear-static-shell`.
- Initial result/reference format: HDF5.
- Reference policy: stored Abaqus S4R is primary for pass/fail; Abaqus S4 is diagnostic.
- Required compared quantities: nodal displacement, reaction, element internal force/resultant, and stress.
- Agents must preserve OpenSees-inspired architecture while using modern C++17 RAII and FESA ownership boundaries.
docs/PLAN.md
+39
View File
@@ -0,0 +1,39 @@
# FESA Multi-Agent Plan
## Purpose
This file tells a new AI Agent what work is planned and how to continue without reconstructing project intent from the full conversation.
New Agents must read `AGENTS.md`, this file, `docs/PROGRESS.md`, `docs/WORKNOTE.md`, and `docs/AGENT_RULES.md` before editing files.
## Active Objective
Build the FESA structural solver foundation around the initial feature `mitc4-linear-static-shell`.
## Current High-Level Plan
1. Maintain project-level documentation and handoff files.
2. Define requirements for `mitc4-linear-static-shell`.
3. Gather research evidence for MITC4, OpenSees `ShellMITC4`, Abaqus S4/S4R, patch tests, and Scordelis-Lo.
4. Write FEM formulation for the MITC4 linear static shell feature.
5. Define Abaqus `.inp` input subset and HDF5 output/reference schemas.
6. Define stored Abaqus S4R/S4 reference model bundles.
7. Write a TDD implementation plan.
8. Implement C++17/MSVC code using CMake/CTest, MKL, TBB, and HDF5.
9. Compare FESA HDF5 results against stored Abaqus S4R reference artifacts using `abs-or-rel 1e-5`.
10. Prepare release documentation after reference verification passes.
## Acceptance Criteria
- Every solver feature follows the stage-gated workflow in `AGENTS.md`.
- C++ production changes are test-first.
- `python scripts/validate_workspace.py` remains the default validation path.
- MITC4 reference comparison covers nodal displacement, reaction, element internal force/resultant, and stress.
- Result comparison uses a single tolerance value `1e-5` with absolute-or-relative pass logic.
## Coordination Rules
- Update this file when the plan, scope, ordering, or acceptance criteria change.
- Update `docs/PROGRESS.md` after completing work or running validation.
- Update `docs/WORKNOTE.md` after mistakes, failed approaches, environment traps, or decisions that future Agents should not rediscover.
- Keep `.codex/agents/*.toml` and `.codex/skills/*/SKILL.md` pointed at `docs/AGENT_RULES.md` for common operating rules.
## Known Blockers
- No CMake project exists yet, so `python scripts/validate_workspace.py` currently takes the no-op path.
- HDF5 is not detected in standard local environment paths; implementation will need `HDF5_ROOT` or `HDF5_DIR`.
- Abaqus reference artifacts are not generated by Agents and must be supplied by a human-approved process.
docs/PROGRESS.md
+41
View File
@@ -0,0 +1,41 @@
# FESA Multi-Agent Progress
## Current Status
- Project documentation has been reframed from a harness-only project to the FESA structural solver project.
- Initial MITC4 solver implementation plan exists in `docs/project-plan/SOLVER_IMPLEMENT_INITIAL_PLAN.md`.
- Solver architecture guidance exists in `docs/ARCHITECTURE.md`.
- ADR and PRD have been updated for MITC4, MKL, TBB, HDF5, tolerance, reference artifacts, and solver state separation.
- Multi-Agent coordination files live under `docs/`: `docs/PLAN.md`, `docs/PROGRESS.md`, and `docs/WORKNOTE.md`.
- Project plan/design documents live under `docs/project-plan/`.
- Common per-run AI Agent rules live in `docs/AGENT_RULES.md`.
## Completed
- Defined the nine-step solver development workflow.
- Recorded initial MITC4 feature scope: linear static, MITC4 shell, Abaqus `.inp` subset, HDF5 output, Abaqus S4R primary reference.
- Recorded tolerance policy: `abs(error) <= 1e-5 OR relative(error) <= 1e-5`.
- Recorded architecture principles: `Domain`, `AnalysisModel`, `AnalysisState`, `DofManager`, factory/registry, adapter layers, deterministic TBB assembly, MKL PARDISO, HDF5 result model.
- Moved handoff documents from repository root to `docs/`.
- Moved solver plan/design documents to `docs/project-plan/` and updated agent, skill, test, and document references.
- Extracted common per-run rules from the solver agent design into `docs/AGENT_RULES.md`.
- Updated `.codex/agents/*.toml`, `.codex/skills/*/SKILL.md`, and related tests to reference `docs/AGENT_RULES.md` instead of the solver agent design document.
## In Progress
- Ready for the next stage: requirements baseline for `mitc4-linear-static-shell`.
## Next Tasks
1. Create `docs/requirements/mitc4-linear-static-shell.md`.
2. Create `docs/research/mitc4-linear-static-shell-research.md`.
3. Create `docs/formulations/mitc4-linear-static-shell-formulation.md`.
4. Create `docs/io-definitions/mitc4-linear-static-shell-io.md`.
5. Create `docs/reference-models/mitc4-linear-static-shell-reference-models.md`.
6. Create `docs/implementation-plans/mitc4-linear-static-shell-implementation-plan.md`.
## Last Validation
- 2026-06-05: After extracting `docs/AGENT_RULES.md`, `python -m unittest discover -s scripts -p "test_*.py"` passed. 85 tests ran successfully.
- 2026-06-05: `python scripts/validate_workspace.py` passed through the expected no-op path because no root `CMakeLists.txt` exists yet.
- 2026-06-05: After document relocation and reference updates, `python -m unittest discover -s scripts -p "test_*.py"` passed. 85 tests ran successfully.
- 2026-06-05: `python scripts/validate_workspace.py` passed through the expected no-op path because no root `CMakeLists.txt` exists yet.
## Open Questions
- Exact HDF5 C library installation path is not known.
- Stored Abaqus S4R/S4 reference artifact generation process is not yet defined.
docs/WORKNOTE.md
+26
View File
@@ -0,0 +1,26 @@
# FESA Multi-Agent Work Notes
## Purpose
This file records mistakes, failed attempts, environment traps, and lessons learned so future AI Agents do not repeat them.
Add dated entries. Do not delete another Agent's note unless the user explicitly asks.
## Notes
### 2026-06-05 - HDF5 Not Found In Standard Paths
During planning, standard checks for `HDF5_ROOT`, `HDF5_DIR`, `h5dump`, and obvious Program Files HDF5 folders did not find HDF5. Future implementation should not assume HDF5 is locally installed. Use `HDF5_ROOT` or `HDF5_DIR` and fail CMake configuration with a clear diagnostic if missing.
### 2026-06-05 - Validation Currently Has No CMake Project
`python scripts/validate_workspace.py` currently exits successfully through the no-op path because there is no root `CMakeLists.txt`. This is expected until the C++ solver project is bootstrapped. Once CMake is introduced, validation must configure, build, and run CTest.
### 2026-06-05 - Reference Solvers Are Not Agent-Run
Agents must not run Abaqus or Nastran. Reference artifacts must come from a human-approved process and be stored under `references/<feature>/<model-id>/`.
### 2026-06-05 - Keep Reaction Recovery Full-System Based
For constrained DOF elimination, reactions must be recovered as `K_full * U_full - F_full`. Do not compare reactions computed only from the reduced system.
### 2026-06-05 - Avoid PowerShell UTF-8 BOM For TOML And SKILL.md
PowerShell `Set-Content -Encoding UTF8` added a UTF-8 BOM to `.codex/agents/*.toml` and `.codex/skills/*/SKILL.md`. That broke `tomllib` with `Invalid statement (at line 1, column 1)` and broke skill frontmatter parsing because files no longer started with `---`. Use BOM-free UTF-8 for mechanical rewrites, for example `[System.Text.UTF8Encoding]::new($false)` with `.NET` `WriteAllText`.
### 2026-06-05 - Mechanical Path Replacement Can Rewrite The New Target File
When replacing old document references with `docs/AGENT_RULES.md`, the new rules file itself was also included in the replacement set and briefly became self-referential. Future broad path rewrites should exclude the newly created target file or inspect it immediately after replacement.
docs/SOLVER_AGENT_DESIGN.md → docs/project-plan/SOLVER_AGENT_DESIGN.md
View File
docs/SOLVER_ARCHITECTURE_INITIAL_DISIGN.md → docs/project-plan/SOLVER_ARCHITECTURE_INITIAL_DISIGN.md
View File
docs/project-plan/SOLVER_IMPLEMENT_INITIAL_PLAN.md
+313
View File
@@ -0,0 +1,313 @@
# MITC4 Linear Static Shell Solver Initial Implementation Plan
## Summary
FESA will implement an initial finite element structural solver feature named `mitc4-linear-static-shell`. The feature reads an Abaqus-style input file, builds an internal finite element model, performs linear static analysis with a MITC4 shell element, writes HDF5 results, and verifies those results against stored Abaqus reference artifacts.
The implementation must follow the full solver development workflow:
1. Define solver feature requirements.
2. Research books, papers, manuals, and related solver implementations.
3. Write the finite element formulation required for code implementation.
4. Define solver input and output data contracts.
5. Create TDD test models for both FESA and the reference solver.
6. Implement code.
7. Compare FESA results against reference solver results for nodal displacement, reaction, element internal force, and stress.
8. Mark implementation complete only when result differences are within tolerance.
9. Release the solver feature.
## Scope
Feature id: `mitc4-linear-static-shell`
Included:
- Linear static structural analysis.
- MITC4 4-node shell element.
- Six DOF per node: `U1, U2, U3, UR1, UR2, UR3`.
- Single-layer isotropic linear elastic shell section.
- Abaqus `.inp` subset input.
- Intel oneAPI MKL CSR/PARDISO sparse linear solve.
- Intel oneAPI TBB parallel element computation and result recovery.
- HDF5 solver result output.
- Stored Abaqus S4R primary reference comparison.
- Stored Abaqus S4 diagnostic reference comparison.
Excluded:
- Nastran BDF input.
- Nonlinear geometry.
- Nonlinear material.
- Dynamic analysis.
- Buckling/eigenvalue analysis.
- Composite/layered shell section.
- Contact.
- Agent-run Abaqus or Nastran execution.
- Reference artifact generation by agents.
- OpenSees API compatibility.
## Architecture
Use OpenSees as an architectural reference, not as an API clone. FESA should use modern C++17 ownership and small testable modules.
Primary conceptual modules:
- `Domain`: model container for nodes, elements, constraints, loads, materials, sections, and analysis metadata.
- `Node`: id, coordinates, and six ordered DOFs.
- `Element`: abstract element behavior for stiffness, internal force, result recovery, and connectivity.
- `ShellMITC4Element`: four-node MITC4 implementation with 24 element DOFs.
- `Material/Section`: isotropic elastic shell section with membrane, bending, shear, and stress recovery contract.
- `Analysis`: linear static analysis driver.
- `SystemOfEqn`: DOF numbering, constraints, CSR assembly, MKL PARDISO solve.
- `ResultWriter`: HDF5 output.
- `ReferenceComparator`: HDF5 reference comparison.
## Step 1: Requirements Baseline
Create `docs/requirements/mitc4-linear-static-shell.md`.
The requirement document must define:
- analysis type: linear static
- element type: MITC4 shell
- DOF order: `U1, U2, U3, UR1, UR2, UR3`
- material: isotropic linear elastic
- section: uniform shell thickness
- input: Abaqus `.inp` subset
- output: HDF5
- verification quantities: nodal displacement, reaction, element internal force/resultant, stress
- tolerance: single value `1e-5`
- pass rule: `abs(error) <= 1e-5` or `relative(error) <= 1e-5`
Acceptance criteria:
- Every must requirement has a verification method.
- Every numerical output requirement has component names and units policy.
- Reference artifact needs are listed under `references/mitc4-linear-static-shell/`.
## Step 2: Research Evidence
Create `docs/research/mitc4-linear-static-shell-research.md`.
Research must cover:
- Dvorkin-Bathe continuum mechanics based four-node shell formulation.
- MITC4 mixed interpolation of tensorial components.
- Assumed transverse shear strain interpolation and shear locking.
- OpenSees `ShellMITC4` class structure and resultants.
- Abaqus S4/S4R behavior as practical reference elements.
- Patch tests and Scordelis-Lo shell benchmark.
The research document must separate verified source facts from implementation inference.
## Step 3: FEM Formulation
Create `docs/formulations/mitc4-linear-static-shell-formulation.md`.
The formulation must define:
- reference coordinates and node ordering.
- shell midsurface interpolation.
- director and local coordinate basis policy.
- six-DOF nodal displacement vector.
- membrane, bending, transverse shear strain measures.
- MITC transverse shear tying/interpolation.
- isotropic shell constitutive matrix.
- element stiffness expression.
- 2x2 Gauss integration.
- drill stiffness policy.
- stress and resultant recovery.
- invalid Jacobian and degenerate element checks.
Default drill stiffness policy:
- v0 hardcodes `alpha=1`.
- `Ktt = alpha * min_eigenvalue(D_membrane)`.
- Input override is deferred to a later phase.
## Step 4: I/O Contract
Create `docs/io-definitions/mitc4-linear-static-shell-io.md`.
Input subset:
- `*NODE`
- `*ELEMENT, TYPE=S4`
- `*ELEMENT, TYPE=S4R`
- `*MATERIAL`
- `*ELASTIC`
- `*SHELL SECTION`
- `*BOUNDARY`
- `*CLOAD`
- `*STEP`
Output format:
- HDF5 file.
- No CSV output is required for this feature.
Required HDF5 layout:
```text
/metadata
feature_id
solver_version
model_id
units
tolerance
reference_solver
/mesh/nodes
/mesh/elements/mitc4/connectivity
/results/step_000/frame_000/nodal/displacement
/results/step_000/frame_000/nodal/reaction
/results/step_000/frame_000/element/forces
/results/step_000/frame_000/element/stress
```
Required result components:
- displacement: `U1, U2, U3, UR1, UR2, UR3`
- reaction: `RF1, RF2, RF3, RM1, RM2, RM3`
- element force/resultant: `N11, N22, N12, M11, M22, M12, Q13, Q23`
- stress: `S11, S22, S12, S13, S23`
## Step 5: TDD Reference Models
Create `docs/reference-models/mitc4-linear-static-shell-reference-models.md`.
Reference policy:
- FESA agents do not run Abaqus or Nastran.
- Stored Abaqus S4R HDF5 artifacts are the primary pass/fail reference.
- Stored Abaqus S4 HDF5 artifacts are diagnostic only.
Initial model portfolio:
- membrane patch
- bending patch
- transverse shear patch
- twist patch
- coarse Scordelis-Lo shell
Each model bundle must include:
```text
references/mitc4-linear-static-shell/<model-id>/
model.inp
metadata.json
abaqus_s4r/results.h5
abaqus_s4/results.h5
README.md
```
`metadata.json` must record:
- model id
- source/provenance
- Abaqus version
- element type
- units
- output locations
- tolerance `1e-5`
- compared quantities
- known limitations
## Step 6: Code Implementation Plan
Create `docs/implementation-plans/mitc4-linear-static-shell-implementation-plan.md`.
Implementation must be TDD-first:
1. Write failing parser tests.
2. Implement minimum Abaqus `.inp` parser behavior.
3. Write failing MITC4 element tests.
4. Implement shape functions, Jacobian checks, MITC shear interpolation, stiffness, and recovery.
5. Write failing assembly tests.
6. Implement DOF numbering, constraint handling, and deterministic CSR assembly.
7. Write failing MKL PARDISO solve tests.
8. Implement solver wrapper and reaction recovery.
9. Write failing TBB deterministic parallel tests.
10. Implement TBB parallel element computations with deterministic merge.
11. Write failing HDF5 schema tests.
12. Implement HDF5 C API RAII wrapper and result writer.
13. Write failing reference comparison tests.
14. Implement HDF5 reference comparator.
15. Run full validation.
Required validation commands:
```powershell
python -m unittest discover -s scripts -p "test_*.py"
python scripts/validate_workspace.py
ctest --test-dir build/msvc-debug --output-on-failure -C Debug -L mitc4
```
## Step 7: Reference Verification
Create `docs/reference-verifications/mitc4-linear-static-shell-reference-verification.md`.
Comparison inputs:
- FESA `results.h5`
- stored Abaqus S4R `results.h5`
- diagnostic Abaqus S4 `results.h5`
- metadata tolerance and schema version
Compared quantities:
- nodal displacement
- nodal reaction
- element internal force/resultant
- stress
Matching rules:
- node id for nodal quantities
- element id plus Gauss point id for element quantities
- component name for scalar comparisons
Pass rule:
```text
abs(error) <= 1e-5 OR relative(error) <= 1e-5
```
Report:
- compared quantity
- number of matched rows
- missing rows
- extra rows
- maximum absolute error
- maximum relative error
- worst id
- worst component
- pass/fail
## Step 8: Completion Decision
Implementation is complete only when:
- all required tests pass;
- CMake/MSVC/x64/Debug build passes;
- all required HDF5 result quantities compare within tolerance `1e-5`;
- no required reference artifact is missing;
- failures are not hidden as known limitations.
If comparison fails, classify the failure as one of:
- missing reference artifact
- schema mismatch
- id mismatch
- unit or coordinate mismatch
- formulation defect
- implementation defect
- tolerance failure
- reference artifact issue
Then return to the owning workflow step.
## Step 9: Release
Create `docs/releases/mitc4-linear-static-shell-release.md`.
Release document must include:
- feature id and scope
- supported input keywords
- supported outputs
- dependency versions
- test model list
- reference comparison summary
- tolerance policy
- known limitations
- validation commands and status
Release is not approved by build success alone. Release requires reference comparison success and documented limitations.
## Dependency Plan
MKL:
- Use oneAPI MKL through `MKLROOT` or known oneAPI path.
- Use CSR matrix storage and PARDISO for the global linear system.
TBB:
- Use oneAPI TBB through `TBBROOT` or known oneAPI path.
- Parallelize element-local stiffness and result recovery.
- Use deterministic merge for global assembly.
HDF5:
- FESA provides an internal RAII wrapper around the HDF5 C API.
- The HDF5 C library itself must be supplied through `HDF5_ROOT` or `HDF5_DIR`.
- HDF5 is required for solver output and reference comparison.
## Assumptions
- Abaqus reference artifacts are generated outside the agent workflow.
- S4R is the primary reference for pass/fail.
- S4 is diagnostic and does not determine pass/fail.
- The single tolerance value is `1e-5`.
- The initial implementation prioritizes correctness and traceability over broad element coverage.
docs/SOLVER_SKILL_DESIGN.md → docs/project-plan/SOLVER_SKILL_DESIGN.md
+3 -3
View File
@@ -11,7 +11,7 @@ Agent는 역할과 책임 단위이고, skill은 여러 Agent가 반복적으로
- Skill은 `.codex/skills/<skill-name>/SKILL.md`에 둔다.
- 각 skill은 필수 frontmatter `name`, `description`과 UI metadata `agents/openai.yaml`을 가진다.
- Skill 본문은 agent TOML의 역할 설명을 반복하지 않고, 입력, 절차, 산출물, 금지사항, 품질 gate, handoff를 정의한다.
- Skill은 `AGENTS.md`와 `docs/SOLVER_AGENT_DESIGN.md`를 공통 상위 기준으로 읽는다.
- Skill은 `AGENTS.md`와 `docs/AGENT_RULES.md`를 공통 상위 기준으로 읽는다.
- Abaqus, Nastran 또는 reference solver 실행은 skill 범위에 포함하지 않는다.
- Reference CSV 생성 또는 수정은 skill 범위에 포함하지 않는다.
- C++ 구현 관련 skill은 C++17 이상, MSVC, CMake, CTest, TDD 원칙을 따른다.
@@ -155,10 +155,10 @@ Skill 구성 검증은 `scripts/test_fesa_solver_skills.py`가 담당한다.
- 10개 solver skill의 `SKILL.md` 존재 여부
- YAML frontmatter의 `name`, `description`
- 공통 섹션: `Inputs`, `Workflow`, `Output Contract`, `Boundaries`, `Quality Gate`, `Handoff`
- `AGENTS.md`와 `docs/SOLVER_AGENT_DESIGN.md` 참조
- `AGENTS.md`와 `docs/AGENT_RULES.md` 참조
- skill-specific 핵심 문구와 산출물 경로
- `agents/openai.yaml` UI metadata
- 이 문서가 아니라 실제 skill 파일이 기준이 되도록 `docs/SOLVER_SKILL_DESIGN.md`에 대한 skill 본문 참조 금지
- 이 문서가 아니라 실제 skill 파일이 기준이 되도록 `docs/project-plan/SOLVER_SKILL_DESIGN.md`에 대한 skill 본문 참조 금지
검증 명령: