modify documents
This commit is contained in:
KOKO\Mimi
@@ -0,0 +1,39 @@
|
||||
---
|
||||
name: fem-formulation-spec
|
||||
description: Use when an approved structural FEM feature needs an implementation-ready mathematical formulation before numerical review or coding.
|
||||
---
|
||||
|
||||
# FEM Formulation Specification
|
||||
|
||||
Translate approved requirements and research into a complete mathematical contract, independent of programming APIs and storage formats.
|
||||
|
||||
## Inputs
|
||||
|
||||
- `docs/<feature-id>/requirements.md`
|
||||
- `docs/<feature-id>/research.md`
|
||||
- Governing standards and approved analysis assumptions
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Fix primary variables, degrees of freedom, units, coordinates, signs, configuration, and boundary-condition conventions.
|
||||
2. Derive governing strong and weak forms with all natural and essential boundary terms.
|
||||
3. Define discretization, interpolation, kinematics, constitutive update contract, element residual/internal and external forces, and consistent tangent or stiffness.
|
||||
4. Define mapping, Jacobian validity, quadrature, state/history evolution, constraints, and result recovery that apply to the selected analysis family.
|
||||
5. State dimensions, invariants, algorithm pseudocode, numerical risks, and tests capable of falsifying each derivation.
|
||||
|
||||
Read [analysis-family guidance](references/analysis-families.md) and apply only the sections selected by the requirements. Use [workflow and decision authority](../fem-requirements-baseline/references/workflow-and-decisions.md) for unresolved physics choices and [evidence and handoff](../fem-requirements-baseline/references/evidence-and-handoff.md) for return data.
|
||||
|
||||
## 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.
|
||||
|
||||
Create or revise `docs/<feature-id>/formulation.md` with assumptions; variables; strong/weak forms; discretization; kinematics; constitutive contract; element equations; integration; algorithms; recovery; numerical risks; verification implications; and handoff.
|
||||
|
||||
## Evidence
|
||||
|
||||
Every equation defines symbols, dimensions, configuration, sign, coordinate basis, and source or derivation. Show linearization when a consistent tangent is required. Link risks and checks to requirement IDs.
|
||||
|
||||
## Boundary
|
||||
|
||||
Do not design source-level APIs, parsers, storage schemas, or implementation tasks. Do not silently choose physics, stabilization, interpolation, constitutive behavior, or solver semantics outside the approved contract; return that critical choice for decision.
|
||||
@@ -0,0 +1,4 @@
|
||||
interface:
|
||||
display_name: "FEM Formulation Specification"
|
||||
short_description: "Specify structural FEM mathematics"
|
||||
default_prompt: "Use $fem-formulation-spec to specify the mathematics for an approved structural FEM feature."
|
||||
@@ -0,0 +1,33 @@
|
||||
# Structural Analysis Family Guidance
|
||||
|
||||
Read only the family selected by the approved requirements. Coupled features apply each relevant section and define the coupling terms explicitly.
|
||||
|
||||
## Common
|
||||
|
||||
Check DOF ordering, boundary conditions, units, coordinate transforms, rigid-body modes, element orientation, residual convention, output location, and conservation or equilibrium identities.
|
||||
|
||||
## Linear static
|
||||
|
||||
Define linearization assumptions, stiffness symmetry expectations, load assembly, constraint treatment, reactions, patch tests, rigid-body/null-space checks, and mesh-convergence quantities.
|
||||
|
||||
## Nonlinear static
|
||||
|
||||
Define configuration and strain/stress measures, state update, residual and consistent tangent, load/time parameter, convergence norms, increment/cutback behavior, path dependence, and energy or work checks.
|
||||
|
||||
## Modal, eigenvalue, and buckling
|
||||
|
||||
Define matrix problem, boundary conditions, mass or geometric stiffness, eigensolver target, normalization, repeated-mode handling, sign/phase invariance, residual norms, and mode correlation. Distinguish linearized buckling from nonlinear collapse.
|
||||
|
||||
## Dynamics
|
||||
|
||||
Define mass and damping, initial conditions, time integration, stability and algorithmic dissipation, load history, time-step convergence, energy balance, frequency/phase measures, and modal truncation where applicable.
|
||||
|
||||
## Contact and constraints
|
||||
|
||||
Define gap and normal orientation, active-set/search semantics, normal and tangential laws, enforcement method, consistent contributions, state transitions, penetration/slip measures, and action-reaction checks.
|
||||
|
||||
## Material nonlinearity
|
||||
|
||||
Define admissible state, yield/failure surface, flow/evolution laws, integration algorithm, consistent material tangent, history initialization, loading/unloading cases, and single-point constitutive tests.
|
||||
|
||||
Do not apply an irrelevant checklist merely for completeness. If the family is ambiguous and the choice changes physical meaning or acceptance, return `needs-user-decision`.
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
name: fem-implementation-tdd
|
||||
description: Use when planning, implementing, correcting, building, testing, or reference-comparing structural FEM solver code under approved upstream contracts.
|
||||
---
|
||||
|
||||
# FEM Implementation TDD
|
||||
|
||||
Implement only approved structural-solver behavior and produce reproducible RED/GREEN/verification evidence.
|
||||
|
||||
## Inputs
|
||||
|
||||
- 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.
|
||||
@@ -0,0 +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."
|
||||
@@ -0,0 +1,34 @@
|
||||
# Toolchain and Verification
|
||||
|
||||
## Command authority
|
||||
|
||||
Choose commands in this order:
|
||||
|
||||
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.
|
||||
@@ -0,0 +1,39 @@
|
||||
---
|
||||
name: fem-io-contract
|
||||
description: Use when an approved structural FEM feature needs external syntax, validation, internal mapping, result schema, or comparison identity contracts.
|
||||
---
|
||||
|
||||
# FEM I/O Contract
|
||||
|
||||
Turn approved requirements, mathematics, and logical verification quantities into deterministic interfaces without changing their meaning.
|
||||
|
||||
## Inputs
|
||||
|
||||
- Requirements, formulation, numerical review, and reference-model contracts for one `feature_id`
|
||||
- Project architecture and configured input, output, and comparison backends
|
||||
- Official specifications for any approved compatibility subset
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Define the supported external syntax and semantics, defaults, ordering, identifiers, units, coordinates, validation, diagnostics, and unsupported behavior.
|
||||
2. Map validated input to implementation-neutral model entities while preserving source identity.
|
||||
3. Define result schema versioning, analysis step/frame identity, quantities, components, locations, units, coordinates, precision, and deterministic ordering.
|
||||
4. Map logical verification quantities to result and reference identities. Specify missing, extra, duplicate, and nonfinite prechecks before tolerance evaluation.
|
||||
5. Add parser, schema, round-trip, migration, and comparison contract tests.
|
||||
|
||||
Use [workflow and decision authority](../fem-requirements-baseline/references/workflow-and-decisions.md) when a format choice changes public compatibility. Use [evidence and handoff](../fem-requirements-baseline/references/evidence-and-handoff.md) for return data.
|
||||
|
||||
## 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.
|
||||
|
||||
Create or revise `docs/<feature-id>/io.md` with input scope; grammar/semantic rules; validation matrix; internal mapping; output schema; comparison mapping; compatibility/versioning policy; test obligations; limitations; and handoff.
|
||||
|
||||
## Evidence
|
||||
|
||||
Trace every public field and mapping to a requirement, formulation quantity, numerical-review identity, or authoritative selected-format specification. Include positive and negative examples only where they disambiguate behavior.
|
||||
|
||||
## Boundary
|
||||
|
||||
Do not claim full compatibility from a subset, infer undocumented reference-product behavior, alter the formulation, redefine logical acceptance quantities, change tolerances, implement code, modify reference artifacts, or run an external solver. Input syntax, result containers, and tabular comparison formats are project-selected contracts, not mandatory solver identity.
|
||||
@@ -0,0 +1,4 @@
|
||||
interface:
|
||||
display_name: "FEM I/O Contract"
|
||||
short_description: "Define structural FEM interface contracts"
|
||||
default_prompt: "Use $fem-io-contract to define deterministic interfaces for an approved structural FEM feature."
|
||||
@@ -0,0 +1,41 @@
|
||||
---
|
||||
name: fem-numerical-review
|
||||
description: Use when independently reviewing a structural FEM formulation, stability risks, and verification-case readiness before interface definition or implementation.
|
||||
---
|
||||
|
||||
# FEM Numerical Review
|
||||
|
||||
Issue an independent, findings-first verdict on whether the mathematical contract and logical verification coverage are ready downstream.
|
||||
|
||||
## Inputs
|
||||
|
||||
- Requirements, research, and formulation for one `feature_id`
|
||||
- Existing reference cases and artifacts, read-only
|
||||
- `docs/TOLERANCE.md` and approved compatibility policies
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Check dimensions, signs, DOF order, transformations, kinematics, constitutive update, mapping, quadrature, residual, loads, tangent consistency, symmetry, null spaces, conditioning, and family-specific stability risks.
|
||||
2. Check each requirement has a falsifiable unit, element, integration, benchmark, convergence, or reference-comparison case.
|
||||
3. Inventory only approved reference cases. Under `docs/TOLERANCE.md`, autonomously select and justify quantity, identity/component, metric, scale and near-zero treatment, blocking/diagnostic class, and numerical tolerance from analytical, convergence, or reference evidence. Define locations, units, coordinates, and entity prechecks without selecting a physical file schema.
|
||||
4. Lead with defects and severity. Return missing derivations to formulation and missing evidence to research; do not repair upstream artifacts in place.
|
||||
|
||||
Read the applicable [analysis-family guidance](../fem-formulation-spec/references/analysis-families.md). Use [workflow and decision authority](../fem-requirements-baseline/references/workflow-and-decisions.md) for escalation and [evidence and handoff](../fem-requirements-baseline/references/evidence-and-handoff.md) for the verdict.
|
||||
|
||||
## 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.
|
||||
|
||||
Create or revise:
|
||||
|
||||
- `docs/<feature-id>/numerical-review.md`: verdict, findings, risks, consistency checks, verification readiness, required revisions, and handoff.
|
||||
- `docs/<feature-id>/reference-model.md`: logical acceptance scope, case inventory, identity/component contract, metric, scale, blocking class, tolerance value/source, prechecks, contract revision, limitations, and I/O handoff.
|
||||
|
||||
## Evidence
|
||||
|
||||
Tie every finding and tolerance choice to an equation, requirement, source, case, convergence result, or reproducible calculation. Record the feature contract revision and preserve prior failing evidence when a tolerance changes. Separate confirmed defects, risks, recommendations, and unresolved decisions. A pass means ready for I/O definition, not feature completion.
|
||||
|
||||
## Boundary
|
||||
|
||||
Do not edit the formulation, implement code, choose APIs or dataset paths, modify or generate reference artifacts, relax a tolerance merely to pass an implementation result, decide final comparison success, or approve release. A missing noncritical naming convention is not a numerical blocker.
|
||||
@@ -0,0 +1,4 @@
|
||||
interface:
|
||||
display_name: "FEM Numerical Review"
|
||||
short_description: "Review structural FEM numerical readiness"
|
||||
default_prompt: "Use $fem-numerical-review to independently review a structural FEM formulation and its verification readiness."
|
||||
@@ -0,0 +1,38 @@
|
||||
---
|
||||
name: fem-physics-review
|
||||
description: Use when validated structural FEM results need an independent physical-plausibility review before release-readiness evaluation.
|
||||
---
|
||||
|
||||
# FEM Physics Review
|
||||
|
||||
Determine whether numerically passing results also satisfy the documented physical behavior of the modeled problem.
|
||||
|
||||
## Inputs
|
||||
|
||||
- Requirements, formulation, numerical review, reference model, and I/O contract
|
||||
- Passing implementation-owned build/test and comparison evidence required by the feature
|
||||
- Solver outputs and approved reference artifacts, read-only
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Confirm prerequisite evidence is passing, current, and tied to the same `feature_id` and contract revision.
|
||||
2. Evaluate only documented expectations: global equilibrium, reactions, deformation direction/mode, symmetry or zeros, internal-force balance, stress/strain signs and coordinates, conservation, residuals, energy, and family-specific behavior.
|
||||
3. Check coverage is sufficient for the claimed feature scope; distinguish a solver defect from formulation, I/O, acceptance-model, or evidence gaps.
|
||||
4. Report findings before the verdict and route each failure to its owning stage.
|
||||
|
||||
Read the applicable [analysis-family guidance](../fem-formulation-spec/references/analysis-families.md). Use [evidence and handoff](../fem-requirements-baseline/references/evidence-and-handoff.md) for the verdict and [workflow and decision authority](../fem-requirements-baseline/references/workflow-and-decisions.md) for missing physical expectations.
|
||||
|
||||
## 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.
|
||||
|
||||
Create or revise `docs/<feature-id>/physics-evaluation.md` with evidence identity, checks and expected relations, observed results, failure classification, coverage assessment, verdict, residual risks, and handoff.
|
||||
|
||||
## Evidence
|
||||
|
||||
Each check states its governing relation or approved expectation, data source, units/coordinates, calculation, tolerance source where applicable, and pass/fail result. Explain why a check is inapplicable rather than silently omitting it.
|
||||
|
||||
## Boundary
|
||||
|
||||
Do not edit code, tests, requirements, formulations, I/O contracts, reference models, reference artifacts, or tolerances. Do not invent extra acceptance gates, approve numerical comparison, run external solvers, or approve release. A physics pass means ready for release-readiness audit only.
|
||||
@@ -0,0 +1,4 @@
|
||||
interface:
|
||||
display_name: "FEM Physics Review"
|
||||
short_description: "Review structural FEM physical plausibility"
|
||||
default_prompt: "Use $fem-physics-review to evaluate the physical plausibility of validated structural FEM results."
|
||||
@@ -0,0 +1,39 @@
|
||||
---
|
||||
name: fem-release-readiness
|
||||
description: Use when a structural FEM solver feature has completed technical gates and needs an evidence-based release-readiness audit.
|
||||
---
|
||||
|
||||
# FEM Release Readiness
|
||||
|
||||
Audit closure evidence and prepare a release recommendation without modifying technical contracts or performing a release.
|
||||
|
||||
## Inputs
|
||||
|
||||
- All lifecycle artifacts for one `feature_id` and contract revision
|
||||
- Passing configured full validation and required comparison evidence
|
||||
- Passing physics review
|
||||
- Correction history, accepted risks, and project release policy
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Inventory required artifacts and verify identity, revision, freshness, ownership, outcome, and absence of contradictions.
|
||||
2. Trace every blocking requirement through acceptance criteria, implementation/tests, required numerical or reference evidence, physics review, and final disposition.
|
||||
3. Confirm unresolved defects, deferred scope, compatibility limits, unsupported behavior, accepted risks, and environment limits are explicit.
|
||||
4. Produce the checklist, known limitations, release-notes draft, and readiness verdict. Return missing or failed evidence to its owning stage.
|
||||
|
||||
Use [evidence and handoff](../fem-requirements-baseline/references/evidence-and-handoff.md) to validate stage envelopes. Read [toolchain and verification](../fem-implementation-tdd/references/toolchain-and-verification.md) when auditing command or comparison evidence. Use [workflow and decision authority](../fem-requirements-baseline/references/workflow-and-decisions.md) for release-scope decisions.
|
||||
|
||||
## 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.
|
||||
|
||||
Create or revise `docs/<feature-id>/release.md` with release scope, gate inventory, requirement traceability, validation summary, known limitations, deferred items, release-notes draft, readiness verdict, residual risks, and handoff.
|
||||
|
||||
## Evidence
|
||||
|
||||
A ready verdict requires complete, passing, current evidence for every blocking gate. Record artifact paths and hashes, configuration/toolchain identity, test and comparison summaries, approved exceptions, and the exact contract revision audited.
|
||||
|
||||
## Boundary
|
||||
|
||||
Do not implement or correct code, edit tests or upstream contracts, waive missing evidence, change acceptance or tolerance, or reinterpret a failed gate. Do not commit, tag, package, publish, deploy, or externally release anything unless the user explicitly authorizes that separate action. Readiness is a recommendation, not publication approval.
|
||||
@@ -0,0 +1,4 @@
|
||||
interface:
|
||||
display_name: "FEM Release Readiness"
|
||||
short_description: "Audit structural FEM release readiness"
|
||||
default_prompt: "Use $fem-release-readiness to audit release readiness for a completed structural FEM solver feature."
|
||||
@@ -0,0 +1,38 @@
|
||||
---
|
||||
name: fem-requirements-baseline
|
||||
description: Use when baselining a finite-element structural solver feature before research, formulation, interface definition, or implementation planning.
|
||||
---
|
||||
|
||||
# FEM Requirements Baseline
|
||||
|
||||
Turn a structural-analysis solver request into a stable, verifiable contract without choosing downstream mathematics or implementation.
|
||||
|
||||
## Inputs
|
||||
|
||||
- Project instructions and architecture decisions
|
||||
- User request, constraints, exclusions, and existing feature artifacts
|
||||
- Applicable standards or compatibility commitments already selected by the project
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Use the stable kebab-case `feature_id` and feature folder supplied by Coordinator; define purpose, scope, exclusions, analysis family, assumptions, units, coordinates, and compatibility boundary.
|
||||
2. Write atomic `FEM-REQ-<FEATURE>-###` shall-statements. Give each an observable acceptance criterion and verification method.
|
||||
3. Define logical verification quantities and required physical behavior. Preserve acceptance fixed by the user or an applicable standard; otherwise delegate quantity details, metric, scale, blocking class, and numerical tolerance to Numerical Review under `docs/TOLERANCE.md`.
|
||||
4. Build the requirement-verification matrix and classify open issues using the project workflow.
|
||||
|
||||
Read [workflow and decision authority](references/workflow-and-decisions.md) when resolving ambiguity or deciding whether user input is critical. Use [evidence and handoff](references/evidence-and-handoff.md) for the returned envelope.
|
||||
|
||||
## 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.
|
||||
|
||||
Create or revise `docs/<feature-id>/requirements.md` with metadata, scope, analysis definition, requirements, acceptance criteria, verification intent, compatibility boundary, matrix, open decisions, and handoff.
|
||||
|
||||
## Evidence
|
||||
|
||||
Every requirement traces to its source and an acceptance method. Numerical outputs state quantity, location, units, coordinates, and tolerance source when applicable.
|
||||
|
||||
## Boundary
|
||||
|
||||
Do not derive the formulation, select a numerical algorithm, design APIs or storage schemas, implement code, calibrate tolerances, or claim compatibility beyond the approved boundary. Route missing theory, reference evidence, or physical acceptance choices to their owning stage.
|
||||
@@ -0,0 +1,4 @@
|
||||
interface:
|
||||
display_name: "FEM Requirements Baseline"
|
||||
short_description: "Baseline verifiable structural FEM requirements"
|
||||
default_prompt: "Use $fem-requirements-baseline to define verifiable requirements for a structural FEM solver feature."
|
||||
@@ -0,0 +1,26 @@
|
||||
# Evidence and Handoff Contract
|
||||
|
||||
Use [Feature document management](../../../../docs/FEATURE_DOCUMENTATION.md) for concise main reports,
|
||||
linked details, and Coordinator's document inventory. Include main and required detail paths in evidence.
|
||||
|
||||
Every stage returns one envelope:
|
||||
|
||||
| Field | Required content |
|
||||
| --- | --- |
|
||||
| `feature_id` | Stable feature identifier |
|
||||
| `stage` | `requirements`, `research`, `formulation`, `numerical-review`, `io-definition`, `implementation-planning`, `implementation`, `correction`, `physics-evaluation`, or `release-readiness` |
|
||||
| `outcome` | `pass`, `return-upstream`, `retry`, `blocked-environment`, or `needs-user-decision` |
|
||||
| `next_owner` | Agent id, or YAML `null` |
|
||||
| `evidence_paths` | Repository-relative artifacts used or produced |
|
||||
| `evidence_digest` | Concise findings tied to requirement IDs |
|
||||
| `failure_classification` | `configure`, `compile`, `link`, `test`, `reference-comparison`, `harness`, `environment`, `upstream-contract`, `physics`, `evidence`, or YAML `null` |
|
||||
| `retry_key` | `<feature-id>\|<failing-gate>\|<classification>\|<contract-revision>`, or YAML `null` |
|
||||
| `attempt` | Coordinator-managed nonnegative attempt count for the retry key |
|
||||
| `escalation_class` | Critical-decision class, or YAML `null` |
|
||||
| `blocker` | Actionable blocker, or YAML `null` |
|
||||
|
||||
Evidence records include, when applicable: source locator and access date; assumptions; command, exit code, duration, and relevant output; test identity and RED/GREEN result; artifact hash; comparison quantity, tolerance source, and decision; residual risk.
|
||||
|
||||
Use repository-relative paths and stable identifiers. Distinguish observed facts, calculations, inferences, and decisions. Never report a pass when a required command failed, evidence is stale, or a blocking acceptance item is unresolved.
|
||||
|
||||
Retry is bounded by the coordinator policy. A repeated normalized failure returns to its owning stage; it does not justify changing requirements, formulations, schemas, reference artifacts, or tolerances.
|
||||
@@ -0,0 +1,33 @@
|
||||
# Workflow and Decision Authority
|
||||
|
||||
## Authority order
|
||||
|
||||
Use the first applicable authority:
|
||||
|
||||
1. Approved feature contract and explicit user decisions
|
||||
2. Governing physics, mathematics, standards, and safety obligations
|
||||
3. Official documentation and verification cases for a project-selected reference product or format
|
||||
4. Repository architecture decisions, configuration, and established conventions
|
||||
5. The simplest deterministic choice that preserves the authorities above
|
||||
|
||||
A commercial solver is a behavioral reference only when the project contract selects it. Its public input semantics, output definitions, documented procedures, and verification examples may support decisions; never infer undocumented internals or claim implementation equivalence.
|
||||
|
||||
## Autonomous decisions
|
||||
|
||||
Proceed without user review for reversible choices within approved contracts: internal naming and data layout, test organization, diagnostics, equivalent implementation mechanics, documentation formatting, and correction of clear build or test defects. Record assumptions that affect interpretation.
|
||||
|
||||
## User decisions
|
||||
|
||||
Return `needs-user-decision` only for a choice that changes at least one of:
|
||||
|
||||
- supported physics, formulation meaning, or analysis scope;
|
||||
- public compatibility or an authoritative I/O schema;
|
||||
- acceptance choices where reasonable criteria split the same evidence between pass and fail and change product acceptance or a public accuracy promise, or where authoritative requirements and reference evidence cannot be reconciled technically;
|
||||
- a material security/trust-boundary or credential-handling change, or acceptance of an unresolved security, legal, licensing, or compliance risk;
|
||||
- external reference-solver execution, destructive history changes, publication, deployment, or release.
|
||||
|
||||
Everything else follows the authority order. Lack of a preference is not a blocker when a deterministic in-contract choice exists.
|
||||
|
||||
## Contract flow
|
||||
|
||||
Requirements own acceptance intent; research owns evidence; formulation owns mathematics; numerical review owns independent numerical findings and logical verification coverage; I/O owns external/internal mappings; implementation owns code and tests; physics review owns physical plausibility; release review owns closure evidence. A downstream stage returns a defect to the owning upstream stage instead of silently rewriting its contract.
|
||||
@@ -0,0 +1,38 @@
|
||||
---
|
||||
name: fem-research-evidence
|
||||
description: Use when a structural FEM feature needs source-backed theory, benchmark, verification, or reference-convention evidence before formulation.
|
||||
---
|
||||
|
||||
# FEM Research Evidence
|
||||
|
||||
Build an auditable evidence brief while keeping documented fact, calculation, inference, and unresolved questions distinct.
|
||||
|
||||
## Inputs
|
||||
|
||||
- `docs/<feature-id>/requirements.md`
|
||||
- Project instructions and user-supplied sources
|
||||
- Existing research brief and reference artifacts, read-only
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Derive research questions from requirement IDs and open decisions.
|
||||
2. Prefer governing standards, primary literature, authoritative textbooks, and official vendor documentation; record reliability and applicability.
|
||||
3. Summarize only the theory needed downstream. Identify analytical solutions, patch tests, convergence studies, manufactured solutions, and published benchmarks appropriate to the analysis family.
|
||||
4. State what each source or case can and cannot verify. Mark unsupported claims as inference or evidence gaps.
|
||||
|
||||
When a configured FEM vault is the requested evidence source, use `fem-theory-query`. Apply [workflow and decision authority](../fem-requirements-baseline/references/workflow-and-decisions.md) to product references and [evidence and handoff](../fem-requirements-baseline/references/evidence-and-handoff.md) to the result.
|
||||
|
||||
## 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.
|
||||
|
||||
Create or revise `docs/<feature-id>/research.md` with research questions, source inventory and reliability, theory findings, candidate verification cases, applicability limits, conflicts, gaps, and downstream handoff.
|
||||
|
||||
## Evidence
|
||||
|
||||
Trace every material claim to a stable locator. For a project-selected reference solver or format, use official public documentation for observable syntax, semantics, output, or procedure only. Record edition/version and access date when behavior can vary.
|
||||
|
||||
## Boundary
|
||||
|
||||
Do not finalize the mathematical formulation, set tolerance values, design APIs or schemas, implement code, alter reference artifacts, or run an external licensed solver without explicit authorization. Do not treat agreement with one product as proof of correctness or infer its undocumented internals.
|
||||
@@ -0,0 +1,4 @@
|
||||
interface:
|
||||
display_name: "FEM Research Evidence"
|
||||
short_description: "Collect structural FEM research evidence"
|
||||
default_prompt: "Use $fem-research-evidence to build a source-backed evidence brief for a structural FEM feature."
|
||||
@@ -0,0 +1 @@
|
||||
vault-path.txt
|
||||
@@ -1,141 +1,45 @@
|
||||
---
|
||||
name: fem-theory-query
|
||||
description: Use when answering finite element method, structural analysis solver, element formulation, residual/tangent, constitutive integration, contact, dynamics, eigenproblem, or verification questions from a configured FEM wiki vault.
|
||||
description: Use when the user requests a finite-element structural-analysis answer grounded in a configured FEM wiki vault, or asks to identify a gap in that vault.
|
||||
---
|
||||
|
||||
# FEM Theory Query
|
||||
|
||||
Use this skill as a portable domain router for finite element method and structural solver theory questions. Ground answers in a configured FEM wiki vault, then compose sibling skills instead of reimplementing their workflows.
|
||||
Answer from configured vault evidence and clearly separate vault knowledge from gaps. Do not activate for ordinary FEM questions that do not request or require vault grounding.
|
||||
|
||||
## FEM Vault Resolution
|
||||
## Inputs
|
||||
|
||||
Resolve the FEM wiki vault in this order:
|
||||
- User question and explicit need for configured-vault evidence
|
||||
- Resolved vault root, index, relevant pages, and optional companion-skill instructions
|
||||
|
||||
1. Skill-local config file: `vault-path.txt` in this skill folder. Read the first non-empty, non-comment line as the vault root path.
|
||||
2. Current project instructions: `AGENTS.md`, `CLAUDE.md`, or an equivalent section named `FEM Solver Theory Wiki`.
|
||||
3. Environment variable: `FEM_THEORY_WIKI_VAULT`.
|
||||
## Vault Resolution
|
||||
|
||||
If no valid vault is found, ask the user for the vault path. A valid vault must contain `wiki/hot.md` or `wiki/index.md`.
|
||||
Resolve the first valid root containing `wiki/hot.md` or `wiki/index.md`:
|
||||
|
||||
Keep `vault-path.txt` PC-specific. When the vault moves, update that file instead of editing this skill body.
|
||||
1. `FEM_THEORY_WIKI_VAULT` environment variable
|
||||
2. A `FEM Solver Theory Wiki` path in project instructions
|
||||
3. Optional skill-local `vault-path.txt`
|
||||
|
||||
## Companion Skill Protocols
|
||||
`vault-path.txt` is a machine-local, untracked override created from `vault-path.example.txt`; never commit a workstation path. If no root resolves, report the missing configuration and ask for a path rather than answering as though it came from the vault.
|
||||
|
||||
This skill is an orchestrator. Do not reimplement sibling skills. Use the sibling skill instructions as authoritative when available.
|
||||
## Workflow
|
||||
|
||||
### Companion skill path resolution
|
||||
1. Read `<vault>/wiki/hot.md`; use the vault retrieval command when its own instructions provide one, otherwise read `wiki/index.md`.
|
||||
2. Read the smallest sufficient set of relevant pages, normally three to seven.
|
||||
3. For nontrivial derivation, solver design, ambiguity, or verification design, follow `<vault>/skills/think/SKILL.md` when present.
|
||||
4. Follow `<vault>/skills/wiki-query/SKILL.md` when present. Resolve its relative links from that companion skill directory and keep them inside the vault.
|
||||
5. Synthesize in the user's language with `[[Page Name]]` citations on core technical claims. Label inference and missing coverage explicitly.
|
||||
|
||||
After reading `vault-path.txt`, call that value `FEM_VAULT_ROOT`. Resolve companion skill files from that absolute vault root:
|
||||
Use `<vault>/skills/autoresearch/SKILL.md` only when the user explicitly requests external research or vault updates. That work may use the web or write to the vault only within the user's authorization and the companion skill's safety rules.
|
||||
|
||||
- `FEM_VAULT_ROOT\skills\think\SKILL.md`: use for non-trivial FEM formulation, solver architecture, ambiguity, tradeoffs, verification design, or gap assessment.
|
||||
- `FEM_VAULT_ROOT\skills\wiki-query\SKILL.md`: use for normal wiki-grounded answers from the configured FEM vault.
|
||||
- `FEM_VAULT_ROOT\skills\autoresearch\SKILL.md`: use only when the user explicitly asks to research, find sources, update the wiki, or fill missing wiki coverage.
|
||||
## Output
|
||||
|
||||
If the runtime provides a skill activation mechanism, activate the companion skill by name. If not, read the absolute companion `SKILL.md` path constructed from `vault-path.txt` and follow its workflow. If an absolute companion path does not exist, tell the user which path is missing and ask them to fix `vault-path.txt`.
|
||||
Lead with the conclusion, then include only relevant formulation, implementation implications, verification, evidence, and vault-gap sections. Short factual questions do not require every section.
|
||||
|
||||
### Relative paths inside companion skills
|
||||
## Evidence
|
||||
|
||||
When a companion skill refers to another file by a relative path, resolve that path from the absolute directory of the companion skill file under `FEM_VAULT_ROOT`, not from the caller project or current working directory. Normalize `..` segments after joining paths. Keep the resolved path inside `FEM_VAULT_ROOT` unless the companion skill explicitly requires an external path.
|
||||
Every core claim traces to a vault page. Cite conflicting pages and explain the conflict; do not silently replace vault evidence with model memory.
|
||||
|
||||
Examples from `FEM_VAULT_ROOT\skills\autoresearch\SKILL.md`:
|
||||
## Boundary
|
||||
|
||||
- `../wiki-cli/SKILL.md` resolves to `FEM_VAULT_ROOT\skills\wiki-cli\SKILL.md`.
|
||||
- `../../wiki/references/transport-fallback.md` resolves to `FEM_VAULT_ROOT\wiki\references\transport-fallback.md`.
|
||||
- `references/program.md` resolves to `FEM_VAULT_ROOT\skills\autoresearch\references\program.md`.
|
||||
|
||||
If a resolved companion-relative path is missing, report the missing absolute path and ask the user to fix `vault-path.txt` or install the full `skills/` bundle.
|
||||
|
||||
### How to use `think`
|
||||
|
||||
Use `think` as a compact internal preflight before answering FEM solver questions.
|
||||
|
||||
Do:
|
||||
- Identify the user's real question: theory derivation, implementation design, verification, comparison, or missing source.
|
||||
- Check whether you are relying on memory instead of wiki evidence.
|
||||
- Decide whether the answer can be handled by wiki query or needs autoresearch.
|
||||
- For complex questions, surface the reasoning structure briefly in the answer.
|
||||
|
||||
Do not:
|
||||
- Print all 10 stages for routine factual questions.
|
||||
- Use `think` as a substitute for reading wiki sources.
|
||||
- Skip the `ACCEPT` step when the wiki has insufficient coverage.
|
||||
|
||||
### How to use `wiki-query`
|
||||
|
||||
Use `wiki-query` for the default answer path.
|
||||
|
||||
Follow this order:
|
||||
|
||||
1. Resolve the FEM vault path.
|
||||
2. Read `wiki/hot.md`.
|
||||
3. If needed, use `wiki-retrieve` when provisioned: `python scripts/retrieve.py "<question>" --top 5`.
|
||||
4. If retrieval is not provisioned or fails, read `wiki/index.md`.
|
||||
5. Read 3-7 relevant wiki pages.
|
||||
6. Synthesize with Obsidian wikilink citations.
|
||||
|
||||
Do:
|
||||
- Cite every core claim with `[[Page Name]]`.
|
||||
- Prefer vault evidence over model memory.
|
||||
- Say clearly when the wiki lacks enough evidence.
|
||||
|
||||
Do not:
|
||||
- Answer a vault-specific question from training data alone.
|
||||
- Open many pages when 3-7 are enough.
|
||||
- Write to the wiki unless the user explicitly asks.
|
||||
|
||||
### How to use `autoresearch`
|
||||
|
||||
Use `autoresearch` only for explicit research or wiki-expansion requests.
|
||||
|
||||
Trigger examples:
|
||||
- "Find sources and strengthen this wiki coverage."
|
||||
- "If the wiki does not cover this, research it."
|
||||
- "Research and file this topic."
|
||||
- "Create source and concept pages for this topic."
|
||||
|
||||
Before starting:
|
||||
- Tell the user it will use web search/fetch and write new wiki pages.
|
||||
- Mention that fetched content is subject to the `autoresearch` web egress hygiene rules.
|
||||
- Ask for approval unless the user already gave explicit approval in the same request.
|
||||
|
||||
Do:
|
||||
- Read `FEM_VAULT_ROOT\skills\autoresearch\SKILL.md` and `FEM_VAULT_ROOT\skills\autoresearch\references\program.md`.
|
||||
- File results into the configured FEM vault, not the caller project.
|
||||
- Use wiki locks and transport rules from the sibling skill.
|
||||
|
||||
Do not:
|
||||
- Run autoresearch for ordinary Q&A.
|
||||
- Fetch web sources silently.
|
||||
- Write into `.raw/` or `wiki/` without explicit user intent.
|
||||
|
||||
## Answer Contract
|
||||
|
||||
Answer in the user's language. For Korean questions, translate the section headings naturally.
|
||||
|
||||
Use this structure unless the user asks for another format:
|
||||
|
||||
- Summary conclusion
|
||||
- Formulation
|
||||
- Solver implementation view
|
||||
- Verification and benchmarks
|
||||
- Evidence
|
||||
- Wiki gap
|
||||
|
||||
Every core technical claim should trace to wiki evidence. Use Obsidian wikilinks such as `[[Finite Element Method]]`, `[[Solid Element Stiffness Integration]]`, or the relevant source page. If the wiki does not cover a point, label it as a gap instead of presenting model memory as vault knowledge.
|
||||
|
||||
## FEM Query Expansion
|
||||
|
||||
When a user asks a short FEM question, expand the retrieval intent before searching:
|
||||
|
||||
- Element formulation: shape functions, DOFs, Jacobian, `B` matrix, integration, load vector, result recovery.
|
||||
- Nonlinear solve: residual, tangent, Newton update, convergence norms, load/time increments, cutback policy.
|
||||
- Constitutive update: stress update, material tangent, state variables, return mapping, history evolution.
|
||||
- Dynamics/eigen: mass, damping, time integration, modal extraction, normalization, residual checks.
|
||||
- Contact/constraints: gap, normal/tangential law, penalty or multiplier enforcement, search, tangent contribution.
|
||||
- Verification: patch tests, convergence, benchmark problems, matrix checks, residual norms, source-solver comparison.
|
||||
|
||||
Keep expansion internal unless showing it helps the user understand the answer.
|
||||
|
||||
## Deployment Notes
|
||||
|
||||
Distribute this skill with the whole `skills/` bundle so sibling paths remain valid. After installing or symlinking the bundle into another agent, update `vault-path.txt` for that PC or set `FEM_THEORY_WIKI_VAULT`.
|
||||
Do not modify the vault during ordinary queries, invent a configured path, force-load every companion skill, or present external research as existing vault knowledge. A missing companion skill limits that mode but does not block direct read-only vault synthesis when the index and relevant pages are available.
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
interface:
|
||||
display_name: "FEM Theory Query"
|
||||
short_description: "Query FEM solver theory from wiki."
|
||||
default_prompt: "Use $fem-theory-query to answer a finite-element structural solver formulation question from the wiki."
|
||||
short_description: "Answer structural FEM questions from a vault"
|
||||
default_prompt: "Use $fem-theory-query to answer this structural FEM question from the configured wiki vault."
|
||||
|
||||
@@ -0,0 +1,3 @@
|
||||
# Copy this file to vault-path.txt for an optional machine-local override.
|
||||
# Keep vault-path.txt untracked. The path must contain wiki/hot.md or wiki/index.md.
|
||||
C:\path\to\your\FEMWikiVault
|
||||
@@ -1,3 +0,0 @@
|
||||
# FEM wiki vault root path.
|
||||
# Edit this per PC. Use an absolute path to the vault that contains wiki/ and .raw/.
|
||||
C:\git\MultiPhysicsVault
|
||||
@@ -1,142 +0,0 @@
|
||||
---
|
||||
name: fesa-cpp-msvc-tdd
|
||||
description: Use when planning, implementing, build/testing, correcting, or reference-comparing FESA solver C++17 MSVC CMake CTest work with TDD.
|
||||
---
|
||||
|
||||
# FESA C++ MSVC TDD
|
||||
|
||||
Use this skill to keep FESA C++ implementation, build/test reporting, correction, and reference comparison test-first, MSVC-compatible, and bounded by approved upstream contracts.
|
||||
|
||||
## Inputs
|
||||
|
||||
Read these first:
|
||||
|
||||
- `AGENTS.md`
|
||||
- `docs/SOLVER_AGENT_DESIGN.md`
|
||||
- `docs/HARNESS.md`
|
||||
- `docs/HARNESS_WORKFLOW.md`
|
||||
- `docs/<feature-id>/requirements.md`
|
||||
- `docs/<feature-id>/research.md`
|
||||
- `docs/<feature-id>/formulation.md`
|
||||
- `docs/<feature-id>/numerical-review.md`
|
||||
- `docs/<feature-id>/reference-model.md`
|
||||
- `docs/<feature-id>/io.md`
|
||||
- `docs/<feature-id>/implementation-plan.md`
|
||||
- `docs/<feature-id>/implementation-report.md` when present
|
||||
- `docs/<feature-id>/build-test.md` when present
|
||||
- `docs/<feature-id>/reference-comparison.md` when present
|
||||
- For the final Implementation-owned verification Step/gate, generated FESA `results.h5` and the
|
||||
exact feature-declared reference `.inp` and Abaqus CSV paths
|
||||
|
||||
For Harness implementation, also read `.agents/skills/harness/SKILL.md`,
|
||||
`.codex/hooks.json`, the materialized phase indexes, and the Executor-selected current
|
||||
`stepN.md`.
|
||||
|
||||
## Workflow
|
||||
|
||||
1. For planning, use the project-local `harness` skill to convert upstream documents into a
|
||||
user-approved multi-Step draft. Materialize only planning files after approval; planning never
|
||||
selects or runs a Step. Run `scripts/execute.py` only after a separate explicit user request.
|
||||
2. For implementation, require the approved plan, materialized phase files, and the
|
||||
Executor-selected current `stepN.md`. Do not start another pending Step.
|
||||
3. Execute the current Step as `RED -> observed failure -> minimal GREEN -> focused/full VERIFY`.
|
||||
Update only its Codex-owned `status` plus `summary`, `error_message`, or `blocked_reason`.
|
||||
The Executor owns branch, pending-Step selection, retry, timestamps, commits, advancement,
|
||||
and top-level phase status.
|
||||
4. Hooks are automatic through `.codex/hooks.json`: PreToolUse intercepts before edits and Stop
|
||||
performs whole-project validation. Do not manually run their entry points as substitutes.
|
||||
5. RED: write the planned unit, integration, parser/I/O, or reference-comparison test first.
|
||||
6. RED: run the targeted test and verify the expected failure before production code.
|
||||
7. GREEN: implement the minimum C++17/MSVC-compatible code needed for the task.
|
||||
8. VERIFY: resolve commands from `.harness/config.json` first, then Harness defaults; run the
|
||||
targeted command and any focused/full MSVC x64 Debug build/test commands declared by the current
|
||||
Step in order.
|
||||
9. For C++ production changes, require a related C++ test file in the same patch or already present.
|
||||
10. Treat PreToolUse as a test-file-existence guardrail, not proof that RED was observed. Record the RED and GREEN commands and results in the implementation report.
|
||||
11. Let Stop perform the final whole-project MSVC build/test before the Step ends.
|
||||
12. Record every build/test command, exit code, duration, stdout/stderr tail, failed test names, environment, and project-selection path. Stop after the first decisive failure unless the implementation plan requires another diagnostic command.
|
||||
13. For failure triage, classify as `configure | compile | link | test | reference-comparison | harness | environment | upstream-contract`.
|
||||
14. A non-final Step ends after its declared `RED -> observed failure -> minimal GREEN -> focused/full VERIFY` acceptance commands and owned status/summary update. Do not fail it merely because final solver output, reference artifacts, or `reference-comparison.md` are not yet available.
|
||||
15. Only when the approved implementation plan places the current Step after all prerequisite
|
||||
implementation Steps as the final Implementation-owned verification Step/gate, run reference
|
||||
comparison in this literal order: `ARTIFACT CHECK -> COMPARE -> CLASSIFY -> REPORT`.
|
||||
16. At that final gate, ARTIFACT CHECK requires exact declared input/CSV paths, generated `results.h5`, the `docs/<feature-id>/io.md` HDF5 projection, source identity/component matching, row uniqueness/finite checks, and approved tolerance.
|
||||
17. COMPARE matches HDF5 and CSV rows by declared source identity and component, never by row order. Reject missing, extra, duplicate, and nonfinite required rows before tolerance; preserve warning-only behavior.
|
||||
18. Fix implementation-owned failures only and keep changes traceable to the implementation plan.
|
||||
|
||||
## Output Contract
|
||||
|
||||
Produce the applicable feature-bundled evidence:
|
||||
|
||||
- `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`
|
||||
|
||||
`docs/<feature-id>/implementation-report.md` records RED/GREEN/VERIFY evidence. `docs/<feature-id>/build-test.md` uses
|
||||
`owner_agent: implementation-agent` and records the historical build/test sections: metadata,
|
||||
execution environment, command-log summary, validation results, failure classification, failed
|
||||
test inventory, handoff recommendation, no-change assertion, and open issues.
|
||||
|
||||
`docs/<feature-id>/reference-comparison.md` records the exact input/CSV artifact inventory, `results.h5`, HDF5
|
||||
projection, source-ID/component matching, row prechecks, approved tolerance, per-quantity
|
||||
per-row decisions, max absolute error, max relative or component-normalized error, RMS error,
|
||||
norm error where the approved feature contract makes each metric applicable, classification,
|
||||
handoff, no-change assertion, and open issues.
|
||||
|
||||
Required validation commands:
|
||||
|
||||
```powershell
|
||||
cmake -S . -B .harness/build -A x64
|
||||
cmake --build .harness/build --config Debug
|
||||
ctest --test-dir .harness/build -C Debug -R <feature-or-label> --output-on-failure
|
||||
ctest --test-dir .harness/build -C Debug --show-only=json-v1
|
||||
ctest --test-dir .harness/build -C Debug --output-on-failure
|
||||
```
|
||||
|
||||
Use configured CMake presets or direct MSBuild commands instead when
|
||||
`.harness/config.json` selects them. For Harness Python, Hook, or agent-config
|
||||
changes, also run:
|
||||
|
||||
```powershell
|
||||
uv run --with pytest python -m pytest -v -rs
|
||||
```
|
||||
|
||||
## Boundaries
|
||||
|
||||
- Do not change requirements.
|
||||
- Do not change formulations.
|
||||
- Do not change I/O contracts.
|
||||
- Do not change numerical review reports.
|
||||
- Do not change reference artifacts.
|
||||
- Do not change tolerance policies.
|
||||
- Do not change declared reference inputs.
|
||||
- Do not modify `docs/<feature-id>/reference-model.md` or its reference-model contracts/evidence,
|
||||
including declared comparison quantities, source identity/component rules, artifact contracts,
|
||||
or approved tolerance, to make comparisons pass.
|
||||
- Do not run Abaqus, Nastran, or any reference solver.
|
||||
- Do not generate or modify Abaqus reference CSV files.
|
||||
- Do not approve release readiness.
|
||||
- During planning, do not block on canonical reference naming, README, metadata, provenance, or
|
||||
an unrequested reference portfolio. Require only feature-declared input/CSV files, matching, and tolerance.
|
||||
|
||||
## Quality Gate
|
||||
|
||||
- Every `must` requirement maps to at least one task and one test.
|
||||
- Each test has a clear RED condition, GREEN condition, linked task, and command.
|
||||
- CMake/CTest plans remain compatible with MSVC x64 Debug validation.
|
||||
- Stop validation is green for the whole discovered C/C++ project; a no-project pass is valid only when no C/C++ files and no build metadata exist.
|
||||
- Build/test reports record command, exit code, duration, stdout/stderr tail, and failure classification.
|
||||
- Reference comparison rejects missing, extra, duplicate, and nonfinite required rows before tolerance.
|
||||
- Warning-only quantities never change the blocking pass/fail result.
|
||||
- Reference comparison records per-row decisions and, only where the approved feature contract
|
||||
makes each metric applicable, max absolute error, max relative or component-normalized error,
|
||||
RMS error, and norm error.
|
||||
- Compile, link, test, and reference-comparison failures return to Implementation Agent first.
|
||||
- Repeated or unclear implementation failures route to Correction Agent through Coordinator Agent.
|
||||
- Automatic rework stops when the same normalized failure classification reaches two attempts.
|
||||
|
||||
## Handoff
|
||||
|
||||
Return the applicable canonical outputs, status, evidence summary, and blockers to Coordinator Agent. Implementation Planning returns `docs/<feature-id>/implementation-plan.md` for one Implementation Agent handoff. A non-final Implementation Step returns only its owned status/summary and applicable evidence. The final Implementation-owned verification Step/gate returns `docs/<feature-id>/implementation-report.md`, `docs/<feature-id>/build-test.md`, and `docs/<feature-id>/reference-comparison.md`; send `pass-for-physics-evaluation` to Physics Evaluation Agent through Coordinator Agent. Correction returns `docs/<feature-id>/corrections.md` and a rerun request to Implementation Agent through Coordinator Agent. Return upstream-contract failures to Coordinator Agent for the owning upstream sub-agent.
|
||||
@@ -1,4 +0,0 @@
|
||||
interface:
|
||||
display_name: "FESA C++ TDD and Verification"
|
||||
short_description: "Implement and verify FESA C++ work"
|
||||
default_prompt: "Use $fesa-cpp-msvc-tdd to plan, implement, build, test, and reference-verify FESA C++ work."
|
||||
@@ -1,69 +0,0 @@
|
||||
---
|
||||
name: fesa-formulation-spec
|
||||
description: Use when drafting FESA FEM formulation specifications, strong or weak forms, shape functions, element equations, numerical integration, Jacobian rules, and output recovery contracts.
|
||||
---
|
||||
|
||||
# FESA Formulation Spec
|
||||
|
||||
Use this skill to turn approved requirements and research evidence into an implementable math-level FEM contract.
|
||||
|
||||
## Inputs
|
||||
|
||||
Read these first:
|
||||
|
||||
- `AGENTS.md`
|
||||
- `docs/SOLVER_AGENT_DESIGN.md`
|
||||
- `docs/<feature-id>/requirements.md`
|
||||
- `docs/<feature-id>/research.md`
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Confirm scope, assumptions, primary variables, DOFs, sign convention, units, and coordinate system.
|
||||
2. Write the Strong Form and boundary conditions.
|
||||
3. Write the Weak or Variational Form and natural boundary terms.
|
||||
4. Define Discretization: interpolation, shape functions, partition of unity, Kronecker delta checks, and nodal layout.
|
||||
5. Define Kinematics: strain-displacement relation, B matrix or kinematic operator, strain measure, and deformation assumptions.
|
||||
6. Define Constitutive Contract without creating C++ APIs.
|
||||
7. Define Element Equations: residual or internal force, external force, stiffness or tangent, mass or damping when applicable, and dimensions.
|
||||
8. Define Mapping and Numerical Integration: reference coordinates, isoparametric mapping, Jacobian, derivative transform, determinant checks, Gauss points, and weights.
|
||||
9. Define Output Recovery for displacement, reaction, element force, strain, stress, and nodal extrapolation.
|
||||
10. List Numerical Risks and downstream tests.
|
||||
|
||||
## Output Contract
|
||||
|
||||
Produce or revise `docs/<feature-id>/formulation.md` with:
|
||||
|
||||
- Scope and Assumptions
|
||||
- Primary Variables and DOFs
|
||||
- Strong Form
|
||||
- Weak or Variational Form
|
||||
- Discretization
|
||||
- Kinematics
|
||||
- Constitutive Contract
|
||||
- Element Equations
|
||||
- Mapping and Numerical Integration
|
||||
- Output Recovery
|
||||
- Algorithm Pseudocode
|
||||
- Numerical Risks
|
||||
- Open Issues and Downstream Handoff
|
||||
|
||||
## Boundaries
|
||||
|
||||
- Do not implement C++ code.
|
||||
- Do not design C++ APIs.
|
||||
- Do not implement parsers.
|
||||
- Do not run Abaqus, Nastran, or any reference solver.
|
||||
- Do not generate or modify Abaqus reference CSV files.
|
||||
- Do not approve release readiness.
|
||||
|
||||
## Quality Gate
|
||||
|
||||
- Strong form, weak form, discretization, kinematics, constitutive contract, and element equations are distinct.
|
||||
- Shape functions include partition of unity and Kronecker delta checks when applicable.
|
||||
- Jacobian, determinant validity, derivative transform, integration rule, and output location are explicit.
|
||||
- Missing research or requirements become open issues, not assumptions.
|
||||
- The document is `ready-for-numerical-review` only when all derivations, assumptions, output recovery rules, numerical risks, and open issues are explicit.
|
||||
|
||||
## Handoff
|
||||
|
||||
Return `docs/<feature-id>/formulation.md`, status, evidence summary, blockers, and all review evidence to Numerical Review Agent through Coordinator Agent. Do not bypass the numerical/reference gate with a downstream handoff.
|
||||
@@ -1,4 +0,0 @@
|
||||
interface:
|
||||
display_name: "FESA Formulation Spec"
|
||||
short_description: "Write FEM formulation specs"
|
||||
default_prompt: "Use $fesa-formulation-spec to draft implementable FESA FEM formulation specs."
|
||||
@@ -1,71 +0,0 @@
|
||||
---
|
||||
name: fesa-io-contract
|
||||
description: Use when defining FESA solver I/O contracts, Abaqus .inp keyword subsets, internal model mapping, validation rules, HDF5 result schemas, and reference CSV comparison row schemas.
|
||||
---
|
||||
|
||||
# FESA I/O Contract
|
||||
|
||||
Use this skill to define exactly what input and output data the solver feature accepts and produces.
|
||||
|
||||
## Inputs
|
||||
|
||||
Read these first:
|
||||
|
||||
- `AGENTS.md`
|
||||
- `docs/SOLVER_AGENT_DESIGN.md`
|
||||
- `docs/<feature-id>/requirements.md`
|
||||
- `docs/<feature-id>/research.md`
|
||||
- `docs/<feature-id>/formulation.md`
|
||||
- `docs/<feature-id>/numerical-review.md`
|
||||
- `docs/<feature-id>/reference-model.md`
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Define Abaqus Input Scope for the feature-specific `.inp` subset.
|
||||
2. Define Syntax Policy for keyword lines, data lines, comments, unsupported keywords, and diagnostics.
|
||||
3. Separate Model Data Mapping from History Data Mapping.
|
||||
4. Define supported keywords such as `*NODE`, `*ELEMENT`, `*MATERIAL`, `*ELASTIC`, `*BOUNDARY`, `*CLOAD`, `*STEP`, `*OUTPUT`, `*NODE OUTPUT`, and `*ELEMENT OUTPUT` only when required.
|
||||
5. Define Internal Model Contract at a semantic level without C++ APIs.
|
||||
6. Define Output HDF5 Schema for authoritative solver output `results.h5`.
|
||||
7. Define only the FESA HDF5 projection and minimum source-ID/component mapping needed for
|
||||
feature-declared blocking or warning-only CSV quantities.
|
||||
8. Define solver HDF5 units, coordinates, component names, locations, and step/frame identity.
|
||||
Do not require duplicated CSV metadata or a CSV schema version for a single-step final-frame case.
|
||||
9. Define validation rules and open issues.
|
||||
|
||||
## Output Contract
|
||||
|
||||
Produce or revise `docs/<feature-id>/io.md` with:
|
||||
|
||||
- Abaqus Input Scope
|
||||
- Syntax Policy
|
||||
- Model Data Mapping
|
||||
- History Data Mapping
|
||||
- Internal Model Contract
|
||||
- Output HDF5 Schema
|
||||
- FESA HDF5 to Reference CSV Comparison Mapping
|
||||
- Validation Rules
|
||||
- Downstream Handoff
|
||||
|
||||
## Boundaries
|
||||
|
||||
- Do not implement parsers.
|
||||
- Do not design C++ APIs.
|
||||
- Do not claim full Abaqus compatibility.
|
||||
- Do not run Abaqus, Nastran, or any reference solver.
|
||||
- Do not generate or modify Abaqus reference CSV files.
|
||||
- Do not approve release readiness.
|
||||
|
||||
## Quality Gate
|
||||
|
||||
- Every supported keyword has a documented purpose, required data, and unsupported-case behavior.
|
||||
- HDF5 schema is the authoritative solver output contract and must carry schema version, step/frame identity, units, coordinate system, output location, and component naming.
|
||||
- Reference comparison must define exact existing CSV paths, source-ID and component columns,
|
||||
deterministic matching, and missing/extra/duplicate/nonfinite prechecks. Never match by row order alone.
|
||||
- Unsupported Abaqus input is explicit: unsupported, ignored-with-warning, or requires user decision.
|
||||
- The I/O contract is compatible with requirements, formulation, and reference comparison needs.
|
||||
- The final HDF5 projection maps every approved logical quantity and source identity from `docs/<feature-id>/reference-model.md` to deterministic dataset and CSV component identities.
|
||||
|
||||
## Handoff
|
||||
|
||||
Return `docs/<feature-id>/io.md`, status, evidence summary, and blockers to Coordinator Agent. Route the final HDF5 projection, parser/schema contracts, exact CSV paths, source-ID/component matching, row prechecks, and tolerance-source constraints to Implementation Planning Agent through Coordinator Agent.
|
||||
@@ -1,4 +0,0 @@
|
||||
interface:
|
||||
display_name: "FESA I/O Contract"
|
||||
short_description: "Define solver I/O contracts"
|
||||
default_prompt: "Use $fesa-io-contract to define Abaqus input, HDF5 result, and reference CSV comparison row contracts."
|
||||
@@ -1,96 +0,0 @@
|
||||
---
|
||||
name: fesa-numerical-review
|
||||
description: Use when independently reviewing FESA FEM formulation numerical correctness, stability risks, verification readiness, and existing reference-case input/CSV readiness before I/O definition.
|
||||
---
|
||||
|
||||
# FESA Numerical and Reference Review
|
||||
|
||||
Use this skill to review a formulation as a numerical algorithm contract and to inventory the
|
||||
minimum existing reference inputs and CSV quantities required by the approved feature scope before
|
||||
I/O definition.
|
||||
|
||||
## Inputs
|
||||
|
||||
Read these first:
|
||||
|
||||
- `AGENTS.md`
|
||||
- `docs/SOLVER_AGENT_DESIGN.md`
|
||||
- `docs/<feature-id>/requirements.md`
|
||||
- `docs/<feature-id>/research.md`
|
||||
- `docs/<feature-id>/formulation.md`
|
||||
- Existing stored reference artifacts under `reference/`, read-only
|
||||
- Coordinator Agent dispatch package for the numerical/reference gate
|
||||
|
||||
## Workflow
|
||||
|
||||
FORMULATION REVIEW -> REFERENCE CASE INVENTORY -> CLASSIFY -> REPORT -> I/O HANDOFF
|
||||
|
||||
1. **FORMULATION REVIEW:** Lead with findings and required revisions. Check dimensions, signs,
|
||||
DOF ordering, constrained/free assumptions, coordinate transforms, kinematic operator,
|
||||
constitutive contract, Jacobian and derivative rules, integration policy, element residual,
|
||||
internal force, external force, stiffness, tangent consistency, symmetry, and positive-definiteness
|
||||
expectations, and only the feature-approved stability and verification risks.
|
||||
2. **REFERENCE CASE INVENTORY:** List each existing case using its exact directory, input filename,
|
||||
and required CSV filenames. Confirm declared input and every required comparison CSV are present
|
||||
and readable without renaming, repairing, normalizing, generating, or modifying artifacts.
|
||||
Define logical blocking and warning-only quantities, source identity/component matching, row
|
||||
prechecks for missing, extra, duplicate, and nonfinite required rows, and the approved tolerance.
|
||||
3. **CLASSIFY:** Use only `pass-for-io-definition`, `needs-formulation-revision`,
|
||||
`needs-research`, `needs-reference-artifacts`, `needs-user-decision`, or `blocked`.
|
||||
4. **REPORT:** Produce both reports in the Output Contract.
|
||||
5. **I/O HANDOFF:** Send both reports through Coordinator Agent to I/O Definition Agent. I/O
|
||||
Definition owns the final HDF5 dataset projection; this review owns logical quantities and source identity.
|
||||
|
||||
## Output Contract
|
||||
|
||||
Produce or revise `docs/<feature-id>/numerical-review.md` with:
|
||||
|
||||
- Metadata and source formulation
|
||||
- Review Verdict
|
||||
- Critical Findings
|
||||
- Numerical Risk Assessment
|
||||
- Consistency Checks
|
||||
- Verification Readiness
|
||||
- Required Revisions
|
||||
- Downstream Handoff
|
||||
|
||||
Produce or revise `docs/<feature-id>/reference-model.md` with:
|
||||
|
||||
- Metadata
|
||||
- Reference Acceptance Scope
|
||||
- Reference Case Inventory: exact input and required CSV paths
|
||||
- Source Identity and Component Contract: logical quantity, source identity, component matching,
|
||||
and blocking or warning-only classification
|
||||
- Row Prechecks: missing, extra, duplicate, and nonfinite required rows fail before tolerance
|
||||
- Tolerance and Blocking/Warning Policy: exact approved tolerance without invention or calibration
|
||||
- Open Issues and I/O Handoff: logical quantity and source identity information for the I/O contract
|
||||
|
||||
## Boundaries
|
||||
|
||||
- Do not implement code.
|
||||
- Do not edit formulations directly.
|
||||
- Do not design C++ APIs or file ownership.
|
||||
- Do not run Abaqus, Nastran, or any reference solver.
|
||||
- Do not generate, rename, repair, normalize, or modify reference inputs or CSV files.
|
||||
- Do not approve release readiness.
|
||||
- Do not decide reference comparison success.
|
||||
- Do not include final HDF5 dataset paths; I/O Definition owns that projection.
|
||||
|
||||
## Quality Gate
|
||||
|
||||
- `pass-for-io-definition` means both reviews are ready for I/O definition, not that the feature is complete.
|
||||
- Confirmed defects, risks, open questions, and test recommendations are separated.
|
||||
- Missing derivations are returned to Formulation Agent instead of being silently fixed.
|
||||
- Missing theory or benchmark evidence is routed to Research Agent.
|
||||
- Use `needs-reference-artifacts` only when a declared input or required comparison CSV is missing.
|
||||
- Use `needs-user-decision` only when a required quantity, source identity/component match,
|
||||
tolerance, or supported-keyword policy is undefined.
|
||||
- Canonical naming, README, metadata, provenance, extended portfolios, and unrequired CSV files do
|
||||
not block readiness.
|
||||
- Both canonical reports must return output paths, status, evidence summary, and blockers before the gate can pass.
|
||||
|
||||
## Handoff
|
||||
|
||||
Return `docs/<feature-id>/numerical-review.md` and `docs/<feature-id>/reference-model.md`, status,
|
||||
evidence summary, and blockers to Coordinator Agent. Route both passed reports to I/O Definition
|
||||
Agent, math defects to Formulation Agent, and source gaps to Research Agent through Coordinator Agent.
|
||||
@@ -1,4 +0,0 @@
|
||||
interface:
|
||||
display_name: "FESA Numerical and Reference Review"
|
||||
short_description: "Review numerical and reference readiness"
|
||||
default_prompt: "Use $fesa-numerical-review to review FESA numerical and reference-model readiness."
|
||||
@@ -1,71 +0,0 @@
|
||||
---
|
||||
name: fesa-physics-sanity
|
||||
description: Use when evaluating FESA solver physics and physical plausibility after a passing implementation-owned reference comparison, including equilibrium, reactions, displacement direction, symmetry, stress sanity, and model coverage.
|
||||
---
|
||||
|
||||
# FESA Physics Sanity
|
||||
|
||||
Use this skill to determine whether reference-passing solver outputs are physically credible enough for release evaluation.
|
||||
|
||||
## Inputs
|
||||
|
||||
Read these first:
|
||||
|
||||
- `AGENTS.md`
|
||||
- `docs/SOLVER_AGENT_DESIGN.md`
|
||||
- `docs/<feature-id>/reference-comparison.md` with `pass-for-physics-evaluation`
|
||||
- `docs/<feature-id>/reference-model.md`
|
||||
- `docs/<feature-id>/requirements.md`
|
||||
- `docs/<feature-id>/formulation.md`
|
||||
- `docs/<feature-id>/numerical-review.md`
|
||||
- `docs/<feature-id>/io.md`
|
||||
- Solver results.h5, feature-declared Abaqus reference CSV files, and optional FESA debug CSV views as read-only evidence
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Evaluate only documented physical expectations.
|
||||
2. Require `pass-for-physics-evaluation` in `docs/<feature-id>/reference-comparison.md`.
|
||||
3. Check global equilibrium when loads, reactions, and sign conventions are documented.
|
||||
4. Check reaction consistency for constrained DOFs.
|
||||
5. Check displacement direction against loads, boundary conditions, and expected deformation mode.
|
||||
6. Check symmetry or expected zero conditions when the model defines them.
|
||||
7. Check element force balance and element internal force sign conventions when documented.
|
||||
8. Check stress/strain component naming, coordinate system, output location, and sign.
|
||||
9. Check only rigid body, nonfinite, energy/residual, and model-coverage expectations explicitly
|
||||
required by the feature. Do not invent expanded portfolios or calibration gates.
|
||||
10. Classify failures and route them to the owning agent.
|
||||
|
||||
## Output Contract
|
||||
|
||||
Produce or revise `docs/<feature-id>/physics-evaluation.md` with:
|
||||
|
||||
- Metadata
|
||||
- Input Evidence
|
||||
- Physics Checks
|
||||
- Failure Classification
|
||||
- Evaluation Verdict
|
||||
- Handoff Recommendation
|
||||
- No-Change Assertion
|
||||
- Open Issues
|
||||
|
||||
## Boundaries
|
||||
|
||||
- Do not edit source code.
|
||||
- Do not edit tests.
|
||||
- Do not edit CMake files.
|
||||
- Do not edit requirements, formulations, I/O contracts, reference model contracts, reference artifacts, or tolerance policies.
|
||||
- Do not run Abaqus, Nastran, or any reference solver.
|
||||
- Do not generate or modify Abaqus reference CSV files.
|
||||
- Do not approve release readiness.
|
||||
- Do not approve reference tolerance success.
|
||||
|
||||
## Quality Gate
|
||||
|
||||
- A physics pass requires documented expectations and passing reference-comparison evidence.
|
||||
- Use `needs-upstream-decision` when physical expectations, sign convention, or model purpose is missing.
|
||||
- Route a feature-required case, declared physical expectation, or model-coverage gap to Numerical Review.
|
||||
- `pass-for-release-agent` means Release Agent can audit release readiness; it is not release approval.
|
||||
|
||||
## Handoff
|
||||
|
||||
Return `docs/<feature-id>/physics-evaluation.md`, status, evidence summary, and blockers to Coordinator Agent. Route `pass-for-release-agent` to Release Agent, implementation-owned failures to Correction Agent, formulation concerns to Formulation Agent, I/O ambiguity to I/O Definition Agent, and model-coverage gaps to Numerical Review Agent, always through Coordinator Agent.
|
||||
@@ -1,4 +0,0 @@
|
||||
interface:
|
||||
display_name: "FESA Physics Sanity"
|
||||
short_description: "Evaluate physical plausibility"
|
||||
default_prompt: "Use $fesa-physics-sanity to evaluate FESA solver physical plausibility."
|
||||
@@ -1,77 +0,0 @@
|
||||
---
|
||||
name: fesa-release-readiness
|
||||
description: Use when auditing FESA solver release readiness, upstream gate evidence, acceptance traceability, known limitations, release notes, and final feature release verdicts.
|
||||
---
|
||||
|
||||
# FESA Release Readiness
|
||||
|
||||
Use this skill to audit whether a solver feature is ready for internal release closure after all technical gates pass.
|
||||
|
||||
## Inputs
|
||||
|
||||
Read these first:
|
||||
|
||||
- `AGENTS.md`
|
||||
- `docs/SOLVER_AGENT_DESIGN.md`
|
||||
- `docs/<feature-id>/requirements.md`
|
||||
- `docs/<feature-id>/research.md`
|
||||
- `docs/<feature-id>/formulation.md`
|
||||
- `docs/<feature-id>/numerical-review.md`
|
||||
- `docs/<feature-id>/reference-model.md`
|
||||
- `docs/<feature-id>/io.md`
|
||||
- `docs/<feature-id>/implementation-plan.md`
|
||||
- `docs/<feature-id>/implementation-report.md`
|
||||
- `docs/<feature-id>/build-test.md` with passing full validation evidence
|
||||
- `docs/<feature-id>/reference-comparison.md` with `pass-for-physics-evaluation`
|
||||
- `docs/<feature-id>/corrections.md` when correction occurred
|
||||
- `docs/<feature-id>/physics-evaluation.md` with `pass-for-release-agent`
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Follow `GATE AUDIT -> TRACEABILITY CHECK -> RELEASE DOCUMENTATION -> RELEASE VERDICT`.
|
||||
2. GATE AUDIT: confirm required reports exist, share the same `feature_id`, are not stale or contradictory, and carry required pass statuses.
|
||||
3. Require passing full validation evidence, `pass-for-physics-evaluation`, and `pass-for-release-agent`.
|
||||
4. TRACEABILITY CHECK: confirm each `must` requirement maps to acceptance criteria, test evidence,
|
||||
feature-required reference evidence when applicable, and release scope.
|
||||
5. Record deferred requirements, unsupported Abaqus keywords, missing required comparison files,
|
||||
unresolved defects, accepted risks, and known limitations.
|
||||
6. RELEASE DOCUMENTATION: prepare a release checklist, Known Limitations, and Release Notes Draft.
|
||||
7. RELEASE VERDICT: issue `ready-for-release` only when all required evidence is present and passing.
|
||||
|
||||
## Output Contract
|
||||
|
||||
Produce or revise `docs/<feature-id>/release.md` with:
|
||||
|
||||
- Metadata
|
||||
- Release Scope
|
||||
- Gate Evidence Inventory
|
||||
- Acceptance Traceability
|
||||
- Validation Evidence
|
||||
- Known Limitations
|
||||
- Release Notes Draft
|
||||
- Release Verdict
|
||||
- Handoff Recommendation
|
||||
- No-Change Assertion
|
||||
- Open Issues
|
||||
|
||||
## Boundaries
|
||||
|
||||
- Do not implement code.
|
||||
- Do not edit source code, tests, CMake files, requirements, formulations, I/O contracts, reference artifacts, or tolerance policies.
|
||||
- Do not run Abaqus, Nastran, or any reference solver.
|
||||
- Do not generate or modify Abaqus reference CSV files.
|
||||
- Do not override failed or missing gates.
|
||||
- Do not publish, deploy, package, tag, commit, or externally release anything unless the user explicitly asks.
|
||||
|
||||
## Quality Gate
|
||||
|
||||
- Do not issue `ready-for-release` without `pass-for-release-agent`, `pass-for-physics-evaluation`, and passing full build/test evidence.
|
||||
- Every `must` requirement traces to release scope, acceptance criteria, test or reference evidence, and final disposition.
|
||||
- Known limitations and deferred issues are included in the Release Notes Draft.
|
||||
- Missing required evidence, contradictory reports, unresolved defects, missing declared comparison
|
||||
files, or unavailable validation commands block release readiness. Canonical naming, README,
|
||||
metadata, provenance, or unrequested portfolio expansion do not.
|
||||
|
||||
## Handoff
|
||||
|
||||
Return `docs/<feature-id>/release.md`, status, evidence summary, blockers, and a closure recommendation to Coordinator Agent. Return missing implementation/build/comparison evidence, missing physics evidence, upstream gaps, or documentation gaps to Coordinator Agent for the owning sub-agent; do not advance or close the workflow directly.
|
||||
@@ -1,4 +0,0 @@
|
||||
interface:
|
||||
display_name: "FESA Release Readiness"
|
||||
short_description: "Audit solver release readiness"
|
||||
default_prompt: "Use $fesa-release-readiness to audit FESA solver feature release readiness."
|
||||
@@ -1,66 +0,0 @@
|
||||
---
|
||||
name: fesa-requirements-baseline
|
||||
description: Use when defining FESA solver feature requirements, acceptance criteria, tolerance decisions, verification quantities, and a requirement verification matrix before research, formulation, reference modeling, or implementation planning.
|
||||
---
|
||||
|
||||
# FESA Requirements Baseline
|
||||
|
||||
Use this skill to turn a solver feature request into a verifiable baseline that downstream agents can use without guessing.
|
||||
|
||||
## Inputs
|
||||
|
||||
Read these first:
|
||||
|
||||
- `AGENTS.md`
|
||||
- `docs/SOLVER_AGENT_DESIGN.md`
|
||||
- User feature request, target capability, constraints, and known exclusions
|
||||
- Existing `docs/<feature-id>/requirements.md` when revising a feature
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Assign a stable `feature_id` in kebab case.
|
||||
2. Define purpose, included scope, excluded scope, and analysis definition.
|
||||
3. Convert requested behavior into `shall` statements with ids like `FESA-REQ-<FEATURE>-###`.
|
||||
4. Define verification quantities: displacement, reaction, element force, stress, strain, energy, or residual.
|
||||
5. Record Tolerance Policy values or mark them `needs-user-decision`.
|
||||
6. Record a minimal Reference Case: exact existing input/required CSV paths, blocking and
|
||||
warning-only quantities, HDF5 projection, source-ID/component matching, and tolerance.
|
||||
7. Build a Requirement Verification Matrix that maps requirement, source, verification method, acceptance criteria, tolerance, downstream agents, and status.
|
||||
8. Keep unresolved decisions visible as open issues; do not hide gaps behind vague wording.
|
||||
|
||||
## Output Contract
|
||||
|
||||
Produce or revise `docs/<feature-id>/requirements.md` with:
|
||||
|
||||
- Metadata with `feature_id`, status, owner agent, and date
|
||||
- Purpose, In Scope, Out Of Scope, and Analysis Definition
|
||||
- Input and Output Requirements
|
||||
- Verification Quantities
|
||||
- Tolerance Policy
|
||||
- Reference Case Requirements
|
||||
- Requirement Verification Matrix
|
||||
- Open Questions and Downstream Handoff
|
||||
|
||||
## Boundaries
|
||||
|
||||
- Do not implement C++ code.
|
||||
- Do not write finite element formulations.
|
||||
- Do not design C++ APIs or file ownership.
|
||||
- Do not run Abaqus, Nastran, or any reference solver.
|
||||
- Do not generate or modify Abaqus reference CSV files.
|
||||
- Do not approve release readiness.
|
||||
|
||||
## Quality Gate
|
||||
|
||||
- Every `must` requirement has a verification method and acceptance criteria.
|
||||
- Every numerical solver-output requirement has units, coordinates, and tolerance when applicable.
|
||||
- Every reference-comparison requirement names exact required files, compared components,
|
||||
source identity, blocking/warning behavior, and tolerance.
|
||||
- Do not require canonical names, README, metadata, provenance, or CSVs for quantities outside
|
||||
the feature acceptance boundary.
|
||||
- Words like "accurate", "fast", and "Abaqus-like" are converted into measurable criteria or open questions.
|
||||
- Return reference artifact, comparison quantity, source-identity/component, and tolerance gaps for Numerical Review rather than inventing acceptance rules.
|
||||
|
||||
## Handoff
|
||||
|
||||
Return `docs/<feature-id>/requirements.md`, status, evidence summary, and blockers to Coordinator Agent. Route theory questions to Research Agent and reference acceptance, artifact, identity/component, and tolerance questions to Numerical Review Agent through Coordinator Agent.
|
||||
@@ -1,4 +0,0 @@
|
||||
interface:
|
||||
display_name: "FESA Requirements Baseline"
|
||||
short_description: "Define solver requirements"
|
||||
default_prompt: "Use $fesa-requirements-baseline to define verifiable FESA solver requirements."
|
||||
@@ -1,61 +0,0 @@
|
||||
---
|
||||
name: fesa-research-evidence
|
||||
description: Use when collecting FESA solver research evidence, FEM theory sources, benchmarks, source reliability, and applicability limits for a feature before formulation or reference model design.
|
||||
---
|
||||
|
||||
# FESA Research Evidence
|
||||
|
||||
Use this skill to collect source-backed evidence for solver features while separating verified facts from inference.
|
||||
|
||||
## Inputs
|
||||
|
||||
Read these first:
|
||||
|
||||
- `AGENTS.md`
|
||||
- `docs/SOLVER_AGENT_DESIGN.md`
|
||||
- `docs/<feature-id>/requirements.md`
|
||||
- User-supplied books, papers, manuals, or benchmark constraints
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Extract research questions from the requirements and open issues.
|
||||
2. Build a Source Inventory with Source Reliability Tier for manuals, standards, books, papers, and benchmark repositories.
|
||||
3. Summarize FEM theory needed for the feature without finalizing implementation math.
|
||||
4. Identify Candidate Benchmarks, patch tests, analytical checks, MMS/MES candidates, and public examples.
|
||||
5. Record Verification Relevance for displacement, reaction, element force, stress, strain, energy, or residual checks.
|
||||
6. Record Applicability Limits: element type, material model, deformation assumptions, loading, boundary conditions, and known exclusions.
|
||||
7. Separate verified facts from inference. Mark unsupported claims as inference or open questions.
|
||||
|
||||
## Output Contract
|
||||
|
||||
Produce or revise `docs/<feature-id>/research.md` with:
|
||||
|
||||
- Metadata and source requirement path
|
||||
- Research Questions
|
||||
- Source Inventory and Source Reliability Tier
|
||||
- Theory Summary
|
||||
- Candidate Benchmarks
|
||||
- Verification Relevance
|
||||
- Applicability Limits
|
||||
- Downstream Handoff
|
||||
|
||||
## Boundaries
|
||||
|
||||
- Do not implement code.
|
||||
- Do not finalize FEM formulations.
|
||||
- Do not design C++ APIs or file ownership.
|
||||
- Do not run Abaqus, Nastran, or any reference solver.
|
||||
- Do not generate or modify Abaqus reference CSV files.
|
||||
- Do not approve release readiness.
|
||||
|
||||
## Quality Gate
|
||||
|
||||
- Every key claim has a source, reliability tier, or explicit inference label.
|
||||
- Benchmark candidates include what quantity they can verify and what they cannot verify.
|
||||
- Missing source evidence is carried forward as an open issue.
|
||||
- No reference value, tolerance, or compatibility claim is invented.
|
||||
- Benchmark/reference evidence identifies exact candidate artifacts, target quantities, applicability limits, and unresolved acceptance questions for Numerical Review.
|
||||
|
||||
## Handoff
|
||||
|
||||
Return `docs/<feature-id>/research.md`, status, evidence summary, and blockers to Coordinator Agent. Route formulation evidence to Formulation Agent and benchmark/reference evidence, artifact candidates, and source limits to Numerical Review Agent through Coordinator Agent.
|
||||
@@ -1,4 +0,0 @@
|
||||
interface:
|
||||
display_name: "FESA Research Evidence"
|
||||
short_description: "Collect FEM research evidence"
|
||||
default_prompt: "Use $fesa-research-evidence to collect source-backed FEM research evidence."
|
||||
Reference in New Issue
Block a user