037-amendment-authoring

An amendment is declared once, in the amending spec

Lifecycle approvedImplementation completeVerification unknownQualification unknown

The corpus has always authored amendments one way: the `amends` edge is declared in the amending spec's frontmatter, and the amended spec's `spec.md` is left alone. Spec 023 amends 004 without editing it; spec 033 amends 005 without editing it. The rule is enforced by nothing, stated by nothing, and visible only as a pattern in the history, so a reader looking at a diff cannot tell a deliberate convention from an omission. That is not hypothetical: the review of PR #89 asked six separate times for spec 030 to be edited to record that 038 had amended it, withdrew the request once on its own analysis, then raised it again, because nothing in the corpus says which answer is right. This spec writes it down, in the one-page contract where a reader checking the edge vocabulary will find it. It adds no mechanism, because the two mechanisms already exist and work: the gate's amends-awareness (005 §3.3) widens the owner set so editing the amender clears a violation on the amended spec's territory, and `registry relationships` reports `amended_by (incoming)` so the amendment is discoverable from the amended spec's side without that spec being touched.

Read the full pinned specification ↗

Relationships

Claimed units

  • establishes
    {
      "anchor": "amendment-authoring",
      "file": "standards/spec/contract.md",
      "kind": "section"
    }

Source headings

  1. 037: Amendment authoring
  2. 1. Purpose
  3. 2. Territory
  4. 3. Behavior
  5. 3.1 The rule
  6. 3.2 Why the predecessor is not edited
  7. 3.3 Discovery is a compiled read, not a prose pointer
  8. 3.4 The gate half is unchanged
  9. 4. Out of scope

Frozen anchors

No frozen anchors declared.