V4.3 revision to Document Types

docs/ver4.3/scope_boundary_v4_3.md

@@ -18,12 +18,12 @@ This document defines the frozen boundary for the constrained-settings revision
 ### 2. Document Type Maintenance
 
 - List active and inactive Document Types.
-- Add new types with a stable unique code and user-facing label.
-- Edit mutable labels and sort order.
+- Add new types with a unique user-facing label.
+- Edit labels and active state.
 - Activate or deactivate types without invalidating historical Documents.
-- Do not allow changing a stable code after creation.
 - Allow deletion only when no Document references the type.
 - Allow label changes regardless of whether the type is referenced.
+- Display types alphabetically by label.
 
 ### 3. Person Role Maintenance
 
@@ -74,9 +74,10 @@ This document defines the frozen boundary for the constrained-settings revision
 
 ## Locked Design Decisions
 
-### A. Registry Codes Are Immutable
+### A. Registry Identity and Lifecycle
 
-- Document Type and Person Role codes are stable identifiers.
+- Document Types use UUID identity and case-insensitively unique labels; no separate code is exposed or stored.
+- Person Role codes remain stable identifiers.
 - Labels and active state remain mutable.
 - Historical references remain valid when a registry entry is inactive.
 - Labels may be updated for referenced and unreferenced entries.
@@ -104,7 +105,7 @@ This document defines the frozen boundary for the constrained-settings revision
 
 - Person Roles are ordered by label and then stable code.
 - V4.3 does not add a `sort_order` field to Person Roles.
-- Document Type sort-order maintenance remains in scope because `DocumentType.sort_order` is already part of the V4 schema.
+- Document Types use alphabetical label ordering and have no persisted sort order.
 
 ### F. Settings Are Installation-Local
 
@@ -122,11 +123,11 @@ This document defines the frozen boundary for the constrained-settings revision
 
 ## Acceptance Criteria
 
-1. Document Type and Person Role maintenance preserves stable codes and historical references.
+1. Document Type UUID identity and Person Role stable codes preserve historical references.
 2. Inactive registry entries remain visible on historical records but are excluded from default create selectors.
 3. Labels can be changed for referenced or unreferenced registry entries.
 4. An unreferenced Document Type or Person Role can be deleted, while deletion of a referenced entry fails without partial mutation.
-5. Document Type sort order is maintainable; Person Roles use deterministic label/code ordering without a schema addition.
+5. Document Types use alphabetical label ordering; Person Roles use deterministic label/code ordering.
 6. Prompt edits are restricted to existing Markdown files directly beneath the configured prompt directory.
 7. Prompt saves use atomic replacement, retain exactly one previous-version backup, and support explicit recovery.
 8. A prompt edit affects future Jobs only and leaves stored Job provenance unchanged.