diff --git a/phases/results-and-pipeline/index.json b/phases/results-and-pipeline/index.json
index c4ee8f6..b4b8f7c 100644
--- a/phases/results-and-pipeline/index.json
+++ b/phases/results-and-pipeline/index.json
@@ -5,7 +5,10 @@
{
"step": 0,
"name": "result-database",
- "status": "pending"
+ "status": "completed",
+ "started_at": "2026-08-01T00:01:45+0900",
+ "summary": "Added HDF5-independent nodal result aggregates and results-stage validation for sizes, duplicate nodes/steps/frames, and finite values with focused tests.",
+ "completed_at": "2026-08-01T00:14:53+0900"
},
{
"step": 1,
@@ -22,5 +25,6 @@
"name": "cli-pipeline-integration",
"status": "pending"
}
- ]
-}
+ ],
+ "created_at": "2026-08-01T00:01:45+0900"
+}
\ No newline at end of file
diff --git a/phases/results-and-pipeline/step0-output.json b/phases/results-and-pipeline/step0-output.json
new file mode 100644
index 0000000..e21f846
--- /dev/null
+++ b/phases/results-and-pipeline/step0-output.json
@@ -0,0 +1,7 @@
+{
+ "step": 0,
+ "name": "result-database",
+ "exitCode": 0,
+ "stdout": "{\"type\":\"thread.started\",\"thread_id\":\"019fb8b2-108c-7f51-9e0b-e321c993fbd7\"}\n{\"type\":\"item.completed\",\"item\":{\"id\":\"item_0\",\"type\":\"error\",\"message\":\"`--dangerously-bypass-hook-trust` is enabled. Enabled hooks may run without review for this invocation.\"}}\n{\"type\":\"item.completed\",\"item\":{\"id\":\"item_1\",\"type\":\"error\",\"message\":\"`--dangerously-bypass-hook-trust` is enabled. Enabled hooks may run without review for this invocation.\"}}\n{\"type\":\"turn.started\"}\n{\"type\":\"item.completed\",\"item\":{\"id\":\"item_2\",\"type\":\"agent_message\",\"text\":\"Step 0 범위만 진행하겠습니다. 먼저 `superpowers:using-superpowers`, `brainstorming`, `writing-plans`, `test-driven-development`, `verification-before-completion`과 저장소의 `harness` 지침을 읽어 작업 계약을 정렬한 뒤, 실패 테스트 → 최소 구현 → 지정 AC → index 갱신 순서로 수행하겠습니다. 커밋은 만들지 않습니다.\"}}\n{\"type\":\"item.started\",\"item\":{\"id\":\"item_3\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\WINDOWS\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Raw 'C:\\\\\\\\Users\\\\\\\\baram\\\\\\\\.codex\\\\\\\\plugins\\\\\\\\cache\\\\\\\\openai-curated-remote\\\\\\\\superpowers\\\\\\\\6.2.0\\\\\\\\skills\\\\\\\\using-superpowers\\\\\\\\SKILL.md'; Get-Content -Raw 'C:\\\\\\\\Users\\\\\\\\baram\\\\\\\\.codex\\\\\\\\plugins\\\\\\\\cache\\\\\\\\openai-curated-remote\\\\\\\\superpowers\\\\\\\\6.2.0\\\\\\\\skills\\\\\\\\brainstorming\\\\\\\\SKILL.md'; Get-Content -Raw 'C:\\\\\\\\Users\\\\\\\\baram\\\\\\\\.codex\\\\\\\\plugins\\\\\\\\cache\\\\\\\\openai-curated-remote\\\\\\\\superpowers\\\\\\\\6.2.0\\\\\\\\skills\\\\\\\\writing-plans\\\\\\\\SKILL.md'; Get-Content -Raw 'C:\\\\\\\\Users\\\\\\\\baram\\\\\\\\.codex\\\\\\\\plugins\\\\\\\\cache\\\\\\\\openai-curated-remote\\\\\\\\superpowers\\\\\\\\6.2.0\\\\\\\\skills\\\\\\\\test-driven-development\\\\\\\\SKILL.md'; Get-Content -Raw 'C:\\\\\\\\Users\\\\\\\\baram\\\\\\\\.codex\\\\\\\\plugins\\\\\\\\cache\\\\\\\\openai-curated-remote\\\\\\\\superpowers\\\\\\\\6.2.0\\\\\\\\skills\\\\\\\\verification-before-completion\\\\\\\\SKILL.md'; Get-Content -Raw '.agents\\\\\\\\skills\\\\\\\\harness\\\\\\\\SKILL.md'\\\"\",\"aggregated_output\":\"\",\"exit_code\":null,\"status\":\"in_progress\"}}\n{\"type\":\"item.completed\",\"item\":{\"id\":\"item_3\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\WINDOWS\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Raw 'C:\\\\\\\\Users\\\\\\\\baram\\\\\\\\.codex\\\\\\\\plugins\\\\\\\\cache\\\\\\\\openai-curated-remote\\\\\\\\superpowers\\\\\\\\6.2.0\\\\\\\\skills\\\\\\\\using-superpowers\\\\\\\\SKILL.md'; Get-Content -Raw 'C:\\\\\\\\Users\\\\\\\\baram\\\\\\\\.codex\\\\\\\\plugins\\\\\\\\cache\\\\\\\\openai-curated-remote\\\\\\\\superpowers\\\\\\\\6.2.0\\\\\\\\skills\\\\\\\\brainstorming\\\\\\\\SKILL.md'; Get-Content -Raw 'C:\\\\\\\\Users\\\\\\\\baram\\\\\\\\.codex\\\\\\\\plugins\\\\\\\\cache\\\\\\\\openai-curated-remote\\\\\\\\superpowers\\\\\\\\6.2.0\\\\\\\\skills\\\\\\\\writing-plans\\\\\\\\SKILL.md'; Get-Content -Raw 'C:\\\\\\\\Users\\\\\\\\baram\\\\\\\\.codex\\\\\\\\plugins\\\\\\\\cache\\\\\\\\openai-curated-remote\\\\\\\\superpowers\\\\\\\\6.2.0\\\\\\\\skills\\\\\\\\test-driven-development\\\\\\\\SKILL.md'; Get-Content -Raw 'C:\\\\\\\\Users\\\\\\\\baram\\\\\\\\.codex\\\\\\\\plugins\\\\\\\\cache\\\\\\\\openai-curated-remote\\\\\\\\superpowers\\\\\\\\6.2.0\\\\\\\\skills\\\\\\\\verification-before-completion\\\\\\\\SKILL.md'; Get-Content -Raw '.agents\\\\\\\\skills\\\\\\\\harness\\\\\\\\SKILL.md'\\\"\",\"aggregated_output\":\"---\\nname: using-superpowers\\ndescription: Use when starting any conversation - establishes how to find and use skills, requiring skill invocation before ANY response including clarifying questions\\n---\\n\\n\\nIf you were dispatched as a subagent to execute a specific task, ignore this skill.\\n\\n\\n\\nIf you think there is even a 1% chance a skill might apply to what you are doing, you ABSOLUTELY MUST invoke the skill.\\n\\nIF A SKILL APPLIES TO YOUR TASK, YOU DO NOT HAVE A CHOICE. YOU MUST USE IT.\\n\\nThis is not negotiable. You cannot rationalize your way out of this.\\n\\n\\n## The Rule\\n\\n**Invoke relevant or requested skills BEFORE any response or action** ??including clarifying questions, exploring the codebase, or checking files. If it turns out wrong for the situation, you don't have to use it.\\n\\n**Before entering plan mode:** if you haven't already brainstormed, invoke the brainstorming skill first.\\n\\nThen announce \\\"Using [skill] to [purpose]\\\" and follow the skill exactly. If it has a checklist, create a todo per item.\\n\\n## Skill Priority\\n\\nWhen multiple skills apply, process skills come first ??they set the approach, then implementation skills (frontend-design, etc.) carry it out. Brainstorming and systematic-debugging are Superpowers' most common process skills, but the rule holds for any of them.\\n\\n- \\\"Let's build X\\\" ??superpowers:brainstorming first, then implementation skills.\\n- \\\"Fix this bug\\\" ??superpowers:systematic-debugging first, then domain skills.\\n\\n## Red Flags\\n\\nThese thoughts mean STOP?봸ou're rationalizing:\\n\\n| Thought | Reality |\\n|---------|---------|\\n| \\\"This is just a simple question\\\" | Questions are tasks. Check for skills. |\\n| \\\"I need more context first\\\" | Skill check comes BEFORE clarifying questions. |\\n| \\\"Let me explore the codebase first\\\" | Skills tell you HOW to explore. Check first. |\\n| \\\"I can check git/files quickly\\\" | Files lack conversation context. Check for skills. |\\n| \\\"Let me gather information first\\\" | Skills tell you HOW to gather information. |\\n| \\\"This doesn't need a formal skill\\\" | If a skill exists, use it. |\\n| \\\"I remember this skill\\\" | Skills evolve. Read current version. |\\n| \\\"This doesn't count as a task\\\" | Action = task. Check for skills. |\\n| \\\"The skill is overkill\\\" | Simple things become complex. Use it. |\\n| \\\"I'll just do this one thing first\\\" | Check BEFORE doing anything. |\\n| \\\"This feels productive\\\" | Undisciplined action wastes time. Skills prevent this. |\\n| \\\"I know what that means\\\" | Knowing the concept ??using the skill. Invoke it. |\\n\\n## Platform Adaptation\\n\\nIf your harness appears here, read its reference file for special instructions:\\n\\n- Codex: `references/codex-tools.md`\\n- Pi: `references/pi-tools.md`\\n- Antigravity: `references/antigravity-tools.md`\\n\\n## User Instructions\\n\\nUser instructions (CLAUDE.md, AGENTS.md, GEMINI.md, etc, direct requests) take precedence over skills, which in turn override default behavior. Only skip skill workflows or instructions when your human partner has explicitly told you to.\\n\\r\\n---\\nname: brainstorming\\ndescription: \\\"You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.\\\"\\n---\\n\\n# Brainstorming Ideas Into Designs\\n\\nHelp turn ideas into fully formed designs and specs through natural collaborative dialogue.\\n\\nStart by understanding the current project context, then ask questions one at a time to refine the idea. Once you understand what you're building, present the design and get user approval.\\n\\n\\nDo NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it. This applies to EVERY project regardless of perceived simplicity.\\n\\n\\n## Anti-Pattern: \\\"This Is Too Simple To Need A Design\\\"\\n\\nEvery project goes through this process. A todo list, a single-function utility, a config change ??all of them. \\\"Simple\\\" projects are where unexamined assumptions cause the most wasted work. The design can be short (a few sentences for truly simple projects), but you MUST present it and get approval.\\n\\n## Checklist\\n\\nYou MUST create a task for each of these items and complete them in order:\\n\\n1. **Explore project context** ??check files, docs, recent commits\\n2. **Offer the visual companion just-in-time** ??NOT upfront. The first time a question would genuinely be clearer shown than described, offer it then (its own message); on approval its browser tab opens for you. If no visual question ever arises, never offer it. See the Visual Companion section below.\\n3. **Ask clarifying questions** ??one at a time, understand purpose/constraints/success criteria\\n4. **Propose 2-3 approaches** ??with trade-offs and your recommendation\\n5. **Present design** ??in sections scaled to their complexity, get user approval after each section\\n6. **Write design doc** ??save to `docs/superpowers/specs/YYYY-MM-DD--design.md` and commit\\n7. **Spec self-review** ??quick inline check for placeholders, contradictions, ambiguity, scope (see below)\\n8. **User reviews written spec** ??ask user to review the spec file before proceeding\\n9. **Transition to implementation** ??invoke writing-plans skill to create implementation plan\\n\\n## Process Flow\\n\\n```dot\\ndigraph brainstorming {\\n \\\"Explore project context\\\" [shape=box];\\n \\\"Ask clarifying questions\\\" [shape=box];\\n \\\"Propose 2-3 approaches\\\" [shape=box];\\n \\\"Present design sections\\\" [shape=box];\\n \\\"User approves design?\\\" [shape=diamond];\\n \\\"Write design doc\\\" [shape=box];\\n \\\"Spec self-review\\\\n(fix inline)\\\" [shape=box];\\n \\\"User reviews spec?\\\" [shape=diamond];\\n \\\"Invoke writing-plans skill\\\" [shape=doublecircle];\\n\\n \\\"Explore project context\\\" -> \\\"Ask clarifying questions\\\";\\n \\\"Ask clarifying questions\\\" -> \\\"Propose 2-3 approaches\\\";\\n \\\"Propose 2-3 approaches\\\" -> \\\"Present design sections\\\";\\n \\\"Present design sections\\\" -> \\\"User approves design?\\\";\\n \\\"User approves design?\\\" -> \\\"Present design sections\\\" [label=\\\"no, revise\\\"];\\n \\\"User approves design?\\\" -> \\\"Write design doc\\\" [label=\\\"yes\\\"];\\n \\\"Write design doc\\\" -> \\\"Spec self-review\\\\n(fix inline)\\\";\\n \\\"Spec self-review\\\\n(fix inline)\\\" -> \\\"User reviews spec?\\\";\\n \\\"User reviews spec?\\\" -> \\\"Write design doc\\\" [label=\\\"changes requested\\\"];\\n \\\"User reviews spec?\\\" -> \\\"Invoke writing-plans skill\\\" [label=\\\"approved\\\"];\\n}\\n```\\n\\n**The terminal state is invoking writing-plans.** Do NOT invoke frontend-design, mcp-builder, or any other implementation skill. The ONLY skill you invoke after brainstorming is writing-plans.\\n\\n## The Process\\n\\n**Understanding the idea:**\\n\\n- Check out the current project state first (files, docs, recent commits)\\n- Before asking detailed questions, assess scope: if the request describes multiple independent subsystems (e.g., \\\"build a platform with chat, file storage, billing, and analytics\\\"), flag this immediately. Don't spend questions refining details of a project that needs to be decomposed first.\\n- If the project is too large for a single spec, help the user decompose into sub-projects: what are the independent pieces, how do they relate, what order should they be built? Then brainstorm the first sub-project through the normal design flow. Each sub-project gets its own spec ??plan ??implementation cycle.\\n- For appropriately-scoped projects, ask questions one at a time to refine the idea\\n- Prefer multiple choice questions when possible, but open-ended is fine too\\n- Only one question per message - if a topic needs more exploration, break it into multiple questions\\n- Focus on understanding: purpose, constraints, success criteria\\n\\n**Exploring approaches:**\\n\\n- Propose 2-3 different approaches with trade-offs\\n- Present options conversationally with your recommendation and reasoning\\n- Lead with your recommended option and explain why\\n- YAGNI ruthlessly - remove unnecessary features from every approach and design\\n\\n**Presenting the design:**\\n\\n- Once you believe you understand what you're building, present the design\\n- Scale each section to its complexity: a few sentences if straightforward, up to 200-300 words if nuanced\\n- Ask after each section whether it looks right so far\\n- Cover: architecture, components, data flow, error handling, testing\\n- Be ready to go back and clarify if something doesn't make sense\\n\\n**Design for isolation and clarity:**\\n\\n- Break the system into smaller units that each have one clear purpose, communicate through well-defined interfaces, and can be understood and tested independently\\n- For each unit, you should be able to answer: what does it do, how do you use it, and what does it depend on?\\n- Can someone understand what a unit does without reading its internals? Can you change the internals without breaking consumers? If not, the boundaries need work.\\n- Smaller, well-bounded units are also easier for you to work with - you reason better about code you can hold in context at once, and your edits are more reliable when files are focused. When a file grows large, that's often a signal that it's doing too much.\\n\\n**Working in existing codebases:**\\n\\n- Explore the current structure before proposing changes. Follow existing patterns.\\n- Where existing code has problems that affect the work (e.g., a file that's grown too large, unclear boundaries, tangled responsibilities), include targeted improvements as part of the design - the way a good developer improves code they're working in.\\n- Don't propose unrelated refactoring. Stay focused on what serves the current goal.\\n\\n## After the Design\\n\\n**Documentation:**\\n\\n- Write the validated design (spec) to `docs/superpowers/specs/YYYY-MM-DD--design.md`\\n - (User preferences for spec location override this default)\\n- Use elements-of-style:writing-clearly-and-concisely skill if available\\n- Commit the design document to git\\n\\n**Spec Self-Review:**\\nAfter writing the spec document, look at it with fresh eyes:\\n\\n1. **Placeholder scan:** Any \\\"TBD\\\", \\\"TODO\\\", incomplete sections, or vague requirements? Fix them.\\n2. **Internal consistency:** Do any sections contradict each other? Does the architecture match the feature descriptions?\\n3. **Scope check:** Is this focused enough for a single implementation plan, or does it need decomposition?\\n4. **Ambiguity check:** Could any requirement be interpreted two different ways? If so, pick one and make it explicit.\\n\\nFix any issues inline. No need to re-review ??just fix and move on.\\n\\n**User Review Gate:**\\nAfter the spec review loop passes, ask the user to review the written spec before proceeding:\\n\\n> \\\"Spec written and committed to ``. Please review it and let me know if you want to make any changes before we start writing out the implementation plan.\\\"\\n\\nWait for the user's response. If they request changes, make them and re-run the spec review loop. Only proceed once the user approves.\\n\\n**Implementation:**\\n\\n- Invoke the writing-plans skill to create a detailed implementation plan\\n- Do NOT invoke any other skill. writing-plans is the next step.\\n\\n## Visual Companion\\n\\nA browser-based companion for showing mockups, diagrams, and visual options during brainstorming. Available as a tool ??not a mode. Accepting the companion means it's available for questions that benefit from visual treatment; it does NOT mean every question goes through the browser.\\n\\n**Offering the companion (just-in-time):** Do NOT offer it upfront. Wait until a question would genuinely be clearer shown than told ??a real mockup / layout / diagram question, not merely a UI *topic*. The first time that happens, offer it then, as its own message:\\n> \\\"This next part might be easier if I show you ??I can put together mockups, diagrams, and comparisons in a browser tab as we go. It's still new and can be token-intensive. Want me to? I'll open it for you.\\\"\\n\\n**This offer MUST be its own message.** Only the offer ??no clarifying question, summary, or other content. Wait for the user's response. If they accept, start the server with `--open` so their browser opens to the first screen automatically. If they decline, continue text-only and don't offer again unless they raise it.\\n\\n**Per-question decision:** Even after the user accepts, decide FOR EACH QUESTION whether to use the browser or the terminal. The test: **would the user understand this better by seeing it than reading it?**\\n\\n- **Use the browser** for content that IS visual ??mockups, wireframes, layout comparisons, architecture diagrams, side-by-side visual designs\\n- **Use the terminal** for content that is text ??requirements questions, conceptual choices, tradeoff lists, A/B/C/D text options, scope decisions\\n\\nA question about a UI topic is not automatically a visual question. \\\"What does personality mean in this context?\\\" is a conceptual question ??use the terminal. \\\"Which wizard layout works better?\\\" is a visual question ??use the browser.\\n\\nIf they agree to the companion, read the detailed guide before proceeding:\\n`skills/brainstorming/visual-companion.md`\\n\\r\\n---\\nname: writing-plans\\ndescription: Use when you have a spec or requirements for a multi-step task, before touching code\\n---\\n\\n# Writing Plans\\n\\n## Overview\\n\\nWrite comprehensive implementation plans assuming the engineer has zero context for our codebase and questionable taste. Document everything they need to know: which files to touch for each task, code, testing, docs they might need to check, how to test it. Give them the whole plan as bite-sized tasks. DRY. YAGNI. TDD. Frequent commits.\\n\\nAssume they are a skilled developer, but know almost nothing about our toolset or problem domain. Assume they don't know good test design very well.\\n\\n**Announce at start:** \\\"I'm using the writing-plans skill to create the implementation plan.\\\"\\n\\n**Context:** If working in an isolated worktree, it should have been created via the `superpowers:using-git-worktrees` skill at execution time.\\n\\n**Save plans to:** `docs/superpowers/plans/YYYY-MM-DD-.md`\\n- (User preferences for plan location override this default)\\n\\n## Scope Check\\n\\nIf the spec covers multiple independent subsystems, it should have been broken into sub-project specs during brainstorming. If it wasn't, suggest breaking this into separate plans ??one per subsystem. Each plan should produce working, testable software on its own.\\n\\n## File Structure\\n\\nBefore defining tasks, map out which files will be created or modified and what each one is responsible for. This is where decomposition decisions get locked in.\\n\\n- Design units with clear boundaries and well-defined interfaces. Each file should have one clear responsibility.\\n- You reason best about code you can hold in context at once, and your edits are more reliable when files are focused. Prefer smaller, focused files over large ones that do too much.\\n- Files that change together should live together. Split by responsibility, not by technical layer.\\n- In existing codebases, follow established patterns. If the codebase uses large files, don't unilaterally restructure - but if a file you're modifying has grown unwieldy, including a split in the plan is reasonable.\\n\\nThis structure informs the task decomposition. Each task should produce self-contained changes that make sense independently.\\n\\n## Task Right-Sizing\\n\\nA task is the smallest unit that carries its own test cycle and is worth a\\nfresh reviewer's gate. When drawing task boundaries: fold setup,\\nconfiguration, scaffolding, and documentation steps into the task whose\\ndeliverable needs them; split only where a reviewer could meaningfully\\nreject one task while approving its neighbor. Each task ends with an\\nindependently testable deliverable.\\n\\n## Bite-Sized Task Granularity\\n\\n**Each step is one action (2-5 minutes):**\\n- \\\"Write the failing test\\\" - step\\n- \\\"Run it to make sure it fails\\\" - step\\n- \\\"Implement the minimal code to make the test pass\\\" - step\\n- \\\"Run the tests and make sure they pass\\\" - step\\n- \\\"Commit\\\" - step\\n\\n## Plan Document Header\\n\\n**Every plan MUST start with this header:**\\n\\n```markdown\\n# [Feature Name] Implementation Plan\\n\\n> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.\\n\\n**Goal:** [One sentence describing what this builds]\\n\\n**Architecture:** [2-3 sentences about approach]\\n\\n**Tech Stack:** [Key technologies/libraries]\\n\\n## Global Constraints\\n\\n[The spec's project-wide requirements ??version floors, dependency limits,\\nnaming and copy rules, platform requirements ??one line each, with exact\\nvalues copied verbatim from the spec. Every task's requirements implicitly\\ninclude this section.]\\n\\n---\\n```\\n\\n## Task Structure\\n\\n````markdown\\n### Task N: [Component Name]\\n\\n**Files:**\\n- Create: `exact/path/to/file.py`\\n- Modify: `exact/path/to/existing.py:123-145`\\n- Test: `tests/exact/path/to/test.py`\\n\\n**Interfaces:**\\n- Consumes: [what this task uses from earlier tasks ??exact signatures]\\n- Produces: [what later tasks rely on ??exact function names, parameter\\n and return types. A task's implementer sees only their own task; this\\n block is how they learn the names and types neighboring tasks use.]\\n\\n- [ ] **Step 1: Write the failing test**\\n\\n```python\\ndef test_specific_behavior():\\n result = function(input)\\n assert result == expected\\n```\\n\\n- [ ] **Step 2: Run test to verify it fails**\\n\\nRun: `pytest tests/path/test.py::test_name -v`\\nExpected: FAIL with \\\"function not defined\\\"\\n\\n- [ ] **Step 3: Write minimal implementation**\\n\\n```python\\ndef function(input):\\n return expected\\n```\\n\\n- [ ] **Step 4: Run test to verify it passes**\\n\\nRun: `pytest tests/path/test.py::test_name -v`\\nExpected: PASS\\n\\n- [ ] **Step 5: Commit**\\n\\n```bash\\ngit add tests/path/test.py src/path/file.py\\ngit commit -m \\\"feat: add specific feature\\\"\\n```\\n````\\n\\n## No Placeholders\\n\\nEvery step must contain the actual content an engineer needs. These are **plan failures** ??never write them:\\n- \\\"TBD\\\", \\\"TODO\\\", \\\"implement later\\\", \\\"fill in details\\\"\\n- \\\"Add appropriate error handling\\\" / \\\"add validation\\\" / \\\"handle edge cases\\\"\\n- \\\"Write tests for the above\\\" (without actual test code)\\n- \\\"Similar to Task N\\\" (repeat the code ??the engineer may be reading tasks out of order)\\n- Steps that describe what to do without showing how (code blocks required for code steps)\\n- References to types, functions, or methods not defined in any task\\n\\n## Self-Review\\n\\nAfter writing the complete plan, look at the spec with fresh eyes and check the plan against it. This is a checklist you run yourself ??not a subagent dispatch.\\n\\n**1. Spec coverage:** Skim each section/requirement in the spec. Can you point to a task that implements it? List any gaps.\\n\\n**2. Placeholder scan:** Search your plan for red flags ??any of the patterns from the \\\"No Placeholders\\\" section above. Fix them.\\n\\n**3. Type consistency:** Do the types, method signatures, and property names you used in later tasks match what you defined in earlier tasks? A function called `clearLayers()` in Task 3 but `clearFullLayers()` in Task 7 is a bug.\\n\\nIf you find issues, fix them inline. No need to re-review ??just fix and move on. If you find a spec requirement with no task, add the task.\\n\\n## Execution Handoff\\n\\nAfter saving the plan, offer execution choice:\\n\\n**\\\"Plan complete and saved to `docs/superpowers/plans/.md`. Two execution options:**\\n\\n**1. Subagent-Driven (recommended)** - I dispatch a fresh subagent per task, review between tasks, fast iteration\\n\\n**2. Inline Execution** - Execute tasks in this session using executing-plans, batch execution with checkpoints\\n\\n**Which approach?\\\"**\\n\\n**If Subagent-Driven chosen:**\\n- **REQUIRED SUB-SKILL:** Use superpowers:subagent-driven-development\\n- Fresh subagent per task + two-stage review\\n\\n**If Inline Execution chosen:**\\n- **REQUIRED SUB-SKILL:** Use superpowers:executing-plans\\n- Batch execution with checkpoints for review\\n\\r\\n---\\nname: test-driven-development\\ndescription: Use when implementing any feature or bugfix, before writing implementation code\\n---\\n\\n# Test-Driven Development (TDD)\\n\\n## Overview\\n\\nWrite the test first. Watch it fail. Write minimal code to pass.\\n\\n**Core principle:** If you didn't watch the test fail, you don't know if it tests the right thing.\\n\\n**Violating the letter of the rules is violating the spirit of the rules.**\\n\\n## When to Use\\n\\n**Always:**\\n- New features\\n- Bug fixes\\n- Refactoring\\n- Behavior changes\\n\\n**Exceptions (ask your human partner):**\\n- Throwaway prototypes\\n- Generated code\\n- Configuration files\\n\\nThinking \\\"skip TDD just this once\\\"? Stop. That's rationalization.\\n\\n## The Iron Law\\n\\n```\\nNO PRODUCTION CODE WITHOUT A FAILING TEST FIRST\\n```\\n\\nWrite code before the test? Delete it. Start over.\\n\\n**No exceptions:**\\n- Don't keep it as \\\"reference\\\"\\n- Don't \\\"adapt\\\" it while writing tests\\n- Don't look at it\\n- Delete means delete\\n\\nImplement fresh from tests. Period.\\n\\n## Red-Green-Refactor\\n\\n```dot\\ndigraph tdd_cycle {\\n rankdir=LR;\\n red [label=\\\"RED\\\\nWrite failing test\\\", shape=box, style=filled, fillcolor=\\\"#ffcccc\\\"];\\n verify_red [label=\\\"Verify fails\\\\ncorrectly\\\", shape=diamond];\\n green [label=\\\"GREEN\\\\nMinimal code\\\", shape=box, style=filled, fillcolor=\\\"#ccffcc\\\"];\\n verify_green [label=\\\"Verify passes\\\\nAll green\\\", shape=diamond];\\n refactor [label=\\\"REFACTOR\\\\nClean up\\\", shape=box, style=filled, fillcolor=\\\"#ccccff\\\"];\\n next [label=\\\"Next\\\", shape=ellipse];\\n\\n red -> verify_red;\\n verify_red -> green [label=\\\"yes\\\"];\\n verify_red -> red [label=\\\"wrong\\\\nfailure\\\"];\\n green -> verify_green;\\n verify_green -> refactor [label=\\\"yes\\\"];\\n verify_green -> green [label=\\\"no\\\"];\\n refactor -> verify_green [label=\\\"stay\\\\ngreen\\\"];\\n verify_green -> next;\\n next -> red;\\n}\\n```\\n\\n### RED - Write Failing Test\\n\\nWrite one minimal test showing what should happen.\\n\\n\\n```typescript\\ntest('retries failed operations 3 times', async () => {\\n let attempts = 0;\\n const operation = () => {\\n attempts++;\\n if (attempts < 3) throw new Error('fail');\\n return 'success';\\n };\\n\\n const result = await retryOperation(operation);\\n\\n expect(result).toBe('success');\\n expect(attempts).toBe(3);\\n});\\n```\\nClear name, tests real behavior, one thing\\n\\n\\n\\n```typescript\\ntest('retry works', async () => {\\n const mock = jest.fn()\\n .mockRejectedValueOnce(new Error())\\n .mockRejectedValueOnce(new Error())\\n .mockResolvedValueOnce('success');\\n await retryOperation(mock);\\n expect(mock).toHaveBeenCalledTimes(3);\\n});\\n```\\nVague name, tests mock not code\\n\\n\\n**Requirements:**\\n- One behavior\\n- Clear name\\n- Real code (no mocks unless unavoidable)\\n\\n### Verify RED - Watch It Fail\\n\\n**MANDATORY. Never skip.**\\n\\n```bash\\nnpm test path/to/test.test.ts\\n```\\n\\nConfirm:\\n- Test fails (not errors)\\n- Failure message is expected\\n- Fails because feature missing (not typos)\\n\\n**Test passes?** You're testing existing behavior. Fix test.\\n\\n**Test errors?** Fix error, re-run until it fails correctly.\\n\\n### GREEN - Minimal Code\\n\\nWrite simplest code to pass the test.\\n\\n\\n```typescript\\nasync function retryOperation(fn: () => Promise): Promise {\\n for (let i = 0; i < 3; i++) {\\n try {\\n return await fn();\\n } catch (e) {\\n if (i === 2) throw e;\\n }\\n }\\n throw new Error('unreachable');\\n}\\n```\\nJust enough to pass\\n\\n\\n\\n```typescript\\nasync function retryOperation(\\n fn: () => Promise,\\n options?: {\\n maxRetries?: number;\\n backoff?: 'linear' | 'exponential';\\n onRetry?: (attempt: number) => void;\\n }\\n): Promise {\\n // YAGNI\\n}\\n```\\nOver-engineered\\n\\n\\nDon't add features, refactor other code, or \\\"improve\\\" beyond the test.\\n\\n### Verify GREEN - Watch It Pass\\n\\n**MANDATORY.**\\n\\n```bash\\nnpm test path/to/test.test.ts\\n```\\n\\nConfirm:\\n- Test passes\\n- Other tests still pass\\n- Output pristine (no errors, warnings)\\n\\n**Test fails?** Fix code, not test.\\n\\n**Other tests fail?** Fix now.\\n\\n### REFACTOR - Clean Up\\n\\nAfter green only:\\n- Remove duplication\\n- Improve names\\n- Extract helpers\\n\\nKeep tests green. Don't add behavior.\\n\\n### Repeat\\n\\nNext failing test for next feature.\\n\\n## Good Tests\\n\\n| Quality | Good | Bad |\\n|---------|------|-----|\\n| **Minimal** | One thing. \\\"and\\\" in name? Split it. | `test('validates email and domain and whitespace')` |\\n| **Clear** | Name describes behavior | `test('test1')` |\\n| **Shows intent** | Demonstrates desired API | Obscures what code should do |\\n\\nWhen writing or changing any test, read [writing-good-tests.md](writing-good-tests.md) for the rules that keep tests honest:\\n- Name the production change that would make the test fail ??before writing it\\n- Assert on real behavior, never on mock behavior\\n- Keep test-only code in test utilities, out of production classes\\n- Understand a dependency's side effects before mocking it\\n\\n## Common Rationalizations\\n\\n| Excuse | Reality |\\n|--------|---------|\\n| \\\"Too simple to test\\\" | Simple code breaks. Test takes 30 seconds. |\\n| \\\"I'll test after\\\" | Tests written after pass immediately ??which proves nothing. They may test the wrong thing, test the implementation instead of the behavior, or miss the edge case you forgot. You never watched it fail, so you never proved it can catch the bug. Test-first forces that failure. |\\n| \\\"Tests after achieve same goals (spirit not ritual)\\\" | Tests-after answer \\\"what does this do?\\\"; tests-first answer \\\"what should this do?\\\" Tests written after are biased by the code you already wrote ??you verify the cases you remembered, not the ones you'd have discovered. Coverage without proof the tests work. |\\n| \\\"Already manually tested\\\" | Manual testing is ad-hoc: no record of what you covered, no way to re-run it when the code changes, easy to forget cases under pressure. \\\"Worked when I tried it\\\" ??comprehensive. Automated tests run the same way every time. |\\n| \\\"Deleting X hours is wasteful\\\" | Sunk cost fallacy ??that time is already spent either way. The real choice: rewrite with TDD (high confidence) vs. keep it and bolt tests on after (low confidence, likely bugs). Keeping code you can't trust is the waste. |\\n| \\\"Keep as reference, write tests first\\\" | You'll adapt it. That's testing after. Delete means delete. |\\n| \\\"Need to explore first\\\" | Fine. Throw away exploration, start with TDD. |\\n| \\\"Test hard = design unclear\\\" | Listen to test. Hard to test = hard to use. |\\n| \\\"TDD will slow me down\\\" | TDD IS the pragmatic path: catches bugs before commit, prevents regressions, lets you refactor without fear. \\\"Pragmatic\\\" shortcuts mean debugging in production ??slower, not faster. |\\n| \\\"Manual test faster\\\" | Manual doesn't prove edge cases. You'll re-test every change. |\\n| \\\"Existing code has no tests\\\" | You're improving it. Add tests for existing code. |\\n\\n## Red Flags - STOP and Start Over\\n\\n- Code before test\\n- Test after implementation\\n- Test passes immediately\\n- Can't explain why test failed\\n- Tests added \\\"later\\\"\\n- Rationalizing \\\"just this once\\\"\\n- \\\"I already manually tested it\\\"\\n- \\\"Tests after achieve the same purpose\\\"\\n- \\\"It's about spirit not ritual\\\"\\n- \\\"Keep as reference\\\" or \\\"adapt existing code\\\"\\n- \\\"Already spent X hours, deleting is wasteful\\\"\\n- \\\"TDD is dogmatic, I'm being pragmatic\\\"\\n- \\\"This is different because...\\\"\\n\\n**All of these mean: Delete code. Start over with TDD.**\\n\\n## Example: Bug Fix\\n\\n**Bug:** Empty email accepted\\n\\n**RED**\\n```typescript\\ntest('rejects empty email', async () => {\\n const result = await submitForm({ email: '' });\\n expect(result.error).toBe('Email required');\\n});\\n```\\n\\n**Verify RED**\\n```bash\\n$ npm test\\nFAIL: expected 'Email required', got undefined\\n```\\n\\n**GREEN**\\n```typescript\\nfunction submitForm(data: FormData) {\\n if (!data.email?.trim()) {\\n return { error: 'Email required' };\\n }\\n // ...\\n}\\n```\\n\\n**Verify GREEN**\\n```bash\\n$ npm test\\nPASS\\n```\\n\\n**REFACTOR**\\nExtract validation for multiple fields if needed.\\n\\n## Verification Checklist\\n\\nBefore marking work complete:\\n\\n- [ ] Every new function/method has a test\\n- [ ] Watched each test fail before implementing\\n- [ ] Each test failed for expected reason (feature missing, not typo)\\n- [ ] Wrote minimal code to pass each test\\n- [ ] All tests pass\\n- [ ] Output pristine (no errors, warnings)\\n- [ ] Tests use real code (mocks only if unavoidable)\\n- [ ] Edge cases and errors covered\\n\\nCan't check all boxes? You skipped TDD. Start over.\\n\\n## When Stuck\\n\\n| Problem | Solution |\\n|---------|----------|\\n| Don't know how to test | Write wished-for API. Write assertion first. Ask your human partner. |\\n| Test too complicated | Design too complicated. Simplify interface. |\\n| Must mock everything | Code too coupled. Use dependency injection. |\\n| Test setup huge | Extract helpers. Still complex? Simplify design. |\\n\\n## Debugging Integration\\n\\nBug found? Write failing test reproducing it. Follow TDD cycle. Test proves fix and prevents regression.\\n\\nNever fix bugs without a test.\\n\\n## Final Rule\\n\\n```\\nProduction code ??test exists and failed first\\nOtherwise ??not TDD\\n```\\n\\nNo exceptions without your human partner's permission.\\n\\r\\n---\\nname: verification-before-completion\\ndescription: Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always\\n---\\n\\n# Verification Before Completion\\n\\n## Overview\\n\\n**Core principle:** Evidence before claims, always.\\n\\n**Violating the letter of this rule is violating the spirit of this rule.**\\n\\n## The Iron Law\\n\\n```\\nNO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE\\n```\\n\\nIf you haven't run the verification command in this message, you cannot claim it passes.\\n\\n## The Gate Function\\n\\n```\\nBEFORE claiming any status or expressing satisfaction:\\n\\n1. IDENTIFY: What command proves this claim?\\n2. RUN: Execute the FULL command (fresh, complete)\\n3. READ: Full output, check exit code, count failures\\n4. VERIFY: Does output confirm the claim?\\n - If NO: State actual status with evidence\\n - If YES: State claim WITH evidence\\n5. ONLY THEN: Make the claim\\n\\nSkip any step = lying, not verifying\\n```\\n\\n## Common Failures\\n\\n| Claim | Requires | Not Sufficient |\\n|-------|----------|----------------|\\n| Tests pass | Test command output: 0 failures | Previous run, \\\"should pass\\\" |\\n| Linter clean | Linter output: 0 errors | Partial check, extrapolation |\\n| Build succeeds | Build command: exit 0 | Linter passing, logs look good |\\n| Bug fixed | Test original symptom: passes | Code changed, assumed fixed |\\n| Regression test works | Red-green cycle verified | Test passes once |\\n| Agent completed | VCS diff shows changes | Agent reports \\\"success\\\" |\\n| Requirements met | Line-by-line checklist | Tests passing |\\n\\n## Red Flags - STOP\\n\\n- Using \\\"should\\\", \\\"probably\\\", \\\"seems to\\\"\\n- Expressing satisfaction before verification (\\\"Great!\\\", \\\"Perfect!\\\", \\\"Done!\\\", etc.)\\n- About to commit/push/PR without verification\\n- Trusting agent success reports\\n- Relying on partial verification\\n- Thinking \\\"just this once\\\"\\n- Tired and wanting work over\\n- **ANY wording implying success without having run verification**\\n\\n## Rationalization Prevention\\n\\n| Excuse | Reality |\\n|--------|---------|\\n| \\\"Should work now\\\" | RUN the verification |\\n| \\\"I'm confident\\\" | Confidence ??evidence |\\n| \\\"Just this once\\\" | No exceptions |\\n| \\\"Linter passed\\\" | Linter ??compiler |\\n| \\\"Agent said success\\\" | Verify independently |\\n| \\\"I'm tired\\\" | Exhaustion ??excuse |\\n| \\\"Partial check is enough\\\" | Partial proves nothing |\\n| \\\"Different words so rule doesn't apply\\\" | Spirit over letter |\\n\\n## Key Patterns\\n\\n**Tests:**\\n```\\n??[Run test command] [See: 34/34 pass] \\\"All tests pass\\\"\\n??\\\"Should pass now\\\" / \\\"Looks correct\\\"\\n```\\n\\n**Regression tests (TDD Red-Green):**\\n```\\n??Write ??Run (pass) ??Revert fix ??Run (MUST FAIL) ??Restore ??Run (pass)\\n??\\\"I've written a regression test\\\" (without red-green verification)\\n```\\n\\n**Build:**\\n```\\n??[Run build] [See: exit 0] \\\"Build passes\\\"\\n??\\\"Linter passed\\\" (linter doesn't check compilation)\\n```\\n\\n**Requirements:**\\n```\\n??Re-read plan ??Create checklist ??Verify each ??Report gaps or completion\\n??\\\"Tests pass, phase complete\\\"\\n```\\n\\n**Agent delegation:**\\n```\\n??Agent reports success ??Check VCS diff ??Verify changes ??Report actual state\\n??Trust agent report\\n```\\n\\n## When To Apply\\n\\n**ALWAYS before:**\\n- ANY variation of success/completion claims\\n- ANY expression of satisfaction\\n- ANY positive statement about work state\\n- Committing, PR creation, task completion\\n- Moving to next task\\n- Delegating to agents\\n\\n**Rule applies to:**\\n- Exact phrases\\n- Paraphrases and synonyms\\n- Implications of success\\n- ANY communication suggesting completion/correctness\\n\\r\\n---\\r\\nname: harness\\r\\ndescription: Use when planning agentic implementation phases, creating phases/index.json and self-contained step files, or running the Harness step executor.\\r\\n---\\r\\n\\r\\n# Harness Workflow\\r\\n\\r\\n???꾨줈?앺듃??Harness ?꾨젅?꾩썙?щ? ?ъ슜?쒕떎. ?꾨옒 ?뚰겕?뚮줈???곕씪 ?묒뾽?쒕떎.\\r\\n\\r\\n## A. ?먯깋\\r\\n\\r\\n`AGENTS.md`? `docs/` ?섏쐞 臾몄꽌(PRD, ARCHITECTURE, ADR ??瑜??쎄퀬 ?꾨줈?앺듃??湲고쉷,\\r\\n?꾪궎?띿쿂, ?ㅺ퀎 ?섎룄瑜??뚯븙?쒕떎. 蹂묐젹 ?먯깋???ㅼ젣濡??좎슜?섍퀬 ?꾩옱 ?몄뀡?먯꽌 ?덉슜??\\n?뚮쭔 Codex subagent瑜??좏깮?곸쑝濡??ъ슜?쒕떎.\\r\\n\\r\\n## B. ?쇱쓽\\r\\n\\r\\n援ы쁽???꾪빐 援ъ껜?뷀븯嫄곕굹 湲곗닠?곸쑝濡?寃곗젙?댁빞 ???ы빆???덉쑝硫??ъ슜?먯뿉寃???踰덉뿉\\r\\n?섎굹???쒖떆?섍퀬 ?쇱쓽?쒕떎.\\r\\n\\r\\n## C. Step ?ㅺ퀎\\r\\n\\r\\n?ъ슜?먭? 援ы쁽 怨꾪쉷 ?묒꽦??吏?쒗븯硫??щ윭 step?쇰줈 ?섎돏 珥덉븞???묒꽦???쇰뱶諛깆쓣\\r\\n?붿껌?쒕떎.\\r\\n\\r\\n?ㅺ퀎 ?먯튃:\\r\\n\\r\\n1. **Scope 理쒖냼??* ???섎굹??step?먯꽌 ?섎굹???덉씠???먮뒗 紐⑤뱢留??ㅻ,?? ?щ윭\\r\\n 紐⑤뱢???숈떆???섏젙?댁빞 ?섎㈃ step??履쇨컿??\\r\\n2. **?먭린?꾧껐??* ??媛?step ?뚯씪? ?낅┰??Codex ?ㅽ뻾?먯꽌 ?ъ슜?쒕떎. ?몃? ???\\n 李몄“瑜?湲덉??섍퀬 ?꾩슂???뺣낫瑜?紐⑤몢 ?뚯씪 ?덉뿉 ?곷뒗??\\r\\n3. **?ъ쟾 以鍮?媛뺤젣** ??愿??臾몄꽌? ?댁쟾 step?먯꽌 ?앹꽦?섍굅???섏젙???뚯씪 寃쎈줈瑜?\\n 紐낆떆?쒕떎.\\r\\n4. **?쒓렇?덉쿂 ?섏? 吏??* ???⑥닔? ?대옒?ㅼ쓽 ?명꽣?섏씠?ㅻ? ?쒖떆?섍퀬 ?대? 援ы쁽?\\r\\n Codex ?щ웾??留↔릿?? 硫깅벑?? 蹂댁븞, ?곗씠??臾닿껐??媛숈? ?듭떖 洹쒖튃? 紐낆떆?쒕떎.\\r\\n5. **AC???ㅽ뻾 媛?ν븳 command** ??異붿긽??議곌굔 ????ㅼ젣 鍮뚮뱶? ?뚯뒪??command瑜?\\n ?ы븿?쒕떎.\\r\\n6. **二쇱쓽?ы빆? 援ъ껜?곸쑝濡?* ??\\\"X瑜??섏? 留덈씪. ?댁쑀: Y\\\" ?뺤떇?쇰줈 ?곷뒗??\\r\\n7. **?ㅼ씠諛?* ??step name? ?듭떖 ?묒뾽???쒗쁽?섎뒗 kebab-case slug濡??뺥븳??\\r\\n\\r\\n## D. ?뚯씪 ?앹꽦\\r\\n\\r\\n?ъ슜?먭? 珥덉븞???뱀씤???꾩뿉留??ㅼ쓬 ?뚯씪???앹꽦?쒕떎.\\r\\n\\r\\n### D-1. `phases/index.json`\\r\\n\\r\\n?щ윭 task瑜?愿由ы븯??top-level ?몃뜳?ㅻ떎. ?대? 議댁옱?섎㈃ `phases` 諛곗뿴??????ぉ??\\n異붽??쒕떎.\\r\\n\\r\\n```json\\r\\n{\\r\\n \\\"phases\\\": [\\r\\n {\\r\\n \\\"dir\\\": \\\"0-mvp\\\",\\r\\n \\\"status\\\": \\\"pending\\\"\\r\\n }\\r\\n ]\\r\\n}\\r\\n```\\r\\n\\r\\n- `dir`: task ?붾젆?곕━紐?\\n- `status`: `pending` | `completed` | `error` | `blocked`\\r\\n- timestamp??executor媛 ?곹깭瑜?諛붽? ??湲곕줉?섎?濡??앹꽦 ???l? ?딅뒗??\\r\\n\\r\\n### D-2. `phases/{task-name}/index.json`\\r\\n\\r\\n```json\\r\\n{\\r\\n \\\"project\\\": \\\"\\\",\\r\\n \\\"steps\\\": [\\r\\n { \\\"step\\\": 0, \\\"name\\\": \\\"project-setup\\\", \\\"status\\\": \\\"pending\\\" },\\r\\n { \\\"step\\\": 1, \\\"name\\\": \\\"core-types\\\", \\\"status\\\": \\\"pending\\\" },\\r\\n { \\\"step\\\": 2, \\\"name\\\": \\\"api-layer\\\", \\\"status\\\": \\\"pending\\\" }\\r\\n ]\\r\\n}\\r\\n```\\r\\n\\r\\n?꾨뱶 洹쒖튃:\\r\\n\\r\\n- `project`: `AGENTS.md`???뺤쓽???꾨줈?앺듃紐?\\n- `phase`: task ?대쫫?대ʼn ?붾젆?곕━紐낃낵 ?쇱튂\\r\\n- `steps[].step`: 0遺???쒖옉?섎뒗 ?쒕쾲\\r\\n- `steps[].name`: kebab-case slug\\r\\n- `steps[].status`: 珥덇린媛?`pending`\\r\\n\\r\\n?곹깭? 湲곕줉 二쇱껜:\\r\\n\\r\\n| ?꾩씠 | 湲곕줉 ?꾨뱶 | 湲곕줉 二쇱껜 |\\r\\n|------|-----------|-----------|\\r\\n| `completed` | `summary`, `completed_at` | Codex媛 summary, executor媛 timestamp |\\r\\n| `error` | `error_message`, `failed_at` | Codex媛 message, executor媛 timestamp |\\r\\n| `blocked` | `blocked_reason`, `blocked_at` | Codex媛 reason, executor媛 timestamp |\\r\\n\\r\\n`summary`?먮뒗 ?ㅼ쓬 step???좎슜???앹꽦 ?뚯씪怨??듭떖 寃곗젙????以꾨줈 ?곷뒗??\\r\\ntask `created_at`怨?step `started_at`? executor媛 湲곕줉?섎?濡??앹꽦 ???l? ?딅뒗??\\r\\n\\r\\n### D-3. `phases/{task-name}/step{N}.md`\\r\\n\\r\\n````markdown\\r\\n# Step {N}: {?대쫫}\\r\\n\\r\\n## ?쎌뼱?????뚯씪\\r\\n\\r\\n癒쇱? ?꾨옒 ?뚯씪???쎄퀬 ?꾨줈?앺듃???꾪궎?띿쿂? ?ㅺ퀎 ?섎룄瑜??뚯븙?섎씪:\\r\\n\\r\\n- `/AGENTS.md`\\r\\n- `/docs/ARCHITECTURE.md`\\r\\n- `/docs/ADR.md`\\r\\n- ?댁쟾 step?먯꽌 ?앹꽦?섍굅???섏젙???뚯씪 寃쎈줈\\r\\n\\r\\n?댁쟾 step??肄붾뱶瑜?瑗쇨세???쎄퀬 ?ㅺ퀎 ?섎룄瑜??댄빐?????묒뾽?섎씪.\\r\\n\\r\\n## ?묒뾽\\r\\n\\r\\n援ъ껜?곸씤 援ы쁽 吏?쒕? ?뚯씪 寃쎈줈, ?대옒?ㅼ? ?⑥닔 ?쒓렇?덉쿂, 濡쒖쭅 ?ㅻ챸怨??④퍡 ?곷뒗??\\r\\n援ы쁽泥대뒗 Codex??留↔린???ㅺ퀎 ?섎룄?먯꽌 踰쀬뼱?섎㈃ ???섎뒗 ?듭떖 洹쒖튃? 紐낆떆?쒕떎.\\r\\n\\r\\n## Acceptance Criteria\\r\\n\\r\\n?꾨줈?앺듃 ?뺤떇??留욌뒗 紐낅졊???ъ슜?쒕떎. `.harness/config.json`???덉쑝硫??대떦 preset,\\r\\nsolution, configuration, platform, test command瑜??곗꽑?쒕떎.\\r\\n\\r\\n```powershell\\r\\n# CMake\\r\\ncmake --build .harness/build --config Debug\\r\\nctest --test-dir .harness/build -C Debug --output-on-failure\\r\\n\\r\\n# 吏곸젒 MSBuild\\r\\nMSBuild.exe MyProject.sln /m /p:Configuration=Debug /p:Platform=x64\\r\\n.\\\\build\\\\tests\\\\Debug\\\\MyProjectTests.exe\\r\\n```\\r\\n\\r\\n## 寃利??덉감\\r\\n\\r\\n1. Acceptance Criteria command瑜??ㅽ뻾?쒕떎.\\r\\n2. ARCHITECTURE ?붾젆?곕━ 援ъ“瑜??곕Ⅴ?붿? ?뺤씤?쒕떎.\\r\\n3. ADR 湲곗닠 ?ㅽ깮怨?`AGENTS.md` CRITICAL 洹쒖튃???뺤씤?쒕떎.\\r\\n4. 寃곌낵???곕씪 task index???대떦 step??媛깆떊?쒕떎.\\r\\n - ?깃났: `status`瑜?`completed`濡?諛붽씀怨???以?`summary` 湲곕줉\\r\\n - ?섏젙 3?????ㅽ뙣: `status`瑜?`error`濡?諛붽씀怨?`error_message` 湲곕줉\\r\\n - ?ъ슜??媛쒖엯 ?꾩슂: `status`瑜?`blocked`濡?諛붽씀怨?`blocked_reason` 湲곕줉 ??以묐떒\\r\\n\\r\\n## 湲덉??ы빆\\r\\n\\r\\n- ??step??踰붿쐞 諛?湲곕뒫??異붽??섏? 留덈씪. ?댁쑀: step???낅┰?깆쓣 源⑤쑉由곕떎.\\r\\n- 湲곗〈 ?뚯뒪?몃? 源⑤쑉由ъ? 留덈씪. ?댁쑀: ?댁쟾 ?숈옉???뚭??쒗궓??\\r\\n````\\r\\n\\r\\n## E. ?ㅽ뻾\\r\\n\\r\\n```bash\\r\\npython scripts/execute.py {task-name}\\r\\npython scripts/execute.py {task-name} --push\\r\\n```\\r\\n\\r\\n?섍꼍?먯꽌 Python 3 ?ㅽ뻾 紐낅졊??`python3`?대㈃ 洹?紐낅졊??????ъ슜?쒕떎.\\r\\n\\r\\nexecutor媛 泥섎━?섎뒗 ?묒뾽:\\r\\n\\r\\n- `feat-{task-name}` 釉뚮옖移??앹꽦 ?먮뒗 checkout\\r\\n- `AGENTS.md`? `docs/*.md` guardrail 二쇱엯\\r\\n- ?꾨즺 step??summary瑜??ㅼ쓬 prompt???꾩쟻\\r\\n- ?ㅽ뙣 ??理쒕? 3???ъ떆?꾪븯硫??댁쟾 ?ㅻ쪟瑜?prompt???꾨떖\\r\\n- 肄붾뱶 蹂寃쎄낵 metadata瑜?遺꾨━??commit\\r\\n- `started_at`, `completed_at`, `failed_at`, `blocked_at` 湲곕줉\\r\\n\\r\\n?먮윭 蹂듦뎄:\\r\\n\\r\\n- `error`: ?대떦 status瑜?`pending`?쇰줈 諛붽씀怨?`error_message`瑜???젣?????ъ떎??\\n- `blocked`: ?먯씤???닿껐?섍퀬 status瑜?`pending`?쇰줈 諛붽씀怨?`blocked_reason`????젣??\\n ???ъ떎??\\n\\r\\n\",\"exit_code\":0,\"status\":\"completed\"}}\n{\"type\":\"item.completed\",\"item\":{\"id\":\"item_4\",\"type\":\"agent_message\",\"text\":\"제공된 Step 문서 자체를 승인된 설계로 간주합니다. 추가 설계 문서·커밋·worktree 생성은 “Step 0 외 파일 금지”와 “직접 커밋 금지”에 어긋나므로 생략합니다. 구현 전 핵심 선택지는 raw aggregate를 유지하면서 production `validate_result_database(...)` 경로로 무효 상태를 거부하는 방식과 validated factory 방식이며, 기존 진단/결과 패턴을 확인한 뒤 더 작은 쪽으로 확정하겠습니다.\"}}\n{\"type\":\"item.started\",\"item\":{\"id\":\"item_5\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\WINDOWS\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Raw 'C:\\\\\\\\Users\\\\\\\\baram\\\\\\\\.codex\\\\\\\\plugins\\\\\\\\cache\\\\\\\\openai-curated-remote\\\\\\\\superpowers\\\\\\\\6.2.0\\\\\\\\skills\\\\\\\\references\\\\\\\\codex-tools.md'; Get-Content -Raw 'C:\\\\\\\\Users\\\\\\\\baram\\\\\\\\.codex\\\\\\\\plugins\\\\\\\\cache\\\\\\\\openai-curated-remote\\\\\\\\superpowers\\\\\\\\6.2.0\\\\\\\\skills\\\\\\\\writing-good-tests.md'; Get-Content -Raw -Encoding UTF8 '.agents\\\\\\\\skills\\\\\\\\harness\\\\\\\\SKILL.md'; Get-Content -Raw -Encoding UTF8 'AGENTS.md'; Get-Content -Raw -Encoding UTF8 'docs\\\\\\\\PRD.md'; Get-Content -Raw -Encoding UTF8 'docs\\\\\\\\ARCHITECTURE.md'; Get-Content -Raw -Encoding UTF8 'docs\\\\\\\\ADR.md'; Get-Content -Raw -Encoding UTF8 'include\\\\\\\\fesa\\\\\\\\model\\\\\\\\domain.hpp'; Get-Content -Raw -Encoding UTF8 'include\\\\\\\\fesa\\\\\\\\core\\\\\\\\diagnostic.hpp'; Get-Content -Raw -Encoding UTF8 'phases\\\\\\\\results-and-pipeline\\\\\\\\index.json'; Get-Content -Raw -Encoding UTF8 'phases\\\\\\\\results-and-pipeline\\\\\\\\step0.md'\\\"\",\"aggregated_output\":\"\",\"exit_code\":null,\"status\":\"in_progress\"}}\n{\"type\":\"item.completed\",\"item\":{\"id\":\"item_5\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\WINDOWS\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Raw 'C:\\\\\\\\Users\\\\\\\\baram\\\\\\\\.codex\\\\\\\\plugins\\\\\\\\cache\\\\\\\\openai-curated-remote\\\\\\\\superpowers\\\\\\\\6.2.0\\\\\\\\skills\\\\\\\\references\\\\\\\\codex-tools.md'; Get-Content -Raw 'C:\\\\\\\\Users\\\\\\\\baram\\\\\\\\.codex\\\\\\\\plugins\\\\\\\\cache\\\\\\\\openai-curated-remote\\\\\\\\superpowers\\\\\\\\6.2.0\\\\\\\\skills\\\\\\\\writing-good-tests.md'; Get-Content -Raw -Encoding UTF8 '.agents\\\\\\\\skills\\\\\\\\harness\\\\\\\\SKILL.md'; Get-Content -Raw -Encoding UTF8 'AGENTS.md'; Get-Content -Raw -Encoding UTF8 'docs\\\\\\\\PRD.md'; Get-Content -Raw -Encoding UTF8 'docs\\\\\\\\ARCHITECTURE.md'; Get-Content -Raw -Encoding UTF8 'docs\\\\\\\\ADR.md'; Get-Content -Raw -Encoding UTF8 'include\\\\\\\\fesa\\\\\\\\model\\\\\\\\domain.hpp'; Get-Content -Raw -Encoding UTF8 'include\\\\\\\\fesa\\\\\\\\core\\\\\\\\diagnostic.hpp'; Get-Content -Raw -Encoding UTF8 'phases\\\\\\\\results-and-pipeline\\\\\\\\index.json'; Get-Content -Raw -Encoding UTF8 'phases\\\\\\\\results-and-pipeline\\\\\\\\step0.md'\\\"\",\"aggregated_output\":\"---\\r\\nname: harness\\r\\ndescription: Use when planning agentic implementation phases, creating phases/index.json and self-contained step files, or running the Harness step executor.\\r\\n---\\r\\n\\r\\n# Harness Workflow\\r\\n\\r\\n이 프로젝트는 Harness 프레임워크를 사용한다. 아래 워크플로에 따라 작업한다.\\r\\n\\r\\n## A. 탐색\\r\\n\\r\\n`AGENTS.md`와 `docs/` 하위 문서(PRD, ARCHITECTURE, ADR 등)를 읽고 프로젝트의 기획,\\r\\n아키텍처, 설계 의도를 파악한다. 병렬 탐색이 실제로 유용하고 현재 세션에서 허용될\\r\\n때만 Codex subagent를 선택적으로 사용한다.\\r\\n\\r\\n## B. 논의\\r\\n\\r\\n구현을 위해 구체화하거나 기술적으로 결정해야 할 사항이 있으면 사용자에게 한 번에\\r\\n하나씩 제시하고 논의한다.\\r\\n\\r\\n## C. Step 설계\\r\\n\\r\\n사용자가 구현 계획 작성을 지시하면 여러 step으로 나뉜 초안을 작성해 피드백을\\r\\n요청한다.\\r\\n\\r\\n설계 원칙:\\r\\n\\r\\n1. **Scope 최소화** — 하나의 step에서 하나의 레이어 또는 모듈만 다룬다. 여러\\r\\n 모듈을 동시에 수정해야 하면 step을 쪼갠다.\\r\\n2. **자기완결성** — 각 step 파일은 독립된 Codex 실행에서 사용된다. 외부 대화\\r\\n 참조를 금지하고 필요한 정보를 모두 파일 안에 적는다.\\r\\n3. **사전 준비 강제** — 관련 문서와 이전 step에서 생성하거나 수정한 파일 경로를\\r\\n 명시한다.\\r\\n4. **시그니처 수준 지시** — 함수와 클래스의 인터페이스를 제시하고 내부 구현은\\r\\n Codex 재량에 맡긴다. 멱등성, 보안, 데이터 무결성 같은 핵심 규칙은 명시한다.\\r\\n5. **AC는 실행 가능한 command** — 추상적 조건 대신 실제 빌드와 테스트 command를\\r\\n 포함한다.\\r\\n6. **주의사항은 구체적으로** — \\\"X를 하지 마라. 이유: Y\\\" 형식으로 적는다.\\r\\n7. **네이밍** — step name은 핵심 작업을 표현하는 kebab-case slug로 정한다.\\r\\n\\r\\n## D. 파일 생성\\r\\n\\r\\n사용자가 초안을 승인한 후에만 다음 파일을 생성한다.\\r\\n\\r\\n### D-1. `phases/index.json`\\r\\n\\r\\n여러 task를 관리하는 top-level 인덱스다. 이미 존재하면 `phases` 배열에 새 항목을\\r\\n추가한다.\\r\\n\\r\\n```json\\r\\n{\\r\\n \\\"phases\\\": [\\r\\n {\\r\\n \\\"dir\\\": \\\"0-mvp\\\",\\r\\n \\\"status\\\": \\\"pending\\\"\\r\\n }\\r\\n ]\\r\\n}\\r\\n```\\r\\n\\r\\n- `dir`: task 디렉터리명\\r\\n- `status`: `pending` | `completed` | `error` | `blocked`\\r\\n- timestamp는 executor가 상태를 바꿀 때 기록하므로 생성 시 넣지 않는다.\\r\\n\\r\\n### D-2. `phases/{task-name}/index.json`\\r\\n\\r\\n```json\\r\\n{\\r\\n \\\"project\\\": \\\"<프로젝트명>\\\",\\r\\n \\\"phase\\\": \\\"\\\",\\r\\n \\\"steps\\\": [\\r\\n { \\\"step\\\": 0, \\\"name\\\": \\\"project-setup\\\", \\\"status\\\": \\\"pending\\\" },\\r\\n { \\\"step\\\": 1, \\\"name\\\": \\\"core-types\\\", \\\"status\\\": \\\"pending\\\" },\\r\\n { \\\"step\\\": 2, \\\"name\\\": \\\"api-layer\\\", \\\"status\\\": \\\"pending\\\" }\\r\\n ]\\r\\n}\\r\\n```\\r\\n\\r\\n필드 규칙:\\r\\n\\r\\n- `project`: `AGENTS.md`에 정의된 프로젝트명\\r\\n- `phase`: task 이름이며 디렉터리명과 일치\\r\\n- `steps[].step`: 0부터 시작하는 순번\\r\\n- `steps[].name`: kebab-case slug\\r\\n- `steps[].status`: 초기값 `pending`\\r\\n\\r\\n상태와 기록 주체:\\r\\n\\r\\n| 전이 | 기록 필드 | 기록 주체 |\\r\\n|------|-----------|-----------|\\r\\n| `completed` | `summary`, `completed_at` | Codex가 summary, executor가 timestamp |\\r\\n| `error` | `error_message`, `failed_at` | Codex가 message, executor가 timestamp |\\r\\n| `blocked` | `blocked_reason`, `blocked_at` | Codex가 reason, executor가 timestamp |\\r\\n\\r\\n`summary`에는 다음 step에 유용한 생성 파일과 핵심 결정을 한 줄로 적는다.\\r\\ntask `created_at`과 step `started_at`은 executor가 기록하므로 생성 시 넣지 않는다.\\r\\n\\r\\n### D-3. `phases/{task-name}/step{N}.md`\\r\\n\\r\\n````markdown\\r\\n# Step {N}: {이름}\\r\\n\\r\\n## 읽어야 할 파일\\r\\n\\r\\n먼저 아래 파일을 읽고 프로젝트의 아키텍처와 설계 의도를 파악하라:\\r\\n\\r\\n- `/AGENTS.md`\\r\\n- `/docs/ARCHITECTURE.md`\\r\\n- `/docs/ADR.md`\\r\\n- 이전 step에서 생성하거나 수정한 파일 경로\\r\\n\\r\\n이전 step의 코드를 꼼꼼히 읽고 설계 의도를 이해한 뒤 작업하라.\\r\\n\\r\\n## 작업\\r\\n\\r\\n구체적인 구현 지시를 파일 경로, 클래스와 함수 시그니처, 로직 설명과 함께 적는다.\\r\\n구현체는 Codex에 맡기되 설계 의도에서 벗어나면 안 되는 핵심 규칙은 명시한다.\\r\\n\\r\\n## Acceptance Criteria\\r\\n\\r\\n프로젝트 형식에 맞는 명령을 사용한다. `.harness/config.json`이 있으면 해당 preset,\\r\\nsolution, configuration, platform, test command를 우선한다.\\r\\n\\r\\n```powershell\\r\\n# CMake\\r\\ncmake --build .harness/build --config Debug\\r\\nctest --test-dir .harness/build -C Debug --output-on-failure\\r\\n\\r\\n# 직접 MSBuild\\r\\nMSBuild.exe MyProject.sln /m /p:Configuration=Debug /p:Platform=x64\\r\\n.\\\\build\\\\tests\\\\Debug\\\\MyProjectTests.exe\\r\\n```\\r\\n\\r\\n## 검증 절차\\r\\n\\r\\n1. Acceptance Criteria command를 실행한다.\\r\\n2. ARCHITECTURE 디렉터리 구조를 따르는지 확인한다.\\r\\n3. ADR 기술 스택과 `AGENTS.md` CRITICAL 규칙을 확인한다.\\r\\n4. 결과에 따라 task index의 해당 step을 갱신한다.\\r\\n - 성공: `status`를 `completed`로 바꾸고 한 줄 `summary` 기록\\r\\n - 수정 3회 후 실패: `status`를 `error`로 바꾸고 `error_message` 기록\\r\\n - 사용자 개입 필요: `status`를 `blocked`로 바꾸고 `blocked_reason` 기록 후 중단\\r\\n\\r\\n## 금지사항\\r\\n\\r\\n- 이 step의 범위 밖 기능을 추가하지 마라. 이유: step의 독립성을 깨뜨린다.\\r\\n- 기존 테스트를 깨뜨리지 마라. 이유: 이전 동작을 회귀시킨다.\\r\\n````\\r\\n\\r\\n## E. 실행\\r\\n\\r\\n```bash\\r\\npython scripts/execute.py {task-name}\\r\\npython scripts/execute.py {task-name} --push\\r\\n```\\r\\n\\r\\n환경에서 Python 3 실행 명령이 `python3`이면 그 명령을 대신 사용한다.\\r\\n\\r\\nexecutor가 처리하는 작업:\\r\\n\\r\\n- `feat-{task-name}` 브랜치 생성 또는 checkout\\r\\n- `AGENTS.md`와 `docs/*.md` guardrail 주입\\r\\n- 완료 step의 summary를 다음 prompt에 누적\\r\\n- 실패 시 최대 3회 재시도하며 이전 오류를 prompt에 전달\\r\\n- 코드 변경과 metadata를 분리해 commit\\r\\n- `started_at`, `completed_at`, `failed_at`, `blocked_at` 기록\\r\\n\\r\\n에러 복구:\\r\\n\\r\\n- `error`: 해당 status를 `pending`으로 바꾸고 `error_message`를 삭제한 뒤 재실행\\r\\n- `blocked`: 원인을 해결하고 status를 `pending`으로 바꾸고 `blocked_reason`을 삭제한\\r\\n 뒤 재실행\\r\\n\\r\\n# FESA Repository Instructions\\r\\n\\r\\n## 적용 범위와 기준 문서\\r\\n\\r\\n이 파일은 저장소 전체에 적용한다.\\r\\n\\r\\n- 제품 요구사항과 Phase 1 수용 조건은 `docs/PRD.md`를 따른다.\\r\\n- 모듈 경계와 데이터 흐름은 `docs/ARCHITECTURE.md`를 따른다.\\r\\n- 기술 선택과 트레이드오프는 `docs/ADR.md`를 따른다.\\r\\n- Harness 실행 방법은 `docs/HARNESS.md`와 `.agents/skills/harness/SKILL.md`를 따른다.\\r\\n- 실제 빌드와 테스트 명령은 `.harness/config.json`과 CMake Preset을 우선한다.\\r\\n\\r\\n## 기술 기준\\r\\n\\r\\n- 언어 표준: C++20\\r\\n- 컴파일러: Visual Studio 2026 MSVC v145\\r\\n- 대상 플랫폼: Windows x64\\r\\n- 빌드 및 테스트: CMake, CMake Presets, CTest, GoogleTest/GoogleMock\\r\\n- 수치 연산 및 희소 직접해법: Intel oneAPI MKL\\r\\n- 요소 계산 및 조립 병렬화: Intel oneAPI TBB\\r\\n- 결과 저장: HDF5\\r\\n- 외부 라이브러리는 개발 환경에 사전 설치된 버전을 사용한다.\\r\\n- FESA는 단위 변환을 수행하지 않는다. 입력은 일관 단위계를 사용해야 한다.\\r\\n\\r\\n## Phase 1 범위\\r\\n\\r\\n- Abaqus `.inp` 제한 부분집합으로 작성된 flat/orphan mesh 또는 좌표변환이 없는\\r\\n 단일 Part/Assembly/Instance 모델을 읽는다.\\r\\n- 단일 선형 정적 `*STEP`만 실행한다.\\r\\n- 절점당 6자유도를 갖는 2절점 3D Isoparametric Timoshenko Beam만 구현한다.\\r\\n- 등방성 선형 탄성, 일반 단면, `*BOUNDARY`, `*CLOAD`만 지원한다.\\r\\n- 다른 요소, 다중 step, 여러 Instance, Instance 좌표변환, MPC, 분포하중, 비선형,\\r\\n 동적, 모달, 좌굴 및 열전달을 선행 구현하지 않는다.\\r\\n\\r\\n## 아키텍처 규칙\\r\\n\\r\\n- public header는 `include/fesa/`, 구현은 `src/fesa/`, 테스트는 `tests/`에 둔다.\\r\\n- `core`, `model`, `fem`, `elements`는 Abaqus, MKL, TBB 및 HDF5 API에 의존하지 않는다.\\r\\n- `io/abaqus`는 입력 syntax와 semantic mapping만 담당하며 해석 알고리즘을 알지 않는다.\\r\\n- `model`에는 Abaqus keyword 문자열 대신 solver semantic model을 저장한다.\\r\\n- 자유도와 equation ID는 `DofManager`가 소유한다. `Node`나 `Element`에 분산 저장하지 않는다.\\r\\n- 외부 라이브러리 handle과 resource는 adapter와 RAII wrapper 내부에 가둔다.\\r\\n- 테스트 helper가 production parser, model validation 또는 solver 경로를 우회하지 않게 한다.\\r\\n- 실제 두 번째 구현이 생기기 전에는 범용 registry, 빈 미래 클래스 또는 디렉터리를 만들지 않는다.\\r\\n\\r\\n## 개발 및 검증 절차\\r\\n\\r\\n1. 요구조건과 완료 기준을 먼저 문서화한다.\\r\\n2. 정식화의 출처, 가정, 좌표계, 부호 및 적분 규칙을 기록한다.\\r\\n3. 입력, semantic model 및 HDF5 계약을 구현 전에 확정한다.\\r\\n4. 실패하는 단위·통합·reference 테스트와 모델을 먼저 작성한다.\\r\\n5. 테스트를 통과하는 최소 코드를 구현한다.\\r\\n6. 해석해, physics sanity 및 Abaqus 2024 골든 결과와 비교한다.\\r\\n7. 물리량별 tolerance를 통과한 뒤에만 기능 완료와 내부 배포를 선언한다.\\r\\n\\r\\n추가 규칙:\\r\\n\\r\\n- 수직 파이프라인을 먼저 연결하되 임시 가짜 강성행렬은 사용하지 않는다.\\r\\n- 같은 입력과 설정의 병렬 조립 결과는 재현 가능해야 한다.\\r\\n- 전단강성이 생략되면 \\\\(A_{sy}=A_{sz}=5A/6\\\\)과 `SCF=0`을 Phase 1 기본값으로\\r\\n 적용한다.\\r\\n- reference 비교는 metadata 없이 요청된 물리량과 CSV 경로를 명시한다. 현재\\r\\n 캔틸레버 샘플은 변위와 반력을 비교하며 요소 내력과 도심 응력 비교 루틴은\\r\\n synthetic CSV로 검증한다.\\r\\n- 새 MSVC 빌드 경고를 추가하지 않는다.\\r\\n- 변경은 요청 범위에 한정하고 Conventional Commits 형식의 메시지를 사용한다.\\r\\n\\r\\n## 검증 명령\\r\\n\\r\\nHarness Python 검증:\\r\\n\\r\\n```powershell\\r\\nuv run --with pytest python -m pytest -v -rs\\r\\n```\\r\\n\\r\\n테스트가 0개 수집된 실행은 성공으로 인정하지 않는다.\\r\\n\\r\\nSolver bootstrap 이후에는 `.harness/config.json`에 지정된 CMake Preset을 사용한다.\\r\\nPreset이 없을 때만 다음 격리 build directory를 사용한다.\\r\\n\\r\\n```powershell\\r\\ncmake -S . -B .harness/build -A x64\\r\\ncmake --build .harness/build --config Debug\\r\\nctest --test-dir .harness/build -C Debug --output-on-failure\\r\\n```\\r\\n\\r\\nHarness phase 실행:\\r\\n\\r\\n```powershell\\r\\npython scripts/execute.py \\r\\n```\\r\\n\\r\\n사용자가 명시적으로 원격 push를 요청한 경우에만 다음을 사용한다.\\r\\n\\r\\n```powershell\\r\\npython scripts/execute.py --push\\r\\n```\\r\\n\\r\\n# PRD: FESA\\n\\n## 1. 제품 목표\\n\\nFESA는 Abaqus `.inp` 제한 부분집합으로 정의된 유한요소 모델을 읽고 선형 정적\\n구조해석을 수행한 뒤, 모델과 절점·요소 결과를 자기완결형 HDF5 파일로 저장하는\\nC++20/MSVC 기반 내부 검증용 솔버다.\\n\\n첫 배포는 Abaqus나 Nastran의 기능 범위를 재현하는 것이 아니라 다음 기반을 검증하는\\n데 목적이 있다.\\n\\n- 입력에서 결과까지 이어지는 전체 해석 파이프라인\\n- FEM 정식화를 추적할 수 있는 모듈 구조\\n- 명시적인 입력·내부 모델·출력 계약\\n- MKL, TBB 및 HDF5를 격리하는 backend 경계\\n- 해석해, physics sanity 및 reference 비교가 가능한 TDD 구조\\n\\n## 2. 대상 사용자와 배포 형태\\n\\n- 주 사용자: FESA를 개발하고 검증하는 1인 개발자\\n- 배포 대상: 개발팀 내부 검증 환경\\n- 산출물: 정적 해석 코어 라이브러리, CLI, 예제 입력, HDF5 schema 문서,\\n reference 데이터 및 검증 보고서\\n- 일정: 고정 기한보다 단계별 완료 조건과 품질 게이트를 우선한다.\\n\\n## 3. Phase 1 기능 범위\\n\\n### 3.1 해석\\n\\n- 소변형 선형 정적 해석\\n- 단일 `*STEP`과 단일 `*STATIC` 하중 케이스\\n- 약 10만 자유도 이하\\n- 비영 지정 변위·회전을 포함한 essential boundary condition\\n- 일관 단위계 사용; FESA 내부 단위 변환 없음\\n\\n### 3.2 요소와 정식화\\n\\n- 2절점 직선 3D Isoparametric Timoshenko Beam\\n- 절점당 자유도:\\n \\\\(u_x,u_y,u_z,\\\\theta_x,\\\\theta_y,\\\\theta_z\\\\)\\n- 선형 형상함수와 자연좌표 \\\\(\\\\xi\\\\in[-1,1]\\\\)\\n- 선택적 감차적분:\\n - 축·굽힘·비틀림 항: 2점 Gauss 적분\\n - 전단 항: 1점 Gauss 적분\\n- 등방성 선형 탄성:\\n - 입력: \\\\(E,\\\\nu\\\\)\\n - 계산: \\\\(G=E/[2(1+\\\\nu)]\\\\)\\n- 일반 단면 semantic property:\\n \\\\(A,I_y,I_z,J,A_{sy},A_{sz}\\\\)\\n- 도심과 전단중심이 일치하는 주축 단면\\n- \\\\(I_{yz}=0\\\\), 단면 오프셋과 워핑 없음\\n- 요소축과 평행하지 않은 국부 단면 기준 방향 벡터 필수\\n- 여러 재료와 여러 단면을 `ELSET`별로 할당\\n\\n### 3.3 Abaqus 입력 부분집합\\n\\n입력은 다음 두 조직 중 하나를 사용한다.\\n\\n- 전역 절점·요소로 구성된 flat/orphan mesh\\n- 여러 Part 정의와 좌표변환이 없는 단일 Assembly·단일 Instance\\n\\n계층형 입력에서는 Assembly의 Instance가 참조하는 Part만 해석에 사용한다. 사용되지\\n않는 Part는 파싱하지만 해석 `Domain`에 포함하지 않는다. 외부 entity는\\n`(instance name, part-local label)`로 식별하고 내부 dense index와 분리한다.\\n\\n필수 지원 대상:\\n\\n- `*NODE`\\n- `*ELEMENT, TYPE=B31`\\n- `*PART`, `*END PART`\\n- `*ASSEMBLY`, `*END ASSEMBLY`\\n- `*INSTANCE`, `*END INSTANCE`\\n- `*NSET`, `*ELSET`\\n - 명시적 ID 목록\\n - `GENERATE`\\n - 기존 집합을 참조하는 중첩 집합\\n- `*MATERIAL`, `*ELASTIC`\\n- `*BEAM GENERAL SECTION, SECTION=GENERAL`\\n- `*TRANSVERSE SHEAR STIFFNESS`(선택)\\n- `*BOUNDARY`\\n- `*CLOAD`\\n- `*STEP`, `*STATIC`, `*END STEP`\\n\\n계층형 입력은 좌표변환이 없는 단일 Instance만 허용한다. 여러 Assembly/Instance,\\nInstance 평행이동·회전, instance-local mesh 수정 및 flat/계층 mesh 혼합은 파일\\n위치와 원인을 포함한 diagnostic으로 거부한다. Part 집합과 Assembly 집합은 scope를\\n구분하며, Assembly의 `INSTANCE=` 집합을 활성 Part의 로컬 ID에 연결한다.\\n\\n파서는 Abaqus syntax를 semantic model로 변환한다. `*HEADING`, `*PREPRINT`,\\n`*RESTART`, `*OUTPUT`은 명시적으로 지원하는 no-op directive로 처리한다. 그 밖의\\n지원하지 않는 keyword나 option을 묵시적으로 무시하지 않는다.\\n\\n명시적 전단강성이 있으면 FESA의 \\\\(A_{sy},A_{sz}\\\\)를 재료의 \\\\(G\\\\)와 일관되게\\n구성한다. 생략되면 \\\\(A_{sy}=A_{sz}=5A/6\\\\)과 `SCF=0`을 Phase 1 기본값으로\\n적용한다. 명시된 `SCF`가 0이 아니면 미지원 입력으로 거부한다.\\n\\n### 3.4 하중과 경계조건\\n\\n- `*BOUNDARY`: 6개 절점 자유도의 0 또는 비영 지정값\\n- `*CLOAD`: 절점 집중력과 집중모멘트\\n- 지정값이 중복되거나 충돌하면 semantic validation 오류\\n- 분포하중, 중력, 압력 및 follower load는 제외\\n\\n### 3.5 결과\\n\\n절점 결과는 전역좌표계로 출력한다.\\n\\n- 변위와 회전\\n- 반력과 반력모멘트\\n\\n요소 결과는 요소 국부좌표계로 출력한다.\\n\\n- 단면력 \\\\(N,V_y,V_z,T,M_y,M_z\\\\)\\n- 대응 단면변형률\\n- 사용자 지정 단면 회복점 \\\\((y,z)\\\\)에서 축력과 이축 굽힘에 의한\\n \\\\(\\\\sigma_{xx}\\\\)\\n- 요소별 국부 기저 벡터\\n- 계층형 입력의 Part/Instance 이름과 part-local ID\\n\\n점별 전단응력과 비틀림응력은 단면 형상 정보 없이는 유일하게 복원할 수 없으므로\\nPhase 1에서 출력하지 않는다.\\n\\nHDF5 결과는 다음 정보를 함께 갖는 자기완결형 파일이어야 한다.\\n\\n- schema와 FESA 버전\\n- 원본 입력 식별 정보\\n- 절점, 요소, 집합, 재료 및 단면\\n- 외부 ID와 내부 dense index mapping\\n- step과 solver 설정\\n- 적용된 전단강성과 입력값/기본값 출처\\n- 절점·요소 결과\\n- 수렴·평형·solver diagnostic\\n\\n## 4. 수치해법과 병렬화 요구사항\\n\\n- 지정 자유도 소거 후 reduced equation system을 구성한다.\\n- 소거 전 평형식 \\\\(r=Ku-f\\\\)를 이용해 반력을 복원한다.\\n- 전역 강성행렬은 대칭 CSR로 저장한다.\\n- MKL PARDISO 대칭 양정치 직접해법을 기본 backend로 사용한다.\\n- oneTBB는 요소 강성·하중·결과 계산과 조립 전처리에 사용한다.\\n- 선형해법 실행 중에는 외부 TBB 작업을 중첩하지 않고 MKL 내부 병렬화를 사용한다.\\n- 부동소수점 contribution의 병합 순서를 고정해 같은 설정에서 재현 가능한 결과를 낸다.\\n\\n## 5. 검증 요구사항\\n\\n### 5.1 검증 계층\\n\\n1. 단위 테스트\\n - 형상함수 partition of unity\\n - Jacobian과 Gauss 적분\\n - 국부 기저 직교성\\n - 좌표변환\\n - 요소 강성 대칭성\\n2. 정식화 테스트\\n - 강체운동에서 무변형\\n - 축력, 비틀림, 단축 및 이축 굽힘\\n - 전단 지배 문제\\n - 세장비 변화와 shear locking\\n3. 통합 테스트\\n - 입력 파싱부터 HDF5 출력까지 전체 파이프라인\\n - 평형 \\\\(Ku-f-r\\\\)\\n - 비영 지정 변위\\n - 여러 재료·단면과 중첩 집합\\n4. Reference 테스트\\n - Abaqus/Standard 2024 B31 결과\\n - 현재 캔틸레버의 변위와 반력\\n - 요소 내력 및 요소 절점 단면 도심 응력 비교 계약의 synthetic CSV 검증\\n\\n### 5.2 골든 데이터\\n\\nAbaqus는 CI나 Harness에서 자동 실행하지 않는다. 별도 Abaqus 2024 환경에서 수동으로\\n생성한 입력과 CSV 결과를 `reference//`에 보관하며 per-model metadata\\n파일은 요구하지 않는다.\\n\\n비교 실행은 물리량과 해당 CSV 경로를 명시한다. 요청한 파일이 없으면 실패하고,\\n요청하지 않은 물리량은 통과로 보고하지 않는다. 현재 `reference/cantilever beam`\\n샘플은 변위와 반력만 비교한다. 요소 내력과 응력 CSV가 추가되기 전까지 해당\\nreader와 비교 kernel은 synthetic CSV로 검증한다.\\n\\nCSV 식별 및 값 열:\\n\\n- 변위: `Part Instance Name`, `Node Label`, `U-U1..U-U3`, `UR-UR1..UR-UR3`\\n- 반력: `Part Instance Name`, `Node Label`, `RF-RF1..RF-RF3`, `RM-RM1..RM-RM3`\\n- 요소 내력: `Part Instance Name`, `Element Label`, `Node Label`,\\n `SF-SF1..SF-SF3`, `SM-SM1..SM-SM3`\\n- 요소 응력: `Part Instance Name`, `Element Label`, `Node Label`, `Sxx`\\n\\n단일 Instance에서는 `Part Instance Name` 열을 생략할 수 있다. 내력은\\n`SF1,SF2,SF3,SM1,SM2,SM3`을 각각 \\\\(N,V_y,V_z,T,M_y,M_z\\\\)로 비교한다.\\n응력은 요소 절점의 단면 도심값 \\\\(\\\\sigma_{xx}=N/A\\\\)를 비교한다.\\n\\n### 5.3 허용오차\\n\\n- 단위·정식화 테스트는 정규화된 엄격한 tolerance를 사용한다.\\n- Abaqus 비교 기본 상대오차는 \\\\(10^{-5}\\\\)로 한다.\\n- 영에 가까운 결과는 특성 길이, 하중 및 응력에 기반한 절대오차를 함께 사용한다.\\n- formulation 또는 output 위치 차이로 별도 tolerance가 필요하면 comparison\\n test 설정과 `docs/VALIDATION.md`에 근거를 기록한다.\\n\\n## 6. 개발 워크플로우\\n\\n각 기능은 다음 게이트를 순서대로 통과한다.\\n\\n1. 요구조건과 완료 기준 정의\\n2. 책, 논문 및 공식 문서 조사\\n3. FEM 정식화, 가정, 좌표계, 부호 및 적분 규칙 작성\\n4. 입력·semantic model·HDF5 데이터 계약 정의\\n5. 실패하는 테스트와 개발 솔버/Abaqus 모델 작성\\n6. 테스트를 통과하는 최소 코드 구현\\n7. 현재 Abaqus 변위·반력 비교와 요소 내력·응력 비교 루틴 검증\\n8. tolerance 및 physics sanity 통과\\n9. 내부 배포\\n\\n파이프라인 수직 슬라이스를 먼저 완성하지만, 이는 수치적으로 자격이 검증된 배포를\\n의미하지 않는다. 요소 정확도와 Abaqus 비교 게이트까지 통과해야 Phase 1이 완료된다.\\n\\n## 7. 제외 범위\\n\\n- Truss, bar, plane, solid, shell 및 다른 Beam 요소\\n- 여러 step과 하중 이력\\n- 여러 Assembly/Instance, Instance 평행이동·회전 및 instance-local mesh 수정\\n- 분포하중, 압력, 중력 및 체적력\\n- MPC, RBE2, RBE3, penalty 및 Lagrange multiplier constraint\\n- 기하·재료 비선형, 접촉, 좌굴, 모달, 동적 및 열전달\\n- 소성, 직교이방성 및 사용자 재료\\n- 단면 오프셋, 곱관성모멘트, 전단중심 편심 및 워핑\\n- 점별 전단·비틀림 응력\\n- 단위 변환\\n- 외부 고객용 installer와 API 호환성 보장\\n\\n## 8. 내부 배포 수용 조건\\n\\n- MSVC Debug와 Release 구성에서 새 경고 없이 빌드\\n- 모든 GoogleTest/CTest와 Harness 검증 통과\\n- 테스트 0개 수집이 아님을 확인\\n- 전체 입력-해석-출력 통합 테스트 통과\\n- physics sanity와 평형 잔차 기준 통과\\n- 현재 Abaqus 2024 변위·반력 골든 결과의 tolerance 통과\\n- 요소 내력·도심 응력 CSV adapter와 비교 kernel의 synthetic 검증 통과\\n- HDF5 schema, 입력 부분집합, 정식화 및 검증 보고서 제공\\n\\r\\n# FESA Architecture\\n\\n## 1. 목표\\n\\nFESA의 아키텍처 목표는 Abaqus `.inp` 부분집합을 내부 semantic model로 변환하고,\\n유한요소 equation system을 구성해 구조해석 결과를 HDF5로 저장하며, reference\\ncomparison과 physics sanity가 가능한 C++20/MSVC 솔버 구조를 제공하는 것이다.\\n\\n핵심 품질 속성:\\n\\n- FEM formulation traceability\\n- explicit I/O contracts\\n- sparse linear algebra backend isolation\\n- deterministic verification\\n- incremental feature addition\\n- Harness 기반 TDD와 workspace validation\\n\\n## 2. 디렉터리 구조\\n\\npublic header와 implementation은 같은 모듈 구조를 사용한다.\\n\\n```text\\ninclude/\\n fesa/\\n core/\\n io/\\n abaqus/\\n hdf5/\\n model/\\n fem/\\n elements/\\n materials/\\n assembly/\\n constraints/\\n solvers/\\n linear/\\n nonlinear/\\n analysis/\\n results/\\n validation/\\nsrc/\\n fesa/\\n core/\\n io/\\n abaqus/\\n hdf5/\\n model/\\n fem/\\n elements/\\n materials/\\n assembly/\\n constraints/\\n solvers/\\n linear/\\n nonlinear/\\n analysis/\\n results/\\n validation/\\ntests/\\n unit/\\n integration/\\n reference/\\nreference/\\n /\\n model.inp\\n _displacements.csv\\n _reactions.csv\\n _internalforces.csv\\n _stresses.csv\\n.agents/\\n skills/\\n harness/\\n review/\\n.codex/\\n hooks.json\\n.harness/\\n config.example.json\\n config.json\\ndocs/\\nscripts/\\n execute.py\\n hooks/\\n msvc_harness/\\nphases/\\n```\\n\\n목표 구조는 장기적인 namespace와 책임 분류다. 실제 소스 디렉터리와 클래스는 해당\\n기능을 구현하는 phase에서만 만든다.\\n\\nPhase 1에서 실체화하는 범위:\\n\\n- `elements/beam`: 2절점 3D Timoshenko Beam\\n- `materials/elastic`: 등방성 선형 탄성\\n- `constraints`: essential BC elimination\\n- `solvers/linear`: MKL PARDISO\\n- `analysis`: `LinearStaticAnalysis`\\n- `results`: 단일 step/frame의 field와 diagnostic output\\n\\nTruss, plane, solid, shell, plasticity, MPC, nonlinear, dynamic, frequency 및 heat\\ntransfer는 목표 taxonomy로만 유지하고 빈 구현을 미리 만들지 않는다.\\n\\n## 3. 모듈 경계\\n\\n### `core`\\n\\nID, status, diagnostic, source location 및 작은 값 타입을 제공한다. 외부 라이브러리에\\n의존하지 않는다. 단위 변환 엔진은 두지 않고 일관 단위계 규약만 표현한다.\\n\\n### `io/abaqus`\\n\\n`.inp` lexer/parser, flat 또는 Part/Assembly/Instance scope record 및\\nsyntax-to-semantic mapping을 담당한다. 해석 알고리즘과 equation numbering을 알지\\n않는다. parser의 임시 syntax 객체는 `model`에 노출하지 않는다. `*HEADING`,\\n`*PREPRINT`, `*RESTART`, `*OUTPUT`은 명시적인 no-op record로 처리하고 일반적인\\nunknown-keyword ignore 경로를 만들지 않는다.\\n\\n### `io/hdf5`\\n\\nHDF5 결과 writer/reader, schema versioning 및 HDF5 resource 수명을 담당한다.\\nHDF5 handle은 RAII wrapper 밖으로 노출하지 않는다.\\n\\n### `model`\\n\\n활성 Instance에서 정규화된 절점, 요소, 집합, 재료, 단면, step, 하중 및\\n경계조건의 solver semantic model을 소유한다. Part/Assembly keyword record나 MKL\\n자료구조를 저장하지 않는다.\\n\\n### `fem`\\n\\nDOF 정의, equation numbering 계약, quadrature, shape function, Jacobian 및\\nlocal/global mapping을 제공한다. 특정 analysis procedure에 종속되지 않는다.\\n\\n### `elements`와 `materials`\\n\\n요소의 local contribution과 결과 회복 계약을 제공한다. Phase 1 요소는 선형 문제에\\n필요한 local stiffness, equivalent load 및 section response만 계산한다.\\n\\n### `assembly`\\n\\nlocal-to-global mapping, sparse pattern 생성, contribution 정렬·병합 및 COO/CSR\\n변환을 담당한다. 요소 formulation이나 PARDISO handle을 소유하지 않는다.\\n\\n### `constraints`\\n\\nessential BC와 full/reduced vector 변환 정책을 담당한다. Phase 1에는 elimination만\\n구현하고 MPC, penalty 및 Lagrange multiplier는 추가하지 않는다.\\n\\n### `solvers`\\n\\n희소 선형계 backend 경계를 제공한다. Phase 1의 `solvers/linear`는 MKL PARDISO를\\nadapter로 감싸며 symbolic analysis, factorization, solve 및 release 수명을 관리한다.\\n\\n### `analysis`\\n\\nstep data를 실행 가능한 `AnalysisModel`로 변환하고 DOF, assembly, constraint,\\nsolver 및 result writer를 조율한다. 구체 수치 kernel이나 외부 API를 직접 구현하지\\n않는다.\\n\\n### `results`\\n\\nnodal, element, integration-point, field, history 및 diagnostic output의 semantic\\n표현을 담당한다. Phase 1에는 nodal/element field와 diagnostic만 실체화한다.\\n\\n### `validation`\\n\\nreference mapping, 비교 metric, tolerance와 physics sanity helper를 제공한다.\\nproduction parser와 solver 내부 상태를 우회하는 별도 해석 경로를 만들지 않는다.\\n\\n## 4. 핵심 객체 모델\\n\\n```text\\nParsedDeck (io/abaqus 전용)\\n├── PartDefinition[]\\n├── AssemblyDefinition\\n│ └── InstanceDefinition[1]\\n├── MaterialDefinition[]\\n└── StepDefinition\\n\\nDomain\\n├── Node\\n├── Element\\n├── Material\\n├── Property\\n├── NodeSet\\n├── ElementSet\\n├── BoundaryCondition\\n├── Load\\n└── StepDefinition\\n\\nAnalysisModel\\n├── active elements\\n├── active loads\\n├── active boundary conditions\\n├── active properties/materials\\n└── equation system view\\n\\nAnalysisState\\n├── displacement U\\n├── external force Fext\\n├── internal force Fint\\n├── residual R\\n├── reaction\\n└── element/integration-point response\\n\\nDofManager\\n├── node dof definitions\\n├── constrained/free dof mapping\\n├── equation numbering\\n├── element equation adjacency view\\n└── full/reduced vector reconstruction\\n\\nResults\\n└── ResultStep\\n └── ResultFrame\\n ├── FieldOutput\\n ├── HistoryOutput\\n └── DiagnosticOutput\\n```\\n\\n장기 목표인 `AnalysisState`의 velocity, acceleration, temperature, increment,\\niteration 및 material state는 해당 해석 기능을 구현할 때 추가한다. Phase 1 객체에\\n사용되지 않는 상태를 미리 할당하지 않는다.\\n\\n## 5. 상태 관리\\n\\n- `Domain`은 입력에서 만들어진 전체 모델 정의를 소유한다.\\n- syntax-to-semantic mapping과 validation이 끝난 `Domain`은 가능한 한 불변으로\\n 취급한다.\\n- 계층형 입력의 외부 ID는 `(instance name, part-local label)`로 표현하고 내부\\n dense index와 구분한다. flat 입력은 예약된 global scope를 사용한다.\\n- 여러 Part를 파싱할 수 있지만 단일 Assembly의 단일 무변환 Instance가 참조하는\\n Part만 `Domain`에 포함한다.\\n- `AnalysisModel`은 현재 step에서 활성화되는 객체의 ID/참조 기반 view다. `Domain`을\\n 복제하지 않는다.\\n- `DofManager`는 DOF와 equation numbering을 전담한다. `Node`와 `Element`에\\n equation ID를 저장하지 않는다.\\n- `AnalysisState`는 해석 중 변하는 물리량만 소유한다.\\n- 결과는 `ResultStep -> ResultFrame -> FieldOutput/HistoryOutput` 구조로 관리한다.\\n\\n## 6. 데이터 흐름\\n\\n```text\\nAbaqus input file\\n-> lexer/parser\\n-> scoped syntax records\\n-> complete-deck reference resolution\\n-> flat scope 또는 단일 active Part/Instance 선택\\n-> set/material/section/load/BC 정규화와 validation\\n-> immutable Domain\\n-> StepDefinition\\n-> AnalysisModel\\n-> DofManager\\n-> sparse pattern\\n-> element contributions\\n-> deterministic Assembler\\n-> essential BC elimination\\n-> MKL PARDISO\\n-> full state/reaction reconstruction\\n-> element result recovery\\n-> Results\\n-> HDF5 writer\\n```\\n\\n파싱, semantic validation, equation construction, solve 및 output 단계는 서로 다른\\ndiagnostic context를 유지한다.\\n\\n## 7. 해석 실행 흐름\\n\\n`Analysis::run()`은 다음 생명주기를 고정한다.\\n\\n```text\\ninitialize\\nbuildAnalysisModel\\nbuildDofMap\\nbuildSparsePattern\\nexecuteProcedure\\nfinalizeResults\\n```\\n\\nPhase 1의 `LinearStaticAnalysis::executeProcedure()`는 다음을 수행한다.\\n\\n```text\\nassemble\\napplyBoundaryConditions\\nsolve\\nreconstructFullState\\nrecoverReactions\\nrecoverElementResults\\nwriteResults\\n```\\n\\n미래의 비선형·동적 해석은 `executeProcedure` 내부에 각각 Newton 또는 time-step\\nloop를 소유한다. base class가 모든 해석 종류의 반복 변수를 미리 소유하지 않는다.\\n\\n## 8. Timoshenko Beam kernel\\n\\nPhase 1 kernel은 다음 입력만 받는다.\\n\\n- 두 절점 좌표\\n- 12개 local/global DOF mapping\\n- \\\\(E,\\\\nu\\\\)\\n- \\\\(A,I_y,I_z,J,A_{sy},A_{sz}\\\\)\\n- 국부 단면축 기준 방향\\n- 필요한 평가 위치와 회복점\\n\\nkernel 책임:\\n\\n- 강건한 국부 직교 기저 생성\\n- 자연좌표 shape function과 Jacobian 평가\\n- 축·굽힘·비틀림 2점 Gauss 적분\\n- 전단 1점 Gauss 적분\\n- local stiffness와 global transformation\\n- section strain/resultant와 \\\\(\\\\sigma_{xx}\\\\) 회복\\n\\nkernel은 Abaqus의 slenderness compensation을 구현하지 않는다. 명시적 전단강성이\\n없으면 semantic mapper가 \\\\(A_{sy}=A_{sz}=5A/6\\\\)과 `SCF=0`을 적용한다. 명시적\\n전단강성은 이 기본값을 덮어쓰며 nonzero `SCF`는 거부한다.\\n\\n## 9. 희소 조립과 병렬성\\n\\n1. `assembly`의 sparse pattern builder가 요소 connectivity와 `DofManager`의\\n equation mapping으로 sparsity pattern을 생성한다.\\n2. oneTBB가 요소별 local contribution을 독립적으로 계산한다.\\n3. worker는 공유 CSR 값 배열에 무질서하게 누적하지 않고 thread-local contribution을\\n 생성한다.\\n4. contribution을 전역 row, column 및 안정된 tie-break key로 정렬한다.\\n5. 고정된 순서로 합산해 대칭 CSR을 생성한다.\\n6. essential BC를 소거해 reduced symmetric system을 만든다.\\n7. TBB 작업이 끝난 뒤 MKL PARDISO를 호출한다.\\n\\n성능보다 같은 입력·설정에서의 수치 재현성을 우선한다. 병렬·직렬 결과 비교와 thread\\ncount 변화 테스트를 reference suite에 포함한다.\\n\\n## 10. 선형해법 backend\\n\\n`LinearSolver` 경계는 matrix structure, numeric values, RHS를 입력받고 solution과\\n진단을 반환한다. Phase 1의 유일한 구현은 `PardisoLinearSolver`다.\\n\\nPARDISO adapter 책임:\\n\\n- 0-based 대칭 CSR 계약 검증\\n- analysis, factorization, solve 및 release phase 관리\\n- MKL error code를 FESA diagnostic으로 변환\\n- matrix checker와 residual diagnostic 제공\\n- handle과 workspace의 RAII 수명 관리\\n\\n반력은 reduced solve 결과를 full vector로 복원한 뒤 원래 시스템의\\n\\\\(r=Ku-f\\\\)에서 계산한다.\\n\\n## 11. HDF5 schema\\n\\n최상위 구조:\\n\\n```text\\n/\\n├── metadata\\n├── model\\n│ ├── nodes\\n│ ├── elements\\n│ ├── sets\\n│ ├── materials\\n│ ├── properties\\n│ └── id_maps\\n├── analysis\\n│ ├── steps\\n│ ├── boundary_conditions\\n│ ├── loads\\n│ └── solver_settings\\n├── results\\n│ └── steps//frames/\\n│ ├── nodal\\n│ ├── element\\n│ └── history\\n└── diagnostics\\n```\\n\\n작은 schema 정보와 설명은 attribute로, 수치 배열과 가변 크기 데이터는 dataset으로\\n저장한다. root metadata에는 schema version, FESA version, 입력 fingerprint,\\n좌표계 및 단위 정책을 기록한다. 계층형 입력은 Part/Instance 이름, part-local ID와\\n전단강성 값의 입력/기본값 출처를 함께 저장한다.\\n\\n## 12. 오류 처리\\n\\n진단은 최소한 다음 분류를 가진다.\\n\\n- I/O 및 encoding 오류\\n- lexical/syntax 오류\\n- 미지원 keyword/option\\n- semantic reference 오류\\n- model validity 오류\\n- equation system 오류\\n- numerical solver 오류\\n- result recovery 또는 HDF5 오류\\n\\n각 진단은 가능한 경우 source file, line, keyword, entity ID, analysis stage 및 원인을\\n포함한다.\\n\\n다음 조건은 묵시적으로 보정하지 않고 실패시킨다.\\n\\n- 길이가 0인 요소\\n- 요소축과 평행하거나 길이가 0인 단면 방향 벡터\\n- 존재하지 않는 절점·집합·재료·단면 참조\\n- 중첩 집합 순환\\n- 여러 Assembly/Instance 또는 Instance 평행이동·회전\\n- Instance가 참조하지 않는 Part entity를 Assembly 집합이 참조하는 경우\\n- 재료나 단면이 없거나 중복 할당된 요소\\n- 상충하는 경계조건\\n- 강체모드가 남은 singular equation system\\n- NaN 또는 무한대 입력·결과\\n\\n## 13. 설계 패턴\\n\\n- Adapter: Abaqus, MKL, TBB 및 HDF5 경계\\n- RAII: PARDISO handle, HDF5 object와 temporary workspace\\n- Strategy: 실제 교체 가능성이 있는 solver와 writer 경계\\n- Template Method: `Analysis::run()`의 공통 생명주기\\n- Factory: Phase 1에는 B31을 생성하는 명시적 factory\\n- Registry: 두 번째 실제 요소나 material type이 추가되는 phase에서만 도입\\n- Runtime polymorphism: assembly가 구체 요소 내부 상태를 알지 않게 하는 최소 계약\\n\\n대규모 모델에서 virtual dispatch가 병목이라는 측정 결과가 있을 때만 타입별 batch\\nkernel을 추가한다.\\n\\n## 14. 검증 구조\\n\\n- `tests/unit`: 값 타입, parser 단위, shape function, quadrature, transformation,\\n element matrix\\n- `tests/integration`: `.inp`에서 HDF5까지 전체 경로\\n- `tests/reference`: CSV 골든 결과와 FESA HDF5 결과 비교\\n- `reference/`: Abaqus 입력과 현재 사용할 수 있는 결과 CSV\\n\\nreference comparison request가 비교할 물리량과 CSV 경로, 상대 tolerance 및\\n물리량별 절대 scale을 명시한다. 요청한 CSV가 없으면 실패하며 요청하지 않은 결과를\\n통과로 표시하지 않는다. 현재 캔틸레버는 변위와 반력만 요청하고, 요소 내력과\\n단면 도심 응력 adapter는 synthetic CSV로 검증한다.\\n\\n요소 내력 CSV의 `(Instance, Element Label, Node Label)` 위치에서\\n`SF1,SF2,SF3,SM1,SM2,SM3`을 \\\\(N,V_y,V_z,T,M_y,M_z\\\\)로 매핑한다. 응력 CSV의\\n같은 위치에 있는 `Sxx`는 단면 도심값 \\\\(N/A\\\\)와 비교한다. 단일 Instance에서는\\nInstance 열 생략을 허용하되 comparison request가 제공한 Instance 이름으로\\n보완한다.\\n\\nreference helper는 반드시 public parser와 analysis 경로로 FESA 결과를 생성한다.\\n테스트 전용 경로로 Domain이나 matrix를 직접 주입해 전체 파이프라인 결함을 숨기지\\n않는다.\\n\\n## 15. Harness 실행 계층\\n\\n현재 저장소의 `scripts/execute.py`, `docs/HARNESS.md` 및\\n`.agents/skills/harness/SKILL.md`를 실행 계약으로 사용한다.\\n\\nExecutor 동작:\\n\\n- `feat-{phase-name}` 브랜치 생성 또는 checkout\\n- `AGENTS.md`와 `docs/*.md` guardrail 주입\\n- 완료된 step의 `summary`를 다음 prompt에 전달\\n- 실패 시 이전 오류를 포함해 최대 3회 재시도\\n- 코드 변경과 phase metadata를 분리해 commit\\n- step/phase timestamp 기록\\n- `--push` 사용 시에만 원격 push\\n\\nCodex hook 동작:\\n\\n- PreToolUse hook은 위험한 명령 패턴을 검사한다.\\n- Stop hook은 감지된 C/C++ 프로젝트를 MSVC로 빌드하고 테스트한다.\\n- `.harness/config.json`이 있으면 해당 설정과 preset을 우선한다.\\n\\n현재 executor에 없는 `allowed_paths`, `validate_workspace.py`,\\n`codex/` 브랜치 및 명시적 clean-worktree 정책은 FESA 아키텍처의\\n요구사항으로 간주하지 않는다.\\n\\r\\n# FESA Architecture Decision Records\\r\\n\\r\\n이 문서는 FESA의 주요 기술 선택과 포기한 대안을 기록한다. 현재 상태가 `Accepted`인\\r\\n결정은 Phase 1 계획과 구현에 적용한다. 결정을 변경할 때는 기존 기록을 지우지 않고\\r\\n새 ADR에서 대체 관계를 명시한다.\\r\\n\\r\\n## ADR-001: C++20, MSVC v143, x64와 CMake Presets\\r\\n\\r\\n**상태:** Superseded by ADR-016\\r\\n\\r\\n**상황:** 첫 배포는 Windows 개발팀 내부 검증용이며 Intel oneAPI와 HDF5를 일관되게\\r\\n연동하고 Harness에서 자동 검증해야 한다.\\r\\n\\r\\n**결정:** C++20, Visual Studio 2022 MSVC v143, Windows x64, CMake, CMake Presets,\\r\\nCTest 및 GoogleTest/GoogleMock을 사용한다.\\r\\n\\r\\n**결과와 트레이드오프:**\\r\\n\\r\\n- `std::span` 등 C++20 기능으로 비소유 수치 view를 명시할 수 있다.\\r\\n- CMake target 경계와 preset을 빌드 계약으로 사용할 수 있다.\\r\\n- 다른 컴파일러, 운영체제 및 32비트 플랫폼은 Phase 1 보장 대상이 아니다.\\r\\n\\r\\n## ADR-002: 외부 의존성은 개발 환경에 사전 설치\\r\\n\\r\\n**상태:** Accepted\\r\\n\\r\\n**상황:** oneMKL, oneTBB, HDF5와 GoogleTest의 공급 방식을 하나로 정해야 한다.\\r\\n\\r\\n**결정:** 모든 외부 라이브러리는 개발·빌드 PC에 사전 설치하고 CMake가 설치 위치를\\r\\n탐색한다. vcpkg나 Conan manifest는 Phase 1에 도입하지 않는다.\\r\\n\\r\\n**결과와 트레이드오프:**\\r\\n\\r\\n- 사내 표준 설치 환경을 그대로 사용할 수 있다.\\r\\n- dependency bootstrap을 구현하지 않는다.\\r\\n- 구성 단계는 누락, architecture 불일치 및 지원하지 않는 설치를 명시적으로\\r\\n 진단해야 한다.\\r\\n- 재현성은 설치 버전 기록과 build environment 문서에 의존한다.\\r\\n\\r\\n## ADR-003: 위험 우선 수직 파이프라인\\r\\n\\r\\n**상태:** Accepted\\r\\n\\r\\n**상황:** 첫 배포는 요소 종류보다 입력부터 결과까지의 코드 구조 검증에 초점을 둔다.\\r\\n\\r\\n**결정:** 가장 작은 Beam 모델로 `.inp` 파싱, semantic model, DOF, 조립, constraint,\\r\\nPARDISO, 결과 회복 및 HDF5 출력을 먼저 연결한다. 이후 합의된 입력 기능을 완성하고\\r\\n마지막으로 요소 정확도 자격 검증을 수행한다.\\r\\n\\r\\n**결과와 트레이드오프:**\\r\\n\\r\\n- 모듈 계약과 데이터 누락을 일찍 발견한다.\\r\\n- 임시 가짜 강성행렬은 사용하지 않고 실제 Timoshenko kernel의 최소 구현을 사용한다.\\r\\n- 파이프라인 연결 완료는 수치적으로 검증된 배포를 뜻하지 않는다.\\r\\n- Abaqus tolerance와 physics sanity를 통과해야 Phase 1 배포가 완료된다.\\r\\n\\r\\n## ADR-004: Abaqus syntax와 solver semantic model 분리\\r\\n\\r\\n**상태:** Superseded by ADR-013\\r\\n\\r\\n**상황:** Abaqus `.inp` 부분집합을 지원하지만 내부 모델이 Abaqus 문법과 결합되면\\r\\n해석 코드와 향후 입력 adapter가 오염된다.\\r\\n\\r\\n**결정:** `io/abaqus`가 syntax를 파싱하고 검증된 `Domain` semantic model로\\r\\n변환한다. 해석 계층에는 keyword 문자열, line layout 및 parser 임시 객체를 전달하지\\r\\n않는다.\\r\\n\\r\\n**결과와 트레이드오프:**\\r\\n\\r\\n- 입력 adapter와 FEM 코어를 독립적으로 시험할 수 있다.\\r\\n- syntax 오류와 semantic 오류를 분리할 수 있다.\\r\\n- 이 결정의 syntax/semantic 분리 원칙은 유지되며 입력 조직 범위는 ADR-013이\\r\\n 대체한다.\\r\\n\\r\\n## ADR-005: 2절점 3D Isoparametric Timoshenko Beam\\r\\n\\r\\n**상태:** Accepted\\r\\n\\r\\n**상황:** 첫 요소는 절점당 6자유도의 3D Beam이며 짧고 두꺼운 보의 전단변형을\\r\\n표현해야 한다.\\r\\n\\r\\n**결정:**\\r\\n\\r\\n- 2절점 직선 Isoparametric Timoshenko Beam을 사용한다.\\r\\n- 축·굽힘·비틀림 항은 2점, 전단 항은 1점 Gauss 적분한다.\\r\\n- 일반 단면 \\\\(A,I_y,I_z,J,A_{sy},A_{sz}\\\\)와 등방성 선형 탄성을 사용한다.\\r\\n- 도심·주축 단면, \\\\(I_{yz}=0\\\\), 단면 오프셋과 워핑 없음으로 제한한다.\\r\\n\\r\\n**결과와 트레이드오프:**\\r\\n\\r\\n- 전단변형을 표현하고 세장 보의 shear locking을 완화한다.\\r\\n- reduced shear integration과 좌표변환을 별도로 검증해야 한다.\\r\\n- 점별 전단·비틀림 응력은 단면 형상 정보가 없어 출력하지 않는다.\\r\\n- 미래 Beam이나 shell formulation을 위한 범용 kernel framework를 미리 만들지 않는다.\\r\\n\\r\\n## ADR-006: Essential BC 소거와 MKL PARDISO\\r\\n\\r\\n**상태:** Accepted\\r\\n\\r\\n**상황:** 최대 약 10만 자유도의 선형 정적 문제를 안정적으로 풀고 비영 지정값과\\r\\n반력을 지원해야 한다.\\r\\n\\r\\n**결정:** essential DOF를 소거해 reduced symmetric CSR system을 구성하고 MKL\\r\\nPARDISO 대칭 양정치 직접해법으로 푼다. full solution을 복원한 뒤 원래 평형식에서\\r\\n반력을 계산한다.\\r\\n\\r\\n**결과와 트레이드오프:**\\r\\n\\r\\n- 초기 구현과 singularity 진단이 반복해법보다 단순하고 안정적이다.\\r\\n- PARDISO API와 handle은 `solvers/linear` adapter에 격리한다.\\r\\n- MPC, penalty, Lagrange multiplier 및 iterative backend는 Phase 1에서 제외한다.\\r\\n- 구속이 부족한 모델은 명시적 numerical failure로 처리한다.\\r\\n\\r\\n## ADR-007: 결정적 oneTBB 요소 계산과 조립\\r\\n\\r\\n**상태:** Accepted\\r\\n\\r\\n**상황:** 요소 계산을 병렬화하면서 reference 회귀검증에 필요한 수치 재현성을\\r\\n유지해야 한다.\\r\\n\\r\\n**결정:** oneTBB로 요소별 contribution을 병렬 계산하고 thread-local 결과를 안정된\\r\\nkey로 정렬한 뒤 고정 순서로 합산해 CSR을 생성한다. PARDISO 실행 중에는 외부 TBB\\r\\n작업을 중첩하지 않는다.\\r\\n\\r\\n**결과와 트레이드오프:**\\r\\n\\r\\n- thread scheduling 변화에 의한 비결정적 합산을 줄인다.\\r\\n- 공유 CSR에 대한 원자적 무질서 누적을 피한다.\\r\\n- 최대 throughput보다 재현성과 디버깅 가능성을 우선한다.\\r\\n- 병렬화 이득이 작은 모델에는 scheduling overhead가 생길 수 있다.\\r\\n\\r\\n## ADR-008: 자기완결형, 버전 지정 HDF5 결과\\r\\n\\r\\n**상태:** Accepted\\r\\n\\r\\n**상황:** 결과 파일만으로 모델과 해석 조건을 추적하고 reference comparison을\\r\\n수행해야 한다.\\r\\n\\r\\n**결정:** 모델, ID mapping, step, solver 설정, 절점·요소 결과와 diagnostic을 하나의\\r\\nHDF5 파일에 저장하고 root에 schema version을 기록한다.\\r\\n\\r\\n**결과와 트레이드오프:**\\r\\n\\r\\n- 원본 `.inp` 없이도 결과 entity와 해석 조건을 추적할 수 있다.\\r\\n- schema 변경을 명시적으로 versioning할 수 있다.\\r\\n- 모델을 중복 저장하므로 결과 파일이 커진다.\\r\\n- HDF5 writer/reader와 resource 수명 관리가 별도 adapter 책임이 된다.\\r\\n\\r\\n## ADR-009: Abaqus 2024 오프라인 골든 검증\\r\\n\\r\\n**상태:** Superseded by ADR-014 and ADR-015\\r\\n\\r\\n**상황:** 상용 reference solver는 개발·CI 환경에서 자동 실행할 수 없지만 변위,\\r\\n반력, 요소 내력 및 응력 비교가 필요하다.\\r\\n\\r\\n**결정:** Abaqus/Standard 2024가 생성한 입력과 CSV 결과를 versioned golden data로\\r\\n관리한다. 구체적인 CSV 선택과 전단 기본값 계약은 ADR-014와 ADR-015가 대체한다.\\r\\n\\r\\n**결과와 트레이드오프:**\\r\\n\\r\\n- CI에서 Abaqus 설치와 license가 필요하지 않다.\\r\\n- 골든 데이터 갱신은 별도 Abaqus 환경과 수동 승인 절차가 필요하다.\\r\\n- per-model metadata 요구사항은 ADR-015에서 제거한다.\\r\\n\\r\\n## ADR-010: 검증 계층별 허용오차\\r\\n\\r\\n**상태:** Accepted\\r\\n\\r\\n**상황:** 모든 물리량에 하나의 상대오차를 적용하면 영에 가까운 값이나 서로 다른\\r\\n규모의 결과를 올바르게 판정할 수 없다.\\r\\n\\r\\n**결정:** 단위·정식화 테스트와 Abaqus 비교를 분리하고, reference 비교에는 기본\\r\\n상대오차 \\\\(10^{-5}\\\\)와 물리량별 characteristic scale 기반 절대오차를 함께 사용한다.\\r\\n\\r\\n**결과와 트레이드오프:**\\r\\n\\r\\n- 영에 가까운 값과 큰 값 모두 의미 있게 비교할 수 있다.\\r\\n- 모델별 예외 tolerance에는 문서화된 수치 근거가 필요하다.\\r\\n- 단일 tolerance보다 comparison request와 helper가 복잡해진다.\\r\\n\\r\\n## ADR-011: 일관 단위계와 결과 좌표계\\r\\n\\r\\n**상태:** Accepted\\r\\n\\r\\n**상황:** Abaqus와 같은 입력 호환성과 명확한 Beam 결과 부호를 유지해야 한다.\\r\\n\\r\\n**결정:** FESA는 단위를 변환하지 않고 사용자가 일관 단위계를 제공한다. 절점\\r\\n변위·회전과 반력은 전역좌표계로, 단면력·단면변형률과 회복응력은 요소\\r\\n국부좌표계로 출력한다.\\r\\n\\r\\n**결과와 트레이드오프:**\\r\\n\\r\\n- 입력이 단순하고 Abaqus 모델과 공유하기 쉽다.\\r\\n- 단위 일관성은 입력 작성자의 책임이다.\\r\\n- HDF5에 요소별 국부 기저와 좌표계 metadata를 저장해야 한다.\\r\\n\\r\\n## ADR-012: Phase 1 최소 실체화와 기존 Harness 유지\\r\\n\\r\\n**상태:** Accepted\\r\\n\\r\\n**상황:** 장기 아키텍처는 여러 요소와 해석 절차를 예상하지만, 첫 배포는 Beam\\r\\n선형 정적 파이프라인에 한정된다. 저장소에는 이미 phase executor와 MSVC validation\\r\\nhook이 있다.\\r\\n\\r\\n**결정:**\\r\\n\\r\\n- 필요한 모듈과 클래스만 해당 phase에서 만든다.\\r\\n- 미래 taxonomy는 `docs/ARCHITECTURE.md`에 기록하되 빈 구현을 생성하지 않는다.\\r\\n- 현재 `scripts/execute.py`, `docs/HARNESS.md` 및\\r\\n `.agents/skills/harness/SKILL.md`의 실행 계약을 변경하지 않는다.\\r\\n\\r\\n**결과와 트레이드오프:**\\r\\n\\r\\n- 선행 abstraction과 사용되지 않는 상태를 줄인다.\\r\\n- 두 번째 실제 요소나 analysis가 추가될 때 factory, registry 또는 state 계약을\\r\\n 확장한다.\\r\\n- Harness phase는 현재의 `feat-{phase-name}` 브랜치, 재시도, guardrail 및\\r\\n 코드/metadata 분리 commit 동작을 따른다.\\r\\n\\r\\n## ADR-013: 단일 Instance를 Domain으로 정규화\\r\\n\\r\\n**상태:** Accepted\\r\\n\\r\\n**상황:** 제공된 Abaqus 검증 모델은 Part/Assembly/Instance 구조를 사용하지만\\r\\n해석 코어 전체에 Abaqus scope를 노출하면 Phase 1 복잡도가 크게 증가한다.\\r\\n\\r\\n**결정:** flat/orphan mesh를 계속 지원하면서 여러 Part와 단일 Assembly·단일\\r\\n무변환 Instance를 파싱한다. semantic mapper는 Instance가 참조하는 Part만 활성화해\\r\\nflat `Domain`으로 정규화한다. 외부 entity는 `(instance name, part-local label)`로\\r\\n식별하고 dense solver index와 분리한다.\\r\\n\\r\\n**결과와 트레이드오프:**\\r\\n\\r\\n- 제공된 계층형 입력을 해석하면서 FEM·assembly·solver 경계를 유지한다.\\r\\n- 사용되지 않는 Part는 파싱하되 해석 객체를 생성하지 않는다.\\r\\n- Part와 Assembly 집합 scope를 별도로 해석해야 한다.\\r\\n- 여러 Assembly/Instance, Instance 좌표변환 및 instance-local mesh 수정은 Phase 1\\r\\n 미지원 diagnostic이다.\\r\\n\\r\\n## ADR-014: 생략된 Beam 전단강성의 Phase 1 기본값\\r\\n\\r\\n**상태:** Accepted\\r\\n\\r\\n**상황:** 일반 Beam 단면 입력과 제공된 검증 샘플에 명시적\\r\\n`*TRANSVERSE SHEAR STIFFNESS`가 없지만 Timoshenko kernel에는 유효 전단면적이\\r\\n필요하다.\\r\\n\\r\\n**결정:** 전단강성이 생략되면 \\\\(A_{sy}=A_{sz}=5A/6\\\\)과 `SCF=0`을 적용한다.\\r\\n지원되는 명시값은 기본값을 덮어쓰고 nonzero `SCF`는 거부한다.\\r\\n\\r\\n**결과와 트레이드오프:**\\r\\n\\r\\n- 현재 정사각형 캔틸레버 샘플의 전단 응답을 일관되게 표현할 수 있다.\\r\\n- 이 값은 임의 일반 단면에 대한 보편적 Abaqus 기본값이 아니라 FESA Phase 1\\r\\n 가정이다.\\r\\n- HDF5 결과에 전단 값과 입력/기본값 출처를 기록해야 한다.\\r\\n\\r\\n## ADR-015: 명시적 물리량 선택 기반 CSV 검증\\r\\n\\r\\n**상태:** Accepted\\r\\n\\r\\n**상황:** 현재 캔틸레버 reference에는 변위와 반력만 있고 per-model metadata는\\r\\n요구하지 않는다. 요소 내력과 응력 비교 기능은 해당 CSV가 추가되기 전에 구현해야\\r\\n한다.\\r\\n\\r\\n**결정:** comparison request가 물리량, CSV 경로, 상대 tolerance와 절대 scale을\\r\\n명시한다. 현재 캔틸레버는 변위와 반력만 선택한다. 요소 내력은\\r\\n`SF1..SF3/SM1..SM3`을 \\\\(N,V_y,V_z,T,M_y,M_z\\\\)로, 응력 `Sxx`는 요소 절점의\\r\\n단면 도심 \\\\(N/A\\\\)로 비교한다. 요소 내력·응력 adapter는 synthetic CSV로 우선\\r\\n검증한다.\\r\\n\\r\\n**결과와 트레이드오프:**\\r\\n\\r\\n- 누락된 비요청 CSV 때문에 현재 reference 검증이 차단되지 않는다.\\r\\n- 요청한 파일이 없으면 실패하며 비요청 물리량을 통과로 오인하지 않는다.\\r\\n- 단일 Instance에서는 Instance 열을 생략할 수 있다.\\r\\n- tolerance와 검증 출처는 test registration과 `docs/VALIDATION.md`에서 관리한다.\\r\\n\\r\\n## ADR-016: Visual Studio 2026 MSVC v145로 툴체인 갱신\\r\\n\\r\\n**상태:** Accepted\\r\\n\\r\\n**상황:** 개발 환경에 Visual Studio 2026 Community와 MSVC v145가 설치되어 있고,\\r\\nCMake 4.4.0이 `Visual Studio 18 2026` 생성기를 지원한다. 반면 기존 ADR-001의\\r\\nVisual Studio 2022 MSVC v143은 설치되어 있지 않아 solver bootstrap을 진행할 수\\r\\n없다.\\r\\n\\r\\n**결정:** ADR-001의 컴파일러 선택을 대체해 C++20, Visual Studio 2026 MSVC v145,\\r\\nWindows x64를 사용한다. CMake Preset은 `Visual Studio 18 2026` 생성기와 `v145`\\r\\ntoolset을 명시한다. CMake, CMake Presets, CTest 및 GoogleTest/GoogleMock 선택은\\r\\n유지한다.\\r\\n\\r\\n**결과와 트레이드오프:**\\r\\n\\r\\n- 현재 설치된 개발 환경에서 별도 v143 설치 없이 bootstrap을 진행할 수 있다.\\r\\n- 빌드 계약이 Visual Studio 2026과 v145에 고정되므로 이전 MSVC toolset은 Phase 1\\r\\n 보장 대상이 아니다.\\r\\n- 컴파일러 갱신에 따른 경고와 표준 라이브러리 동작은 전체 Debug/Release 검증에서\\r\\n 다시 확인해야 한다.\\r\\n\\r\\n#pragma once\\r\\n\\r\\n#include \\r\\n#include \\r\\n#include