diff --git a/phases/fem-and-beam-kernel/index.json b/phases/fem-and-beam-kernel/index.json
index 6252ba5..b29cc85 100644
--- a/phases/fem-and-beam-kernel/index.json
+++ b/phases/fem-and-beam-kernel/index.json
@@ -29,7 +29,10 @@
{
"step": 3,
"name": "timoshenko-stiffness-kernel",
- "status": "pending"
+ "status": "completed",
+ "summary": "Documented and implemented selectively integrated Beam3D2 local/global stiffness with rigid-body, analytical, slenderness, and rotation-invariance tests.",
+ "started_at": "2026-07-31T02:08:27+0900",
+ "completed_at": "2026-07-31T02:24:47+0900"
}
],
"created_at": "2026-07-31T01:37:23+0900"
diff --git a/phases/fem-and-beam-kernel/step3-output.json b/phases/fem-and-beam-kernel/step3-output.json
new file mode 100644
index 0000000..e80ebfc
--- /dev/null
+++ b/phases/fem-and-beam-kernel/step3-output.json
@@ -0,0 +1,7 @@
+{
+ "step": 3,
+ "name": "timoshenko-stiffness-kernel",
+ "exitCode": 0,
+ "stdout": "{\"type\":\"thread.started\",\"thread_id\":\"019fb3ff-b520-76b2-816d-38ccc1c62a8f\"}\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은 `using-superpowers → brainstorming/계획 → harness → TDD → 검증` 순서로 진행하겠습니다. 먼저 각 스킬의 실행 규칙과 Step 기준 파일을 끝까지 읽고, 현재 브랜치·작업 트리·기존 Step 0~2 구현을 확인하겠습니다. 정식화 문서를 먼저 고정한 뒤 실패 테스트, 최소 커널 구현, focused/full 검증, phase 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 -LiteralPath 'C:\\\\\\\\git\\\\\\\\FESA\\\\\\\\.agents\\\\\\\\skills\\\\\\\\harness\\\\\\\\SKILL.md'\\\"\",\"aggregated_output\":\"\",\"exit_code\":null,\"status\":\"in_progress\"}}\n{\"type\":\"item.started\",\"item\":{\"id\":\"item_4\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Raw -LiteralPath 'C:\\\\\\\\Users\\\\\\\\baram\\\\\\\\.codex\\\\\\\\plugins\\\\\\\\cache\\\\\\\\openai-curated-remote\\\\\\\\superpowers\\\\\\\\6.2.0\\\\\\\\skills\\\\\\\\brainstorming\\\\\\\\SKILL.md'\\\"\",\"aggregated_output\":\"\",\"exit_code\":null,\"status\":\"in_progress\"}}\n{\"type\":\"item.started\",\"item\":{\"id\":\"item_5\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Raw -LiteralPath 'C:\\\\\\\\Users\\\\\\\\baram\\\\\\\\.codex\\\\\\\\plugins\\\\\\\\cache\\\\\\\\openai-curated-remote\\\\\\\\superpowers\\\\\\\\6.2.0\\\\\\\\skills\\\\\\\\verification-before-completion\\\\\\\\SKILL.md'\\\"\",\"aggregated_output\":\"\",\"exit_code\":null,\"status\":\"in_progress\"}}\n{\"type\":\"item.started\",\"item\":{\"id\":\"item_6\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Raw -LiteralPath 'C:\\\\\\\\Users\\\\\\\\baram\\\\\\\\.codex\\\\\\\\plugins\\\\\\\\cache\\\\\\\\openai-curated-remote\\\\\\\\superpowers\\\\\\\\6.2.0\\\\\\\\skills\\\\\\\\writing-plans\\\\\\\\SKILL.md'\\\"\",\"aggregated_output\":\"\",\"exit_code\":null,\"status\":\"in_progress\"}}\n{\"type\":\"item.started\",\"item\":{\"id\":\"item_7\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Raw -LiteralPath 'C:\\\\\\\\git\\\\\\\\FESA\\\\\\\\.agents\\\\\\\\skills\\\\\\\\review\\\\\\\\SKILL.md'\\\"\",\"aggregated_output\":\"\",\"exit_code\":null,\"status\":\"in_progress\"}}\n{\"type\":\"item.started\",\"item\":{\"id\":\"item_8\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Raw -LiteralPath 'C:\\\\\\\\Users\\\\\\\\baram\\\\\\\\.codex\\\\\\\\plugins\\\\\\\\cache\\\\\\\\openai-curated-remote\\\\\\\\superpowers\\\\\\\\6.2.0\\\\\\\\skills\\\\\\\\test-driven-development\\\\\\\\SKILL.md'\\\"\",\"aggregated_output\":\"\",\"exit_code\":null,\"status\":\"in_progress\"}}\n{\"type\":\"item.started\",\"item\":{\"id\":\"item_9\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Raw -LiteralPath 'C:\\\\\\\\Users\\\\\\\\baram\\\\\\\\.codex\\\\\\\\plugins\\\\\\\\cache\\\\\\\\openai-curated-remote\\\\\\\\superpowers\\\\\\\\6.2.0\\\\\\\\skills\\\\\\\\using-superpowers\\\\\\\\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 -LiteralPath 'C:\\\\\\\\git\\\\\\\\FESA\\\\\\\\.agents\\\\\\\\skills\\\\\\\\harness\\\\\\\\SKILL.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?꾪궎?띿쿂, ?ㅺ퀎 ?섎룄瑜??뚯븙?쒕떎. 蹂묐젹 ?먯깋???ㅼ젣濡??좎슜?섍퀬 ?꾩옱 ?몄뀡?먯꽌 ?덉슜??\\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\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Raw -LiteralPath 'C:\\\\\\\\Users\\\\\\\\baram\\\\\\\\.codex\\\\\\\\plugins\\\\\\\\cache\\\\\\\\openai-curated-remote\\\\\\\\superpowers\\\\\\\\6.2.0\\\\\\\\skills\\\\\\\\brainstorming\\\\\\\\SKILL.md'\\\"\",\"aggregated_output\":\"---\\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\",\"exit_code\":0,\"status\":\"completed\"}}\n{\"type\":\"item.completed\",\"item\":{\"id\":\"item_5\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Raw -LiteralPath 'C:\\\\\\\\Users\\\\\\\\baram\\\\\\\\.codex\\\\\\\\plugins\\\\\\\\cache\\\\\\\\openai-curated-remote\\\\\\\\superpowers\\\\\\\\6.2.0\\\\\\\\skills\\\\\\\\verification-before-completion\\\\\\\\SKILL.md'\\\"\",\"aggregated_output\":\"---\\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\",\"exit_code\":0,\"status\":\"completed\"}}\n{\"type\":\"item.completed\",\"item\":{\"id\":\"item_6\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Raw -LiteralPath 'C:\\\\\\\\Users\\\\\\\\baram\\\\\\\\.codex\\\\\\\\plugins\\\\\\\\cache\\\\\\\\openai-curated-remote\\\\\\\\superpowers\\\\\\\\6.2.0\\\\\\\\skills\\\\\\\\writing-plans\\\\\\\\SKILL.md'\\\"\",\"aggregated_output\":\"---\\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\",\"exit_code\":0,\"status\":\"completed\"}}\n{\"type\":\"item.completed\",\"item\":{\"id\":\"item_7\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Raw -LiteralPath 'C:\\\\\\\\git\\\\\\\\FESA\\\\\\\\.agents\\\\\\\\skills\\\\\\\\review\\\\\\\\SKILL.md'\\\"\",\"aggregated_output\":\"---\\r\\nname: review\\r\\ndescription: Use when reviewing repository changes against AGENTS.md, architecture decisions, tests, and build requirements.\\r\\n---\\r\\n\\r\\n# Repository Review\\r\\n\\r\\n癒쇱? ?ㅼ쓬 臾몄꽌瑜??쎈뒗??\\r\\n\\r\\n- `/AGENTS.md`\\r\\n- `/docs/ARCHITECTURE.md`\\r\\n- `/docs/ADR.md`\\r\\n\\r\\n?ъ슜?먭? 踰붿쐞瑜?吏?뺥븯吏 ?딆쑝硫??꾩옱 ?묒뾽 ?몃━??蹂寃쎌쓣 由щ럭?쒕떎. 愿??diff瑜?\\n?뺤씤?섍퀬 媛?ν븳 鍮뚮뱶? ?뚯뒪??command瑜??ㅼ젣濡??ㅽ뻾?쒕떎.\\r\\n\\r\\n## 泥댄겕由ъ뒪??\\n\\r\\n1. MSVC toolset? C++ ?쒖???AGENTS.md/ADR怨??쇱튂?섎뒗媛?\\r\\n2. CMake ?먮뒗 MSBuild Debug/x64 鍮뚮뱶媛 ?듦낵?섎뒗媛?\\r\\n3. CTest ?먮뒗 `.harness/config.json`??紐낆떆??test command媛 ?듦낵?섎뒗媛?\\r\\n4. ??C/C++ ?뚯뒪? ?ㅻ뜑??????뚯뒪?멸? ?덈뒗媛?\\r\\n5. CRITICAL ?꾪궎?띿쿂 洹쒖튃怨?public header 寃쎄퀎瑜?吏?ㅻ뒗媛?\\r\\n\\r\\n## 異쒕젰 ?뺤떇\\r\\n\\r\\n?ㅼ젣 寃고븿???ш컖?꾩닚?쇰줈 癒쇱? ?쒖떆?쒕떎. 媛?finding???뚯씪怨?以?踰덊샇, ?곹뼢,\\r\\n?ы쁽 ?먮뒗 洹쇨굅, 援ъ껜?곸씤 ?섏젙 諛⑹븞???ы븿?쒕떎.\\r\\n\\r\\n洹????ㅼ쓬 ?쒕? ?쒓났?쒕떎.\\r\\n\\r\\n| ??ぉ | 寃곌낵 | 鍮꾧퀬 |\\r\\n|------|------|------|\\r\\n| ?꾪궎?띿쿂 以??| ????誘멸?利?| ?곸꽭 |\\r\\n| 湲곗닠 ?ㅽ깮 以??| ????誘멸?利?| ?곸꽭 |\\r\\n| ?뚯뒪??議댁옱 | ????誘멸?利?| ?곸꽭 |\\r\\n| CRITICAL 洹쒖튃 | ????誘멸?利?| ?곸꽭 |\\r\\n| 鍮뚮뱶 媛??| ????誘멸?利?| ?곸꽭 |\\r\\n\\r\\n?ㅽ뻾?????녿뒗 寃?щ뒗 ?깃났?쇰줈 異붿젙?섏? 留먭퀬 `誘멸?利?怨??댁쑀瑜??곷뒗?? finding??\\n?놁쑝硫?諛쒓껄??臾몄젣媛 ?녿떎怨?紐낆떆?섍퀬 ?⑥븘 ?덈뒗 寃利?怨듬갚???ㅻ챸?쒕떎.\\r\\n\\r\\n\",\"exit_code\":0,\"status\":\"completed\"}}\n{\"type\":\"item.completed\",\"item\":{\"id\":\"item_8\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Raw -LiteralPath 'C:\\\\\\\\Users\\\\\\\\baram\\\\\\\\.codex\\\\\\\\plugins\\\\\\\\cache\\\\\\\\openai-curated-remote\\\\\\\\superpowers\\\\\\\\6.2.0\\\\\\\\skills\\\\\\\\test-driven-development\\\\\\\\SKILL.md'\\\"\",\"aggregated_output\":\"---\\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\",\"exit_code\":0,\"status\":\"completed\"}}\n{\"type\":\"item.completed\",\"item\":{\"id\":\"item_9\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Raw -LiteralPath 'C:\\\\\\\\Users\\\\\\\\baram\\\\\\\\.codex\\\\\\\\plugins\\\\\\\\cache\\\\\\\\openai-curated-remote\\\\\\\\superpowers\\\\\\\\6.2.0\\\\\\\\skills\\\\\\\\using-superpowers\\\\\\\\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\",\"exit_code\":0,\"status\":\"completed\"}}\n{\"type\":\"item.started\",\"item\":{\"id\":\"item_10\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"(Get-Content -Encoding utf8 -LiteralPath 'C:\\\\\\\\Users\\\\\\\\baram\\\\\\\\.codex\\\\\\\\plugins\\\\\\\\cache\\\\\\\\openai-curated-remote\\\\\\\\superpowers\\\\\\\\6.2.0\\\\\\\\skills\\\\\\\\writing-plans\\\\\\\\SKILL.md').Count\\\"\",\"aggregated_output\":\"\",\"exit_code\":null,\"status\":\"in_progress\"}}\n{\"type\":\"item.started\",\"item\":{\"id\":\"item_11\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"(Get-Content -Encoding utf8 -LiteralPath 'C:\\\\\\\\Users\\\\\\\\baram\\\\\\\\.codex\\\\\\\\plugins\\\\\\\\cache\\\\\\\\openai-curated-remote\\\\\\\\superpowers\\\\\\\\6.2.0\\\\\\\\skills\\\\\\\\using-superpowers\\\\\\\\references\\\\\\\\codex-tools.md').Count\\\"\",\"aggregated_output\":\"\",\"exit_code\":null,\"status\":\"in_progress\"}}\n{\"type\":\"item.started\",\"item\":{\"id\":\"item_12\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"(Get-Content -Encoding utf8 -LiteralPath 'C:\\\\\\\\Users\\\\\\\\baram\\\\\\\\.codex\\\\\\\\plugins\\\\\\\\cache\\\\\\\\openai-curated-remote\\\\\\\\superpowers\\\\\\\\6.2.0\\\\\\\\skills\\\\\\\\test-driven-development\\\\\\\\SKILL.md').Count\\\"\",\"aggregated_output\":\"\",\"exit_code\":null,\"status\":\"in_progress\"}}\n{\"type\":\"item.started\",\"item\":{\"id\":\"item_13\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"(Get-Content -Encoding utf8 -LiteralPath 'C:\\\\\\\\Users\\\\\\\\baram\\\\\\\\.codex\\\\\\\\plugins\\\\\\\\cache\\\\\\\\openai-curated-remote\\\\\\\\superpowers\\\\\\\\6.2.0\\\\\\\\skills\\\\\\\\test-driven-development\\\\\\\\writing-good-tests.md').Count\\\"\",\"aggregated_output\":\"\",\"exit_code\":null,\"status\":\"in_progress\"}}\n{\"type\":\"item.completed\",\"item\":{\"id\":\"item_10\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"(Get-Content -Encoding utf8 -LiteralPath 'C:\\\\\\\\Users\\\\\\\\baram\\\\\\\\.codex\\\\\\\\plugins\\\\\\\\cache\\\\\\\\openai-curated-remote\\\\\\\\superpowers\\\\\\\\6.2.0\\\\\\\\skills\\\\\\\\writing-plans\\\\\\\\SKILL.md').Count\\\"\",\"aggregated_output\":\"168\\r\\n\",\"exit_code\":0,\"status\":\"completed\"}}\n{\"type\":\"item.completed\",\"item\":{\"id\":\"item_11\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"(Get-Content -Encoding utf8 -LiteralPath 'C:\\\\\\\\Users\\\\\\\\baram\\\\\\\\.codex\\\\\\\\plugins\\\\\\\\cache\\\\\\\\openai-curated-remote\\\\\\\\superpowers\\\\\\\\6.2.0\\\\\\\\skills\\\\\\\\using-superpowers\\\\\\\\references\\\\\\\\codex-tools.md').Count\\\"\",\"aggregated_output\":\"39\\r\\n\",\"exit_code\":0,\"status\":\"completed\"}}\n{\"type\":\"item.completed\",\"item\":{\"id\":\"item_12\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"(Get-Content -Encoding utf8 -LiteralPath 'C:\\\\\\\\Users\\\\\\\\baram\\\\\\\\.codex\\\\\\\\plugins\\\\\\\\cache\\\\\\\\openai-curated-remote\\\\\\\\superpowers\\\\\\\\6.2.0\\\\\\\\skills\\\\\\\\test-driven-development\\\\\\\\SKILL.md').Count\\\"\",\"aggregated_output\":\"320\\r\\n\",\"exit_code\":0,\"status\":\"completed\"}}\n{\"type\":\"item.completed\",\"item\":{\"id\":\"item_13\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"(Get-Content -Encoding utf8 -LiteralPath 'C:\\\\\\\\Users\\\\\\\\baram\\\\\\\\.codex\\\\\\\\plugins\\\\\\\\cache\\\\\\\\openai-curated-remote\\\\\\\\superpowers\\\\\\\\6.2.0\\\\\\\\skills\\\\\\\\test-driven-development\\\\\\\\writing-good-tests.md').Count\\\"\",\"aggregated_output\":\"198\\r\\n\",\"exit_code\":0,\"status\":\"completed\"}}\n{\"type\":\"item.started\",\"item\":{\"id\":\"item_14\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command '$p1='\\\"'C:\\\\\\\\Users\\\\\\\\baram\\\\\\\\.codex\\\\\\\\plugins\\\\\\\\cache\\\\\\\\openai-curated-remote\\\\\\\\superpowers\\\\\\\\6.2.0\\\\\\\\skills\\\\\\\\writing-plans\\\\\\\\SKILL.md'; \\\"'$p2='\\\"'C:\\\\\\\\Users\\\\\\\\baram\\\\\\\\.codex\\\\\\\\plugins\\\\\\\\cache\\\\\\\\openai-curated-remote\\\\\\\\superpowers\\\\\\\\6.2.0\\\\\\\\skills\\\\\\\\using-superpowers\\\\\\\\references\\\\\\\\codex-tools.md'; Get-Content -Raw -Encoding utf8 -LiteralPath \\\"'$p1; Get-Content -Raw -Encoding utf8 -LiteralPath $p2'\",\"aggregated_output\":\"\",\"exit_code\":null,\"status\":\"in_progress\"}}\n{\"type\":\"item.completed\",\"item\":{\"id\":\"item_14\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command '$p1='\\\"'C:\\\\\\\\Users\\\\\\\\baram\\\\\\\\.codex\\\\\\\\plugins\\\\\\\\cache\\\\\\\\openai-curated-remote\\\\\\\\superpowers\\\\\\\\6.2.0\\\\\\\\skills\\\\\\\\writing-plans\\\\\\\\SKILL.md'; \\\"'$p2='\\\"'C:\\\\\\\\Users\\\\\\\\baram\\\\\\\\.codex\\\\\\\\plugins\\\\\\\\cache\\\\\\\\openai-curated-remote\\\\\\\\superpowers\\\\\\\\6.2.0\\\\\\\\skills\\\\\\\\using-superpowers\\\\\\\\references\\\\\\\\codex-tools.md'; Get-Content -Raw -Encoding utf8 -LiteralPath \\\"'$p1; Get-Content -Raw -Encoding utf8 -LiteralPath $p2'\",\"aggregated_output\":\"---\\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## Subagent dispatch requires multi-agent support\\n\\nAdd to your Codex config (`~/.codex/config.toml`):\\n\\n```toml\\n[features]\\nmulti_agent = true\\n```\\n\\nThis enables `spawn_agent`, `wait_agent`, and `close_agent` for skills like `dispatching-parallel-agents` and `subagent-driven-development`. When using subagent-driven-development, close reviewer subagents when their review returns. Keep each implementer subagent open until its task's review passes — the fix loop resumes the implementer — then close it. If your harness cannot send another message to a spawned agent, dispatch each fix round as a fresh implementer carrying the brief, the report file, and the findings.\\n\\n## Environment Detection\\n\\nSkills that create worktrees or finish branches should detect their\\nenvironment with read-only git commands before proceeding:\\n\\n```bash\\nGIT_DIR=$(cd \\\"$(git rev-parse --git-dir)\\\" 2>/dev/null && pwd -P)\\nGIT_COMMON=$(cd \\\"$(git rev-parse --git-common-dir)\\\" 2>/dev/null && pwd -P)\\nBRANCH=$(git branch --show-current)\\n```\\n\\n- `GIT_DIR != GIT_COMMON` → already in a linked worktree (skip creation)\\n- `BRANCH` empty → detached HEAD (cannot branch/push/PR from sandbox)\\n\\nSee `using-git-worktrees` Step 0 and `finishing-a-development-branch`\\nStep 1 for how each skill uses these signals.\\n\\n## Codex App Finishing\\n\\nWhen the sandbox blocks branch/push operations (detached HEAD in an\\nexternally managed worktree), the agent commits all work and informs\\nthe user to use the App's native controls:\\n\\n- **\\\"Create branch\\\"** — names the branch, then commit/push/PR via App UI\\n- **\\\"Hand off to local\\\"** — transfers work to the user's local checkout\\n\\nThe agent can still run tests, stage files, and output suggested branch\\nnames, commit messages, and PR descriptions for the user to copy.\\n\\r\\n\",\"exit_code\":0,\"status\":\"completed\"}}\n{\"type\":\"item.started\",\"item\":{\"id\":\"item_15\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Raw -Encoding utf8 -LiteralPath 'C:\\\\\\\\Users\\\\\\\\baram\\\\\\\\.codex\\\\\\\\plugins\\\\\\\\cache\\\\\\\\openai-curated-remote\\\\\\\\superpowers\\\\\\\\6.2.0\\\\\\\\skills\\\\\\\\executing-plans\\\\\\\\SKILL.md'\\\"\",\"aggregated_output\":\"\",\"exit_code\":null,\"status\":\"in_progress\"}}\n{\"type\":\"item.completed\",\"item\":{\"id\":\"item_15\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Raw -Encoding utf8 -LiteralPath 'C:\\\\\\\\Users\\\\\\\\baram\\\\\\\\.codex\\\\\\\\plugins\\\\\\\\cache\\\\\\\\openai-curated-remote\\\\\\\\superpowers\\\\\\\\6.2.0\\\\\\\\skills\\\\\\\\executing-plans\\\\\\\\SKILL.md'\\\"\",\"aggregated_output\":\"---\\nname: executing-plans\\ndescription: Use when you have a written implementation plan to execute in a separate session with review checkpoints\\n---\\n\\n# Executing Plans\\n\\n## Overview\\n\\nLoad plan, review critically, execute all tasks, report when complete.\\n\\n**Announce at start:** \\\"I'm using the executing-plans skill to implement this plan.\\\"\\n\\n**Note:** Tell your human partner that Superpowers works much better with access to subagents (Claude Code, Codex CLI, Codex App, Copilot CLI, and Gemini CLI all qualify; see the per-platform tool refs in `../using-superpowers/references/`). If subagents are available, use superpowers:subagent-driven-development instead of this skill.\\n\\n## The Process\\n\\n### Step 1: Load and Review Plan\\n1. Ensure an isolated workspace: use superpowers:using-git-worktrees to create one or verify the existing one\\n2. Read plan file\\n3. Review critically - identify any questions or concerns about the plan\\n4. If concerns: Raise them with your human partner before starting\\n5. If no concerns: Create todos for the plan items and proceed\\n\\n### Step 2: Execute Tasks\\n\\nFor each task:\\n1. Mark as in_progress\\n2. Follow each step exactly (plan has bite-sized steps)\\n3. Run verifications as specified\\n4. Mark as completed\\n\\n### Step 3: Complete Development\\n\\nAfter all tasks complete and verified:\\n- Announce: \\\"I'm using the finishing-a-development-branch skill to complete this work.\\\"\\n- **REQUIRED SUB-SKILL:** Use superpowers:finishing-a-development-branch\\n- Follow that skill to verify tests, present options, execute choice\\n\\n## When to Stop and Ask for Help\\n\\n**STOP executing immediately when:**\\n- Hit a blocker (missing dependency, test fails, instruction unclear)\\n- Plan has critical gaps preventing starting\\n- You don't understand an instruction\\n- Verification fails repeatedly\\n\\n**Ask for clarification rather than guessing.**\\n\\n## When to Revisit Earlier Steps\\n\\n**Return to Review (Step 1) when:**\\n- Partner updates the plan based on your feedback\\n- Fundamental approach needs rethinking\\n\\n**Don't force through blockers** - stop and ask.\\n\\n## Remember\\n- Review plan critically first\\n- Follow plan steps exactly\\n- Don't skip verifications\\n- Reference skills when plan says to\\n- Stop when blocked, don't guess\\n- Never start implementation on main/master branch without explicit user consent\\n\\r\\n\",\"exit_code\":0,\"status\":\"completed\"}}\n{\"type\":\"item.started\",\"item\":{\"id\":\"item_16\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Raw -Encoding utf8 -LiteralPath 'C:\\\\\\\\Users\\\\\\\\baram\\\\\\\\.codex\\\\\\\\plugins\\\\\\\\cache\\\\\\\\openai-curated-remote\\\\\\\\superpowers\\\\\\\\6.2.0\\\\\\\\skills\\\\\\\\test-driven-development\\\\\\\\SKILL.md'\\\"\",\"aggregated_output\":\"\",\"exit_code\":null,\"status\":\"in_progress\"}}\n{\"type\":\"item.completed\",\"item\":{\"id\":\"item_16\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Raw -Encoding utf8 -LiteralPath 'C:\\\\\\\\Users\\\\\\\\baram\\\\\\\\.codex\\\\\\\\plugins\\\\\\\\cache\\\\\\\\openai-curated-remote\\\\\\\\superpowers\\\\\\\\6.2.0\\\\\\\\skills\\\\\\\\test-driven-development\\\\\\\\SKILL.md'\\\"\",\"aggregated_output\":\"---\\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\",\"exit_code\":0,\"status\":\"completed\"}}\n{\"type\":\"item.started\",\"item\":{\"id\":\"item_17\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Raw -Encoding utf8 -LiteralPath 'C:\\\\\\\\Users\\\\\\\\baram\\\\\\\\.codex\\\\\\\\plugins\\\\\\\\cache\\\\\\\\openai-curated-remote\\\\\\\\superpowers\\\\\\\\6.2.0\\\\\\\\skills\\\\\\\\test-driven-development\\\\\\\\writing-good-tests.md'\\\"\",\"aggregated_output\":\"\",\"exit_code\":null,\"status\":\"in_progress\"}}\n{\"type\":\"item.completed\",\"item\":{\"id\":\"item_17\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Raw -Encoding utf8 -LiteralPath 'C:\\\\\\\\Users\\\\\\\\baram\\\\\\\\.codex\\\\\\\\plugins\\\\\\\\cache\\\\\\\\openai-curated-remote\\\\\\\\superpowers\\\\\\\\6.2.0\\\\\\\\skills\\\\\\\\test-driven-development\\\\\\\\writing-good-tests.md'\\\"\",\"aggregated_output\":\"# Writing Good Tests\\n\\n**Load this reference when:** writing or changing tests, adding mocks, or\\nadding cleanup/helper methods for tests.\\n\\n## Overview\\n\\nA test exists to catch a specific break. Two principles govern everything\\nhere:\\n\\n```\\n1. Every test names the break it catches\\n2. Every test exercises the real thing\\n```\\n\\nStrict TDD produces both naturally: a test written first and watched\\nfailing against real code has already proven it can fail, and only earns\\na mock when the real dependency proves slow or external.\\n\\n## Principle 1: Name the Break\\n\\nBefore writing the test body, answer: **what production change should\\nmake this test fail — and is that change a bug or a decision?** A test\\nearns its place by catching a wrong branch, missing side effect, wrong\\nargument, boundary case, or broken contract.\\n\\n**Derive expectations independently.** Use literals and hand-checked\\nfixtures; table-driven tests with literal `want` values are the preferred\\nshape. An expectation computed by the code under test — or its helpers —\\npasses no matter what that code does:\\n\\n```typescript\\n// ❌ Mirror assertion: the same builder computes both sides — always true\\nconst expected = buildSearchQuery({ tag: 'urgent' });\\nexpect(buildSearchQuery({ tag: 'urgent' })).toBe(expected);\\n\\n// ✅ Hand-derived literal\\nexpect(buildSearchQuery({ tag: 'urgent' })).toBe('tag:\\\"urgent\\\"');\\n```\\n\\n**No change detectors.** If only intentional decisions can fail a test —\\na constant's value, exact message wording, private structure — it fires\\non redesign and sleeps through bugs. Test the behavior that depends on\\nthe decision: not `expect(MAX_RETRIES).toBe(5)` but \\\"a failing call is\\nretried 5 times and the 6th attempt never happens.\\\"\\n\\n**Behavior, not text.** Asserting that a script, skill, or config\\ncontains an exact line proves only that the source is the source. Run\\nscripts against controlled inputs and assert outputs, side effects, or\\nexit codes. Documents that instruct agents are tested by the consuming\\nagent's behavior (superpowers:writing-skills); prose for humans earns no\\ntest at all.\\n\\n**Your code, not the framework.** Test the contract your code makes at\\nits boundaries — the route you register, the query you emit, the payload\\nyou produce. Upstream mechanics are their maintainers' tests to write\\n(the classic: asserting your router invokes a registered handler — that\\nis the framework's test, not yours). When upstream behavior genuinely\\nsurprised you, write one narrow characterization test naming the\\nassumption. The same boundary applies inside your code: constructors,\\ngetters, constants, and trivial forwarding earn tests only when they\\nvalidate, normalize, default, derive, enforce, or cause side effects —\\notherwise assert the first consumer-visible result that depends on them.\\n\\n### Gate Function\\n\\n```\\nBEFORE writing the test body:\\n Name the production change that would make this test fail.\\n\\n Cannot name one → redesign around an observable behavior\\n \\\"The source text changed\\\" → run the artifact and assert its effects\\n Only intentional decisions → change detector; test the behavior\\n that depends on the decision\\n\\n Confirm the expected value is derived without the code under test.\\n IF it reuses the code's logic or helpers:\\n Replace it with a literal or hand-checked fixture\\n```\\n\\n## Principle 2: Exercise the Real Thing\\n\\n**The mock earns no assertions.** A mock assertion passes when the mock\\nis present and fails when it is absent — it says nothing about the\\ncomponent. Assert the real component's behavior; if the mock is what you\\nare checking, unmock it or delete the assertion.\\n\\n```typescript\\n// ✅ Real behavior\\nexpect(screen.getByRole('navigation')).toBeInTheDocument();\\n\\n// ❌ Mock existence\\nexpect(screen.getByTestId('sidebar-mock')).toBeInTheDocument();\\n```\\n\\n**your human partner's correction:** \\\"Are we testing the behavior of a\\nmock?\\\"\\n\\n**Mock at the right level.** Learn every side effect of the real method\\nbefore replacing it; mock the slow or external operation and keep what\\nthe test depends on real. When unsure, run the test against the real\\nimplementation first and observe what actually needs to happen.\\n\\n```typescript\\n// ❌ The mock swallows the config write that duplicate detection reads\\nvi.mock('ToolCatalog', () => ({\\n discoverAndCacheTools: vi.fn().mockResolvedValue(undefined)\\n}));\\n\\n// ✅ Mock only the slow server startup; the config write stays real\\nvi.mock('MCPServerManager');\\n```\\n\\n**Make doubles specific.** When arguments, call counts, or ordering are\\npart of the contract, assert them — a fake that accepts anything verifies\\nnothing. Give each branch (success, error, malformed) its own fixture or\\nspy, so the wrong branch cannot satisfy the expectation.\\n\\n**Mirror real data completely.** Mock the complete structure as it exists\\nin reality — all documented fields — not just the ones your test reads.\\nPartial mocks fail silently when downstream code reads an omitted field:\\nthe test passes while integration breaks.\\n\\n**Production classes carry production methods only.** Cleanup that only\\ntests need lives in test utilities, never as a `destroy()` on the\\nproduction class. Ask: is this method called only from tests? Does this\\nclass own this resource's lifecycle? Wrong answers → test utility.\\n\\n**Prefer real components over complex mocks.** When mock setup outgrows\\nthe test logic, mocks miss methods the real components have, or tests\\nbreak when the mock changes, switch to an integration test with real\\ncomponents. **your human partner's question:** \\\"Do we need to be using a\\nmock here?\\\"\\n\\n### Gate Function\\n\\n```\\nBEFORE adding a mock or test helper:\\n List the real method's side effects; keep the ones the test\\n depends on real — mock the slow/external level below them.\\n\\n Mock responses mirror the complete real structure.\\n\\n A method only tests call lives in test utilities, not production.\\n\\n About to assert on the mock itself?\\n Unmock it or delete the assertion.\\n```\\n\\n## Tests Ship With the Implementation\\n\\nThe TDD cycle — failing test, minimal implementation, refactor — is what\\n\\\"complete\\\" means. Ship the tests the behavior needs and only those:\\ntrivial code and human prose earn none, and a test written to satisfy\\nprocess costs maintenance forever.\\n\\n## The Mutation Check\\n\\nBefore finishing, mentally mutate the production code; at least one test\\nshould fail for each realistic mutation:\\n\\n- Wrong constant or argument\\n- Wrong branch handler\\n- Missing state change or side effect\\n- Empty or default return\\n- Missing validation for zero, empty, nil, unauthorized, or malformed input\\n\\nA mutation nothing catches marks the behavior as unprotected — or the\\ntest as tautological.\\n\\n## Quick Reference\\n\\n| When you... | Do |\\n|-------------|-----|\\n| Write any test | Name the break it catches — a bug, not a decision |\\n| Build an expected value | Derive it by hand; never with the code under test |\\n| Test a script or document | Run it / pressure-test its consumer; never grep its text |\\n| Reach for a dependency test | Test your boundary contract, not their documented mechanics |\\n| Want to assert on a mocked element | Test the real component, or unmock it |\\n| Are about to mock a method | Learn its side effects; mock the slow/external level |\\n| Build a mock response | Mirror the real structure completely |\\n| Need cleanup only tests use | Put it in test utilities |\\n| Watch mock setup balloon | Switch to an integration test with real components |\\n| Finish a test file | Run the mutation check |\\n\\n## Warning Signs\\n\\n- Setup and assertion share the same object, guaranteeing equality\\n- The test can fail only through a panic, crash, or missing selector\\n- The test fails on every intentional change, never on accidental breakage\\n- Expected values are hidden behind loops, builders, or helpers\\n- The test greps source text, or asserts a removed symbol stays removed\\n- The test would still matter if only the framework remained\\n- The test exists for coverage, checking no side effect or outcome\\n- An assertion checks a `*-mock` test ID, or fails if you remove the mock\\n- A method is called only from test files\\n- Mock setup is more than half the test, or you can't explain why the mock is needed\\n- Mocking \\\"just to be safe\\\"\\n\\r\\n\",\"exit_code\":0,\"status\":\"completed\"}}\n{\"type\":\"item.started\",\"item\":{\"id\":\"item_18\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Raw -Encoding utf8 -LiteralPath 'C:\\\\\\\\Users\\\\\\\\baram\\\\\\\\.codex\\\\\\\\plugins\\\\\\\\cache\\\\\\\\openai-curated-remote\\\\\\\\superpowers\\\\\\\\6.2.0\\\\\\\\skills\\\\\\\\using-superpowers\\\\\\\\references\\\\\\\\codex-tools.md'\\\"\",\"aggregated_output\":\"\",\"exit_code\":null,\"status\":\"in_progress\"}}\n{\"type\":\"item.completed\",\"item\":{\"id\":\"item_18\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Raw -Encoding utf8 -LiteralPath 'C:\\\\\\\\Users\\\\\\\\baram\\\\\\\\.codex\\\\\\\\plugins\\\\\\\\cache\\\\\\\\openai-curated-remote\\\\\\\\superpowers\\\\\\\\6.2.0\\\\\\\\skills\\\\\\\\using-superpowers\\\\\\\\references\\\\\\\\codex-tools.md'\\\"\",\"aggregated_output\":\"## Subagent dispatch requires multi-agent support\\n\\nAdd to your Codex config (`~/.codex/config.toml`):\\n\\n```toml\\n[features]\\nmulti_agent = true\\n```\\n\\nThis enables `spawn_agent`, `wait_agent`, and `close_agent` for skills like `dispatching-parallel-agents` and `subagent-driven-development`. When using subagent-driven-development, close reviewer subagents when their review returns. Keep each implementer subagent open until its task's review passes — the fix loop resumes the implementer — then close it. If your harness cannot send another message to a spawned agent, dispatch each fix round as a fresh implementer carrying the brief, the report file, and the findings.\\n\\n## Environment Detection\\n\\nSkills that create worktrees or finish branches should detect their\\nenvironment with read-only git commands before proceeding:\\n\\n```bash\\nGIT_DIR=$(cd \\\"$(git rev-parse --git-dir)\\\" 2>/dev/null && pwd -P)\\nGIT_COMMON=$(cd \\\"$(git rev-parse --git-common-dir)\\\" 2>/dev/null && pwd -P)\\nBRANCH=$(git branch --show-current)\\n```\\n\\n- `GIT_DIR != GIT_COMMON` → already in a linked worktree (skip creation)\\n- `BRANCH` empty → detached HEAD (cannot branch/push/PR from sandbox)\\n\\nSee `using-git-worktrees` Step 0 and `finishing-a-development-branch`\\nStep 1 for how each skill uses these signals.\\n\\n## Codex App Finishing\\n\\nWhen the sandbox blocks branch/push operations (detached HEAD in an\\nexternally managed worktree), the agent commits all work and informs\\nthe user to use the App's native controls:\\n\\n- **\\\"Create branch\\\"** — names the branch, then commit/push/PR via App UI\\n- **\\\"Hand off to local\\\"** — transfers work to the user's local checkout\\n\\nThe agent can still run tests, stage files, and output suggested branch\\nnames, commit messages, and PR descriptions for the user to copy.\\n\\r\\n\",\"exit_code\":0,\"status\":\"completed\"}}\n{\"type\":\"item.started\",\"item\":{\"id\":\"item_19\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Raw -Encoding utf8 -LiteralPath 'C:\\\\\\\\Users\\\\\\\\baram\\\\\\\\.codex\\\\\\\\plugins\\\\\\\\cache\\\\\\\\openai-curated-remote\\\\\\\\superpowers\\\\\\\\6.2.0\\\\\\\\skills\\\\\\\\using-git-worktrees\\\\\\\\SKILL.md'\\\"\",\"aggregated_output\":\"\",\"exit_code\":null,\"status\":\"in_progress\"}}\n{\"type\":\"item.completed\",\"item\":{\"id\":\"item_19\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Raw -Encoding utf8 -LiteralPath 'C:\\\\\\\\Users\\\\\\\\baram\\\\\\\\.codex\\\\\\\\plugins\\\\\\\\cache\\\\\\\\openai-curated-remote\\\\\\\\superpowers\\\\\\\\6.2.0\\\\\\\\skills\\\\\\\\using-git-worktrees\\\\\\\\SKILL.md'\\\"\",\"aggregated_output\":\"---\\nname: using-git-worktrees\\ndescription: Use when starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallback\\n---\\n\\n# Using Git Worktrees\\n\\n## Overview\\n\\nEnsure work happens in an isolated workspace. Prefer your platform's native worktree tools. Fall back to manual git worktrees only when no native tool is available.\\n\\n**Core principle:** Detect existing isolation first. Then use native tools. Then fall back to git. Never fight the harness.\\n\\n**Announce at start:** \\\"I'm using the using-git-worktrees skill to set up an isolated workspace.\\\"\\n\\n## Step 0: Detect Existing Isolation\\n\\n**Before creating anything, check if you are already in an isolated workspace.**\\n\\n```bash\\nGIT_DIR=$(cd \\\"$(git rev-parse --git-dir)\\\" 2>/dev/null && pwd -P)\\nGIT_COMMON=$(cd \\\"$(git rev-parse --git-common-dir)\\\" 2>/dev/null && pwd -P)\\nBRANCH=$(git branch --show-current)\\n```\\n\\n**Submodule guard:** `GIT_DIR != GIT_COMMON` is also true inside git submodules. Before concluding \\\"already in a worktree,\\\" verify you are not in a submodule:\\n\\n```bash\\n# If this returns a path, you're in a submodule, not a worktree — treat as normal repo\\ngit rev-parse --show-superproject-working-tree 2>/dev/null\\n```\\n\\n**If `GIT_DIR != GIT_COMMON` (and not a submodule):** You are already in a linked worktree. Skip to Step 2 (Project Setup). Do NOT create another worktree.\\n\\nReport with branch state:\\n- On a branch: \\\"Already in isolated workspace at `` on branch ``.\\\"\\n- Detached HEAD: \\\"Already in isolated workspace at `` (detached HEAD, externally managed). Branch creation needed at finish time.\\\"\\n\\n**If `GIT_DIR == GIT_COMMON` (or in a submodule):** You are in a normal repo checkout.\\n\\nHas the user already indicated their worktree preference in your instructions? If not, ask for consent before creating a worktree:\\n\\n> \\\"Would you like me to set up an isolated worktree? It protects your current branch from changes.\\\"\\n\\nHonor any existing declared preference without asking. If the user declines consent, work in place and skip to Step 2.\\n\\n## Step 1: Create Isolated Workspace\\n\\n**You have two mechanisms. Try them in this order.**\\n\\n### 1a. Native Worktree Tools (preferred)\\n\\nThe user has asked for an isolated workspace (Step 0 consent). Do you already have a way to create a worktree? It might be a tool with a name like `EnterWorktree`, `WorktreeCreate`, a `/worktree` command, or a `--worktree` flag. If you do, use it and skip to Step 2.\\n\\nNative tools handle directory placement, branch creation, and cleanup automatically. Using `git worktree add` when you have a native tool creates phantom state your harness can't see or manage.\\n\\nOnly proceed to Step 1b if you have no native worktree tool available.\\n\\n### 1b. Git Worktree Fallback\\n\\n**Only use this if Step 1a does not apply** — you have no native worktree tool available. Create a worktree manually using git.\\n\\n#### Directory Selection\\n\\nFollow this priority order. Explicit user preference always beats observed filesystem state.\\n\\n1. **Check your instructions for a declared worktree directory preference.** If the user has already specified one, use it without asking.\\n\\n2. **Check for an existing project-local worktree directory:**\\n ```bash\\n ls -d .worktrees 2>/dev/null # Preferred (hidden)\\n ls -d worktrees 2>/dev/null # Alternative\\n ```\\n If found, use it. If both exist, `.worktrees` wins.\\n\\n3. **If there is no other guidance available**, default to `.worktrees/` at the project root.\\n\\n#### Safety Verification (project-local directories only)\\n\\n**MUST verify directory is ignored before creating worktree:**\\n\\n```bash\\ngit check-ignore -q .worktrees 2>/dev/null || git check-ignore -q worktrees 2>/dev/null\\n```\\n\\n**If NOT ignored:** Add to .gitignore, commit the change, then proceed.\\n\\n**Why critical:** Prevents accidentally committing worktree contents to repository.\\n\\n#### Create the Worktree\\n\\n```bash\\n# Determine path based on chosen location\\npath=\\\"$LOCATION/$BRANCH_NAME\\\"\\n\\ngit worktree add \\\"$path\\\" -b \\\"$BRANCH_NAME\\\"\\ncd \\\"$path\\\"\\n```\\n\\n**Sandbox fallback:** If `git worktree add` fails with a permission error (sandbox denial), tell the user the sandbox blocked worktree creation and you're working in the current directory instead. Then run setup and baseline tests in place.\\n\\n## Step 2: Project Setup\\n\\nAuto-detect and run appropriate setup:\\n\\n```bash\\n# Node.js\\nif [ -f package.json ]; then npm install; fi\\n\\n# Rust\\nif [ -f Cargo.toml ]; then cargo build; fi\\n\\n# Python\\nif [ -f requirements.txt ]; then pip install -r requirements.txt; fi\\nif [ -f pyproject.toml ]; then poetry install; fi\\n\\n# Go\\nif [ -f go.mod ]; then go mod download; fi\\n```\\n\\n## Step 3: Verify Clean Baseline\\n\\nRun tests to ensure workspace starts clean:\\n\\n```bash\\n# Use project-appropriate command\\nnpm test / cargo test / pytest / go test ./...\\n```\\n\\n**If tests fail:** Report failures, ask whether to proceed or investigate.\\n\\n**If tests pass:** Report ready.\\n\\n### Report\\n\\n```\\nWorktree ready at \\nTests passing ( tests, 0 failures)\\nReady to implement \\n```\\n\\n## Quick Reference\\n\\n| Situation | Action |\\n|-----------|--------|\\n| Already in linked worktree | Skip creation (Step 0) |\\n| In a submodule | Treat as normal repo (Step 0 guard) |\\n| Native worktree tool available | Use it (Step 1a) |\\n| No native tool | Git worktree fallback (Step 1b) |\\n| `.worktrees/` exists | Use it (verify ignored) |\\n| `worktrees/` exists | Use it (verify ignored) |\\n| Both exist | Use `.worktrees/` |\\n| Neither exists | Check instruction file, then default `.worktrees/` |\\n| Directory not ignored | Add to .gitignore + commit |\\n| Permission error on create | Sandbox fallback, work in place |\\n| Tests fail during baseline | Report failures + ask |\\n| No package.json/Cargo.toml | Skip dependency install |\\n\\n## Common Rationalizations\\n\\n| Excuse | Reality |\\n|--------|---------|\\n| \\\"I'm obviously not in a worktree — no need to check\\\" | Run Step 0. Harness-created isolation and submodules both fool eyeballing; the detection commands settle it. |\\n| \\\"`git worktree add` is quicker than hunting for a native tool\\\" | A native tool (e.g. `EnterWorktree`) owns placement, branching, and cleanup. Bypassing it is the #1 mistake — it creates phantom state your harness can't see or manage. |\\n| \\\"The worktree directory is surely ignored already\\\" | Run `git check-ignore`. An unignored worktree directory commits the whole tree into the repo. |\\n| \\\"Any directory name works\\\" | Explicit instructions beat an existing project-local directory, which beats the `.worktrees/` default. |\\n| \\\"The workspace is fresh — baseline tests can wait\\\" | A dirty baseline makes every later failure ambiguous. Run the tests now; proceeding past failures is your human partner's call. |\\n\\r\\n\",\"exit_code\":0,\"status\":\"completed\"}}\n{\"type\":\"item.completed\",\"item\":{\"id\":\"item_20\",\"type\":\"agent_message\",\"text\":\"사용자가 이미 상세 설계·인터페이스·수치 계약·검증 명령을 승인된 Step으로 제공했고, 새 설계/계획 파일 및 커밋을 금지했으므로 별도 승인 라운드와 추가 spec/plan 파일은 만들지 않습니다. 기존 Phase 계획을 실행 계획으로 사용하되, Harness가 마련한 현재 작업공간의 격리 상태와 baseline을 먼저 확인하겠습니다.\"}}\n{\"type\":\"item.started\",\"item\":{\"id\":\"item_21\",\"type\":\"todo_list\",\"items\":[{\"text\":\"현재 작업공간/브랜치와 필수 문서·Step 0~2 구현·CMake 테스트 구성을 점검한다\",\"completed\":false},{\"text\":\"Timoshenko 3D Beam 정식화 문서를 먼저 작성하고 식·부호·적분 계약을 자가 검토한다\",\"completed\":false},{\"text\":\"Beam3D2 수치 invariant 테스트를 먼저 추가하고 예상된 RED 실패를 확인한다\",\"completed\":false},{\"text\":\"최소 Beam3D2 stiffness kernel을 구현해 focused 테스트를 GREEN으로 만든다\",\"completed\":false},{\"text\":\"전체 빌드·CTest·Harness pytest 및 diff/아키텍처 리뷰를 수행한다\",\"completed\":false},{\"text\":\"Step 3 phase index를 completed와 한 줄 summary로 갱신하고 최종 상태를 재검증한다\",\"completed\":false}]}}\n{\"type\":\"item.started\",\"item\":{\"id\":\"item_22\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command 'rg --files include/fesa/fem include/fesa/model src/fesa/fem tests phases/fem-and-beam-kernel docs/formulation docs/superpowers/plans CMakeLists.txt tests/CMakeLists.txt'\",\"aggregated_output\":\"\",\"exit_code\":null,\"status\":\"in_progress\"}}\n{\"type\":\"item.started\",\"item\":{\"id\":\"item_23\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command '$files=@('\\\"'AGENTS.md','docs/PRD.md','docs/ARCHITECTURE.md','docs/ADR.md','docs/superpowers/plans/2026-07-29-fesa-phase-1.md','phases/fem-and-beam-kernel/index.json','phases/fem-and-beam-kernel/step3.md','include/fesa/model/material.hpp','include/fesa/model/beam_section.hpp'); foreach(\\\"'$file in $files){ $count=(Get-Content -Encoding utf8 -LiteralPath $file).Count; Write-Output \\\"$file`t$count\\\" }; if(Test-Path '\\\"'docs/formulation/timoshenko-beam-3d.md'){ Write-Output \\\\\\\"docs/formulation/timoshenko-beam-3d.md\\\"'`t$((Get-Content -Encoding utf8 -LiteralPath '\\\"'docs/formulation/timoshenko-beam-3d.md').Count)\\\\\\\" }\\\"\",\"aggregated_output\":\"\",\"exit_code\":null,\"status\":\"in_progress\"}}\n{\"type\":\"item.started\",\"item\":{\"id\":\"item_24\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command 'git status --short --branch; git branch --show-current; git rev-parse --git-dir; git rev-parse --git-common-dir; git rev-parse --show-superproject-working-tree; git rev-parse HEAD; git log -5 --oneline'\",\"aggregated_output\":\"\",\"exit_code\":null,\"status\":\"in_progress\"}}\n{\"type\":\"item.completed\",\"item\":{\"id\":\"item_22\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command 'rg --files include/fesa/fem include/fesa/model src/fesa/fem tests phases/fem-and-beam-kernel docs/formulation docs/superpowers/plans CMakeLists.txt tests/CMakeLists.txt'\",\"aggregated_output\":\"tests/CMakeLists.txt\\nCMakeLists.txt\\nphases/fem-and-beam-kernel\\\\step3.md\\nphases/fem-and-beam-kernel\\\\step2.md\\nphases/fem-and-beam-kernel\\\\step2-output.json\\nphases/fem-and-beam-kernel\\\\step1.md\\nphases/fem-and-beam-kernel\\\\step1-output.json\\nphases/fem-and-beam-kernel\\\\step0.md\\nphases/fem-and-beam-kernel\\\\step0-output.json\\nphases/fem-and-beam-kernel\\\\index.json\\nsrc/fesa/fem\\\\line2_shape.cpp\\nsrc/fesa/fem\\\\gauss_rule.cpp\\nsrc/fesa/fem\\\\dof_manager.cpp\\nsrc/fesa/fem\\\\beam_frame.cpp\\ninclude/fesa/model\\\\step_definition.hpp\\ninclude/fesa/model\\\\node.hpp\\ninclude/fesa/model\\\\material.hpp\\ninclude/fesa/model\\\\ids.hpp\\ninclude/fesa/model\\\\entity_set.hpp\\ninclude/fesa/model\\\\entity_origin.hpp\\ninclude/fesa/model\\\\domain_builder.hpp\\ninclude/fesa/model\\\\domain.hpp\\ninclude/fesa/model\\\\beam_section.hpp\\ninclude/fesa/model\\\\beam_element.hpp\\ndocs/superpowers/plans\\\\2026-07-29-fesa-phase-1.md\\ntests\\\\unit\\\\model\\\\model_types_test.cpp\\ntests\\\\unit\\\\model\\\\entity_origin_test.cpp\\ntests\\\\unit\\\\model\\\\domain_builder_test.cpp\\ninclude/fesa/fem\\\\line2_shape.hpp\\ninclude/fesa/fem\\\\gauss_rule.hpp\\ninclude/fesa/fem\\\\dof_manager.hpp\\ninclude/fesa/fem\\\\beam_frame.hpp\\ntests\\\\unit\\\\io\\\\abaqus\\\\parser_test.cpp\\ntests\\\\integration\\\\io\\\\minimal_deck_to_domain_test.cpp\\ntests\\\\unit\\\\fem\\\\line2_shape_test.cpp\\ntests\\\\unit\\\\fem\\\\gauss_rule_test.cpp\\ntests\\\\unit\\\\fem\\\\dof_manager_test.cpp\\ntests\\\\unit\\\\fem\\\\beam_frame_test.cpp\\ntests\\\\harness\\\\test_process.py\\ntests\\\\harness\\\\test_execute.py\\ntests\\\\harness\\\\test_discovery.py\\ntests\\\\harness\\\\test_config.py\\ntests\\\\unit\\\\dependencies\\\\dependency_smoke_test.cpp\\ntests\\\\unit\\\\core\\\\version_test.cpp\\ntests\\\\unit\\\\core\\\\vec3_test.cpp\\ntests\\\\unit\\\\core\\\\status_test.cpp\\ntests\\\\unit\\\\core\\\\entity_id_test.cpp\\ntests\\\\unit\\\\core\\\\diagnostic_test.cpp\\ntests\\\\CMakeLists.txt\\ntests\\\\fixtures\\\\abaqus\\\\minimal_part_instance_cantilever.inp\\ntests\\\\fixtures\\\\abaqus\\\\minimal_cantilever.inp\\nrg: docs/formulation: 지정된 파일을 찾을 수 없습니다. (os error 2)\\n\",\"exit_code\":1,\"status\":\"failed\"}}\n{\"type\":\"item.started\",\"item\":{\"id\":\"item_25\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command 'git status --short --branch; git branch --show-current; git rev-parse --git-dir; git rev-parse --git-common-dir; git rev-parse --show-superproject-working-tree; git rev-parse HEAD; git log -5 --oneline'\",\"aggregated_output\":\"\",\"exit_code\":null,\"status\":\"in_progress\"}}\n{\"type\":\"item.completed\",\"item\":{\"id\":\"item_25\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command 'git status --short --branch; git branch --show-current; git rev-parse --git-dir; git rev-parse --git-common-dir; git rev-parse --show-superproject-working-tree; git rev-parse HEAD; git log -5 --oneline'\",\"aggregated_output\":\"## feat-fem-and-beam-kernel\\n M phases/fem-and-beam-kernel/index.json\\nfeat-fem-and-beam-kernel\\n.git\\n.git\\n07f0bb3c135bf078f856fdb7ad2a74d7f631cc3f\\n07f0bb3 chore(fem-and-beam-kernel): step 2 output\\n7ddd8e6 feat(fem-and-beam-kernel): step 2 — beam-local-frame\\n63a71b7 chore(fem-and-beam-kernel): step 1 output\\ndc6b9f1 feat(fem-and-beam-kernel): step 1 — dof-manager\\n7f28047 chore(fem-and-beam-kernel): step 0 output\\n\",\"exit_code\":0,\"status\":\"completed\"}}\n{\"type\":\"item.started\",\"item\":{\"id\":\"item_26\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command '$files=@('\\\"'AGENTS.md','docs/PRD.md','docs/ARCHITECTURE.md','docs/ADR.md','docs/superpowers/plans/2026-07-29-fesa-phase-1.md','phases/fem-and-beam-kernel/index.json','phases/fem-and-beam-kernel/step3.md','include/fesa/model/material.hpp','include/fesa/model/beam_section.hpp'); foreach(\\\"'$file in $files){ $count=(Get-Content -Encoding utf8 -LiteralPath $file).Count; Write-Output \\\"$file`t$count\\\" }; if(Test-Path '\\\"'docs/formulation/timoshenko-beam-3d.md'){ Write-Output \\\\\\\"docs/formulation/timoshenko-beam-3d.md\\\"'`t$((Get-Content -Encoding utf8 -LiteralPath '\\\"'docs/formulation/timoshenko-beam-3d.md').Count)\\\\\\\" } else { Write-Output 'docs/formulation/timoshenko-beam-3d.md\\\"'`tMISSING'\\\"' }\\\"\",\"aggregated_output\":\"\",\"exit_code\":null,\"status\":\"in_progress\"}}\n{\"type\":\"item.completed\",\"item\":{\"id\":\"item_26\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command '$files=@('\\\"'AGENTS.md','docs/PRD.md','docs/ARCHITECTURE.md','docs/ADR.md','docs/superpowers/plans/2026-07-29-fesa-phase-1.md','phases/fem-and-beam-kernel/index.json','phases/fem-and-beam-kernel/step3.md','include/fesa/model/material.hpp','include/fesa/model/beam_section.hpp'); foreach(\\\"'$file in $files){ $count=(Get-Content -Encoding utf8 -LiteralPath $file).Count; Write-Output \\\"$file`t$count\\\" }; if(Test-Path '\\\"'docs/formulation/timoshenko-beam-3d.md'){ Write-Output \\\\\\\"docs/formulation/timoshenko-beam-3d.md\\\"'`t$((Get-Content -Encoding utf8 -LiteralPath '\\\"'docs/formulation/timoshenko-beam-3d.md').Count)\\\\\\\" } else { Write-Output 'docs/formulation/timoshenko-beam-3d.md\\\"'`tMISSING'\\\"' }\\\"\",\"aggregated_output\":\"AGENTS.md\\t97\\r\\ndocs/PRD.md\\t240\\r\\ndocs/ARCHITECTURE.md\\t470\\r\\ndocs/ADR.md\\t299\\r\\ndocs/superpowers/plans/2026-07-29-fesa-phase-1.md\\t1395\\r\\nphases/fem-and-beam-kernel/index.json\\t37\\r\\nphases/fem-and-beam-kernel/step3.md\\t59\\r\\ninclude/fesa/model/material.hpp\\t16\\r\\ninclude/fesa/model/beam_section.hpp\\t28\\r\\ndocs/formulation/timoshenko-beam-3d.md`tMISSING\\r\\n\",\"exit_code\":0,\"status\":\"completed\"}}\n{\"type\":\"item.completed\",\"item\":{\"id\":\"item_27\",\"type\":\"agent_message\",\"text\":\"현재는 Harness가 준비한 `feat-fem-and-beam-kernel` 브랜치의 일반 checkout이며, 기존 변경은 `phases/fem-and-beam-kernel/index.json`의 실행기 metadata뿐입니다. 이 변경을 보존하고 현재 checkout에서 작업하겠습니다. 별도 worktree를 만들면 실행기 상태와 분리되므로 이번 Harness Step에는 맞지 않습니다.\"}}\n{\"type\":\"item.started\",\"item\":{\"id\":\"item_28\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Raw -Encoding utf8 -LiteralPath 'AGENTS.md'\\\"\",\"aggregated_output\":\"\",\"exit_code\":null,\"status\":\"in_progress\"}}\n{\"type\":\"item.completed\",\"item\":{\"id\":\"item_28\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Raw -Encoding utf8 -LiteralPath 'AGENTS.md'\\\"\",\"aggregated_output\":\"# 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\",\"exit_code\":0,\"status\":\"completed\"}}\n{\"type\":\"item.started\",\"item\":{\"id\":\"item_29\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Raw -Encoding utf8 -LiteralPath 'docs/PRD.md'\\\"\",\"aggregated_output\":\"\",\"exit_code\":null,\"status\":\"in_progress\"}}\n{\"type\":\"item.completed\",\"item\":{\"id\":\"item_29\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Raw -Encoding utf8 -LiteralPath 'docs/PRD.md'\\\"\",\"aggregated_output\":\"# 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\",\"exit_code\":0,\"status\":\"completed\"}}\n{\"type\":\"item.started\",\"item\":{\"id\":\"item_30\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Encoding utf8 -LiteralPath 'docs/ARCHITECTURE.md' | Select-Object -First 240\\\"\",\"aggregated_output\":\"\",\"exit_code\":null,\"status\":\"in_progress\"}}\n{\"type\":\"item.completed\",\"item\":{\"id\":\"item_30\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Encoding utf8 -LiteralPath 'docs/ARCHITECTURE.md' | Select-Object -First 240\\\"\",\"aggregated_output\":\"# FESA Architecture\\r\\n\\r\\n## 1. 목표\\r\\n\\r\\nFESA의 아키텍처 목표는 Abaqus `.inp` 부분집합을 내부 semantic model로 변환하고,\\r\\n유한요소 equation system을 구성해 구조해석 결과를 HDF5로 저장하며, reference\\r\\ncomparison과 physics sanity가 가능한 C++20/MSVC 솔버 구조를 제공하는 것이다.\\r\\n\\r\\n핵심 품질 속성:\\r\\n\\r\\n- FEM formulation traceability\\r\\n- explicit I/O contracts\\r\\n- sparse linear algebra backend isolation\\r\\n- deterministic verification\\r\\n- incremental feature addition\\r\\n- Harness 기반 TDD와 workspace validation\\r\\n\\r\\n## 2. 디렉터리 구조\\r\\n\\r\\npublic header와 implementation은 같은 모듈 구조를 사용한다.\\r\\n\\r\\n```text\\r\\ninclude/\\r\\n fesa/\\r\\n core/\\r\\n io/\\r\\n abaqus/\\r\\n hdf5/\\r\\n model/\\r\\n fem/\\r\\n elements/\\r\\n materials/\\r\\n assembly/\\r\\n constraints/\\r\\n solvers/\\r\\n linear/\\r\\n nonlinear/\\r\\n analysis/\\r\\n results/\\r\\n validation/\\r\\nsrc/\\r\\n fesa/\\r\\n core/\\r\\n io/\\r\\n abaqus/\\r\\n hdf5/\\r\\n model/\\r\\n fem/\\r\\n elements/\\r\\n materials/\\r\\n assembly/\\r\\n constraints/\\r\\n solvers/\\r\\n linear/\\r\\n nonlinear/\\r\\n analysis/\\r\\n results/\\r\\n validation/\\r\\ntests/\\r\\n unit/\\r\\n integration/\\r\\n reference/\\r\\nreference/\\r\\n /\\r\\n model.inp\\r\\n _displacements.csv\\r\\n _reactions.csv\\r\\n _internalforces.csv\\r\\n _stresses.csv\\r\\n.agents/\\r\\n skills/\\r\\n harness/\\r\\n review/\\r\\n.codex/\\r\\n hooks.json\\r\\n.harness/\\r\\n config.example.json\\r\\n config.json\\r\\ndocs/\\r\\nscripts/\\r\\n execute.py\\r\\n hooks/\\r\\n msvc_harness/\\r\\nphases/\\r\\n```\\r\\n\\r\\n목표 구조는 장기적인 namespace와 책임 분류다. 실제 소스 디렉터리와 클래스는 해당\\r\\n기능을 구현하는 phase에서만 만든다.\\r\\n\\r\\nPhase 1에서 실체화하는 범위:\\r\\n\\r\\n- `elements/beam`: 2절점 3D Timoshenko Beam\\r\\n- `materials/elastic`: 등방성 선형 탄성\\r\\n- `constraints`: essential BC elimination\\r\\n- `solvers/linear`: MKL PARDISO\\r\\n- `analysis`: `LinearStaticAnalysis`\\r\\n- `results`: 단일 step/frame의 field와 diagnostic output\\r\\n\\r\\nTruss, plane, solid, shell, plasticity, MPC, nonlinear, dynamic, frequency 및 heat\\r\\ntransfer는 목표 taxonomy로만 유지하고 빈 구현을 미리 만들지 않는다.\\r\\n\\r\\n## 3. 모듈 경계\\r\\n\\r\\n### `core`\\r\\n\\r\\nID, status, diagnostic, source location 및 작은 값 타입을 제공한다. 외부 라이브러리에\\r\\n의존하지 않는다. 단위 변환 엔진은 두지 않고 일관 단위계 규약만 표현한다.\\r\\n\\r\\n### `io/abaqus`\\r\\n\\r\\n`.inp` lexer/parser, flat 또는 Part/Assembly/Instance scope record 및\\r\\nsyntax-to-semantic mapping을 담당한다. 해석 알고리즘과 equation numbering을 알지\\r\\n않는다. parser의 임시 syntax 객체는 `model`에 노출하지 않는다. `*HEADING`,\\r\\n`*PREPRINT`, `*RESTART`, `*OUTPUT`은 명시적인 no-op record로 처리하고 일반적인\\r\\nunknown-keyword ignore 경로를 만들지 않는다.\\r\\n\\r\\n### `io/hdf5`\\r\\n\\r\\nHDF5 결과 writer/reader, schema versioning 및 HDF5 resource 수명을 담당한다.\\r\\nHDF5 handle은 RAII wrapper 밖으로 노출하지 않는다.\\r\\n\\r\\n### `model`\\r\\n\\r\\n활성 Instance에서 정규화된 절점, 요소, 집합, 재료, 단면, step, 하중 및\\r\\n경계조건의 solver semantic model을 소유한다. Part/Assembly keyword record나 MKL\\r\\n자료구조를 저장하지 않는다.\\r\\n\\r\\n### `fem`\\r\\n\\r\\nDOF 정의, equation numbering 계약, quadrature, shape function, Jacobian 및\\r\\nlocal/global mapping을 제공한다. 특정 analysis procedure에 종속되지 않는다.\\r\\n\\r\\n### `elements`와 `materials`\\r\\n\\r\\n요소의 local contribution과 결과 회복 계약을 제공한다. Phase 1 요소는 선형 문제에\\r\\n필요한 local stiffness, equivalent load 및 section response만 계산한다.\\r\\n\\r\\n### `assembly`\\r\\n\\r\\nlocal-to-global mapping, sparse pattern 생성, contribution 정렬·병합 및 COO/CSR\\r\\n변환을 담당한다. 요소 formulation이나 PARDISO handle을 소유하지 않는다.\\r\\n\\r\\n### `constraints`\\r\\n\\r\\nessential BC와 full/reduced vector 변환 정책을 담당한다. Phase 1에는 elimination만\\r\\n구현하고 MPC, penalty 및 Lagrange multiplier는 추가하지 않는다.\\r\\n\\r\\n### `solvers`\\r\\n\\r\\n희소 선형계 backend 경계를 제공한다. Phase 1의 `solvers/linear`는 MKL PARDISO를\\r\\nadapter로 감싸며 symbolic analysis, factorization, solve 및 release 수명을 관리한다.\\r\\n\\r\\n### `analysis`\\r\\n\\r\\nstep data를 실행 가능한 `AnalysisModel`로 변환하고 DOF, assembly, constraint,\\r\\nsolver 및 result writer를 조율한다. 구체 수치 kernel이나 외부 API를 직접 구현하지\\r\\n않는다.\\r\\n\\r\\n### `results`\\r\\n\\r\\nnodal, element, integration-point, field, history 및 diagnostic output의 semantic\\r\\n표현을 담당한다. Phase 1에는 nodal/element field와 diagnostic만 실체화한다.\\r\\n\\r\\n### `validation`\\r\\n\\r\\nreference mapping, 비교 metric, tolerance와 physics sanity helper를 제공한다.\\r\\nproduction parser와 solver 내부 상태를 우회하는 별도 해석 경로를 만들지 않는다.\\r\\n\\r\\n## 4. 핵심 객체 모델\\r\\n\\r\\n```text\\r\\nParsedDeck (io/abaqus 전용)\\r\\n├── PartDefinition[]\\r\\n├── AssemblyDefinition\\r\\n│ └── InstanceDefinition[1]\\r\\n├── MaterialDefinition[]\\r\\n└── StepDefinition\\r\\n\\r\\nDomain\\r\\n├── Node\\r\\n├── Element\\r\\n├── Material\\r\\n├── Property\\r\\n├── NodeSet\\r\\n├── ElementSet\\r\\n├── BoundaryCondition\\r\\n├── Load\\r\\n└── StepDefinition\\r\\n\\r\\nAnalysisModel\\r\\n├── active elements\\r\\n├── active loads\\r\\n├── active boundary conditions\\r\\n├── active properties/materials\\r\\n└── equation system view\\r\\n\\r\\nAnalysisState\\r\\n├── displacement U\\r\\n├── external force Fext\\r\\n├── internal force Fint\\r\\n├── residual R\\r\\n├── reaction\\r\\n└── element/integration-point response\\r\\n\\r\\nDofManager\\r\\n├── node dof definitions\\r\\n├── constrained/free dof mapping\\r\\n├── equation numbering\\r\\n├── element equation adjacency view\\r\\n└── full/reduced vector reconstruction\\r\\n\\r\\nResults\\r\\n└── ResultStep\\r\\n └── ResultFrame\\r\\n ├── FieldOutput\\r\\n ├── HistoryOutput\\r\\n └── DiagnosticOutput\\r\\n```\\r\\n\\r\\n장기 목표인 `AnalysisState`의 velocity, acceleration, temperature, increment,\\r\\niteration 및 material state는 해당 해석 기능을 구현할 때 추가한다. Phase 1 객체에\\r\\n사용되지 않는 상태를 미리 할당하지 않는다.\\r\\n\\r\\n## 5. 상태 관리\\r\\n\\r\\n- `Domain`은 입력에서 만들어진 전체 모델 정의를 소유한다.\\r\\n- syntax-to-semantic mapping과 validation이 끝난 `Domain`은 가능한 한 불변으로\\r\\n 취급한다.\\r\\n- 계층형 입력의 외부 ID는 `(instance name, part-local label)`로 표현하고 내부\\r\\n dense index와 구분한다. flat 입력은 예약된 global scope를 사용한다.\\r\\n- 여러 Part를 파싱할 수 있지만 단일 Assembly의 단일 무변환 Instance가 참조하는\\r\\n Part만 `Domain`에 포함한다.\\r\\n- `AnalysisModel`은 현재 step에서 활성화되는 객체의 ID/참조 기반 view다. `Domain`을\\r\\n 복제하지 않는다.\\r\\n- `DofManager`는 DOF와 equation numbering을 전담한다. `Node`와 `Element`에\\r\\n equation ID를 저장하지 않는다.\\r\\n- `AnalysisState`는 해석 중 변하는 물리량만 소유한다.\\r\\n- 결과는 `ResultStep -> ResultFrame -> FieldOutput/HistoryOutput` 구조로 관리한다.\\r\\n\\r\\n## 6. 데이터 흐름\\r\\n\",\"exit_code\":0,\"status\":\"completed\"}}\n{\"type\":\"item.started\",\"item\":{\"id\":\"item_31\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Encoding utf8 -LiteralPath 'docs/ARCHITECTURE.md' | Select-Object -Skip 240\\\"\",\"aggregated_output\":\"\",\"exit_code\":null,\"status\":\"in_progress\"}}\n{\"type\":\"item.completed\",\"item\":{\"id\":\"item_31\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Encoding utf8 -LiteralPath 'docs/ARCHITECTURE.md' | Select-Object -Skip 240\\\"\",\"aggregated_output\":\"\\r\\n```text\\r\\nAbaqus input file\\r\\n-> lexer/parser\\r\\n-> scoped syntax records\\r\\n-> complete-deck reference resolution\\r\\n-> flat scope 또는 단일 active Part/Instance 선택\\r\\n-> set/material/section/load/BC 정규화와 validation\\r\\n-> immutable Domain\\r\\n-> StepDefinition\\r\\n-> AnalysisModel\\r\\n-> DofManager\\r\\n-> sparse pattern\\r\\n-> element contributions\\r\\n-> deterministic Assembler\\r\\n-> essential BC elimination\\r\\n-> MKL PARDISO\\r\\n-> full state/reaction reconstruction\\r\\n-> element result recovery\\r\\n-> Results\\r\\n-> HDF5 writer\\r\\n```\\r\\n\\r\\n파싱, semantic validation, equation construction, solve 및 output 단계는 서로 다른\\r\\ndiagnostic context를 유지한다.\\r\\n\\r\\n## 7. 해석 실행 흐름\\r\\n\\r\\n`Analysis::run()`은 다음 생명주기를 고정한다.\\r\\n\\r\\n```text\\r\\ninitialize\\r\\nbuildAnalysisModel\\r\\nbuildDofMap\\r\\nbuildSparsePattern\\r\\nexecuteProcedure\\r\\nfinalizeResults\\r\\n```\\r\\n\\r\\nPhase 1의 `LinearStaticAnalysis::executeProcedure()`는 다음을 수행한다.\\r\\n\\r\\n```text\\r\\nassemble\\r\\napplyBoundaryConditions\\r\\nsolve\\r\\nreconstructFullState\\r\\nrecoverReactions\\r\\nrecoverElementResults\\r\\nwriteResults\\r\\n```\\r\\n\\r\\n미래의 비선형·동적 해석은 `executeProcedure` 내부에 각각 Newton 또는 time-step\\r\\nloop를 소유한다. base class가 모든 해석 종류의 반복 변수를 미리 소유하지 않는다.\\r\\n\\r\\n## 8. Timoshenko Beam kernel\\r\\n\\r\\nPhase 1 kernel은 다음 입력만 받는다.\\r\\n\\r\\n- 두 절점 좌표\\r\\n- 12개 local/global DOF mapping\\r\\n- \\\\(E,\\\\nu\\\\)\\r\\n- \\\\(A,I_y,I_z,J,A_{sy},A_{sz}\\\\)\\r\\n- 국부 단면축 기준 방향\\r\\n- 필요한 평가 위치와 회복점\\r\\n\\r\\nkernel 책임:\\r\\n\\r\\n- 강건한 국부 직교 기저 생성\\r\\n- 자연좌표 shape function과 Jacobian 평가\\r\\n- 축·굽힘·비틀림 2점 Gauss 적분\\r\\n- 전단 1점 Gauss 적분\\r\\n- local stiffness와 global transformation\\r\\n- section strain/resultant와 \\\\(\\\\sigma_{xx}\\\\) 회복\\r\\n\\r\\nkernel은 Abaqus의 slenderness compensation을 구현하지 않는다. 명시적 전단강성이\\r\\n없으면 semantic mapper가 \\\\(A_{sy}=A_{sz}=5A/6\\\\)과 `SCF=0`을 적용한다. 명시적\\r\\n전단강성은 이 기본값을 덮어쓰며 nonzero `SCF`는 거부한다.\\r\\n\\r\\n## 9. 희소 조립과 병렬성\\r\\n\\r\\n1. `assembly`의 sparse pattern builder가 요소 connectivity와 `DofManager`의\\r\\n equation mapping으로 sparsity pattern을 생성한다.\\r\\n2. oneTBB가 요소별 local contribution을 독립적으로 계산한다.\\r\\n3. worker는 공유 CSR 값 배열에 무질서하게 누적하지 않고 thread-local contribution을\\r\\n 생성한다.\\r\\n4. contribution을 전역 row, column 및 안정된 tie-break key로 정렬한다.\\r\\n5. 고정된 순서로 합산해 대칭 CSR을 생성한다.\\r\\n6. essential BC를 소거해 reduced symmetric system을 만든다.\\r\\n7. TBB 작업이 끝난 뒤 MKL PARDISO를 호출한다.\\r\\n\\r\\n성능보다 같은 입력·설정에서의 수치 재현성을 우선한다. 병렬·직렬 결과 비교와 thread\\r\\ncount 변화 테스트를 reference suite에 포함한다.\\r\\n\\r\\n## 10. 선형해법 backend\\r\\n\\r\\n`LinearSolver` 경계는 matrix structure, numeric values, RHS를 입력받고 solution과\\r\\n진단을 반환한다. Phase 1의 유일한 구현은 `PardisoLinearSolver`다.\\r\\n\\r\\nPARDISO adapter 책임:\\r\\n\\r\\n- 0-based 대칭 CSR 계약 검증\\r\\n- analysis, factorization, solve 및 release phase 관리\\r\\n- MKL error code를 FESA diagnostic으로 변환\\r\\n- matrix checker와 residual diagnostic 제공\\r\\n- handle과 workspace의 RAII 수명 관리\\r\\n\\r\\n반력은 reduced solve 결과를 full vector로 복원한 뒤 원래 시스템의\\r\\n\\\\(r=Ku-f\\\\)에서 계산한다.\\r\\n\\r\\n## 11. HDF5 schema\\r\\n\\r\\n최상위 구조:\\r\\n\\r\\n```text\\r\\n/\\r\\n├── metadata\\r\\n├── model\\r\\n│ ├── nodes\\r\\n│ ├── elements\\r\\n│ ├── sets\\r\\n│ ├── materials\\r\\n│ ├── properties\\r\\n│ └── id_maps\\r\\n├── analysis\\r\\n│ ├── steps\\r\\n│ ├── boundary_conditions\\r\\n│ ├── loads\\r\\n│ └── solver_settings\\r\\n├── results\\r\\n│ └── steps//frames/\\r\\n│ ├── nodal\\r\\n│ ├── element\\r\\n│ └── history\\r\\n└── diagnostics\\r\\n```\\r\\n\\r\\n작은 schema 정보와 설명은 attribute로, 수치 배열과 가변 크기 데이터는 dataset으로\\r\\n저장한다. root metadata에는 schema version, FESA version, 입력 fingerprint,\\r\\n좌표계 및 단위 정책을 기록한다. 계층형 입력은 Part/Instance 이름, part-local ID와\\r\\n전단강성 값의 입력/기본값 출처를 함께 저장한다.\\r\\n\\r\\n## 12. 오류 처리\\r\\n\\r\\n진단은 최소한 다음 분류를 가진다.\\r\\n\\r\\n- I/O 및 encoding 오류\\r\\n- lexical/syntax 오류\\r\\n- 미지원 keyword/option\\r\\n- semantic reference 오류\\r\\n- model validity 오류\\r\\n- equation system 오류\\r\\n- numerical solver 오류\\r\\n- result recovery 또는 HDF5 오류\\r\\n\\r\\n각 진단은 가능한 경우 source file, line, keyword, entity ID, analysis stage 및 원인을\\r\\n포함한다.\\r\\n\\r\\n다음 조건은 묵시적으로 보정하지 않고 실패시킨다.\\r\\n\\r\\n- 길이가 0인 요소\\r\\n- 요소축과 평행하거나 길이가 0인 단면 방향 벡터\\r\\n- 존재하지 않는 절점·집합·재료·단면 참조\\r\\n- 중첩 집합 순환\\r\\n- 여러 Assembly/Instance 또는 Instance 평행이동·회전\\r\\n- Instance가 참조하지 않는 Part entity를 Assembly 집합이 참조하는 경우\\r\\n- 재료나 단면이 없거나 중복 할당된 요소\\r\\n- 상충하는 경계조건\\r\\n- 강체모드가 남은 singular equation system\\r\\n- NaN 또는 무한대 입력·결과\\r\\n\\r\\n## 13. 설계 패턴\\r\\n\\r\\n- Adapter: Abaqus, MKL, TBB 및 HDF5 경계\\r\\n- RAII: PARDISO handle, HDF5 object와 temporary workspace\\r\\n- Strategy: 실제 교체 가능성이 있는 solver와 writer 경계\\r\\n- Template Method: `Analysis::run()`의 공통 생명주기\\r\\n- Factory: Phase 1에는 B31을 생성하는 명시적 factory\\r\\n- Registry: 두 번째 실제 요소나 material type이 추가되는 phase에서만 도입\\r\\n- Runtime polymorphism: assembly가 구체 요소 내부 상태를 알지 않게 하는 최소 계약\\r\\n\\r\\n대규모 모델에서 virtual dispatch가 병목이라는 측정 결과가 있을 때만 타입별 batch\\r\\nkernel을 추가한다.\\r\\n\\r\\n## 14. 검증 구조\\r\\n\\r\\n- `tests/unit`: 값 타입, parser 단위, shape function, quadrature, transformation,\\r\\n element matrix\\r\\n- `tests/integration`: `.inp`에서 HDF5까지 전체 경로\\r\\n- `tests/reference`: CSV 골든 결과와 FESA HDF5 결과 비교\\r\\n- `reference/`: Abaqus 입력과 현재 사용할 수 있는 결과 CSV\\r\\n\\r\\nreference comparison request가 비교할 물리량과 CSV 경로, 상대 tolerance 및\\r\\n물리량별 절대 scale을 명시한다. 요청한 CSV가 없으면 실패하며 요청하지 않은 결과를\\r\\n통과로 표시하지 않는다. 현재 캔틸레버는 변위와 반력만 요청하고, 요소 내력과\\r\\n단면 도심 응력 adapter는 synthetic CSV로 검증한다.\\r\\n\\r\\n요소 내력 CSV의 `(Instance, Element Label, Node Label)` 위치에서\\r\\n`SF1,SF2,SF3,SM1,SM2,SM3`을 \\\\(N,V_y,V_z,T,M_y,M_z\\\\)로 매핑한다. 응력 CSV의\\r\\n같은 위치에 있는 `Sxx`는 단면 도심값 \\\\(N/A\\\\)와 비교한다. 단일 Instance에서는\\r\\nInstance 열 생략을 허용하되 comparison request가 제공한 Instance 이름으로\\r\\n보완한다.\\r\\n\\r\\nreference helper는 반드시 public parser와 analysis 경로로 FESA 결과를 생성한다.\\r\\n테스트 전용 경로로 Domain이나 matrix를 직접 주입해 전체 파이프라인 결함을 숨기지\\r\\n않는다.\\r\\n\\r\\n## 15. Harness 실행 계층\\r\\n\\r\\n현재 저장소의 `scripts/execute.py`, `docs/HARNESS.md` 및\\r\\n`.agents/skills/harness/SKILL.md`를 실행 계약으로 사용한다.\\r\\n\\r\\nExecutor 동작:\\r\\n\\r\\n- `feat-{phase-name}` 브랜치 생성 또는 checkout\\r\\n- `AGENTS.md`와 `docs/*.md` guardrail 주입\\r\\n- 완료된 step의 `summary`를 다음 prompt에 전달\\r\\n- 실패 시 이전 오류를 포함해 최대 3회 재시도\\r\\n- 코드 변경과 phase metadata를 분리해 commit\\r\\n- step/phase timestamp 기록\\r\\n- `--push` 사용 시에만 원격 push\\r\\n\\r\\nCodex hook 동작:\\r\\n\\r\\n- PreToolUse hook은 위험한 명령 패턴을 검사한다.\\r\\n- Stop hook은 감지된 C/C++ 프로젝트를 MSVC로 빌드하고 테스트한다.\\r\\n- `.harness/config.json`이 있으면 해당 설정과 preset을 우선한다.\\r\\n\\r\\n현재 executor에 없는 `allowed_paths`, `validate_workspace.py`,\\r\\n`codex/` 브랜치 및 명시적 clean-worktree 정책은 FESA 아키텍처의\\r\\n요구사항으로 간주하지 않는다.\\r\\n\",\"exit_code\":0,\"status\":\"completed\"}}\n{\"type\":\"item.started\",\"item\":{\"id\":\"item_32\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Encoding utf8 -LiteralPath 'docs/ADR.md' | Select-Object -First 160\\\"\",\"aggregated_output\":\"\",\"exit_code\":null,\"status\":\"in_progress\"}}\n{\"type\":\"item.completed\",\"item\":{\"id\":\"item_32\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Encoding utf8 -LiteralPath 'docs/ADR.md' | Select-Object -First 160\\\"\",\"aggregated_output\":\"# 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\",\"exit_code\":0,\"status\":\"completed\"}}\n{\"type\":\"item.started\",\"item\":{\"id\":\"item_33\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Encoding utf8 -LiteralPath 'docs/ADR.md' | Select-Object -Skip 160\\\"\",\"aggregated_output\":\"\",\"exit_code\":null,\"status\":\"in_progress\"}}\n{\"type\":\"item.completed\",\"item\":{\"id\":\"item_33\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Encoding utf8 -LiteralPath 'docs/ADR.md' | Select-Object -Skip 160\\\"\",\"aggregated_output\":\"- 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\",\"exit_code\":0,\"status\":\"completed\"}}\n{\"type\":\"item.started\",\"item\":{\"id\":\"item_34\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Encoding utf8 -LiteralPath 'docs/superpowers/plans/2026-07-29-fesa-phase-1.md' | Select-Object -First 200\\\"\",\"aggregated_output\":\"\",\"exit_code\":null,\"status\":\"in_progress\"}}\n{\"type\":\"item.completed\",\"item\":{\"id\":\"item_34\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Encoding utf8 -LiteralPath 'docs/superpowers/plans/2026-07-29-fesa-phase-1.md' | Select-Object -First 200\\\"\",\"aggregated_output\":\"# FESA Phase 1 Implementation Plan\\r\\n\\r\\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.\\r\\n\\r\\n**Goal:** Build and internally qualify a C++20/MSVC linear-static finite-element solver that reads the agreed Abaqus `.inp` subset, solves 2-node 3D Timoshenko Beam models, and writes self-contained HDF5 results.\\r\\n\\r\\n**Architecture:** Implement one end-to-end vertical slice first, then complete the input, numerical, parallel, result, and reference-verification contracts behind the module boundaries in `docs/ARCHITECTURE.md`. Keep the semantic model independent of Abaqus syntax and isolate oneMKL, oneTBB, and HDF5 behind adapters.\\r\\n\\r\\n**Tech Stack:** C++20, Visual Studio 2026 MSVC v145 x64, CMake/CMake Presets/CTest, GoogleTest/GoogleMock, Intel oneAPI MKL PARDISO, Intel oneAPI TBB, HDF5 C API, Python 3 Harness.\\r\\n\\r\\n## Global Constraints\\r\\n\\r\\n- Only the Phase 1 scope in `docs/PRD.md` may be implemented.\\r\\n- Public headers live under `include/fesa/`; implementations live under `src/fesa/`; tests live under `tests/`.\\r\\n- Write a failing test before every production behavior change.\\r\\n- Do not add a fake stiffness matrix or a test-only solver path.\\r\\n- Do not introduce empty future modules, a generic registry, MPC, iterative solvers, nonlinear state, or additional element types.\\r\\n- FESA performs no unit conversion.\\r\\n- Abaqus inputs may use a flat mesh or one untransformed Part/Assembly/Instance.\\r\\n- When transverse shear stiffness is omitted, use \\\\(A_{sy}=A_{sz}=5A/6\\\\) and `SCF=0`.\\r\\n- Reference comparison requests name their quantities and CSV paths; no per-model metadata file is required.\\r\\n- A pipeline milestone is not a numerically qualified release.\\r\\n- No new MSVC warnings are allowed.\\r\\n- The existing Harness contract in `docs/HARNESS.md` and `.agents/skills/harness/SKILL.md` remains unchanged.\\r\\n\\r\\n## Environment Audit\\r\\n\\r\\nThe planning environment currently has:\\r\\n\\r\\n- CMake 4.4.0\\r\\n- Visual Studio Community 2026 at `C:/Program Files/Microsoft Visual Studio/18/Community`\\r\\n- MSVC v145 tools at `C:/Program Files/Microsoft Visual Studio/18/Community/VC/Tools/MSVC/14.51.36231`\\r\\n- CMake generator `Visual Studio 18 2026`\\r\\n- oneMKL CMake package at `C:/Program Files (x86)/Intel/oneAPI/2026.1/lib/cmake/mkl`\\r\\n- oneTBB CMake package at `C:/Program Files (x86)/Intel/oneAPI/2026.1/lib/cmake/tbb`\\r\\n- HDF5 2.1.1 CMake package at `C:/Program Files/HDF_Group/HDF5/2.1.1/cmake`\\r\\n- GoogleTest/GoogleMock v1.17 VS2026/v145 x64 package at\\r\\n `C:/Users/baram/AppData/Local/FESA/dependencies/googletest-1.17.0-v145-x64-crt`\\r\\n- `MSBuild.exe` at `C:/Program Files/Microsoft Visual Studio/18/Community/MSBuild/Current/Bin/MSBuild.exe`\\r\\n\\r\\nThe solver bootstrap must stop as `blocked` rather than downloading packages if a dependency\\r\\nrequired by its current step is unavailable.\\r\\n\\r\\n## Required Research Record\\r\\n\\r\\nBefore the related production task begins, record the relevant equations,\\r\\nassumptions, API contracts, and FESA decisions from these sources:\\r\\n\\r\\n- K. J. Bathe, *Finite Element Procedures*, 2nd edition: finite-element\\r\\n discretization, assembly, constraints, and verification.\\r\\n- T. J. R. Hughes, *The Finite Element Method: Linear Static and Dynamic\\r\\n Finite Element Analysis*: variational formulation and numerical integration.\\r\\n- K. J. Bathe and S. Bolourchi, “Large Displacement Analysis of\\r\\n Three-Dimensional Beam Structures,” 1979: three-dimensional isoparametric\\r\\n Beam coordinates and transformations. Phase 1 uses only the linearized\\r\\n subset.\\r\\n- T. J. R. Hughes, R. L. Taylor, and W. Kanoknukulchai, “A Simple and\\r\\n Efficient Finite Element for Plate Bending,” 1977: selective reduced\\r\\n integration rationale. Do not copy its plate kinematics into the Beam\\r\\n formulation.\\r\\n- [Abaqus 2024—Choosing a Beam Element](https://docs.software.vt.edu/abaqusv2024/English/SIMACAEELMRefMap/simaelm-c-beamelem.htm):\\r\\n B31 shear-flexible behavior and slenderness compensation.\\r\\n- [Abaqus 2024—BEAM GENERAL SECTION](https://docs.software.vt.edu/abaqusv2024/English/SIMACAEKEYRefMap/simakey-r-beamgeneralsection.htm):\\r\\n supported general-section data and orientation.\\r\\n- [Intel oneMKL PARDISO reference](https://www.intel.com/content/www/us/en/docs/onemkl/developer-reference-c/2025-0/pardiso.html):\\r\\n matrix type, CSR indexing, phases, checks, and error codes.\\r\\n- [oneTBB reduction guide](https://uxlfoundation.github.io/oneTBB/main/tbb_userguide/design_patterns/Reduction.html):\\r\\n deterministic floating-point reduction.\\r\\n- [HDF5 data model](https://support.hdfgroup.org/documentation/hdf5/latest/_intro_h_d_f5.html):\\r\\n groups, datasets, dataspaces, and attributes.\\r\\n- [CMake FindHDF5](https://cmake.org/cmake/help/latest/module/FindHDF5.html):\\r\\n installed C-library discovery and imported targets.\\r\\n\\r\\n`docs/formulation/timoshenko-beam-3d.md`, `docs/HDF5_SCHEMA.md`, and\\r\\n`docs/VALIDATION.md` must cite the applicable source and state where FESA\\r\\nintentionally differs.\\r\\n\\r\\n## Harness Phase Map\\r\\n\\r\\n| Order | Harness phase | Plan tasks | Independent deliverable |\\r\\n| ---: | --- | --- | --- |\\r\\n| 0 | `solver-bootstrap` | Harness baseline, 1-2 | Harness self-tests, reproducible C++20 build, dependency smoke tests, core IDs and diagnostics |\\r\\n| 1 | `domain-and-input-skeleton` | 3-4 | Flat or single-Instance B31 input becomes an immutable normalized `Domain` |\\r\\n| 2 | `fem-and-beam-kernel` | 5-6 | Real Timoshenko Beam local stiffness with analytical sanity tests |\\r\\n| 3 | `equation-and-linear-solve` | 7-8 | Deterministic serial CSR system solved by PARDISO |\\r\\n| 4 | `results-and-pipeline` | 9-10 | CLI runs one deck end-to-end and writes readable HDF5 |\\r\\n| 5 | `abaqus-subset-completion` | 11 | Full agreed scoped keyword, set, material, section, load, and BC subset |\\r\\n| 6 | `deterministic-parallel-assembly` | 12 | oneTBB assembly matches serial output across thread counts |\\r\\n| 7 | `result-contract-completion` | 13 | Complete self-contained HDF5 schema and Beam result recovery |\\r\\n| 8 | `beam-reference-qualification` | 14 | Analytical suite and available Abaqus displacement/reaction data pass tolerance |\\r\\n| 9 | `internal-release` | 15 | Debug/Release validation, 100k-DOF benchmark, install tree, reports |\\r\\n\\r\\nCreate `phases/index.json`, phase indexes, and step files only after this plan and its phase split are approved.\\r\\n\\r\\n## Planned File Map\\r\\n\\r\\n```text\\r\\nCMakeLists.txt root targets and project policies\\r\\nCMakePresets.json windows-debug/windows-release workflows\\r\\ncmake/FesaDependencies.cmake installed dependency discovery\\r\\n.harness/config.json Harness CMake preset selection\\r\\ninclude/fesa/core/ IDs, vectors, source locations, diagnostics\\r\\ninclude/fesa/model/ immutable semantic entities and Domain\\r\\ninclude/fesa/io/abaqus/ deck records, parser, semantic mapper\\r\\ninclude/fesa/fem/ quadrature, shape functions, frames, DOFs\\r\\ninclude/fesa/elements/beam/ Beam3D2 input, contribution, recovery contract\\r\\ninclude/fesa/assembly/ symmetric COO/CSR and assembly\\r\\ninclude/fesa/constraints/ essential-BC elimination and reconstruction\\r\\ninclude/fesa/solvers/linear/ backend contract and PARDISO adapter\\r\\ninclude/fesa/results/ step/frame/field/diagnostic result model\\r\\ninclude/fesa/io/hdf5/ schema constants, writer, reader\\r\\ninclude/fesa/analysis/ analysis lifecycle and linear-static procedure\\r\\ninclude/fesa/validation/ comparison metrics and CSV mapping\\r\\nsrc/fesa/ implementations mirroring public modules\\r\\nsrc/fesa/cli/main.cpp thin `fesa` command-line executable\\r\\ntests/unit/ single-module behavior\\r\\ntests/integration/ public input-to-output path\\r\\ntests/reference/ FESA HDF5 to golden CSV comparisons\\r\\ntests/fixtures/ small invalid and valid decks\\r\\nreference/cantilever beam/ supplied Abaqus input and available golden CSV data\\r\\ndocs/formulation/ signed-off equations and conventions\\r\\ndocs/HDF5_SCHEMA.md versioned output contract\\r\\ndocs/VALIDATION.md benchmark matrix and qualification result\\r\\n```\\r\\n\\r\\n---\\r\\n\\r\\n### Task 1: CMake, Installed Dependencies, and Test Bootstrap\\r\\n\\r\\n**Files:**\\r\\n\\r\\n- Create before CMake bootstrap: `tests/harness/test_config.py`\\r\\n- Create before CMake bootstrap: `tests/harness/test_discovery.py`\\r\\n- Create before CMake bootstrap: `tests/harness/test_process.py`\\r\\n- Create: `CMakeLists.txt`\\r\\n- Create: `CMakePresets.json`\\r\\n- Create: `cmake/FesaDependencies.cmake`\\r\\n- Create: `.harness/config.json`\\r\\n- Create: `include/fesa/core/version.hpp`\\r\\n- Create: `src/fesa/core/version.cpp`\\r\\n- Create: `src/fesa/cli/main.cpp`\\r\\n- Create: `tests/CMakeLists.txt`\\r\\n- Create: `tests/unit/core/version_test.cpp`\\r\\n- Modify: `.gitignore`\\r\\n\\r\\n**Interfaces:**\\r\\n\\r\\n- Produces: `std::string_view fesa::version() noexcept`\\r\\n- Produces CMake targets: `fesa_core`, `fesa_cli`, `fesa_unit_tests`\\r\\n- Produces presets: `windows-debug`, `windows-release`\\r\\n- Later tasks consume the common warning and include-directory policies.\\r\\n\\r\\nBefore the CMake task, add characterization tests for the existing Harness\\r\\nconfiguration, project discovery, and validation-result contracts. This\\r\\nprecondition makes the repository-level pytest command collect at least one\\r\\ntest without changing production Harness behavior.\\r\\n\\r\\n- [ ] **Step 1: Verify required installed packages without changing the machine**\\r\\n\\r\\nRun:\\r\\n\\r\\n```powershell\\r\\ncmake --version\\r\\n& \\\"${env:ProgramFiles(x86)}\\\\Microsoft Visual Studio\\\\Installer\\\\vswhere.exe\\\" `\\r\\n -latest -products * -requires Microsoft.VisualStudio.Component.VC.Tools.x86.x64 `\\r\\n -property installationPath\\r\\nTest-Path \\\"C:\\\\Program Files\\\\Microsoft Visual Studio\\\\18\\\\Community\\\\MSBuild\\\\Current\\\\Bin\\\\MSBuild.exe\\\"\\r\\nGet-ChildItem \\\"C:\\\\Program Files\\\\Microsoft Visual Studio\\\\18\\\\Community\\\\VC\\\\Tools\\\\MSVC\\\" -Directory\\r\\nGet-ChildItem \\\"C:\\\\Program Files (x86)\\\\Intel\\\\oneAPI\\\" -Recurse -Filter MKLConfig.cmake\\r\\nGet-ChildItem \\\"C:\\\\Program Files (x86)\\\\Intel\\\\oneAPI\\\" -Recurse -Filter TBBConfig.cmake\\r\\nGet-ChildItem \\\"C:\\\\Program Files\\\" -Recurse -Filter hdf5-config.cmake\\r\\nGet-ChildItem \\\"C:\\\\Program Files\\\" -Recurse -Filter GTestConfig.cmake\\r\\n```\\r\\n\\r\\nExpected: Visual Studio 2026/MSVC v145, oneMKL, oneTBB, HDF5, and GoogleTest\\r\\nare all discoverable before the step that consumes each dependency. If a required item is\\r\\nmissing, mark that Harness step `blocked` and name it; do not download it.\\r\\n\\r\\n- [ ] **Step 2: Write the failing version test**\\r\\n\\r\\n```cpp\\r\\n#include \\r\\n#include \\r\\n\\r\\nTEST(Version, ReportsPhaseOneSemanticVersion) {\\r\\n EXPECT_EQ(fesa::version(), \\\"0.1.0\\\");\\r\\n}\\r\\n```\\r\\n\\r\\n- [ ] **Step 3: Add configure files and verify the test fails before implementation**\\r\\n\\r\\n`cmake/FesaDependencies.cmake` must set the oneMKL choices before package discovery:\\r\\n\\r\\n```cmake\\r\\ncmake_minimum_required(VERSION 3.30)\\r\\n\\r\\nset(MKL_LINK dynamic)\\r\\nset(MKL_THREADING tbb_thread)\\r\\nset(MKL_INTERFACE lp64)\\r\\nfind_package(MKL CONFIG REQUIRED)\\r\\n\",\"exit_code\":0,\"status\":\"completed\"}}\n{\"type\":\"item.started\",\"item\":{\"id\":\"item_35\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Encoding utf8 -LiteralPath 'docs/superpowers/plans/2026-07-29-fesa-phase-1.md' | Select-Object -Skip 200 -First 200\\\"\",\"aggregated_output\":\"\",\"exit_code\":null,\"status\":\"in_progress\"}}\n{\"type\":\"item.completed\",\"item\":{\"id\":\"item_35\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Encoding utf8 -LiteralPath 'docs/superpowers/plans/2026-07-29-fesa-phase-1.md' | Select-Object -Skip 200 -First 200\\\"\",\"aggregated_output\":\"find_package(TBB CONFIG REQUIRED COMPONENTS tbb)\\r\\nfind_package(HDF5 REQUIRED COMPONENTS C)\\r\\nfind_package(GTest CONFIG REQUIRED)\\r\\n```\\r\\n\\r\\nLink `MKL::MKL`, `TBB::tbb`, `HDF5::HDF5`, and `GTest::gtest_main` only to targets that use them. Configure and build:\\r\\nCompile FESA targets with `/W4 /permissive- /EHsc`; do not apply FESA warning\\r\\nflags to imported targets.\\r\\n\\r\\n```powershell\\r\\ncmake --preset windows-debug\\r\\ncmake --build --preset windows-debug\\r\\n```\\r\\n\\r\\nExpected: build fails because `fesa::version()` has no definition.\\r\\n\\r\\n- [ ] **Step 4: Implement the minimum version API and thin CLI**\\r\\n\\r\\n```cpp\\r\\nnamespace fesa {\\r\\nstd::string_view version() noexcept;\\r\\n}\\r\\n```\\r\\n\\r\\nThe CLI accepts only `--version` in this task. Any other command prints usage and returns a nonzero exit code.\\r\\n\\r\\n- [ ] **Step 5: Run focused and full bootstrap validation**\\r\\n\\r\\n```powershell\\r\\ncmake --build --preset windows-debug\\r\\nctest --preset windows-debug --output-on-failure\\r\\n.\\\\out\\\\build\\\\windows-debug\\\\Debug\\\\fesa.exe --version\\r\\n```\\r\\n\\r\\nExpected: one test passes and the CLI prints `0.1.0`.\\r\\n\\r\\n- [ ] **Step 6: Commit**\\r\\n\\r\\n```powershell\\r\\ngit add CMakeLists.txt CMakePresets.json cmake .harness/config.json include/fesa/core/version.hpp src/fesa/core/version.cpp src/fesa/cli/main.cpp tests/CMakeLists.txt tests/unit/core/version_test.cpp .gitignore\\r\\ngit commit -m \\\"build: bootstrap FESA CMake project\\\"\\r\\n```\\r\\n\\r\\n---\\r\\n\\r\\n### Task 2: Core IDs, Vectors, Source Locations, and Diagnostics\\r\\n\\r\\n**Files:**\\r\\n\\r\\n- Create: `include/fesa/core/entity_id.hpp`\\r\\n- Create: `include/fesa/core/vec3.hpp`\\r\\n- Create: `include/fesa/core/source_location.hpp`\\r\\n- Create: `include/fesa/core/diagnostic.hpp`\\r\\n- Create: `include/fesa/core/status.hpp`\\r\\n- Create: `tests/unit/core/entity_id_test.cpp`\\r\\n- Create: `tests/unit/core/vec3_test.cpp`\\r\\n- Create: `tests/unit/core/diagnostic_test.cpp`\\r\\n- Create: `tests/unit/core/status_test.cpp`\\r\\n- Modify: `CMakeLists.txt`\\r\\n- Modify: `tests/CMakeLists.txt`\\r\\n\\r\\n**Interfaces:**\\r\\n\\r\\n```cpp\\r\\ntemplate\\r\\nclass EntityId final {\\r\\npublic:\\r\\n explicit constexpr EntityId(std::int64_t value);\\r\\n [[nodiscard]] constexpr std::int64_t value() const noexcept;\\r\\n auto operator<=>(const EntityId&) const = default;\\r\\n};\\r\\n\\r\\nstruct Vec3 final {\\r\\n double x;\\r\\n double y;\\r\\n double z;\\r\\n};\\r\\n\\r\\n[[nodiscard]] bool is_finite(Vec3 value) noexcept;\\r\\n\\r\\nstruct SourceLocation final {\\r\\n std::filesystem::path file;\\r\\n std::size_t line;\\r\\n std::size_t column;\\r\\n};\\r\\n\\r\\nenum class DiagnosticStage {\\r\\n io, syntax, semantic, model, equation, solver, results, validation\\r\\n};\\r\\n\\r\\nenum class Severity { warning, error };\\r\\n\\r\\nstruct Diagnostic final {\\r\\n DiagnosticStage stage;\\r\\n Severity severity;\\r\\n std::string code;\\r\\n std::string message;\\r\\n std::optional source;\\r\\n};\\r\\n\\r\\nstruct Status final {\\r\\n bool succeeded;\\r\\n std::vector diagnostics;\\r\\n};\\r\\n```\\r\\n\\r\\n- [ ] **Step 1: Write failing tests**\\r\\n\\r\\nCover negative entity-ID rejection, typed-ID non-interchangeability at compile time, finite `Vec3` validation, full diagnostic context preservation, and success/failure status preservation.\\r\\n\\r\\n- [ ] **Step 2: Run focused tests and confirm compile or assertion failure**\\r\\n\\r\\n```powershell\\r\\ncmake --build --preset windows-debug\\r\\nctest --preset windows-debug -R \\\"Core\\\" --output-on-failure\\r\\n```\\r\\n\\r\\nExpected: failure because the core types do not exist.\\r\\n\\r\\n- [ ] **Step 3: Implement only the declared core types**\\r\\n\\r\\nUse `double` for all Phase 1 real values and `std::int64_t` for external Abaqus IDs. Do not introduce a unit library, generic error monad, matrix class, or logging framework.\\r\\n\\r\\n- [ ] **Step 4: Run all tests**\\r\\n\\r\\n```powershell\\r\\ncmake --build --preset windows-debug\\r\\nctest --preset windows-debug --output-on-failure\\r\\n```\\r\\n\\r\\nExpected: all tests pass with no new MSVC warnings.\\r\\n\\r\\n- [ ] **Step 5: Commit**\\r\\n\\r\\n```powershell\\r\\ngit add include/fesa/core tests/unit/core CMakeLists.txt tests/CMakeLists.txt\\r\\ngit commit -m \\\"feat(core): add typed IDs and diagnostics\\\"\\r\\n```\\r\\n\\r\\n---\\r\\n\\r\\n### Task 3: Immutable Semantic Domain\\r\\n\\r\\n**Files:**\\r\\n\\r\\n- Create: `include/fesa/model/ids.hpp`\\r\\n- Create: `include/fesa/model/entity_origin.hpp`\\r\\n- Create: `include/fesa/model/node.hpp`\\r\\n- Create: `include/fesa/model/material.hpp`\\r\\n- Create: `include/fesa/model/beam_section.hpp`\\r\\n- Create: `include/fesa/model/beam_element.hpp`\\r\\n- Create: `include/fesa/model/entity_set.hpp`\\r\\n- Create: `include/fesa/model/step_definition.hpp`\\r\\n- Create: `include/fesa/model/domain.hpp`\\r\\n- Create: `include/fesa/model/domain_builder.hpp`\\r\\n- Create: `src/fesa/model/domain.cpp`\\r\\n- Create: `src/fesa/model/domain_builder.cpp`\\r\\n- Create: `tests/unit/model/domain_builder_test.cpp`\\r\\n- Modify: root and test CMake files\\r\\n\\r\\n**Interfaces:**\\r\\n\\r\\n```cpp\\r\\nusing NodeId = EntityId;\\r\\nusing ElementId = EntityId;\\r\\nusing MaterialId = EntityId;\\r\\nusing SectionId = EntityId;\\r\\n\\r\\nstruct EntityOrigin final {\\r\\n std::string part_name;\\r\\n std::string instance_name;\\r\\n std::int64_t local_label;\\r\\n};\\r\\nstruct Node final { NodeId id; EntityOrigin origin; Vec3 position; };\\r\\nstruct IsotropicElastic final { MaterialId id; std::string name; double young; double poisson; };\\r\\nstruct BeamSection final {\\r\\n SectionId id;\\r\\n std::string name;\\r\\n double area;\\r\\n double iy;\\r\\n double iz;\\r\\n double torsion_j;\\r\\n double shear_area_y;\\r\\n double shear_area_z;\\r\\n Vec3 orientation;\\r\\n std::vector> recovery_points;\\r\\n};\\r\\nstruct BeamElement final {\\r\\n ElementId id;\\r\\n EntityOrigin origin;\\r\\n std::array nodes;\\r\\n MaterialId material;\\r\\n SectionId section;\\r\\n};\\r\\nstruct NodeSet final { std::string name; std::vector members; };\\r\\nstruct ElementSet final { std::string name; std::vector members; };\\r\\nstruct PrescribedDof final { NodeId node; std::uint8_t dof; double value; };\\r\\nstruct NodalLoad final { NodeId node; std::array values; };\\r\\nstruct StepDefinition final {\\r\\n std::string name;\\r\\n\",\"exit_code\":0,\"status\":\"completed\"}}\n{\"type\":\"item.started\",\"item\":{\"id\":\"item_36\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Encoding utf8 -LiteralPath 'docs/superpowers/plans/2026-07-29-fesa-phase-1.md' | Select-Object -Skip 400 -First 200\\\"\",\"aggregated_output\":\"\",\"exit_code\":null,\"status\":\"in_progress\"}}\n{\"type\":\"item.completed\",\"item\":{\"id\":\"item_36\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Encoding utf8 -LiteralPath 'docs/superpowers/plans/2026-07-29-fesa-phase-1.md' | Select-Object -Skip 400 -First 200\\\"\",\"aggregated_output\":\" std::vector prescribed_dofs;\\r\\n std::vector nodal_loads;\\r\\n};\\r\\n\\r\\nclass Domain final {\\r\\npublic:\\r\\n [[nodiscard]] std::span nodes() const noexcept;\\r\\n [[nodiscard]] std::span beam_elements() const noexcept;\\r\\n [[nodiscard]] const Node& node(NodeId id) const;\\r\\n [[nodiscard]] const Node& node(const EntityOrigin& origin) const;\\r\\n};\\r\\n\\r\\nstruct DomainBuildResult final {\\r\\n std::optional domain;\\r\\n std::vector diagnostics;\\r\\n};\\r\\n\\r\\nclass DomainBuilder final {\\r\\npublic:\\r\\n void add_node(Node value);\\r\\n void add_material(IsotropicElastic value);\\r\\n void add_section(BeamSection value);\\r\\n void add_beam_element(BeamElement value);\\r\\n void add_node_set(NodeSet value);\\r\\n void add_element_set(ElementSet value);\\r\\n void set_step(StepDefinition value);\\r\\n [[nodiscard]] DomainBuildResult build() &&;\\r\\n};\\r\\n```\\r\\n\\r\\n`DomainBuilder::build()` returns either one immutable `Domain` or a nonempty\\r\\ndiagnostic list. It must resolve every reference and reject duplicate internal\\r\\nIDs, duplicate `(instance_name, local_label)` origins, nonfinite values, invalid\\r\\nmaterial constants, invalid section properties, zero-length elements, missing\\r\\nassignments, and invalid orientation vectors. Empty Part/Instance names denote\\r\\nthe flat global scope.\\r\\n\\r\\n- [ ] **Step 1: Write failing builder tests**\\r\\n\\r\\nWrite one valid two-node domain test and one test for every rejection listed above.\\r\\n\\r\\n- [ ] **Step 2: Run the model tests and confirm failure**\\r\\n\\r\\n```powershell\\r\\ncmake --build --preset windows-debug\\r\\nctest --preset windows-debug -R \\\"Domain\\\" --output-on-failure\\r\\n```\\r\\n\\r\\n- [ ] **Step 3: Implement the minimum immutable storage and validation**\\r\\n\\r\\nPreserve external IDs and create private dense lookup maps. Do not store equation numbers in `Node` or `BeamElement`.\\r\\n\\r\\n- [ ] **Step 4: Run all tests and commit**\\r\\n\\r\\n```powershell\\r\\ncmake --build --preset windows-debug\\r\\nctest --preset windows-debug --output-on-failure\\r\\ngit add include/fesa/model src/fesa/model tests/unit/model CMakeLists.txt tests/CMakeLists.txt\\r\\ngit commit -m \\\"feat(model): add immutable beam domain\\\"\\r\\n```\\r\\n\\r\\n---\\r\\n\\r\\n### Task 4: Minimal Scoped Abaqus Deck to Domain\\r\\n\\r\\n**Files:**\\r\\n\\r\\n- Create: `include/fesa/io/abaqus/deck_record.hpp`\\r\\n- Create: `include/fesa/io/abaqus/parser.hpp`\\r\\n- Create: `include/fesa/io/abaqus/semantic_mapper.hpp`\\r\\n- Create: `src/fesa/io/abaqus/parser.cpp`\\r\\n- Create: `src/fesa/io/abaqus/semantic_mapper.cpp`\\r\\n- Create: `tests/fixtures/abaqus/minimal_cantilever.inp`\\r\\n- Create: `tests/fixtures/abaqus/minimal_part_instance_cantilever.inp`\\r\\n- Create: `tests/fixtures/abaqus/unsupported_keyword.inp`\\r\\n- Create: `tests/unit/io/abaqus/parser_test.cpp`\\r\\n- Create: `tests/integration/io/minimal_deck_to_domain_test.cpp`\\r\\n- Modify: CMake files\\r\\n\\r\\n**Interfaces:**\\r\\n\\r\\n```cpp\\r\\nstruct DeckRecord final {\\r\\n std::string keyword;\\r\\n std::map> parameters;\\r\\n std::vector> data;\\r\\n SourceLocation source;\\r\\n};\\r\\n\\r\\nstruct ParsedPart final {\\r\\n std::string name;\\r\\n std::vector records;\\r\\n SourceLocation source;\\r\\n};\\r\\n\\r\\nstruct ParsedInstance final {\\r\\n std::string name;\\r\\n std::string part_name;\\r\\n std::vector> transform_data;\\r\\n SourceLocation source;\\r\\n};\\r\\n\\r\\nstruct ParsedAssembly final {\\r\\n std::string name;\\r\\n std::vector instances;\\r\\n std::vector records;\\r\\n SourceLocation source;\\r\\n};\\r\\n\\r\\nstruct ParsedDeck final {\\r\\n std::vector global_records;\\r\\n std::vector parts;\\r\\n std::optional assembly;\\r\\n};\\r\\n\\r\\nstruct ParseDeckResult final {\\r\\n std::optional deck;\\r\\n std::vector diagnostics;\\r\\n};\\r\\n\\r\\n[[nodiscard]] ParseDeckResult parse_deck(const std::filesystem::path& path);\\r\\n[[nodiscard]] DomainBuildResult map_deck_to_domain(const ParsedDeck& deck);\\r\\n```\\r\\n\\r\\nEach minimal fixture contains two nodes, one B31 element, one material, one\\r\\ngeneral section, one node set, one element set, one boundary definition, one\\r\\nconcentrated load, and one static step. One fixture is flat; the other contains\\r\\none Part, one Assembly, and one untransformed Instance.\\r\\n\\r\\n- [ ] **Step 1: Write failing parser and integration tests**\\r\\n\\r\\nTests must call `parse_deck()` and `map_deck_to_domain()`; they may not\\r\\nconstruct the `Domain` directly. Assert that both organizations produce\\r\\nequivalent active analysis entities and that the hierarchical Domain retains\\r\\nPart/Instance provenance.\\r\\n\\r\\n- [ ] **Step 2: Confirm failure**\\r\\n\\r\\n```powershell\\r\\ncmake --build --preset windows-debug\\r\\nctest --preset windows-debug -R \\\"Abaqus|Deck\\\" --output-on-failure\\r\\n```\\r\\n\\r\\n- [ ] **Step 3: Implement the smallest case-insensitive keyword parser**\\r\\n\\r\\nSupport comments, blank lines, comma-separated parameters and data, UTF-8\\r\\ninput, exact source lines, `*PART/*END PART`, `*ASSEMBLY/*END ASSEMBLY`, and\\r\\n`*INSTANCE/*END INSTANCE`. In this task, accept only the keywords used by the\\r\\ntwo minimal fixtures. Treat `*INCLUDE` and every other keyword as an explicit\\r\\nunsupported-keyword error.\\r\\n\\r\\n- [ ] **Step 4: Implement semantic mapping for the fixture**\\r\\n\\r\\nFor hierarchical input, require exactly one Assembly and one Instance, reject\\r\\nnonempty Instance transform data, activate only the referenced Part, and map\\r\\nthe result to the same flat `Domain` used by orphan meshes. When transverse\\r\\nstiffness is omitted, set \\\\(A_{sy}=A_{sz}=5A/6\\\\) and `SCF=0`; supported\\r\\nexplicit values override the default.\\r\\n\\r\\n- [ ] **Step 5: Validate and commit**\\r\\n\\r\\n```powershell\\r\\ncmake --build --preset windows-debug\\r\\nctest --preset windows-debug --output-on-failure\\r\\ngit add include/fesa/io src/fesa/io tests/fixtures tests/unit/io tests/integration/io CMakeLists.txt tests/CMakeLists.txt\\r\\ngit commit -m \\\"feat(input): parse minimal Abaqus B31 deck\\\"\\r\\n```\\r\\n\\r\\n---\\r\\n\\r\\n### Task 5: FEM Primitives and DOF Management\\r\\n\\r\\n**Files:**\\r\\n\\r\\n- Create: `include/fesa/fem/gauss_rule.hpp`\\r\\n- Create: `include/fesa/fem/line2_shape.hpp`\\r\\n- Create: `include/fesa/fem/local_frame.hpp`\\r\\n- Create: `include/fesa/fem/dof_manager.hpp`\\r\\n- Create: `src/fesa/fem/local_frame.cpp`\\r\\n- Create: `src/fesa/fem/dof_manager.cpp`\\r\\n- Create: `tests/unit/fem/gauss_rule_test.cpp`\\r\\n- Create: `tests/unit/fem/line2_shape_test.cpp`\\r\\n- Create: `tests/unit/fem/local_frame_test.cpp`\\r\\n- Create: `tests/unit/fem/dof_manager_test.cpp`\\r\\n\\r\\n**Interfaces:**\\r\\n\\r\\n```cpp\\r\\nstruct GaussPoint1D final { double xi; double weight; };\\r\\n[[nodiscard]] std::array gauss_rule_1();\\r\\n[[nodiscard]] std::array gauss_rule_2();\\r\\n[[nodiscard]] std::array line2_shape(double xi);\\r\\n[[nodiscard]] std::array line2_shape_derivative();\\r\\n\\r\\nstruct LocalFrame final { Vec3 ex; Vec3 ey; Vec3 ez; double length; };\\r\\n[[nodiscard]] LocalFrame make_beam_frame(Vec3 first, Vec3 second, Vec3 orientation);\\r\\n\\r\\nclass DofManager final {\\r\\npublic:\\r\\n explicit DofManager(const Domain& domain);\\r\\n\",\"exit_code\":0,\"status\":\"completed\"}}\n{\"type\":\"item.started\",\"item\":{\"id\":\"item_37\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Encoding utf8 -LiteralPath 'docs/superpowers/plans/2026-07-29-fesa-phase-1.md' | Select-Object -Skip 600 -First 200\\\"\",\"aggregated_output\":\"\",\"exit_code\":null,\"status\":\"in_progress\"}}\n{\"type\":\"item.completed\",\"item\":{\"id\":\"item_37\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Encoding utf8 -LiteralPath 'docs/superpowers/plans/2026-07-29-fesa-phase-1.md' | Select-Object -Skip 600 -First 200\\\"\",\"aggregated_output\":\" [[nodiscard]] std::size_t full_dof_count() const noexcept;\\r\\n [[nodiscard]] std::array beam_dofs(ElementId id) const;\\r\\n};\\r\\n```\\r\\n\\r\\n- [ ] **Step 1: Write failing mathematical invariant tests**\\r\\n\\r\\nTest Gauss exactness through degree 3, shape-function partition of unity, derivative sum zero, right-handed orthonormal frames, nearly parallel orientation rejection, stable external-ID ordering, and 12-DOF element maps.\\r\\n\\r\\n- [ ] **Step 2: Confirm failure, implement, and rerun**\\r\\n\\r\\n```powershell\\r\\ncmake --build --preset windows-debug\\r\\nctest --preset windows-debug -R \\\"Fem|Dof|Frame\\\" --output-on-failure\\r\\n```\\r\\n\\r\\n- [ ] **Step 3: Run full validation and commit**\\r\\n\\r\\n```powershell\\r\\nctest --preset windows-debug --output-on-failure\\r\\ngit add include/fesa/fem src/fesa/fem tests/unit/fem CMakeLists.txt tests/CMakeLists.txt\\r\\ngit commit -m \\\"feat(fem): add quadrature frames and DOF mapping\\\"\\r\\n```\\r\\n\\r\\n---\\r\\n\\r\\n### Task 6: Minimal Real Timoshenko Beam Kernel\\r\\n\\r\\n**Files:**\\r\\n\\r\\n- Create: `docs/formulation/timoshenko-beam-3d.md`\\r\\n- Create: `include/fesa/elements/beam/beam3d2.hpp`\\r\\n- Create: `src/fesa/elements/beam/beam3d2.cpp`\\r\\n- Create: `tests/unit/elements/beam3d2_test.cpp`\\r\\n- Modify: CMake files\\r\\n\\r\\n**Interfaces:**\\r\\n\\r\\n```cpp\\r\\nstruct Beam3D2Input final {\\r\\n std::array coordinates;\\r\\n IsotropicElastic material;\\r\\n BeamSection section;\\r\\n};\\r\\n\\r\\nstruct Beam3D2Contribution final {\\r\\n std::array stiffness;\\r\\n std::array equivalent_load;\\r\\n LocalFrame frame;\\r\\n};\\r\\n\\r\\n[[nodiscard]] Beam3D2Contribution evaluate_beam3d2(const Beam3D2Input& input);\\r\\n```\\r\\n\\r\\n- [ ] **Step 1: Write and review the formulation document before production code**\\r\\n\\r\\nThe document must define DOF order, local axes, strain measures, constitutive diagonal, Jacobian, transformation, Gauss rules, matrix storage order, force/moment signs, and reference sources. It must show that axial/bending/torsion use two points and shear uses one point.\\r\\n\\r\\n- [ ] **Step 2: Write failing kernel tests**\\r\\n\\r\\nTest symmetry, six rigid-body modes, positive strain energy for non-rigid modes, analytical axial stiffness \\\\(EA/L\\\\), analytical torsional stiffness \\\\(GJ/L\\\\), coordinate-rotation invariance, and finite values.\\r\\n\\r\\n- [ ] **Step 3: Confirm the tests fail**\\r\\n\\r\\n```powershell\\r\\ncmake --build --preset windows-debug\\r\\nctest --preset windows-debug -R \\\"Beam3D2\\\" --output-on-failure\\r\\n```\\r\\n\\r\\n- [ ] **Step 4: Implement the minimum kernel from the signed-off equations**\\r\\n\\r\\nUse fixed-size `std::array` storage and small explicit loops. Do not add a dynamic matrix abstraction or copy Abaqus slenderness compensation.\\r\\n\\r\\n- [ ] **Step 5: Validate and commit**\\r\\n\\r\\n```powershell\\r\\ncmake --build --preset windows-debug\\r\\nctest --preset windows-debug --output-on-failure\\r\\ngit add docs/formulation include/fesa/elements src/fesa/elements tests/unit/elements CMakeLists.txt tests/CMakeLists.txt\\r\\ngit commit -m \\\"feat(elements): add 3D Timoshenko beam kernel\\\"\\r\\n```\\r\\n\\r\\n---\\r\\n\\r\\n### Task 7: Deterministic Serial Assembly and Essential BC Elimination\\r\\n\\r\\n**Files:**\\r\\n\\r\\n- Create: `include/fesa/assembly/symmetric_coo.hpp`\\r\\n- Create: `include/fesa/assembly/symmetric_csr.hpp`\\r\\n- Create: `include/fesa/assembly/assembler.hpp`\\r\\n- Create: `src/fesa/assembly/assembler.cpp`\\r\\n- Create: `include/fesa/constraints/essential_bc.hpp`\\r\\n- Create: `src/fesa/constraints/essential_bc.cpp`\\r\\n- Create: `tests/unit/assembly/assembler_test.cpp`\\r\\n- Create: `tests/unit/constraints/essential_bc_test.cpp`\\r\\n\\r\\n**Interfaces:**\\r\\n\\r\\n```cpp\\r\\nstruct CooEntry final {\\r\\n std::size_t row;\\r\\n std::size_t column;\\r\\n ElementId source_element;\\r\\n std::size_t local_order;\\r\\n double value;\\r\\n};\\r\\n\\r\\nstruct SymmetricCsr final {\\r\\n std::vector row_offsets;\\r\\n std::vector column_indices;\\r\\n std::vector values;\\r\\n};\\r\\n\\r\\nstruct EquationSystem final {\\r\\n SymmetricCsr stiffness;\\r\\n std::vector load;\\r\\n};\\r\\n\\r\\n[[nodiscard]] EquationSystem assemble_serial(\\r\\n const Domain& domain,\\r\\n const DofManager& dofs);\\r\\n\\r\\nstruct ReducedSystem final {\\r\\n SymmetricCsr stiffness;\\r\\n std::vector rhs;\\r\\n std::vector free_dofs;\\r\\n std::vector prescribed_full_values;\\r\\n};\\r\\n```\\r\\n\\r\\n- [ ] **Step 1: Write failing assembly tests**\\r\\n\\r\\nCover a one-element matrix, a two-element shared-node chain, stable sort/reduction order, upper-triangle storage with every diagonal present, nonzero prescribed values, reduced RHS correction, and full-vector reconstruction.\\r\\n\\r\\n- [ ] **Step 2: Confirm failure and implement serial baseline**\\r\\n\\r\\nSort COO entries by `(row, column, source_element, local_order)` and then sum. This serial result is the oracle for Task 12.\\r\\n\\r\\n- [ ] **Step 3: Verify and commit**\\r\\n\\r\\n```powershell\\r\\ncmake --build --preset windows-debug\\r\\nctest --preset windows-debug -R \\\"Assembly|EssentialBc\\\" --output-on-failure\\r\\nctest --preset windows-debug --output-on-failure\\r\\ngit add include/fesa/assembly src/fesa/assembly include/fesa/constraints src/fesa/constraints tests/unit/assembly tests/unit/constraints CMakeLists.txt tests/CMakeLists.txt\\r\\ngit commit -m \\\"feat(assembly): assemble and constrain beam systems\\\"\\r\\n```\\r\\n\\r\\n---\\r\\n\\r\\n### Task 8: MKL PARDISO Linear Solver Adapter\\r\\n\\r\\n**Files:**\\r\\n\\r\\n- Create: `include/fesa/solvers/linear/linear_solver.hpp`\\r\\n- Create: `include/fesa/solvers/linear/pardiso_solver.hpp`\\r\\n- Create: `src/fesa/solvers/linear/pardiso_solver.cpp`\\r\\n- Create: `tests/unit/solvers/pardiso_solver_test.cpp`\\r\\n- Modify: `cmake/FesaDependencies.cmake`\\r\\n- Modify: CMake files\\r\\n\\r\\n**Interfaces:**\\r\\n\\r\\n```cpp\\r\\nstruct LinearSolveResult final {\\r\\n std::vector solution;\\r\\n double relative_residual;\\r\\n std::vector diagnostics;\\r\\n};\\r\\n\\r\\nclass LinearSolver {\\r\\npublic:\\r\\n virtual ~LinearSolver() = default;\\r\\n [[nodiscard]] virtual LinearSolveResult solve(\\r\\n const SymmetricCsr& matrix,\\r\\n std::span rhs) = 0;\\r\\n};\\r\\n\\r\\nclass PardisoLinearSolver final : public LinearSolver {\\r\\npublic:\\r\\n PardisoLinearSolver();\\r\\n ~PardisoLinearSolver() override;\\r\\n PardisoLinearSolver(const PardisoLinearSolver&) = delete;\\r\\n PardisoLinearSolver& operator=(const PardisoLinearSolver&) = delete;\\r\\n [[nodiscard]] LinearSolveResult solve(\\r\\n const SymmetricCsr& matrix,\\r\\n std::span rhs) override;\\r\\n};\\r\\n```\\r\\n\\r\\n- [ ] **Step 1: Write failing adapter tests**\\r\\n\\r\\nUse a hand-calculated 3x3 SPD system, multiple RHS calls on one adapter, invalid CSR, dimension mismatch, and a singular matrix. Assert `mtype=2`, LP64-compatible index checks, 0-based indexing, and residual reporting through observable behavior.\\r\\n\\r\\n- [ ] **Step 2: Confirm failure**\\r\\n\\r\\n```powershell\\r\\ncmake --build --preset windows-debug\\r\\nctest --preset windows-debug -R \\\"Pardiso\\\" --output-on-failure\\r\\n\",\"exit_code\":0,\"status\":\"completed\"}}\n{\"type\":\"item.started\",\"item\":{\"id\":\"item_38\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Encoding utf8 -LiteralPath 'docs/superpowers/plans/2026-07-29-fesa-phase-1.md' | Select-Object -Skip 800 -First 200\\\"\",\"aggregated_output\":\"\",\"exit_code\":null,\"status\":\"in_progress\"}}\n{\"type\":\"item.completed\",\"item\":{\"id\":\"item_38\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Encoding utf8 -LiteralPath 'docs/superpowers/plans/2026-07-29-fesa-phase-1.md' | Select-Object -Skip 800 -First 200\\\"\",\"aggregated_output\":\"```\\r\\n\\r\\n- [ ] **Step 3: Implement RAII PARDISO phases**\\r\\n\\r\\nSet `iparm[34]=1` for zero-based indexing and enable the matrix checker. Run symbolic analysis, numerical factorization, solve, and release. Convert every MKL error to `DiagnosticStage::solver`.\\r\\n\\r\\n- [ ] **Step 4: Validate and commit**\\r\\n\\r\\n```powershell\\r\\ncmake --build --preset windows-debug\\r\\nctest --preset windows-debug --output-on-failure\\r\\ngit add include/fesa/solvers src/fesa/solvers tests/unit/solvers cmake/FesaDependencies.cmake CMakeLists.txt tests/CMakeLists.txt\\r\\ngit commit -m \\\"feat(solver): add PARDISO linear backend\\\"\\r\\n```\\r\\n\\r\\n---\\r\\n\\r\\n### Task 9: Result Model and Minimal HDF5 Round Trip\\r\\n\\r\\n**Files:**\\r\\n\\r\\n- Create: `docs/HDF5_SCHEMA.md`\\r\\n- Create: `include/fesa/results/result_database.hpp`\\r\\n- Create: `include/fesa/io/hdf5/schema.hpp`\\r\\n- Create: `include/fesa/io/hdf5/writer.hpp`\\r\\n- Create: `include/fesa/io/hdf5/reader.hpp`\\r\\n- Create: `src/fesa/io/hdf5/writer.cpp`\\r\\n- Create: `src/fesa/io/hdf5/reader.cpp`\\r\\n- Create: `tests/unit/io/hdf5_round_trip_test.cpp`\\r\\n- Modify: CMake files\\r\\n\\r\\n**Interfaces:**\\r\\n\\r\\n```cpp\\r\\nstruct NodalFrame final {\\r\\n std::vector node_ids;\\r\\n std::vector> displacement;\\r\\n std::vector> reaction;\\r\\n};\\r\\n\\r\\nstruct ResultFrame final {\\r\\n double step_time;\\r\\n NodalFrame nodal;\\r\\n std::vector diagnostics;\\r\\n};\\r\\n\\r\\nstruct ResultStep final {\\r\\n std::string name;\\r\\n std::vector frames;\\r\\n};\\r\\n\\r\\nstruct ResultDatabase final {\\r\\n std::string schema_version;\\r\\n std::vector steps;\\r\\n};\\r\\n\\r\\nstruct Hdf5ReadResult final {\\r\\n std::optional database;\\r\\n std::vector diagnostics;\\r\\n};\\r\\n\\r\\n[[nodiscard]] std::vector write_hdf5(\\r\\n const std::filesystem::path&,\\r\\n const Domain&,\\r\\n const ResultDatabase&);\\r\\n[[nodiscard]] Hdf5ReadResult read_hdf5_results(const std::filesystem::path&);\\r\\n```\\r\\n\\r\\n- [ ] **Step 1: Write schema version `1.0.0` before writer code**\\r\\n\\r\\nDefine exact group paths, dataset ranks, scalar types, dense ID mappings,\\r\\nPart/Instance/local-label origins, coordinate-system attributes, applied\\r\\ntransverse-shear values and their input/default source, required HDF5 metadata,\\r\\nand compatibility rules.\\r\\n\\r\\n- [ ] **Step 2: Write a failing round-trip test**\\r\\n\\r\\nUse a two-node hierarchical-origin `Domain` and one result frame. Reopen\\r\\nthrough the FESA reader and compare every stored value, origin mapping,\\r\\ntransverse-shear source, and schema attribute.\\r\\n\\r\\n- [ ] **Step 3: Confirm failure and implement minimum C-API RAII wrappers**\\r\\n\\r\\nDo not use global HDF5 handles. Convert every failing HDF5 call into a results-stage diagnostic or exception caught at the adapter boundary.\\r\\n\\r\\n- [ ] **Step 4: Validate with tests and HDF5 tools**\\r\\n\\r\\n```powershell\\r\\ncmake --build --preset windows-debug\\r\\nctest --preset windows-debug -R \\\"Hdf5\\\" --output-on-failure\\r\\nh5ls -r .\\\\out\\\\build\\\\windows-debug\\\\Testing\\\\Temporary\\\\fesa-round-trip.h5\\r\\nctest --preset windows-debug --output-on-failure\\r\\n```\\r\\n\\r\\n- [ ] **Step 5: Commit**\\r\\n\\r\\n```powershell\\r\\ngit add docs/HDF5_SCHEMA.md include/fesa/results include/fesa/io/hdf5 src/fesa/io/hdf5 tests/unit/io CMakeLists.txt tests/CMakeLists.txt\\r\\ngit commit -m \\\"feat(results): add versioned HDF5 result adapter\\\"\\r\\n```\\r\\n\\r\\n---\\r\\n\\r\\n### Task 10: Linear Static Analysis and End-to-End CLI Slice\\r\\n\\r\\n**Files:**\\r\\n\\r\\n- Create: `include/fesa/analysis/analysis.hpp`\\r\\n- Create: `include/fesa/analysis/linear_static_analysis.hpp`\\r\\n- Create: `src/fesa/analysis/analysis.cpp`\\r\\n- Create: `src/fesa/analysis/linear_static_analysis.cpp`\\r\\n- Create: `include/fesa/analysis/run_solver.hpp`\\r\\n- Create: `src/fesa/analysis/run_solver.cpp`\\r\\n- Modify: `src/fesa/cli/main.cpp`\\r\\n- Create: `tests/integration/pipeline/minimal_cantilever_test.cpp`\\r\\n- Modify: CMake files\\r\\n\\r\\n**Interfaces:**\\r\\n\\r\\n```cpp\\r\\nstruct AnalysisRequest final {\\r\\n std::filesystem::path input_path;\\r\\n std::filesystem::path output_path;\\r\\n};\\r\\n\\r\\nstruct AnalysisRunResult final {\\r\\n bool succeeded;\\r\\n std::vector diagnostics;\\r\\n};\\r\\n\\r\\n[[nodiscard]] AnalysisRunResult run_solver(const AnalysisRequest& request);\\r\\n```\\r\\n\\r\\nThe CLI contract is:\\r\\n\\r\\n```text\\r\\nfesa solve --output \\r\\nfesa --version\\r\\n```\\r\\n\\r\\n- [ ] **Step 1: Write the failing end-to-end test**\\r\\n\\r\\nInvoke only `run_solver()` or the CLI with `tests/fixtures/abaqus/minimal_cantilever.inp`, then use the public HDF5 reader to assert node IDs, finite displacement, equilibrium residual, and result paths.\\r\\n\\r\\n- [ ] **Step 2: Confirm the pipeline test fails**\\r\\n\\r\\n```powershell\\r\\ncmake --build --preset windows-debug\\r\\nctest --preset windows-debug -R \\\"MinimalCantileverPipeline\\\" --output-on-failure\\r\\n```\\r\\n\\r\\n- [ ] **Step 3: Implement the analysis lifecycle**\\r\\n\\r\\nConnect parser, `Domain`, `DofManager`, Beam kernel, serial assembly, essential BC, PARDISO, full-vector reconstruction, reaction recovery, result model, and HDF5 writer. Keep CLI parsing out of `fesa_core`.\\r\\n\\r\\n- [ ] **Step 4: Validate the vertical slice**\\r\\n\\r\\n```powershell\\r\\ncmake --build --preset windows-debug\\r\\nctest --preset windows-debug --output-on-failure\\r\\n.\\\\out\\\\build\\\\windows-debug\\\\Debug\\\\fesa.exe solve tests\\\\fixtures\\\\abaqus\\\\minimal_cantilever.inp --output out\\\\minimal-cantilever.h5\\r\\nh5ls -r out\\\\minimal-cantilever.h5\\r\\n```\\r\\n\\r\\nExpected: full pipeline succeeds. Do not label the Beam numerically qualified yet.\\r\\n\\r\\n- [ ] **Step 5: Commit**\\r\\n\\r\\n```powershell\\r\\ngit add include/fesa/analysis src/fesa/analysis src/fesa/cli/main.cpp tests/integration/pipeline CMakeLists.txt tests/CMakeLists.txt\\r\\ngit commit -m \\\"feat(analysis): connect linear static pipeline\\\"\\r\\n```\\r\\n\\r\\n---\\r\\n\\r\\n### Task 11: Complete the Agreed Abaqus Input Subset\\r\\n\\r\\n**Files:**\\r\\n\\r\\n- Modify: Abaqus parser and mapper files from Task 4\\r\\n- Create: `tests/unit/io/abaqus/set_resolution_test.cpp`\\r\\n- Create: `tests/unit/io/abaqus/scope_resolution_test.cpp`\\r\\n- Create: `tests/unit/io/abaqus/semantic_validation_test.cpp`\\r\\n- Create: `tests/integration/io/multiple_properties_test.cpp`\\r\\n- Create: `tests/integration/io/supplied_cantilever_to_domain_test.cpp`\\r\\n- Create fixtures under: `tests/fixtures/abaqus/valid/`\\r\\n- Create fixtures under: `tests/fixtures/abaqus/invalid/`\\r\\n- Create: `docs/ABAQUS_INPUT_SUBSET.md`\\r\\n\\r\\n**Interfaces:**\\r\\n\\r\\n- Existing parser and mapper signatures remain unchanged.\\r\\n- `docs/ABAQUS_INPUT_SUBSET.md` becomes the normative keyword/parameter/data-line contract.\\r\\n\\r\\n- [ ] **Step 1: Write the contract document and failing fixture matrix**\\r\\n\\r\\nCover `*NODE`, B31 `*ELEMENT`, `*PART/*END PART`,\\r\\n`*ASSEMBLY/*END ASSEMBLY`, `*INSTANCE/*END INSTANCE`, `*NSET`, `*ELSET`,\\r\\nexplicit members, `GENERATE`, nested set references, `INSTANCE=`,\\r\\n`*MATERIAL`, `*ELASTIC`, general Beam section, optional transverse shear\\r\\n\",\"exit_code\":0,\"status\":\"completed\"}}\n{\"type\":\"item.started\",\"item\":{\"id\":\"item_39\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Encoding utf8 -LiteralPath 'docs/superpowers/plans/2026-07-29-fesa-phase-1.md' | Select-Object -Skip 1000 -First 200\\\"\",\"aggregated_output\":\"\",\"exit_code\":null,\"status\":\"in_progress\"}}\n{\"type\":\"item.completed\",\"item\":{\"id\":\"item_39\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Encoding utf8 -LiteralPath 'docs/superpowers/plans/2026-07-29-fesa-phase-1.md' | Select-Object -Skip 1000 -First 200\\\"\",\"aggregated_output\":\"stiffness, `*BOUNDARY`, `*CLOAD`, and one static step. Document\\r\\n`*HEADING`, `*PREPRINT`, `*RESTART`, and `*OUTPUT` as recognized no-op\\r\\ndirectives.\\r\\n\\r\\n- [ ] **Step 2: Add invalid tests before parser changes**\\r\\n\\r\\nCover duplicate IDs and origins, missing references, set cycles, invalid\\r\\nranges, multiple section assignments, missing material, conflicting prescribed\\r\\nvalues, unsupported options, `*INCLUDE`, multiple Assemblies, multiple\\r\\nInstances, Instance translation/rotation data, instance-local mesh changes,\\r\\nmixed flat/hierarchical meshes, nonzero `SCF`, multiple steps, and source-line\\r\\naccuracy.\\r\\n\\r\\n- [ ] **Step 3: Run and confirm the new tests fail**\\r\\n\\r\\n```powershell\\r\\ncmake --build --preset windows-debug\\r\\nctest --preset windows-debug -R \\\"Abaqus|SetResolution|MultipleProperties\\\" --output-on-failure\\r\\n```\\r\\n\\r\\n- [ ] **Step 4: Implement only the documented subset**\\r\\n\\r\\nResolve Part and Assembly scopes before normalizing only the active Part and\\r\\nInstance. Resolve nested sets with explicit cycle detection and canonical\\r\\nsorted-unique membership. Recognized no-op directives must be consumed\\r\\ndeliberately; do not add a general ignore-unknown path. Verify the supplied\\r\\n`reference/cantilever beam/cantilever beam.inp` maps to the expected 11 nodes,\\r\\n10 elements, one active material/section, six fixed DOFs, and one nodal load.\\r\\n\\r\\n- [ ] **Step 5: Validate and commit**\\r\\n\\r\\n```powershell\\r\\ncmake --build --preset windows-debug\\r\\nctest --preset windows-debug --output-on-failure\\r\\ngit add docs/ABAQUS_INPUT_SUBSET.md include/fesa/io/abaqus src/fesa/io/abaqus tests/fixtures/abaqus tests/unit/io/abaqus tests/integration/io\\r\\ngit commit -m \\\"feat(input): complete Phase 1 Abaqus subset\\\"\\r\\n```\\r\\n\\r\\n---\\r\\n\\r\\n### Task 12: Deterministic oneTBB Assembly\\r\\n\\r\\n**Files:**\\r\\n\\r\\n- Modify: `include/fesa/assembly/assembler.hpp`\\r\\n- Modify: `src/fesa/assembly/assembler.cpp`\\r\\n- Create: `tests/unit/assembly/parallel_assembler_test.cpp`\\r\\n- Create: `tests/integration/assembly/thread_count_determinism_test.cpp`\\r\\n- Create: `tests/performance/assembly_benchmark.cpp`\\r\\n- Modify: CMake files\\r\\n\\r\\n**Interfaces:**\\r\\n\\r\\n```cpp\\r\\nstruct AssemblyOptions final {\\r\\n std::size_t max_threads;\\r\\n std::size_t grain_size;\\r\\n};\\r\\n\\r\\n[[nodiscard]] EquationSystem assemble_parallel(\\r\\n const Domain& domain,\\r\\n const DofManager& dofs,\\r\\n AssemblyOptions options);\\r\\n```\\r\\n\\r\\n- [ ] **Step 1: Write failing serial-versus-parallel tests**\\r\\n\\r\\nGenerate fixed chain and branched Beam domains. Compare CSR row offsets and column indices exactly and values bit-for-bit for thread counts 1, 2, and the available concurrency.\\r\\n\\r\\n- [ ] **Step 2: Confirm failure**\\r\\n\\r\\n```powershell\\r\\ncmake --build --preset windows-debug\\r\\nctest --preset windows-debug -R \\\"ParallelAssembly|ThreadCount\\\" --output-on-failure\\r\\n```\\r\\n\\r\\n- [ ] **Step 3: Implement parallel element evaluation with deterministic merge**\\r\\n\\r\\nUse oneTBB for independent element evaluation. Each contribution retains `(row, column, element ID, local order)`. Sort and reduce in the same order as the serial oracle. Do not perform concurrent unordered writes to CSR values.\\r\\n\\r\\n- [ ] **Step 4: Validate correctness before measuring performance**\\r\\n\\r\\n```powershell\\r\\ncmake --build --preset windows-debug\\r\\nctest --preset windows-debug --output-on-failure\\r\\n.\\\\out\\\\build\\\\windows-debug\\\\Debug\\\\fesa_assembly_benchmark.exe\\r\\n```\\r\\n\\r\\nRecord timings without asserting a speedup in unit tests.\\r\\n\\r\\n- [ ] **Step 5: Commit**\\r\\n\\r\\n```powershell\\r\\ngit add include/fesa/assembly src/fesa/assembly tests/unit/assembly tests/integration/assembly tests/performance CMakeLists.txt tests/CMakeLists.txt\\r\\ngit commit -m \\\"perf(assembly): add deterministic TBB assembly\\\"\\r\\n```\\r\\n\\r\\n---\\r\\n\\r\\n### Task 13: Complete Beam Recovery and Self-Contained HDF5 Contract\\r\\n\\r\\n**Files:**\\r\\n\\r\\n- Modify: `include/fesa/elements/beam/beam3d2.hpp`\\r\\n- Modify: `src/fesa/elements/beam/beam3d2.cpp`\\r\\n- Modify: result-model and HDF5 files from Task 9\\r\\n- Modify: `docs/HDF5_SCHEMA.md`\\r\\n- Create: `tests/unit/elements/beam3d2_recovery_test.cpp`\\r\\n- Create: `tests/integration/results/self_contained_hdf5_test.cpp`\\r\\n\\r\\n**Interfaces:**\\r\\n\\r\\n```cpp\\r\\nstruct BeamSectionResult final {\\r\\n double xi;\\r\\n NodeId end_node;\\r\\n std::array section_strain;\\r\\n std::array section_force;\\r\\n double centroid_sigma_xx;\\r\\n std::vector sigma_xx;\\r\\n};\\r\\n\\r\\n[[nodiscard]] std::vector recover_beam3d2(\\r\\n const Beam3D2Input& input,\\r\\n std::span element_displacement,\\r\\n std::span> recovery_points);\\r\\n```\\r\\n\\r\\n- [ ] **Step 1: Write failing recovery tests**\\r\\n\\r\\nCover pure axial force, pure torsion, bending about each principal axis,\\r\\ncombined axial/biaxial bending, force sign at both element ends,\\r\\n`centroid_sigma_xx=N/A`, and recovery-point ordering.\\r\\n\\r\\n- [ ] **Step 2: Write the failing self-contained-file test**\\r\\n\\r\\nReopen one result file and reconstruct node coordinates, connectivity,\\r\\nPart/Instance origins, sets, material, section, applied shear values and their\\r\\nsource, step, solver settings, local frame, nodal fields, element section\\r\\nfields including centroid stress, ID maps, and diagnostics.\\r\\n\\r\\n- [ ] **Step 3: Implement recovery and schema additions**\\r\\n\\r\\nDo not output point shear or point torsional stress. Store section shear resultants and torsional moment as generalized quantities.\\r\\n\\r\\n- [ ] **Step 4: Validate and commit**\\r\\n\\r\\n```powershell\\r\\ncmake --build --preset windows-debug\\r\\nctest --preset windows-debug -R \\\"Beam3D2Recovery|SelfContainedHdf5\\\" --output-on-failure\\r\\nctest --preset windows-debug --output-on-failure\\r\\ngit add include/fesa/elements src/fesa/elements include/fesa/results include/fesa/io/hdf5 src/fesa/io/hdf5 docs/HDF5_SCHEMA.md tests/unit/elements tests/integration/results\\r\\ngit commit -m \\\"feat(results): recover and store beam section results\\\"\\r\\n```\\r\\n\\r\\n---\\r\\n\\r\\n### Task 14: Analytical and Available Abaqus 2024 Qualification\\r\\n\\r\\n**Files:**\\r\\n\\r\\n- Create: `include/fesa/validation/comparison.hpp`\\r\\n- Create: `include/fesa/validation/reference_csv.hpp`\\r\\n- Create: `src/fesa/validation/comparison.cpp`\\r\\n- Create: `src/fesa/validation/reference_csv.cpp`\\r\\n- Create: `src/fesa/validation/reference_compare_main.cpp`\\r\\n- Create: `tests/unit/validation/comparison_test.cpp`\\r\\n- Create: `tests/unit/validation/reference_csv_test.cpp`\\r\\n- Create: `tests/fixtures/reference/internalforces.csv`\\r\\n- Create: `tests/fixtures/reference/stresses.csv`\\r\\n- Create: `tests/reference/CMakeLists.txt`\\r\\n- Create: `tests/reference/cantilever_reference_test.cpp`\\r\\n- Create: `docs/VALIDATION.md`\\r\\n- Modify: CMake files\\r\\n\\r\\n**Interfaces:**\\r\\n\\r\\n```cpp\\r\\nstruct Tolerance final {\\r\\n double relative;\\r\\n double absolute_scale;\\r\\n};\\r\\n\\r\\nenum class ReferenceQuantity {\\r\\n displacement,\\r\\n reaction,\\r\\n internal_force,\\r\\n centroid_stress\\r\\n};\\r\\n\\r\\nstruct ResultPosition final {\\r\\n std::string instance_name;\\r\\n std::int64_t entity_label;\\r\\n std::optional end_node_label;\\r\\n};\\r\\n\\r\\nstruct ComparisonSample final {\\r\\n ReferenceQuantity quantity;\\r\\n ResultPosition position;\\r\\n std::vector reference;\\r\\n\",\"exit_code\":0,\"status\":\"completed\"}}\n{\"type\":\"item.started\",\"item\":{\"id\":\"item_40\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Encoding utf8 -LiteralPath 'docs/superpowers/plans/2026-07-29-fesa-phase-1.md' | Select-Object -Skip 1200 -First 200\\\"\",\"aggregated_output\":\"\",\"exit_code\":null,\"status\":\"in_progress\"}}\n{\"type\":\"item.completed\",\"item\":{\"id\":\"item_40\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Encoding utf8 -LiteralPath 'docs/superpowers/plans/2026-07-29-fesa-phase-1.md' | Select-Object -Skip 1200 -First 200\\\"\",\"aggregated_output\":\" std::vector actual;\\r\\n Tolerance tolerance;\\r\\n};\\r\\n\\r\\nstruct ReferenceRow final {\\r\\n ReferenceQuantity quantity;\\r\\n ResultPosition position;\\r\\n std::vector values;\\r\\n};\\r\\n\\r\\nstruct ComparisonReport final {\\r\\n bool passed;\\r\\n double maximum_normalized_error;\\r\\n std::vector failures;\\r\\n};\\r\\n\\r\\n[[nodiscard]] ComparisonReport compare_samples(\\r\\n std::span samples);\\r\\n\\r\\nstruct ReferenceCsvReadResult final {\\r\\n std::vector rows;\\r\\n std::vector diagnostics;\\r\\n};\\r\\n\\r\\n[[nodiscard]] ReferenceCsvReadResult read_reference_csv(\\r\\n ReferenceQuantity quantity,\\r\\n const std::filesystem::path& path,\\r\\n std::string_view single_instance_name,\\r\\n Tolerance tolerance);\\r\\n```\\r\\n\\r\\nFor each scalar component, define\\r\\n\\\\[\\r\\ne_n=\\\\frac{|a-r|}{a_\\\\mathrm{scale}+r_\\\\mathrm{tol}|r|}\\r\\n\\\\]\\r\\nand pass only when \\\\(e_n\\\\leq1\\\\). Reject nonfinite inputs before computing the\\r\\nmetric.\\r\\n\\r\\n- [ ] **Step 1: Write failing metric and entity-matching tests**\\r\\n\\r\\nTest the normalized error, near-zero absolute scale, nonfinite values,\\r\\nduplicate positions, unknown entities, invalid element-node pairs, and\\r\\ncomponent-count mismatches.\\r\\n\\r\\n- [ ] **Step 2: Write failing CSV adapter tests for all four quantities**\\r\\n\\r\\nAccept the supplied displacement/reaction headers after trimming whitespace.\\r\\nFor a single Instance, allow the `Part Instance Name` column to be absent.\\r\\nUse these exact element schemas:\\r\\n\\r\\n```text\\r\\nPart Instance Name, Element Label, Node Label,\\r\\nSF-SF1, SF-SF2, SF-SF3, SM-SM1, SM-SM2, SM-SM3\\r\\n\\r\\nPart Instance Name, Element Label, Node Label, Sxx\\r\\n```\\r\\n\\r\\nMap `SF1,SF2,SF3,SM1,SM2,SM3` to \\\\(N,V_y,V_z,T,M_y,M_z\\\\).\\r\\nCompare `Sxx` with the element-end section-centroid value \\\\(N/A\\\\). The\\r\\nsynthetic fixtures exercise both element result schemas before real files\\r\\nexist.\\r\\n\\r\\n- [ ] **Step 3: Write the failing supplied-cantilever reference test**\\r\\n\\r\\nRun FESA through the public parser, analysis, and HDF5 reader. Create an\\r\\nexplicit request selecting only:\\r\\n\\r\\n```text\\r\\nreference/cantilever beam/cantilever beam displacements.csv\\r\\nreference/cantilever beam/cantilever beam reactions.csv\\r\\n```\\r\\n\\r\\nUse relative tolerance \\\\(10^{-5}\\\\) and test-registered absolute scales. Do not\\r\\nlook for metadata, internal-force CSV, or stress CSV in this reference test.\\r\\nThe equivalent command-line contract is:\\r\\n\\r\\n```powershell\\r\\nfesa-reference-compare `\\r\\n --results out\\\\cantilever-beam.h5 `\\r\\n --instance Part-1-1 `\\r\\n --displacements \\\"reference\\\\cantilever beam\\\\cantilever beam displacements.csv\\\" `\\r\\n --reactions \\\"reference\\\\cantilever beam\\\\cantilever beam reactions.csv\\\" `\\r\\n --relative-tolerance 1e-5 `\\r\\n --displacement-absolute-scale 1e-10 `\\r\\n --reaction-absolute-scale 1e-8\\r\\n```\\r\\n\\r\\n- [ ] **Step 4: Confirm failures before numerical corrections**\\r\\n\\r\\n```powershell\\r\\ncmake --preset windows-debug\\r\\ncmake --build --preset windows-debug\\r\\nctest --preset windows-debug -R \\\"Reference\\\" --output-on-failure\\r\\n```\\r\\n\\r\\n- [ ] **Step 5: Correct only evidenced formulation or recovery defects**\\r\\n\\r\\nFor every change, add or tighten the smallest analytical test that reproduces\\r\\nthe discrepancy. Do not widen tolerance to hide a defect. Record justified\\r\\ntolerance differences in `docs/VALIDATION.md` and the CTest registration.\\r\\n\\r\\n- [ ] **Step 6: Run the full qualification suite**\\r\\n\\r\\n```powershell\\r\\nctest --preset windows-debug --output-on-failure\\r\\nctest --preset windows-debug -R \\\"Reference\\\" --output-on-failure\\r\\n```\\r\\n\\r\\nExpected: all analytical, physics-sanity, pipeline, deterministic-parallel,\\r\\nCSV-adapter, and available Abaqus displacement/reaction comparisons pass.\\r\\nDo not claim Abaqus qualification of element internal force or stress until\\r\\nthose CSV files are supplied and selected.\\r\\n\\r\\n- [ ] **Step 7: Complete the validation report and commit**\\r\\n\\r\\n`docs/VALIDATION.md` must list each benchmark, analytical/reference source,\\r\\nAbaqus configuration, selected quantities, tolerance, maximum observed error,\\r\\nand disposition. It must distinguish synthetic adapter coverage from\\r\\nAbaqus-backed quantity qualification.\\r\\n\\r\\n```powershell\\r\\ngit add include/fesa/validation src/fesa/validation tests/unit/validation tests/fixtures/reference tests/reference docs/VALIDATION.md CMakeLists.txt tests/CMakeLists.txt\\r\\ngit commit -m \\\"test(validation): qualify Beam solver against Abaqus\\\"\\r\\n```\\r\\n\\r\\n---\\r\\n\\r\\n### Task 15: Internal Release Gate\\r\\n\\r\\n**Files:**\\r\\n\\r\\n- Create: `cmake/install.cmake`\\r\\n- Create: `cmake/FESAConfig.cmake.in`\\r\\n- Create: `docs/BUILDING.md`\\r\\n- Create: `docs/INPUT_FORMAT.md`\\r\\n- Create: `docs/RELEASE_CHECKLIST.md`\\r\\n- Create: `tests/performance/phase1_scale_benchmark.cpp`\\r\\n- Modify: root CMake files\\r\\n- Modify: `docs/VALIDATION.md`\\r\\n\\r\\n**Interfaces:**\\r\\n\\r\\n- Produces install tree containing `fesa.exe`, the static library, public headers, required runtime DLL inventory, example input, schema, and validation report.\\r\\n- No public ABI compatibility promise is made for Phase 1.\\r\\n\\r\\n- [ ] **Step 1: Write the release checklist before packaging changes**\\r\\n\\r\\nInclude environment versions, Debug/Release builds, zero-warning requirement,\\r\\nCTest count, selected reference quantities, synthetic four-quantity adapter\\r\\ncoverage, HDF5 inspection, 100k-DOF memory/time measurement, runtime DLL\\r\\ninventory, example run, and clean install-tree smoke test.\\r\\n\\r\\n- [ ] **Step 2: Add a failing install-tree smoke test**\\r\\n\\r\\nThe test configures a small consumer against installed headers and the static library, runs `fesa --version`, solves the example, and opens its HDF5 output.\\r\\n\\r\\n- [ ] **Step 3: Implement CMake install rules**\\r\\n\\r\\nUse `cmake --install`; do not add an installer, registry writes, package download, or external-customer SDK promise.\\r\\n\\r\\n- [ ] **Step 4: Run Debug, Release, performance, and install validation**\\r\\n\\r\\n```powershell\\r\\ncmake --preset windows-debug\\r\\ncmake --build --preset windows-debug\\r\\nctest --preset windows-debug --output-on-failure\\r\\ncmake --preset windows-release\\r\\ncmake --build --preset windows-release\\r\\nctest --preset windows-release --output-on-failure\\r\\n.\\\\out\\\\build\\\\windows-release\\\\Release\\\\fesa_phase1_scale_benchmark.exe\\r\\ncmake --install out\\\\build\\\\windows-release --config Release --prefix out\\\\package\\\\fesa\\r\\n```\\r\\n\\r\\nExpected: all tests pass, no new MSVC warnings exist, the benchmark completes within documented resources, and the clean install-tree smoke test passes.\\r\\n\\r\\n- [ ] **Step 5: Verify every PRD release criterion**\\r\\n\\r\\nMap every item in `docs/PRD.md` section 8 to fresh command output or a validation-report entry. Stop the release if any item lacks evidence.\\r\\n\\r\\n- [ ] **Step 6: Commit**\\r\\n\\r\\n```powershell\\r\\ngit add cmake/install.cmake docs/BUILDING.md docs/INPUT_FORMAT.md docs/RELEASE_CHECKLIST.md docs/VALIDATION.md tests/performance CMakeLists.txt\\r\\ngit commit -m \\\"chore(release): prepare FESA Phase 1 internal package\\\"\\r\\n```\\r\\n\\r\\n## Plan Execution Gate\\r\\n\\r\\nBefore implementation:\\r\\n\\r\\n1. Review and approve this phase split.\\r\\n2. Use the Harness skill to draft `phases/index.json`, each phase index, and self-contained step files.\\r\\n3. Review the phase-file draft before creating it.\\r\\n4. Execute one Harness phase at a time.\\r\\n5. Do not begin the next phase until its tests, review, and acceptance commands pass.\\r\\n\",\"exit_code\":0,\"status\":\"completed\"}}\n{\"type\":\"item.started\",\"item\":{\"id\":\"item_41\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Raw -Encoding utf8 -LiteralPath 'phases/fem-and-beam-kernel/index.json'\\\"\",\"aggregated_output\":\"\",\"exit_code\":null,\"status\":\"in_progress\"}}\n{\"type\":\"item.completed\",\"item\":{\"id\":\"item_41\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Raw -Encoding utf8 -LiteralPath 'phases/fem-and-beam-kernel/index.json'\\\"\",\"aggregated_output\":\"{\\r\\n \\\"project\\\": \\\"FESA\\\",\\r\\n \\\"phase\\\": \\\"fem-and-beam-kernel\\\",\\r\\n \\\"steps\\\": [\\r\\n {\\r\\n \\\"step\\\": 0,\\r\\n \\\"name\\\": \\\"quadrature-and-shape-functions\\\",\\r\\n \\\"status\\\": \\\"completed\\\",\\r\\n \\\"summary\\\": \\\"Added fixed 1D Gauss rules, Line2 shape primitives, and a validated length/2 Jacobian with invariant and invalid-input tests.\\\",\\r\\n \\\"started_at\\\": \\\"2026-07-31T01:37:23+0900\\\",\\r\\n \\\"completed_at\\\": \\\"2026-07-31T01:48:32+0900\\\"\\r\\n },\\r\\n {\\r\\n \\\"step\\\": 1,\\r\\n \\\"name\\\": \\\"dof-manager\\\",\\r\\n \\\"status\\\": \\\"completed\\\",\\r\\n \\\"summary\\\": \\\"Added deterministic six-DOF equation numbering, prescribed-value reconstruction, and 12-DOF Beam element mapping with validation tests.\\\",\\r\\n \\\"started_at\\\": \\\"2026-07-31T01:48:33+0900\\\",\\r\\n \\\"completed_at\\\": \\\"2026-07-31T01:55:21+0900\\\"\\r\\n },\\r\\n {\\r\\n \\\"step\\\": 2,\\r\\n \\\"name\\\": \\\"beam-local-frame\\\",\\r\\n \\\"status\\\": \\\"completed\\\",\\r\\n \\\"summary\\\": \\\"Added scale-aware right-handed Beam frames and fixed 12x12 global-to-local transformations with degeneracy, orthonormality, rotation, and energy-invariance tests.\\\",\\r\\n \\\"started_at\\\": \\\"2026-07-31T01:55:21+0900\\\",\\r\\n \\\"completed_at\\\": \\\"2026-07-31T02:08:27+0900\\\"\\r\\n },\\r\\n {\\r\\n \\\"step\\\": 3,\\r\\n \\\"name\\\": \\\"timoshenko-stiffness-kernel\\\",\\r\\n \\\"status\\\": \\\"pending\\\",\\r\\n \\\"started_at\\\": \\\"2026-07-31T02:08:27+0900\\\"\\r\\n }\\r\\n ],\\r\\n \\\"created_at\\\": \\\"2026-07-31T01:37:23+0900\\\"\\r\\n}\\r\\n\",\"exit_code\":0,\"status\":\"completed\"}}\n{\"type\":\"item.started\",\"item\":{\"id\":\"item_42\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Raw -Encoding utf8 -LiteralPath 'phases/fem-and-beam-kernel/step3.md'\\\"\",\"aggregated_output\":\"\",\"exit_code\":null,\"status\":\"in_progress\"}}\n{\"type\":\"item.completed\",\"item\":{\"id\":\"item_42\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Raw -Encoding utf8 -LiteralPath 'phases/fem-and-beam-kernel/step3.md'\\\"\",\"aggregated_output\":\"# Step 3: Timoshenko Stiffness Kernel\\n\\n## 읽어야 할 파일\\n\\n- `/AGENTS.md`\\n- `/docs/PRD.md`\\n- `/docs/ARCHITECTURE.md`\\n- `/docs/ADR.md`\\n- `/docs/superpowers/plans/2026-07-29-fesa-phase-1.md`\\n- `/include/fesa/fem/`\\n- `/include/fesa/model/material.hpp`\\n- `/include/fesa/model/beam_section.hpp`\\n- `/docs/formulation/timoshenko-beam-3d.md`가 있으면 전체\\n\\n## 작업\\n\\n먼저 `docs/formulation/timoshenko-beam-3d.md`에 자유도 순서, 변형률, 부호,\\nconstitutive matrix, Jacobian과 선택적 감차적분 식을 작성한다. 그 식으로 실제\\n2절점 3D isoparametric Timoshenko Beam stiffness를 구현한다.\\n\\n```cpp\\nstruct Beam3D2Input final {\\n std::array coordinates;\\n IsotropicElastic material;\\n BeamSection section;\\n};\\nstruct Beam3D2Contribution final {\\n Matrix12 local_stiffness;\\n Matrix12 global_stiffness;\\n BeamFrame frame;\\n};\\n[[nodiscard]] BeamKernelResult compute_beam3d2(const Beam3D2Input&);\\n```\\n\\n- 축·굽힘·비틀림은 2점, 전단은 1점 Gauss 적분한다.\\n- \\\\(G=E/[2(1+\\\\nu)]\\\\)를 사용한다.\\n- 먼저 대칭성, 강체운동 zero energy, 축/비틀림/굽힘 해석해, shear-dominant,\\n 세장비 sweep과 좌표회전 invariant 테스트를 실패시킨다.\\n\\n## Acceptance Criteria\\n\\n```powershell\\ncmake --build --preset windows-debug\\nctest --preset windows-debug -R \\\"Beam3D2|Timoshenko|RigidBody\\\" --output-on-failure\\nctest --preset windows-debug --output-on-failure\\n```\\n\\n## 검증 절차\\n\\n1. 정식화 문서를 production code보다 먼저 확정한다.\\n2. 실패 테스트를 실행해 가짜 matrix로 통과하지 않음을 확인한다.\\n3. 최소 kernel을 구현하고 focused/full test를 실행한다.\\n4. 식과 코드의 DOF/component 순서를 대조하고 index를 갱신한다.\\n\\n## 금지사항\\n\\n- 닫힌형 가짜 stiffness를 임시로 넣지 마라. 이유: 파이프라인 수치 신뢰성을 훼손한다.\\n- shear term을 2점 적분하지 마라. 이유: 승인된 selective integration과 다르다.\\n- 비선형, 워핑, offset 또는 \\\\(I_{yz}\\\\)를 추가하지 마라. 이유: Phase 1 밖이다.\\n\\r\\n\",\"exit_code\":0,\"status\":\"completed\"}}\n{\"type\":\"item.started\",\"item\":{\"id\":\"item_43\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Raw -Encoding utf8 -LiteralPath 'include/fesa/model/material.hpp'\\\"\",\"aggregated_output\":\"\",\"exit_code\":null,\"status\":\"in_progress\"}}\n{\"type\":\"item.completed\",\"item\":{\"id\":\"item_43\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Raw -Encoding utf8 -LiteralPath 'include/fesa/model/material.hpp'\\\"\",\"aggregated_output\":\"#pragma once\\r\\n\\r\\n#include \\r\\n\\r\\n#include \\r\\n\\r\\nnamespace fesa {\\r\\n\\r\\nstruct IsotropicElastic final {\\r\\n MaterialId id;\\r\\n std::string name;\\r\\n double young;\\r\\n double poisson;\\r\\n};\\r\\n\\r\\n} // namespace fesa\\r\\n\\r\\n\",\"exit_code\":0,\"status\":\"completed\"}}\n{\"type\":\"item.started\",\"item\":{\"id\":\"item_44\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Raw -Encoding utf8 -LiteralPath 'include/fesa/model/beam_section.hpp'\\\"\",\"aggregated_output\":\"\",\"exit_code\":null,\"status\":\"in_progress\"}}\n{\"type\":\"item.completed\",\"item\":{\"id\":\"item_44\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Raw -Encoding utf8 -LiteralPath 'include/fesa/model/beam_section.hpp'\\\"\",\"aggregated_output\":\"#pragma once\\r\\n\\r\\n#include \\r\\n#include \\r\\n#include \\r\\n\\r\\n#include \\r\\n#include \\r\\n\\r\\nnamespace fesa {\\r\\n\\r\\nenum class ShearPropertySource { input, phase1_default };\\r\\n\\r\\nstruct BeamSection final {\\r\\n SectionId id;\\r\\n std::string name;\\r\\n double area;\\r\\n double iy;\\r\\n double iz;\\r\\n double torsion_j;\\r\\n double shear_area_y;\\r\\n double shear_area_z;\\r\\n ShearPropertySource shear_source;\\r\\n Vec3 orientation;\\r\\n std::vector> recovery_points;\\r\\n};\\r\\n\\r\\n} // namespace fesa\\r\\n\\r\\n\",\"exit_code\":0,\"status\":\"completed\"}}\n{\"type\":\"item.started\",\"item\":{\"id\":\"item_45\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Raw -Encoding utf8 -LiteralPath 'CMakeLists.txt'\\\"\",\"aggregated_output\":\"\",\"exit_code\":null,\"status\":\"in_progress\"}}\n{\"type\":\"item.completed\",\"item\":{\"id\":\"item_45\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Raw -Encoding utf8 -LiteralPath 'CMakeLists.txt'\\\"\",\"aggregated_output\":\"cmake_minimum_required(VERSION 3.30)\\r\\n\\r\\nproject(FESA VERSION 0.1.0 LANGUAGES CXX)\\r\\n\\r\\nif(NOT MSVC)\\r\\n message(FATAL_ERROR \\\"FESA requires the Microsoft Visual C++ compiler (MSVC v145).\\\")\\r\\nendif()\\r\\n\\r\\nif(NOT CMAKE_VS_PLATFORM_TOOLSET STREQUAL \\\"v145\\\")\\r\\n message(\\r\\n FATAL_ERROR\\r\\n \\\"FESA requires the v145 platform toolset; configured toolset is \\\"\\r\\n \\\"'${CMAKE_VS_PLATFORM_TOOLSET}'.\\\"\\r\\n )\\r\\nendif()\\r\\n\\r\\nif(NOT CMAKE_GENERATOR_PLATFORM STREQUAL \\\"x64\\\")\\r\\n message(FATAL_ERROR \\\"FESA requires the x64 generator platform.\\\")\\r\\nendif()\\r\\n\\r\\nif(NOT CMAKE_SIZEOF_VOID_P EQUAL 8)\\r\\n message(FATAL_ERROR \\\"FESA requires a 64-bit target.\\\")\\r\\nendif()\\r\\n\\r\\ninclude(CTest)\\r\\ninclude(cmake/FesaDependencies.cmake)\\r\\n\\r\\nadd_library(fesa_core STATIC\\n src/fesa/core/version.cpp\\n src/fesa/fem/beam_frame.cpp\\n src/fesa/fem/dof_manager.cpp\\n src/fesa/fem/gauss_rule.cpp\\n src/fesa/fem/line2_shape.cpp\\n src/fesa/io/abaqus/parser.cpp\\n src/fesa/io/abaqus/semantic_mapper.cpp\\n src/fesa/model/domain.cpp\\n src/fesa/model/domain_builder.cpp\\r\\n)\\r\\n\\r\\ntarget_include_directories(fesa_core\\r\\n PUBLIC\\r\\n \\\"${CMAKE_CURRENT_SOURCE_DIR}/include\\\"\\r\\n)\\r\\n\\r\\ntarget_compile_features(fesa_core PUBLIC cxx_std_20)\\r\\ntarget_compile_options(fesa_core PRIVATE /W4 /permissive- /EHsc)\\r\\n\\r\\nadd_executable(fesa\\r\\n src/fesa/cli/main.cpp\\r\\n)\\r\\n\\r\\ntarget_link_libraries(fesa PRIVATE fesa_core)\\r\\ntarget_compile_features(fesa PRIVATE cxx_std_20)\\r\\ntarget_compile_options(fesa PRIVATE /W4 /permissive- /EHsc)\\r\\n\\r\\nif(BUILD_TESTING)\\r\\n add_subdirectory(tests)\\r\\nendif()\\r\\n\\r\\n\",\"exit_code\":0,\"status\":\"completed\"}}\n{\"type\":\"item.started\",\"item\":{\"id\":\"item_46\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Raw -Encoding utf8 -LiteralPath 'tests/CMakeLists.txt'\\\"\",\"aggregated_output\":\"\",\"exit_code\":null,\"status\":\"in_progress\"}}\n{\"type\":\"item.completed\",\"item\":{\"id\":\"item_46\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Raw -Encoding utf8 -LiteralPath 'tests/CMakeLists.txt'\\\"\",\"aggregated_output\":\"add_test(\\r\\n NAME VersionCommand\\r\\n COMMAND \\\"${CMAKE_BINARY_DIR}/$/fesa.exe\\\" --version\\r\\n)\\r\\n\\r\\nset_tests_properties(\\r\\n VersionCommand\\r\\n PROPERTIES\\r\\n PASS_REGULAR_EXPRESSION \\\"[0-9]+\\\\\\\\.[0-9]+\\\\\\\\.[0-9]+\\\"\\r\\n)\\r\\n\\r\\nadd_executable(fesa_dependency_smoke_test\\r\\n unit/dependencies/dependency_smoke_test.cpp\\r\\n)\\r\\n\\r\\ntarget_compile_features(fesa_dependency_smoke_test PRIVATE cxx_std_20)\\r\\ntarget_compile_options(fesa_dependency_smoke_test PRIVATE /W4 /permissive- /EHsc)\\r\\n\\r\\ntarget_link_libraries(fesa_dependency_smoke_test\\r\\n PRIVATE\\r\\n MKL::MKL\\r\\n TBB::tbb\\r\\n HDF5::HDF5\\r\\n GTest::gtest_main\\r\\n GTest::gtest\\r\\n GTest::gmock\\r\\n)\\r\\n\\r\\nadd_test(\\r\\n NAME DependencySmoke\\r\\n COMMAND \\\"$\\\"\\r\\n)\\r\\n\\r\\nset_property(\\r\\n TEST DependencySmoke\\r\\n PROPERTY ENVIRONMENT_MODIFICATION\\r\\n ${FESA_DEPENDENCY_RUNTIME_MODIFICATIONS}\\r\\n)\\r\\n\\r\\nadd_test(\\r\\n NAME ProductionConfigureWithoutGTest\\r\\n COMMAND\\r\\n \\\"${CMAKE_COMMAND}\\\"\\r\\n --fresh\\r\\n -S \\\"${CMAKE_SOURCE_DIR}\\\"\\r\\n -B \\\"${CMAKE_BINARY_DIR}/testing/production-no-gtest\\\"\\r\\n -G \\\"${CMAKE_GENERATOR}\\\"\\r\\n -A \\\"${CMAKE_GENERATOR_PLATFORM}\\\"\\r\\n -T \\\"${CMAKE_VS_PLATFORM_TOOLSET}\\\"\\r\\n -DBUILD_TESTING=OFF\\r\\n -DCMAKE_DISABLE_FIND_PACKAGE_GTest=TRUE\\r\\n \\\"-DMKL_DIR=${MKL_DIR}\\\"\\r\\n \\\"-DTBB_DIR=${TBB_DIR}\\\"\\r\\n \\\"-DHDF5_DIR=${HDF5_DIR}\\\"\\r\\n)\\r\\n\\r\\nadd_executable(fesa_core_value_tests\\r\\n unit/core/diagnostic_test.cpp\\r\\n unit/core/entity_id_test.cpp\\r\\n unit/core/status_test.cpp\\r\\n unit/core/vec3_test.cpp\\r\\n unit/core/version_test.cpp\\r\\n)\\r\\n\\r\\ntarget_compile_features(fesa_core_value_tests PRIVATE cxx_std_20)\\r\\ntarget_compile_options(fesa_core_value_tests PRIVATE /W4 /permissive- /EHsc)\\r\\n\\r\\ntarget_link_libraries(fesa_core_value_tests\\r\\n PRIVATE\\r\\n fesa_core\\r\\n GTest::gtest_main\\r\\n)\\r\\n\\r\\nadd_test(\\r\\n NAME CoreValueTypes\\r\\n COMMAND \\\"$\\\"\\r\\n)\\r\\n\\r\\nadd_executable(fesa_model_value_tests\\r\\n unit/model/domain_builder_test.cpp\\r\\n unit/model/entity_origin_test.cpp\\r\\n unit/model/model_types_test.cpp\\r\\n)\\r\\n\\r\\ntarget_compile_features(fesa_model_value_tests PRIVATE cxx_std_20)\\r\\ntarget_compile_options(fesa_model_value_tests PRIVATE /W4 /permissive- /EHsc)\\r\\n\\r\\ntarget_link_libraries(fesa_model_value_tests\\r\\n PRIVATE\\r\\n fesa_core\\r\\n GTest::gtest_main\\r\\n)\\r\\n\\r\\nadd_test(\\r\\n NAME ModelTypes\\r\\n COMMAND \\\"$\\\" --gtest_filter=ModelTypes.*\\r\\n)\\r\\n\\r\\nadd_test(\\r\\n NAME EntityOrigin\\r\\n COMMAND \\\"$\\\" --gtest_filter=EntityOrigin.*\\r\\n)\\r\\n\\r\\nadd_test(\\r\\n NAME DomainBuilder\\r\\n COMMAND \\\"$\\\" --gtest_filter=DomainBuilder.*\\r\\n)\\r\\n\\r\\nadd_test(\\r\\n NAME DomainValidation\\r\\n COMMAND \\\"$\\\" --gtest_filter=*DomainValidation*\\r\\n)\\r\\n\\r\\nadd_executable(fesa_abaqus_parser_tests\\r\\n unit/io/abaqus/parser_test.cpp\\r\\n)\\r\\n\\r\\ntarget_compile_features(fesa_abaqus_parser_tests PRIVATE cxx_std_20)\\r\\ntarget_compile_options(fesa_abaqus_parser_tests PRIVATE /W4 /permissive- /EHsc)\\r\\ntarget_compile_definitions(\\r\\n fesa_abaqus_parser_tests\\r\\n PRIVATE\\r\\n FESA_TEST_SOURCE_DIR=\\\"${CMAKE_CURRENT_SOURCE_DIR}\\\"\\r\\n)\\r\\n\\r\\ntarget_link_libraries(fesa_abaqus_parser_tests\\r\\n PRIVATE\\r\\n fesa_core\\r\\n GTest::gtest_main\\r\\n)\\r\\n\\r\\nadd_test(\\r\\n NAME AbaqusParser\\r\\n COMMAND \\\"$\\\"\\r\\n --gtest_filter=AbaqusParser.*\\r\\n)\\r\\n\\r\\nadd_test(\\r\\n NAME ScopedDeck\\r\\n COMMAND \\\"$\\\"\\r\\n --gtest_filter=ScopedDeck.*\\r\\n)\\r\\n\\r\\nadd_executable(fesa_deck_to_domain_tests\\r\\n integration/io/minimal_deck_to_domain_test.cpp\\r\\n)\\r\\n\\r\\ntarget_compile_features(fesa_deck_to_domain_tests PRIVATE cxx_std_20)\\r\\ntarget_compile_options(fesa_deck_to_domain_tests PRIVATE /W4 /permissive- /EHsc)\\r\\ntarget_compile_definitions(\\r\\n fesa_deck_to_domain_tests\\r\\n PRIVATE\\r\\n FESA_TEST_SOURCE_DIR=\\\"${CMAKE_CURRENT_SOURCE_DIR}\\\"\\r\\n)\\r\\n\\r\\ntarget_link_libraries(fesa_deck_to_domain_tests\\r\\n PRIVATE\\r\\n fesa_core\\r\\n GTest::gtest_main\\r\\n)\\r\\n\\r\\nadd_test(\\r\\n NAME DeckToDomain\\r\\n COMMAND \\\"$\\\"\\r\\n --gtest_filter=DeckToDomain.*\\r\\n)\\r\\n\\r\\nadd_test(\\n NAME ActiveInstance\\n COMMAND \\\"$\\\"\\n --gtest_filter=ActiveInstance.*\\n)\\n\\nadd_executable(fesa_fem_primitives_tests\\n unit/fem/beam_frame_test.cpp\\n unit/fem/dof_manager_test.cpp\\n unit/fem/gauss_rule_test.cpp\\n unit/fem/line2_shape_test.cpp\\n)\\n\\ntarget_compile_features(fesa_fem_primitives_tests PRIVATE cxx_std_20)\\ntarget_compile_options(\\n fesa_fem_primitives_tests\\n PRIVATE\\n /W4\\n /permissive-\\n /EHsc\\n)\\n\\ntarget_link_libraries(fesa_fem_primitives_tests\\n PRIVATE\\n fesa_core\\n GTest::gtest_main\\n)\\n\\nadd_test(\\n NAME Quadrature\\n COMMAND \\\"$\\\"\\n --gtest_filter=Quadrature.*\\n)\\n\\nadd_test(\\n NAME ShapeFunction\\n COMMAND \\\"$\\\"\\n --gtest_filter=ShapeFunction.*\\n)\\n\\nadd_test(\\n NAME Jacobian\\n COMMAND \\\"$\\\"\\n --gtest_filter=Jacobian.*\\n)\\n\\nadd_test(\\n NAME DofManager\\n COMMAND \\\"$\\\"\\n --gtest_filter=DofManager.*\\n)\\n\\nadd_test(\\n NAME EquationNumbering\\n COMMAND \\\"$\\\"\\n --gtest_filter=EquationNumbering.*\\n)\\n\\nadd_test(\\n NAME BeamFrame\\n COMMAND \\\"$\\\"\\n --gtest_filter=BeamFrame.*\\n)\\n\\nadd_test(\\n NAME BeamTransformation\\n COMMAND \\\"$\\\"\\n --gtest_filter=BeamTransformation.*\\n)\\n\\r\\n\",\"exit_code\":0,\"status\":\"completed\"}}\n{\"type\":\"item.started\",\"item\":{\"id\":\"item_47\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Raw -Encoding utf8 -LiteralPath 'include/fesa/fem/beam_frame.hpp'\\\"\",\"aggregated_output\":\"\",\"exit_code\":null,\"status\":\"in_progress\"}}\n{\"type\":\"item.completed\",\"item\":{\"id\":\"item_47\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Raw -Encoding utf8 -LiteralPath 'include/fesa/fem/beam_frame.hpp'\\\"\",\"aggregated_output\":\"#pragma once\\n\\n#include \\n#include \\n#include \\n\\n#include \\n#include \\n\\nnamespace fesa {\\n\\nusing Matrix12 = std::array, 12>;\\n\\nstruct BeamFrame final {\\n Vec3 ex;\\n Vec3 ey;\\n Vec3 ez;\\n};\\n\\nstruct BeamFrameResult final {\\n std::optional frame;\\n std::vector diagnostics;\\n};\\n\\n[[nodiscard]] BeamFrameResult make_beam_frame(\\n const Vec3& first,\\n const Vec3& second,\\n const Vec3& orientation);\\n\\n[[nodiscard]] Matrix12 beam_transformation(const BeamFrame& frame);\\n\\n} // namespace fesa\\n\\r\\n\",\"exit_code\":0,\"status\":\"completed\"}}\n{\"type\":\"item.started\",\"item\":{\"id\":\"item_48\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Raw -Encoding utf8 -LiteralPath 'include/fesa/fem/dof_manager.hpp'\\\"\",\"aggregated_output\":\"\",\"exit_code\":null,\"status\":\"in_progress\"}}\n{\"type\":\"item.completed\",\"item\":{\"id\":\"item_48\",\"type\":\"command_execution\",\"command\":\"\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\WindowsPowerShell\\\\\\\\v1.0\\\\\\\\powershell.exe\\\" -Command \\\"Get-Content -Raw -Encoding utf8 -LiteralPath 'include/fesa/fem/dof_manager.hpp'\\\"\",\"aggregated_output\":\"#pragma once\\n\\n#include \\n#include \\n#include \\n#include