Specify 0.3.0-rc.5: concurrent edits, reported validity, regex profile

[callumalpass]

Specifies 0.3.0-rc.5. Collections keep spec_version: "0.3.0". Most changes relax rc.4 rules; the few that tighten are reported as diagnostics rather than breaking compatibility.

Full release notes: docs/releases/0.3.0-rc.5.md. Chapter 13, "Changes Since rc.4", has the behaviour-change table and an engine checklist.

What changes

Validity is reported, never guaranteed (00, 01, 04). Checks fall into three tiers:

• request/safety checks always reject;
• single-record checks reject writes made through an engine only at error;
• cross-record checks (uniqueness, validate_exists, link targets) are reported and never block.

Concurrent edits (new chapter 12A):

• record identity without in-file IDs;
• move detection;
• a three-way record merge, with per-field strategies in collection.merge (conflict/max/min/union); defaults are max for lifecycle now/today and union for tags and uniqueItems arrays;
• a line-based body merge with append-append union;
• a format-fidelity rule for writers.

Updates (12):

• add/remove list operations;
• body_edits: text edits against a known base body, rebased with the 12A body merge;
• if_revision is opt-in, and engines must never add it on a caller's behalf.

Paths (02): NFC, full case folding, then NFC again, plus a deterministic (n) collision rule. Path-pattern values containing / are rejected.

Uniqueness (07): unique.enforce: write | report, defaulting to report, with real scope semantics.

One regex profile (06, 07, 10): RE2 syntax with regex-lite semantics.

• \d, \w, \s, \b and (?i) are ASCII-only.
• Unsupported constructs such as \p{…} make a type invalid (invalid_pattern).
• The same profile applies to CEL matches(), JSON Schema pattern and match.where.

Determinism:

• match.expr must not depend on time or on other records. In rc.5 this is a nondeterministic_match warning; it becomes an error in 0.3.0 stable.
• generated: sequence has no v0.3 destination.

Fixes for drift:

• id_field has no default;
• ambiguous IDs resolve to null with ambiguous_link, with no filename fallback.

Deterministic link resolution and rename (08, 12):

• the filename tiebreakers are required: referring directory, then fewest path segments, then code-point order, never scan or storage order;
• a rename with reference updating rewrites the links that resolved to the renamed record, including tiebreaker-selected matches, and never rewrites ambiguous links or links to other records. The rewrites are listed in references_updated.

The earlier Unreleased entries ship in rc.5: YAML document records and Bases, seed type upgrades, and saved-view identification.

Conformance

The v0.3 suite gains a merge profile and a merge_records fixture format, documented in tests/v0.3/README.md.

• New tests carry since: 0.3.0-rc.5; changed tests carry changed: 0.3.0-rc.5.
• scripts/concurrent_edits_model.py is an executable model. CI runs 175 fixtures against it; 215 more need a real engine.
• Only one existing test changes its expected outcome: links.duplicate_id_ambiguous now also reports ambiguous_link. The release notes list every new test on which an rc.4 engine would diverge.

Decided vs provisional

• Decided:
  • \p{…} makes a type invalid;
  • body_edits conflicts are detected per line, and a finer granularity would be a compatible refinement;
  • time-dependent match.expr warns now and becomes an error at stable.
• Provisional: 35 choices, listed in the release notes for review.

Related open PRs

Reconciled in e6fb2de. None of the other PRs was changed.

• Fail closed on ambiguous simple links #49, fail closed on ambiguous simple links: disagrees with rc.5. Recommend closing it unmerged. Fail closed on ambiguous simple links #49 drops the filename tiebreakers from v0.2, so that any duplicate filename resolves to null. rc.5 keeps the tiebreakers and makes them required. Align rename references with deterministic resolution #51 also depends on them, so merging both would leave the v0.2 suite contradicting itself; the guardrails would not catch it, because they don't execute legacy fixtures. The part of Fail closed on ambiguous simple links #49 that rc.5 agrees with is in Specify 0.3.0-rc.5: concurrent edits, reported validity, regex profile #61: an ambiguous ID fails closed with no filename fallback, and the selection no longer depends on the provider (tiebreakers are a MUST, depth is counted in segments, and scan, index or storage order is forbidden). Fail closed on ambiguous simple links #49's other concern, that a link can be silently rebound when a create or rename adds a closer candidate, is listed under "Not in this release". If the owner does want fail-closed filename resolution, it needs a v0.3 change to Chapter 08, not a v0.2 edit.
• Align rename references with deterministic resolution #51, rename references with deterministic resolution: agrees with rc.5. Specify 0.3.0-rc.5: concurrent edits, reported validity, regex profile #61 absorbs the semantics for v0.3; Align rename references with deterministic resolution #51 can still merge for v0.2. It touches only tests/level-5/references.yaml (v0.2) and has no textual overlap with Specify 0.3.0-rc.5: concurrent edits, reported validity, regex profile #61. Its rule is that a rename rewrites the link the tiebreakers selected, not every duplicate. Specify 0.3.0-rc.5: concurrent edits, reported validity, regex profile #61 now states that rule for v0.3 in Chapter 12, pins "shortest path" as fewest segments to match mdbase-rs, and adds core/rename-references.yaml and the tiebreaker cases in core/link-ambiguity.yaml. Align rename references with deterministic resolution #51 merges cleanly before or after Specify 0.3.0-rc.5: concurrent edits, reported validity, regex profile #61. One caveat for Align rename references with deterministic resolution #51's own review: v0.2 §12 still says "if a link could refer to multiple files, don't update", which reads as contradicting its fixture unless "multiple" means "after tiebreakers".
• Remove the saved-view source operations #58, remove the saved-view source operations: independent of rc.5, but it must merge after Specify 0.3.0-rc.5: concurrent edits, reported validity, regex profile #61. It is on hold because hosted providers still need the operations, so rc.5 does not absorb it, and rc.5 ships with the source operations. It merges without textual conflicts but mis-merges silently: its changelog entry lands inside the 0.3.0-rc.5 section, because rc.5 replaced ## Unreleased. A local branch, reconcile/pr58-rc5, has Remove the saved-view source operations #58 rebased onto Specify 0.3.0-rc.5: concurrent edits, reported validity, regex profile #61 with the entry under a new ## Unreleased heading. It is not pushed, and the checks and the site build pass on it.

Recommended merge order:

1. Specify 0.3.0-rc.5: concurrent edits, reported validity, regex profile #61.
2. Align rename references with deterministic resolution #51, whenever it is ready; it is independent of Specify 0.3.0-rc.5: concurrent edits, reported validity, regex profile #61.
3. Remove the saved-view source operations #58 once the hold lifts, rebased as in reconcile/pr58-rc5.

Close #49.

Context

These semantics come from the mdbase-next redesign. Its feasibility prototype measured conflict rates of 0.08% of writes with field-level merging, against about 2% with whole-file revision checks.

How to review

Start with docs/releases/0.3.0-rc.5.md, then 12a-concurrent-edits.md, then chapter 13's "Changes Since rc.4". Checks:

python scripts/check_v03_tests.py

plus the site build.