feat: Refactored test system

.agents/skills/ptf-extract/SKILL.md

@@ -17,17 +17,41 @@ input error.
 
 ## Procedure
 
-1. Read the supplied local paper, `specs/schema/ptf-spec.schema.json`, and
+1. Read the supplied local paper, `specs/schema/ptf-spec.schema.json`,
+   `specs/quantities.yaml`, `specs/units.yaml`, and
    `references/extraction-quality-gate.md`.
    If the source defines a finite categorical input or a table selected by that
    input, also read `references/categorical-lookups.md`.
-2. Extract only facts explicitly supported by the paper. Write its standalone
+2. Resolve every scalar output and record field to a stable quantity identifier
+   and normalized unit identifier allowed by `specs/quantities.yaml`. Preserve the
+   literal source notation in `reported_unit` and check it against the preferred
+   notation or aliases in `specs/units.yaml`. If an identifier, allowed pair, or
+   equivalent notation is absent, stop and ask
+   the user to review a proposed identifier or unit entry, absolute tolerance,
+   optional relative tolerance, and concise rationale. Include the output
+   description and nearest analogous entries. Add the policy only after the
+   user accepts or edits it; never silently invent a registry entry.
+3. Extract only facts explicitly supported by the paper. Write its standalone
    YAML directly to `specs/functions/<apa_article_key>.yaml`, following
    `references/spec-template.yaml`.
-3. Record missing or ambiguous required scientific information as explicit
+4. Add every source-published input-output example as a `published`
+   `verification_cases` entry. If none exists, select physically meaningful
+   inputs and calculate the expected outputs with simple reference code as
+   described in `references/extraction-quality-gate.md`. Give each case an ID
+   that is unique within its function and valid as a Rust test function name.
+   Use descriptive lowercase `snake_case` identifiers and avoid Rust keywords.
+   Specification validation checks uniqueness but does not validate Rust
+   identifier syntax. Invalid names can cause Rust code generation or subsequent
+   compilation to fail even after specification validation succeeds.
+5. If the publication explicitly states an applicable output accuracy or
+   resolution, optionally propose a function-level `verification_tolerances`
+   override keyed by output name and cite its exact `source_location`. Do not
+   search indefinitely for one, put an override in a verification case, or use
+   model-performance statistics such as RMSE as implementation tolerances.
+6. Record missing or ambiguous computational-contract information as explicit
    blockers and set affected functions to `blocked`; otherwise set reviewed,
    complete functions to `ready-for-implementation`.
-4. Run `cargo run --manifest-path codegen/Cargo.toml -- validate` and fix
+7. Run `cargo run --manifest-path codegen/Cargo.toml -- validate` and fix
    validation errors before finishing. When a nontrivial formula expression is
    repeated within one implementation, declare it once as an earlier local
    implementation variable and reference that variable; retain the published
@@ -42,14 +66,23 @@ exact YAML path and explicit blockers.
 ## Hard rules
 
 - Do not set `implemented`, run target generation, or edit generated files.
-- Do not invent formulas, units, metadata, golden values, applicability, or
-  API details. Keep uncertainty explicit in the YAML.
+- Do not invent formulas, units, published examples, applicability, or API
+  details. Calculated verification inputs must satisfy the documented domain
+  and physical constraints; fix independently calculated expected values in
+  YAML and explain the choice in `rationale`.
+- Do not call a calculated case independent, source-native, artifact-native,
+  external validation, or evidence of model accuracy.
 - Do not normalize, alias, abbreviate, or otherwise broaden source-defined
   categorical values. Keep enum member names, canonical textual values, lookup
   rows, and their evidence distinct.
 - Give every `type: record` output a PascalCase `name`, whether it is inline or
   declared in `$defs`. It names generated structures and classes; `$defs` keys
   only resolve local `$ref` targets.
+- Give every scalar output and record field a reviewed `quantity`, normalized
+  `unit`, and literal `reported_unit`. Resolve aliases only within the quantity
+  context and only when they preserve numerical values exactly. Never convert
+  values through alias resolution. Tolerances belong to the quantity-unit pair;
+  the unit registry owns identity and notation only.
 - Use `generation.public_python: manual` only when the public wrapper cannot
   follow the standard generated API; it never opts the native NumPy ufunc out
   of generation.

.agents/skills/ptf-extract/references/categorical-lookups.md

@@ -43,7 +43,7 @@ field names.
 Invoke the lookup as an ordered implementation variable. Its `key` names an
 in-scope input of the lookup's enum type. Return a compatible record-valued
 variable directly, or use `variable.field` in later formula expressions.
