Files
FESADev/.codex/skills/fem-requirements-baseline/references/workflow-and-decisions.md
T
2026-09-05 15:14:21 +09:00

2.3 KiB

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.