docs: complete phase 1 rebaseline audit

PROGRESS.md

@@ -13,10 +13,33 @@ Every new agent session must read this file together with `PLAN.md` before plann
 - Do not remove history unless the user explicitly asks for archival cleanup.
 
 ## Current Status
-Phase 1 has a new rebaseline phase definition in `phases/1-linear-static-mitc4-rebaseline`. The old `phases/1-linear-static-mitc4` path is historical and superseded after the MITC4 formulation reset. P1-01 through P1-14 have an initial C++17 implementation, but it is no longer authoritative until reviewed against the revised paper-based `docs/MITC4_FORMULATION.md`. `quad_02` is now the stored S4 reference pair, but its `Part/Assembly/Instance` and `*Density` features remain a compatibility decision for rebaseline step 1.
+Phase 1 has a new rebaseline phase definition in `phases/1-linear-static-mitc4-rebaseline`. Step 0 is complete and captured in `phases/1-linear-static-mitc4-rebaseline/step0-audit.md`. The old `phases/1-linear-static-mitc4` path is historical and superseded after the MITC4 formulation reset. P1-01 through P1-14 have an initial C++17 implementation, but it is no longer authoritative until each layer is revalidated against the revised paper-based `docs/MITC4_FORMULATION.md`. `quad_02` is now the stored S4 reference pair, but its `Part/Assembly/Instance` and `*Density` features remain a compatibility decision for rebaseline step 1.
 
 ## Completed Work
 
+### 2026-05-04 - P1R-00 rebaseline audit completed
+Author: Codex
+
+Changed files:
+- `phases/1-linear-static-mitc4-rebaseline/step0-audit.md`
+- `phases/1-linear-static-mitc4-rebaseline/index.json`
+- `PLAN.md`
+- `PROGRESS.md`
+
+Summary:
+- Audited the existing C++ Phase 1 implementation against the revised paper-based `docs/MITC4_FORMULATION.md` without changing production solver behavior.
+- Classified reusable scaffolding for revalidation: CMake/CTest validation, core aliases, DOF mapping, diagnostics, parser/domain skeleton, in-memory `U`/`RF` results, displacement CSV comparator, full-vector reaction recovery, and the linear static workflow.
+- Identified MITC4 conflicts requiring rebuild: averaged-edge local basis, 2D projected Jacobian, direct Cartesian-like shear row construction, membrane/bending/shear pre-integration, midsurface-only `2 x 2` integration, and old `1.0e-6` drilling stabilization.
+- Preserved the compatibility decision that `quad_02.inp` is an S4 reference artifact but still contains `Part/Assembly/Instance` and `*Density`, so Step 1 must choose a normalized-input or explicit parser-compatibility path.
+
+Verification:
+- Inspected `include/fesa/fesa.hpp`, `tests/test_main.cpp`, current reference files, and active rebaseline phase contracts.
+- `python scripts/validate_workspace.py` configured CMake, built `fesa_core` and `fesa_tests`, and ran CTest successfully.
+
+Follow-up:
+- Continue with P1R-01 reference onboarding.
+- Revalidate retained scaffolding in its assigned steps before treating it as Phase 1 evidence.
+
 ### 2026-05-04 - Phase 1 rebaseline steps redefined
 Author: Codex
 
@@ -425,9 +448,10 @@ Verification:
 ## Known Blockers
 - No reaction-force reference artifact exists yet under `references/`.
 - The current initial `quad_01.inp` reference contains `S4R`, `Part/Assembly/Instance`, `*Density`, and `NLGEOM=YES`, so it is not a Phase 1 parser acceptance case as-is.
-- No Phase 1-compatible Abaqus `TYPE=S4` input with matching `*_displacements.csv` exists yet for stored-reference regression.
+- `quad_02.inp` is a stored Abaqus `TYPE=S4` reference with matching displacement CSV, but it contains `Part/Assembly/Instance` and `*Density`; Step 1 must define a normalized-input or explicit parser-compatibility path before stored-reference regression.
 
 ## Current Risks
 - Implementation could start from the `quad_01` reference input without accounting for its unsupported Abaqus features.
+- Implementation could treat the old MITC4 kernel as authoritative even though it conflicts with the revised formulation contract.
 - Reaction output may be wrong if full-space stiffness/load data is not preserved or reconstructed.
 - Large-model support may be weakened if any module narrows ids or sparse indices below int64.