-Golden-test categorical inputs also use enum member schema names.
+Verification-case categorical inputs also use enum member schema names.
 
 ```yaml
 $defs:
@@ -73,12 +73,12 @@ functions:
             table:
               $ref: "#/$defs/ParametersByTexture"
             key: texture
-    golden_tests:
+    verification_cases:
       - id: coarse_table_row
+        kind: published
         inputs: {texture: coarse}
         expected: {coefficient: 1.25}
-        rtol: 0.0
-        atol: 0.0
+        source_location: "Published parameter table, coarse row"
         notes: Direct published table row.
 ```
 

.agents/skills/ptf-extract/references/extraction-quality-gate.md

@@ -8,17 +8,22 @@ APA-style slug and identifies the generated public module, for example
 ## Required facts
 
 - Preserve the ordered functions, inputs, outputs, source metadata, units,
-  golden and edge cases, documentation, scope, and semantic `implementation`
+  verification and edge cases, documentation, scope, and semantic `implementation`
   fields required by the schema.
 - Every record output has an explicit PascalCase `name`.
+- Every scalar output and record field has a stable `quantity` and normalized
+  `unit` allowed by `specs/quantities.yaml`. Its literal `reported_unit` matches
+  the unit preferred notation or an alias in `specs/units.yaml` without changing
+  the numerical value. Registry tolerances are reviewed project
+  policy, not claims of measurement uncertainty or model predictive accuracy.
 - When the source uses a finite categorical predictor, represent its reusable
   type as an enum in `$defs` and bind it to each function-local argument with
   `name` plus `$ref`. The enum owns its type description and admissible values;
   the binding description, when present, explains only that argument's role.
 - When the source publishes a table selected by a category, model it as a typed
   lookup from the enum to a record in `$defs`. Preserve one row per enum member
   and one numeric value per output-record field. Use enum member names in lookup
-  keys and golden inputs, not canonical textual values or target ordinals.
+  keys and verification-case inputs, not canonical textual values or target ordinals.
 - Use the formula DSL only in `implementation` expressions. In
   `scientific_notes`, retain source-supported scientific context, derivations
   needed to justify an interpretation, evidence for review decisions, citations,
@@ -35,13 +40,44 @@ APA-style slug and identifies the generated public module, for example
   `generation.public_python: manual` only for an intentional manual public
   wrapper; native ufunc generation remains required.
 
+## Verification cases
+
+Every computationally complete function needs at least one verification case.
+Use only these provenance kinds:
+
+- `published` when a complete input-output pair appears in the paper,
+  supplementary material, official author software, or another authoritative
+  source. Preserve its location in `source_location`.
+- `calculated` when no complete published pair exists. Select an input and
+  independently calculate the expected output from the published computational
+  contract, fix the result in YAML, and explain the input choice in `rationale`.
+
+Prefer calculated inputs in this order: a complete published predictor row,
+published predictor means or medians, an interior point of the documented
+domain, then an expert-selected typical physically valid soil. Keep values away
+from boundaries, use the stated units and scales, preserve texture sums and
+positive logarithm arguments, and respect physical relations such as
+`theta_1500 <= theta_33 <= theta_s`. Do not combine unrelated marginal extrema.
+For piecewise models and trees, cover every material computational branch with
+a published case where available and a calculated case otherwise.
+
+For record outputs, `expected` contains every output field. Verification cases
+contain provenance but no tolerance or precision fields. Generated tests use
+the resolved function-output policy from `specs/quantities.yaml` or an explicit
+function-level `verification_tolerances` override with `source_location`.
+
+The lack of a published case is not an extraction or release blocker.
+
 ## Blockers
 
 Set affected functions to `blocked` and name the missing evidence when a
-formula, constant, unit, output mapping, semantic expression, golden value,
-numeric policy, or applicability fact is missing or ambiguous. Do not use
+formula, constant, unit, output mapping, preprocessing step, transform, branch,
+fitted payload, or applicability fact is missing or ambiguous. Do not use
 `TODO` as a substitute for a structured required value; write it only in an
-explicit blocker note. Schema-valid YAML may still be blocked.
+explicit blocker note. The absence of a published example, row-level dataset,
+supplement, or author calculator is not a blocker when the computational
+contract is complete enough to create a calculated case. Rights and licensing
+remain a separate release gate and do not change scientific extraction status.
 
 ## Statuses
 

.agents/skills/ptf-extract/references/spec-template.yaml

@@ -18,8 +18,21 @@ functions:
         h_theta: null
         k_h: null
     inputs: []
