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

update agent, skill and scripts

Browse Source
This commit is contained in:
KOKO\Mimi
2026-09-07 01:15:26 +09:00
parent 42a4847da5
commit d7e9629640
38 changed files with 476 additions and 2946 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.codex/skills/fem-implementation-tdd/SKILL.md
+5 -43
View File
@@ -1,50 +1,12 @@
---
name: fem-implementation-tdd
description: Use when planning, implementing, correcting, building, testing, or reference-comparing structural FEM solver code under approved upstream contracts.
description: Plan, implement, or correct structural FEM solver code with behavior-focused tests and configured verification.
---
# FEM Implementation TDD
# FEM Implementation
Implement only approved structural-solver behavior and produce reproducible RED/GREEN/verification evidence.
Read the assigned task, directly affected contracts, and repository build configuration. Keep the change minimal and preserve public boundaries, units, ordering, state ownership, deterministic behavior, and fail-closed diagnostics.
## Inputs
For changed behavior, add or update meaningful verification and observe the failure before a bug fix when practical. Then implement the smallest correction and run affected configured checks. Run the configured full build/test once when the solver feature is complete, requested, or needed after broad impact. Required reference comparison must validate identity, quantities, units, row completeness, finite values, metrics, and the approved tolerance; do not alter references or tolerances to pass.
- Project instructions, architecture decisions, and Harness configuration
- Approved requirements, formulation, numerical review, reference model, and I/O contract
- Implementation plan and Executor-selected current step when Harness is active
- Existing implementation and validation reports when correcting a failure
## Workflow
1. For planning, map every requirement to bounded tasks, tests, commands, dependencies, and owned files. Leave critical upstream choices unresolved and return them to their owner.
2. For execution, change only the selected step. Write one focused test, run it, and observe the expected failure before production code.
3. Implement the minimum change; run the focused test, configured build/test suite, and declared comparison gates.
4. Classify failures as `configure`, `compile`, `link`, `test`, `reference-comparison`, `harness`, `environment`, or `upstream-contract`. Fix implementation-owned failures; route the rest.
5. Update only artifacts and status fields owned by the current role. The Executor owns step selection, transport/session retry, timestamps, commits, and phase advancement. The Coordinator owns normalized `retry_key` state, correction attempts, and the workflow retry budget.
Read [toolchain and verification](references/toolchain-and-verification.md) before choosing commands. Use [evidence and handoff](../fem-requirements-baseline/references/evidence-and-handoff.md) for reports and [workflow and decision authority](../fem-requirements-baseline/references/workflow-and-decisions.md) for escalation.
## Output
Follow [Feature document management](../../../docs/FEATURE_DOCUMENTATION.md): read the Coordinator's
feature context, keep main reports concise, and link necessary owned details in the same feature folder.
Produce the applicable canonical artifacts:
- `docs/<feature-id>/implementation-plan.md`
- `docs/<feature-id>/implementation-report.md`
- `docs/<feature-id>/build-test.md`
- `docs/<feature-id>/reference-comparison.md`
- `docs/<feature-id>/corrections.md`
Each task and test traces to requirement IDs and owned files. Create only artifacts applicable to the dispatched role and completed gate.
## Evidence
Record the RED failure reason, GREEN result, exact commands, exit codes, duration, relevant output, environment/config selection, changed artifacts and hashes, comparison prechecks and tolerance source, failure classification, assumptions, and residual risk.
## Boundary
Never write production behavior before observing the corresponding test fail. Hooks are guardrails, not RED evidence. Do not change requirements, formulations, I/O contracts, tolerances, or reference artifacts to make tests pass. Do not run licensed external solvers, publish, deploy, or perform destructive version-control operations without explicit authorization.
If the same retry key fails after the coordinator's bounded correction cycle, return the failure; do not loop or broaden scope.
Read [toolchain-and-verification.md](references/toolchain-and-verification.md) when selecting configured commands or evaluating comparison evidence. Return changed files, commands and exit codes, decisive results, and blockers. Do not require phase files, automatic Git actions, or a formal RED/GREEN report for harmless refactors with sufficient coverage.