@mitre/hdf-schema 3.6.0-rc.5 → 3.6.0

package/README.md

@@ -191,12 +191,12 @@ Interactive schema reference documentation is published at:
 
 ### What's new in v3.6.0
 
-- **No structural schema changes.** Every document type and primitive is structurally identical to v3.5.x: no fields, enum values, or constraints were added, removed, renamed, or tightened. v3.5.x documents validate unchanged under v3.6.0, and documents produced under v3.6.0 validate against the v3.5.x schemas.
+- **`preAmendmentChecksum` on the Results root.** Optional `Checksum` recording the document's hash as it stood immediately before the most recent amendment application, written by `hdf amend apply`. It covers the results file's raw bytes as read, not a canonical form, and records only the most recent application rather than accumulating. Distinct from the override-level `previousChecksum`, which chains amendments to one another over a canonical form. This is the only structural change in v3.6.0; everything else below is description-level.
 - **`previousChecksum` semantics stated precisely** (description-only, on `Standalone_Override`, `Status_Override`, and the POA&M element) — each amendment's checksum is recorded by the *next* one, so an in-place edit is detectable only for an amendment that has a later one chained to it. The chain is not tamper-proof: the final amendment, the document envelope, deleted trailing amendments, and a wholesale recompute are outside what it can detect; use `signature` for non-repudiation. The field is omitted (not `null`) on the first amendment. This is the contract `hdf amend verify` enforces.
 - **Schema descriptions reflowed into paragraphs** and the source files pretty-printed one value per line. Cosmetic in the source, but the bundled `dist/schemas/` descriptions now carry paragraph breaks, which IDE tooltips render.
 - **`computeEffectiveStatus` helper delegates to the canonical status ladder** in `@mitre/hdf-utilities`. **Behavior change** for `@mitre/hdf-schema/helpers` consumers: the helper no longer returns a pre-set `effectiveStatus` verbatim, and it now applies the governing non-expired `statusOverrides` entry and the error roll-up ahead of the impact-0 `notApplicable` short-circuit, matching the CLI and converters.
 - **`@mitre/hdf-schema/testhdf` sub-path export** — test-only builders (`req`, `baseline`, `doc`, `results`, `baselineDoc`, `override`, `amendments`, `system`, `plan`, `evidencePackage`, `changeEvent`, `comparison`, and friends) that construct schema-valid documents for downstream test suites, with a Go counterpart at `github.com/mitre/hdf-libs/hdf-schema/testhdf/go`.
-- **Compatibility.** Fully compatible in both directions at the schema level. The only behavior change is in the `computeEffectiveStatus` helper above.
+- **Compatibility.** The one schema addition is optional, so v3.5.x documents validate unchanged under v3.6.0. A v3.6.0 document carrying `preAmendmentChecksum` will not validate against the v3.5.x schemas, which reject unevaluated properties; strip the field or validate against v3.6.0.
 
 ### What's new in v3.5.0
 

package/dist/go/hdf.go

@@ -141,6 +141,16 @@ type HDFResults struct {
 	// Reference to an hdf-plan document describing the assessment plan that produced these                            
 	// results. May be a relative path, absolute URI, or fragment identifier.                                          
 	PlanRef                                                                                     *string                `json:"planRef,omitempty"`
+	// Hash of this results document as it stood immediately before the most recent amendment                          
+	// application. Written by `hdf amend apply` when it applies at least one override; an apply                       
+	// that matches nothing leaves the document untouched. The hash covers the results file's                          
+	// RAW BYTES as read, not a canonical form, so reproducing it requires the byte-identical                          
+	// original — reformatting or re-serializing the source changes the value. Only the most                           
+	// recent pre-application state is recorded: applying amendments to an already-amended                             
+	// document REPLACES this value, so it is a single link back one step, not a growing chain.                        
+	// Distinct from the `previousChecksum` inside an override, which chains amendments to each                        
+	// other and is computed over a canonical JSON form.                                                               
+	PreAmendmentChecksum                                                                        *Checksum              `json:"preAmendmentChecksum,omitempty"`
 	// Optional reference to automated remediation resources (Ansible playbooks, Terraform                             
 	// scripts, etc.) for fixing failing requirements found in this assessment.                                        
 	Remediation                                                                                 *Remediation           `json:"remediation,omitempty"`