KOKO\Mimi
71 lines
3.2 KiB
Markdown
71 lines
3.2 KiB
Markdown
---
|
|
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/releases/README.md`
|
|
- Physics Evaluation report with `pass-for-release-agent`
|
|
- Reference Verification report with `pass-for-physics-evaluation`
|
|
- Build/Test report with `pass-for-reference-verification`
|
|
- Requirements, formulation, numerical review, I/O definition, reference model, implementation, and correction reports
|
|
|
|
## 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 `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,
|
|
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/releases/<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 `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 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
|
|
|
|
Send `ready-for-release` to Coordinator Agent for final workflow closure. Send missing documentation to Release Agent revision, missing verification to Reference Verification Agent or Physics Evaluation Agent, and implementation defects to Correction Agent.
|