docs: align FESA agents with minimal reference cases
This commit is contained in:
@@ -21,7 +21,9 @@ Read these first:
|
||||
|
||||
## Workflow
|
||||
|
||||
1. For planning, convert upstream documents into small ordered tasks and test ids.
|
||||
1. For planning, use the project-local `harness` skill to convert upstream documents into a
|
||||
user-approved multi-Step draft. Create `phases/` files only after approval and never run the
|
||||
executor without a separate explicit request.
|
||||
2. For implementation, follow `RED -> GREEN -> VERIFY`.
|
||||
3. RED: write the planned unit, integration, parser/I/O, or reference-comparison test first.
|
||||
4. RED: run the targeted test and verify the expected failure before production code.
|
||||
@@ -71,6 +73,8 @@ uv run --with pytest python -m pytest -v -rs
|
||||
- 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
|
||||
|
||||
|
||||
@@ -26,8 +26,10 @@ Read these first:
|
||||
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 FESA HDF5 to Reference CSV Comparison Schema for normalized rows matched against Abaqus CSV files under `reference/<model-id>/`.
|
||||
8. Define units, coordinate system, component naming, output location, step/frame identity, and ID matching rules.
|
||||
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
|
||||
@@ -40,7 +42,7 @@ Produce or revise `docs/io-definitions/<feature-id>-io.md` with:
|
||||
- History Data Mapping
|
||||
- Internal Model Contract
|
||||
- Output HDF5 Schema
|
||||
- FESA HDF5 to Reference CSV Comparison Schema
|
||||
- FESA HDF5 to Reference CSV Comparison Mapping
|
||||
- Validation Rules
|
||||
- Downstream Handoff
|
||||
|
||||
@@ -57,7 +59,8 @@ Produce or revise `docs/io-definitions/<feature-id>-io.md` with:
|
||||
|
||||
- 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 CSV comparison row schema must define stable row ordering, ID fields, and component ordering for matching against Abaqus reference CSV.
|
||||
- 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.
|
||||
|
||||
|
||||
@@ -26,8 +26,10 @@ Read these first:
|
||||
5. Review Jacobian rules, determinant checks, derivative transforms, and distortion handling.
|
||||
6. Review integration rule, Gauss points, weights, and full/reduced/selective integration policy.
|
||||
7. Check element residual, internal force, external force, stiffness, tangent, symmetry, and positive definiteness expectations.
|
||||
8. Assess rigid body modes, patch test readiness, hourglass, shear locking, volumetric locking, singular Jacobian, conditioning, and convergence risk.
|
||||
9. Decide status: `pass-for-implementation-planning`, `needs-formulation-revision`, `needs-research`, `needs-reference-model`, or `blocked`.
|
||||
8. Assess only rigid modes, patch tests, locking, singularity, conditioning, convergence, and
|
||||
other risks required by the approved feature scope. Do not invent calibration or portfolio gates.
|
||||
9. Decide status: `pass-for-implementation-planning`, `needs-formulation-revision`,
|
||||
`needs-research`, or `blocked`.
|
||||
|
||||
## Output Contract
|
||||
|
||||
@@ -58,7 +60,11 @@ Produce or revise `docs/numerical-reviews/<feature-id>-review.md` with:
|
||||
- Confirmed defects, risks, open questions, and test recommendations are separated.
|
||||
- Missing derivations are returned to Formulation Agent instead of being silently fixed.
|
||||
- Evidence gaps are routed to Research Agent or Reference Model Agent.
|
||||
- Missing downstream Reference Model documents, canonical naming, README, metadata, provenance,
|
||||
extended portfolios, or comparison results do not block a formulation verdict.
|
||||
|
||||
## Handoff
|
||||
|
||||
Send pass results to Implementation Planning Agent and Reference Model Agent. Send math defects to Formulation Agent, source gaps to Research Agent, and blocked decisions to Coordinator Agent.
|
||||
Send pass results to Implementation Planning Agent and optional test notes to Reference Model
|
||||
Agent. Send math defects to Formulation Agent, source gaps to Research Agent, and blocked decisions
|
||||
to Coordinator Agent.
|
||||
|
||||
@@ -17,7 +17,7 @@ Read these first:
|
||||
- Reference Verification report with `pass-for-physics-evaluation`
|
||||
- `docs/reference-models/<feature-id>-reference-models.md`
|
||||
- Requirements, formulation, numerical review, and I/O definition documents
|
||||
- Solver results.h5, Abaqus reference CSV files under reference/<model-id>/, and optional FESA debug CSV views as read-only evidence
|
||||
- Solver results.h5, feature-declared Abaqus reference CSV files, and optional FESA debug CSV views as read-only evidence
|
||||
|
||||
## Workflow
|
||||
|
||||
@@ -29,7 +29,8 @@ Read these first:
|
||||
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 rigid body mode symptoms, nonfinite values, energy/residual evidence, and model coverage.
|
||||
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
|
||||
@@ -60,7 +61,7 @@ Produce or revise `docs/physics-evaluations/<feature-id>-physics-evaluation.md`
|
||||
|
||||
- A physics pass requires documented expectations and reference verification pass evidence.
|
||||
- Use `needs-upstream-decision` when physical expectations, sign convention, or model purpose is missing.
|
||||
- Use `needs-reference-model` when the model does not cover the claimed feature.
|
||||
- Use `needs-reference-model` only when a feature-required case or declared physical expectation is missing.
|
||||
- `pass-for-release-agent` means Release Agent can audit release readiness; it is not release approval.
|
||||
|
||||
## Handoff
|
||||
|
||||
@@ -1,11 +1,12 @@
|
||||
---
|
||||
name: fesa-reference-comparison
|
||||
description: Use when comparing FESA solver HDF5 results against Abaqus reference CSV files for reference comparison, checking schema, units, ID matching, tolerance metrics, and reference verification status.
|
||||
description: Use when comparing FESA results.h5 quantities against feature-declared Abaqus CSV values or diagnosing reference tolerance, identity, row-set, or nonfinite-result failures.
|
||||
---
|
||||
|
||||
# FESA Reference Comparison
|
||||
|
||||
Use this skill to compare generated solver outputs against stored reference artifacts without modifying either side.
|
||||
Compare generated FESA HDF5 values with only the Abaqus CSV quantities declared by the feature.
|
||||
The comparison tests observable values; it does not test Abaqus implementation equivalence.
|
||||
|
||||
## Inputs
|
||||
|
||||
@@ -17,20 +18,29 @@ Read these first:
|
||||
- Build/Test report with `pass-for-reference-verification`
|
||||
- `docs/reference-models/<feature-id>-reference-models.md`
|
||||
- `docs/io-definitions/<feature-id>-io.md`
|
||||
- Generated solver result HDF5, normally `results.h5`
|
||||
- Abaqus reference CSV files under `reference/<model-id>/`
|
||||
- Optional deterministic solver CSV views materialized from `results.h5` for debugging or review
|
||||
- Generated FESA `results.h5`
|
||||
- Declared reference `.inp` and required Abaqus CSV files
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Follow `ARTIFACT CHECK -> COMPARE -> CLASSIFY -> REPORT`.
|
||||
2. ARTIFACT CHECK: verify `model.inp`, generated solver `results.h5`, required `reference/<model-id>/<model-id>_displacements.csv`, `reference/<model-id>/<model-id>_reactions.csv`, `reference/<model-id>/<model-id>_internalforces.csv`, `reference/<model-id>/<model-id>_stresses.csv`, Reference Model Contract provenance, reference CSV schema version, FESA HDF5 schema version, units, coordinate system, step/frame identity, ID matching, output location, component naming, and tolerance policy.
|
||||
3. Treat `metadata.json` as optional: record absence as `absent-allowed`; when present, inspect it read-only and cross-check overlapping fields against the Reference Model Contract and stored artifacts. Stop on a conflict, not on absence.
|
||||
4. Stop with `needs-reference-artifacts`, `needs-solver-results`, or `needs-upstream-decision` when required comparison inputs are missing.
|
||||
5. COMPARE FESA HDF5 datasets by normalizing their rows and matching them directly against Abaqus reference CSV rows.
|
||||
6. Apply upstream tolerance exactly. Do not loosen or reinterpret tolerance.
|
||||
7. Report max absolute error, max relative error, RMS error, norm error, worst id, worst component, missing rows, extra rows, and pass/fail.
|
||||
8. CLASSIFY failures as missing-reference-artifact, missing-solver-output, schema-mismatch, id-mismatch, unit-or-coordinate-mismatch, tolerance-failure, nonfinite-result, upstream-contract, or environment.
|
||||
2. ARTIFACT CHECK: verify the declared input, `results.h5`, every required CSV, HDF5
|
||||
projection, source-ID/component mapping, row prechecks, blocking/warning behavior, and tolerance.
|
||||
3. Reject a missing input or required CSV as `needs-reference-artifacts`.
|
||||
4. Reject a missing HDF5 result or comparison command as `needs-solver-results`.
|
||||
5. Reject missing, extra, duplicate, or nonfinite required rows before tolerance evaluation.
|
||||
6. COMPARE: normalize HDF5 values and match CSV values by declared source identity and component.
|
||||
Never match by row order alone.
|
||||
7. Apply the upstream tolerance exactly. Do not clamp values, drop rows, loosen tolerance, or
|
||||
modify either artifact to obtain a pass.
|
||||
8. Report per-row decisions, max absolute error, max relative error, RMS error, norm error when
|
||||
required, worst source ID/component, and pass/fail or warning per quantity.
|
||||
9. CLASSIFY failures as missing-reference-artifact, missing-solver-output, schema-mismatch,
|
||||
id-mismatch, tolerance-failure, nonfinite-result, upstream-contract, or environment.
|
||||
|
||||
Do not require canonical names, README, metadata, Abaqus version/provenance, duplicated CSV
|
||||
units/coordinates/step-frame fields, or a reference CSV schema version unless the feature
|
||||
requirements explicitly make one of them part of comparison acceptance.
|
||||
|
||||
## Output Contract
|
||||
|
||||
@@ -47,25 +57,21 @@ Produce or revise `docs/reference-verifications/<feature-id>-reference-verificat
|
||||
|
||||
## Boundaries
|
||||
|
||||
- Do not edit source code.
|
||||
- Do not edit tests.
|
||||
- Do not edit CMake files.
|
||||
- Do not change requirements, formulations, I/O contracts, reference artifacts, or tolerance policies.
|
||||
- Do not change tolerance policies.
|
||||
- Do not run Abaqus, Nastran, or any reference solver.
|
||||
- Do not generate or modify Abaqus reference CSV files.
|
||||
- Do not edit source, tests, CMake, upstream contracts, reference artifacts, or tolerances.
|
||||
- Do not run Abaqus, Nastran, or another reference solver.
|
||||
- Do not generate or modify reference CSV files.
|
||||
- Do not approve physics validation or release readiness.
|
||||
|
||||
## Quality Gate
|
||||
|
||||
- Every compared row has a deterministic matching rule.
|
||||
- Missing rows and extra rows are reported, not ignored.
|
||||
- Nonfinite values are reported explicitly.
|
||||
- `pass-for-physics-evaluation` means reference tolerance success only.
|
||||
- FESA solver `results.h5` is the authoritative solver output.
|
||||
- Abaqus reference CSV files are the authoritative reference result artifacts.
|
||||
- FESA debug CSV views are derived from `results.h5` for review only; do not treat FESA debug CSV views as authoritative solver output or reference artifacts.
|
||||
- Every declared required row has a deterministic source-ID/component match.
|
||||
- Missing/extra/duplicate/nonfinite required rows remain visible and fail before tolerance.
|
||||
- Warning-only quantities never change the blocking pass/fail verdict.
|
||||
- `pass-for-physics-evaluation` means required reference tolerance success only.
|
||||
- FESA `results.h5` remains authoritative solver output; Abaqus CSV remains external reference data.
|
||||
|
||||
## Handoff
|
||||
|
||||
Send passing reports to Physics Evaluation Agent. Send implementation-owned mismatches to Correction Agent. Send missing artifacts to Reference Model Agent and HDF5/reference CSV schema conflicts to I/O Definition Agent.
|
||||
Send passing reports to Physics Evaluation Agent. Send implementation-owned mismatches to
|
||||
Correction Agent, missing declared files to Reference Model Agent, and HDF5 projection or
|
||||
identity-contract conflicts to I/O Definition Agent.
|
||||
|
||||
@@ -1,11 +1,13 @@
|
||||
---
|
||||
name: fesa-reference-models
|
||||
description: Use when designing FESA reference model portfolios, Abaqus input artifact bundles, metadata provenance, required Abaqus reference CSV files, coverage matrices, and implementation-planning handoffs.
|
||||
description: Use when a FESA feature needs existing Abaqus input/CSV reference cases, required comparison quantities, tolerance mapping, or implementation-planning handoff.
|
||||
---
|
||||
|
||||
# FESA Reference Models
|
||||
# FESA Reference Cases
|
||||
|
||||
Use this skill to define test model portfolios and reference artifact contracts before implementation planning.
|
||||
Use this skill to inventory the minimum stored reference inputs and CSV quantities that a
|
||||
feature actually compares. Abaqus is an external numerical reference, not the FESA formulation
|
||||
or behavior specification.
|
||||
|
||||
## Inputs
|
||||
|
||||
@@ -15,56 +17,67 @@ Read these first:
|
||||
- `docs/SOLVER_AGENT_DESIGN.md`
|
||||
- `docs/reference-models/README.md`
|
||||
- `docs/requirements/<feature-id>.md`
|
||||
- `docs/research/<feature-id>-research.md`
|
||||
- `docs/formulations/<feature-id>-formulation.md`
|
||||
- `docs/numerical-reviews/<feature-id>-review.md`
|
||||
- `docs/io-definitions/<feature-id>-io.md`
|
||||
- Existing files under `reference/`
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Define reference strategy: code verification, solution verification, and benchmark/reference comparison.
|
||||
2. Build a model inventory: smoke, analytical, patch test, benchmark, regression, and negative/invalid-input models.
|
||||
3. For each model, record `model_id`, purpose, verified requirements, analysis type, element type, material, boundary conditions, loads, expected quantities, tolerance, source, and status.
|
||||
4. Define `reference/<model-id>/` artifact bundle requirements.
|
||||
5. Require `model.inp`, the applicable `<model-id>_displacements.csv`, `<model-id>_reactions.csv`, `<model-id>_internalforces.csv`, `<model-id>_stresses.csv`, and `README.md` unless explicitly not applicable. Treat `metadata.json` as optional.
|
||||
6. Define optional `<model-id>_strains.csv`, `<model-id>_energy_or_residual.csv`, and `<model-id>_<quantity>.csv` only when upstream acceptance criteria require them.
|
||||
7. Define metadata provenance, units, coordinate system, output requests, artifact status, reference_csv_schema_version, reference_csv_files, and limitations in the Reference Model Contract. If `metadata.json` exists, inventory it read-only and cross-check overlapping fields.
|
||||
8. Build a Coverage Matrix mapping requirement id, model id, compared quantity, FESA HDF5 dataset, reference CSV file, tolerance, verification method, and status.
|
||||
1. Read the feature requirements and list only blocking and warning-only reference quantities.
|
||||
2. Inventory each existing case using its exact directory, input filename, and required CSV filenames.
|
||||
3. Confirm the input and every required comparison CSV are present and readable.
|
||||
4. Record the FESA HDF5 dataset, source identity column, required component columns, and stable matching rule.
|
||||
5. Require unique source IDs, complete required row sets, and finite comparison values.
|
||||
6. Copy the approved tolerance and blocking/warning behavior without inventing or calibrating values.
|
||||
7. Map each reference-comparison requirement to at least one existing case when the feature requires that coverage.
|
||||
|
||||
Do not require or create:
|
||||
|
||||
- canonical directories or filenames;
|
||||
- legacy-alias approvals;
|
||||
- bundle `README.md` or `metadata.json`;
|
||||
- Abaqus version or generation provenance;
|
||||
- duplicated units, coordinates, step/frame, material, section, thickness, or element-type metadata;
|
||||
- a reference CSV schema version;
|
||||
- CSV files for quantities outside the approved comparison boundary;
|
||||
- an expanded benchmark portfolio unless the feature requirements explicitly require it.
|
||||
|
||||
Read source element type, material, section, loads, constraints, and supported single-step
|
||||
identity from the `.inp`. Do not rename, repair, normalize, or generate reference artifacts.
|
||||
|
||||
## Output Contract
|
||||
|
||||
Produce or revise `docs/reference-models/<feature-id>-reference-models.md` with:
|
||||
|
||||
- Metadata
|
||||
- Reference Strategy
|
||||
- Model Inventory
|
||||
- Model Record
|
||||
- Abaqus Input Requirements
|
||||
- Artifact Bundle Contract
|
||||
- Reference Metadata Contract and optional `metadata.json` cross-check
|
||||
- Abaqus Reference CSV Requirements
|
||||
- Coverage Matrix
|
||||
- Artifact Acceptance Checklist
|
||||
- Reference Acceptance Scope
|
||||
- Reference Case Inventory
|
||||
- HDF5-to-CSV Comparison Mapping
|
||||
- Tolerance and Blocking/Warning Policy
|
||||
- Readiness Checklist
|
||||
- Open Issues and Downstream Handoff
|
||||
|
||||
## Boundaries
|
||||
|
||||
- Do not implement code.
|
||||
- Do not implement parsers.
|
||||
- Do not implement code or parsers.
|
||||
- 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 run Abaqus, Nastran, or another reference solver.
|
||||
- Do not generate or modify reference inputs or CSV files.
|
||||
- Do not compare solver results.
|
||||
- Do not approve release readiness.
|
||||
|
||||
## Quality Gate
|
||||
|
||||
- Every `must` requirement maps to at least one model and compared quantity.
|
||||
- `model.inp` stays within the supported Abaqus keyword subset or records an open issue.
|
||||
- The Reference Model Contract includes provenance, Abaqus version/source, units, coordinate system, tolerance, reference_csv_schema_version, and reference_csv_files.
|
||||
- An absent `metadata.json` is allowed and does not change readiness. A present file is read-only supplementary evidence; any conflict with the contract or stored artifacts remains visible as an upstream issue.
|
||||
- Missing required Abaqus reference CSV files keep the model at `needs-reference-artifacts`.
|
||||
- Every blocking or warning-only quantity names an exact input/CSV pair.
|
||||
- Every comparison defines an HDF5 projection, source-ID/component mapping, and tolerance.
|
||||
- Missing, extra, duplicate, and nonfinite required rows have an explicit fail-before-tolerance rule.
|
||||
- Use `needs-reference-artifacts` only when a declared input or required comparison CSV is missing.
|
||||
- Use `needs-user-decision` only when required quantities, matching, or tolerance are undefined.
|
||||
- Canonical naming, README, metadata, provenance, and unrequested portfolio coverage never block readiness.
|
||||
|
||||
## Handoff
|
||||
|
||||
Send model order and tests that should fail first to Implementation Planning Agent. Send FESA HDF5 dataset paths, reference CSV schemas, matching, output location, and tolerance mapping to Reference Verification Agent. Send physical expectations to Physics Evaluation Agent.
|
||||
Send exact paths, HDF5 projection, source-ID/component matching, row prechecks, and tolerance to
|
||||
Implementation Planning Agent and Reference Verification Agent. Send only feature-required
|
||||
physical expectations to Physics Evaluation Agent.
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
interface:
|
||||
display_name: "FESA Reference Models"
|
||||
short_description: "Design Abaqus CSV reference bundles"
|
||||
default_prompt: "Use $fesa-reference-models to design Abaqus reference CSV artifact bundles."
|
||||
display_name: "FESA Reference Cases"
|
||||
short_description: "Inventory required input and CSV cases"
|
||||
default_prompt: "Use $fesa-reference-models to inventory the existing Abaqus input and required CSV cases for a FESA feature."
|
||||
|
||||
@@ -24,8 +24,10 @@ Read these first:
|
||||
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 `pass-for-reference-verification`, `pass-for-physics-evaluation`, and `pass-for-release-agent`.
|
||||
4. TRACEABILITY CHECK: confirm each `must` requirement maps to acceptance criteria, test evidence, reference model evidence, and release scope.
|
||||
5. Record deferred requirements, unsupported Abaqus keywords, incomplete artifacts, unresolved defects, accepted risks, and known limitations.
|
||||
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.
|
||||
|
||||
@@ -59,7 +61,9 @@ Produce or revise `docs/releases/<feature-id>-release.md` with:
|
||||
- Do not issue `ready-for-release` without `pass-for-release-agent`, `pass-for-physics-evaluation`, and `pass-for-reference-verification`.
|
||||
- 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 evidence, contradictory reports, unresolved defects, incomplete artifacts, or unavailable validation commands block release readiness.
|
||||
- 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
|
||||
|
||||
|
||||
@@ -24,7 +24,8 @@ Read these first:
|
||||
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 Reference Artifact Requirements under `references/<feature-id>/`.
|
||||
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.
|
||||
|
||||
@@ -37,7 +38,7 @@ Produce or revise `docs/requirements/<feature-id>.md` with:
|
||||
- Input and Output Requirements
|
||||
- Verification Quantities
|
||||
- Tolerance Policy
|
||||
- Reference Artifact Requirements
|
||||
- Reference Case Requirements
|
||||
- Requirement Verification Matrix
|
||||
- Open Questions and Downstream Handoff
|
||||
|
||||
@@ -53,8 +54,11 @@ Produce or revise `docs/requirements/<feature-id>.md` with:
|
||||
## Quality Gate
|
||||
|
||||
- Every `must` requirement has a verification method and acceptance criteria.
|
||||
- Every numerical requirement has units, coordinate system, and tolerance or an explicit owner for the decision.
|
||||
- Every reference-comparison requirement names required artifacts.
|
||||
- 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.
|
||||
|
||||
## Handoff
|
||||
|
||||
Reference in New Issue
Block a user