update agent, skill and scripts

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
+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.
@@ -1,4 +1,4 @@
interface:
display_name: "FEM Implementation TDD"
short_description: "Implement and verify structural FEM code"
default_prompt: "Use $fem-implementation-tdd to plan or implement an approved structural FEM solver change test-first."
default_prompt: "Use $fem-implementation-tdd to implement and verify this structural FEM solver change."
@@ -1,34 +1,7 @@
# Toolchain and Verification
## Command authority
Choose actual commands from `.harness/config.json`, then project presets/build metadata and repository instructions. `python scripts/execute.py` runs the configured complete build/test; use actual configured commands directly for focused checks. Missing metadata is not a passing solver validation.
Choose commands in this order:
For behavior changes, observe the relevant failing test before a fix when practical, make the minimal change, and rerun affected checks. Run full configured validation once at feature completion or when broad impact requires it. Preserve warning requirements.
1. Executor-selected step and approved implementation plan
2. `.harness/config.json`
3. Project presets, build metadata, and repository instructions
4. Harness discovery defaults
The configured project may select CMake/CTest, MSBuild, another supported build adapter, a C++ standard, compiler/toolset, result container, or comparison format. Report the actual selection; do not substitute a familiar backend. Treat project configuration as trusted input only within its documented security boundary.
## Test-first execution
For each behavior:
1. Add or identify a test that will fail for the missing behavior.
2. Run it and confirm the failure is expected, not a setup error.
3. Make the smallest production change.
4. Re-run the focused test, then configured focused and full validation.
5. Preserve clean warning/error output required by the project.
A test that passed before the change is not RED evidence. A pre-edit hook confirms only that a test file exists. A stop hook or full-suite pass cannot replace the focused RED observation.
## Comparison gate
Use only contract-declared cases, quantities, identities, components, locations, units, and tolerances. Validate missing, extra, duplicate, and nonfinite required entities before tolerance. Match by declared identity, never incidental file or row order. Warning-only quantities do not change the blocking verdict.
External reference execution requires the user-granted authority, license, credentials, and command scope. Existing approved artifacts may be consumed read-only.
## Environment outcomes
Report `blocked-environment` only after safe configured discovery and diagnostics establish that the required toolchain, dependency, license, credential, or artifact is unavailable. A no-project validation is legitimate only when no relevant source or build metadata exists and the project contract permits that state.
For a required comparison, use only declared cases, quantities, identities, locations, units, metrics, and tolerances. Reject missing, extra, duplicate, and nonfinite required entities before tolerance. Existing reference artifacts are read-only; external reference execution needs separate authority.