-    outputs: []
-    golden_tests: []
+    outputs:
+      type: scalar
+      name: target
+      quantity: reviewed_quantity_identifier
+      symbol: null
+      unit: reviewed_unit_identifier
+      reported_unit: source unit
+      domain: null
+      description: Source-supported output description.
+    verification_cases:
+      - id: representative_case
+        kind: calculated
+        inputs: {}
+        expected: {}
+        rationale: Explain why the input is physically meaningful and within the source domain.
     edge_cases: []
     documentation:
       notes: []

.agents/skills/ptf-review/SKILL.md

@@ -19,7 +19,7 @@ modifying repository state.
 
 1. Read `specs/schema/ptf-spec.schema.json`, the selected YAML specification,
    implementation diff, generated Rust, C, C++, and native NumPy targets,
-   golden tests, and relevant public wrapper.
+   verification tests, and relevant public wrapper.
 2. Load `references/implementation-review-checklist.md`.
 3. Check schema and semantic IR fidelity, all retained targets, deterministic
    regeneration, status transition evidence, categorical type and lookup
@@ -40,7 +40,7 @@ modifying repository state.
 
 - Treat the YAML specification and semantic implementation as the sole
   numerical source of truth, not guessed article intent.
-- Treat missing golden tests, ambiguous units, and public API breaks as
+- Treat missing verification tests, ambiguous units, and public API breaks as
   blocking unless explicitly approved.
 - Verify that each record `outputs.name` is PascalCase and names generated
   structures and classes.

.agents/skills/ptf-review/references/implementation-review-checklist.md

@@ -10,7 +10,7 @@
 - [ ] Every categorical argument binds its function-local name to the intended
   enum type; type and optional binding descriptions retain their separate roles.
 - [ ] Enum member names, exact canonical textual values, order, and optional
-  descriptions match the source-supported specification. Golden inputs use
+  descriptions match the source-supported specification. Verification inputs use
   member names, never textual values or generated ordinals.
 - [ ] Every lookup maps the declared enum to the declared record, covers each
   member exactly once, and gives each row exactly the record fields. Lookup
@@ -29,7 +29,7 @@
   lookup conversion, record shape, and numeric computation from the semantic IR.
 - [ ] Generated native NumPy ufuncs use the same IR and private ordinal encoding
   only as a target implementation detail.
-- [ ] Generated target tests cover every structured golden case.
+- [ ] Generated target tests cover every structured verification case.
 - [ ] Valid IR unsupported by a retained target is reported as a generator
   capability blocker, not replaced with hand-written computation.
 
@@ -57,5 +57,5 @@
 
 Classify as blocking: schema or semantic failure; formula, unit, output-order,
 categorical-type, lookup, or public-API mismatch; missing retained target or
-golden test; unsupported IR; nondeterministic generation; unsubstantiated
+verification test; unsupported IR; nondeterministic generation; unsubstantiated
 status transition; or exposed repository-only specification paths.

codegen/README.md

@@ -7,8 +7,10 @@ contract; internal generator APIs are not.
 
 ## Pipeline
 
-1. `specs` loads source specifications and `validate` checks their contracts.
-2. `compile` resolves formulas and golden cases into `CompiledFunction` values.
+1. `specs` loads source specifications and `specs/quantities.yaml` and `specs/units.yaml`; `validate`
+   checks output coverage and their remaining contracts.
+2. `compile` resolves formulas and fixed verification cases into
+   `CompiledFunction` values and validates their complete input-output shape.
 3. `documentation` provides borrowed source/function facts without target
    markup. `render` contains shared text, Markdown, and C-family expression
    rendering support.
@@ -50,12 +52,15 @@ mise run corpus-report --format json
 The command uses the normal specification loader, schema and semantic
 validation, and compilation path. It counts every schema-valid function,
 including `draft` and `blocked` functions. Verification coverage counts declared
-`golden_tests` and `edge_cases`; it does not describe external predictive
+`verification_cases` and `edge_cases`; it does not describe external predictive
 validation on soil datasets, and a declared edge case is not necessarily an
-executable test.
+executable test. Provenance counts distinguish published examples from
+calculated implementation checks.
 
 The JSON document has stable top-level `sources`, `functions`, `verification`,
-`inputs`, `outputs`, `scope`, and `blocked_functions` sections. Category tables
+`quantity_registry`, `inputs`, `outputs`, `scope`, and `blocked_functions`
+sections. Quantity-registry coverage reports used and unused quantity-unit
+entries and whether outputs use registry defaults or cited source overrides. Category tables
 are emitted as sorted arrays with explicit counts and percentages. Inputs are
 resolved by the specification loader and reported separately as `numeric` or
 `categorical`.