docs(spec): introduce 0.8beta1 spec version that clarifies schema -> schema validation for chained GTS IDs

[Artifizer]

This is the very first part of the:
#51

Summary by CodeRabbit

• Documentation
  • Expanded validation semantics documentation to include Instance and Schema validation rules with transitivity and compatibility guidelines.
  • Added OP#12 (Schema vs Schema Validation) operation to the reference implementation, extending documented operations from OP#1–OP#11 to OP#1–OP#12.

[coderabbitai]

📝 Walkthrough

Walkthrough

Documentation updates expanding the GTS operations reference implementation section to include OP#12 (Schema vs Schema Validation), along with new validation semantics content describing Instance → Schema and Schema → Schema validation rules, transitivity, compatibility, and additionalProperties handling in inheritance chains.

Changes

Cohort / File(s)

Summary

Documentation Updates README.md

Added new validation semantics block for GTS chained IDs covering Instance→Schema and Schema→Schema validation, including transitivity and compatibility rules. Expanded reference implementation section to include OP#12 (Schema vs Schema Validation), updating operation range from OP#1–OP#11 to OP#1–OP#12. Updated multiple headings and descriptions to reflect the new operation and provide clarification on inheritance validation guarantees.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Poem

🐰 A schema dances, checking all its kin,
From instance validation to schema within,
OP#12 hops in with rules so bright,
Inheritance chains preserved just right! ✨

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main change: introducing a new spec version (0.8beta1) that clarifies schema-to-schema validation for chained GTS IDs, which aligns with the README.md additions of OP#12 and expanded validation semantics.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Merge Conflict Detection	✅ Passed	✅ No merge conflicts detected when merging into main

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

Tip

Issue Planner is now in beta. Read the docs and try it out! Share your feedback on Discord.

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

README.md (1)

1-1: ⚠️ Potential issue | 🟡 Minor

Update the top-level VERSION banner to 0.8beta1.

The banner still says “version 0.7” while the Document Version table introduces 0.8beta1, which will confuse readers.

✅ Suggested edit

-> **VERSION**: GTS specification draft, version 0.7
+> **VERSION**: GTS specification draft, version 0.8beta1

Also applies to: 94-95

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@README.md` at line 1, Update the top-level VERSION banner string
"**VERSION**: GTS specification draft, version 0.7" to read "0.8beta1" and
similarly replace any other occurrences labeled "version 0.7" (notably the
instances around lines 94-95) so the README's header and the Document Version
table consistently show "0.8beta1"; ensure the exact formatting of the banner
(bold "**VERSION**: ...") is preserved while only changing the version token to
"0.8beta1".

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@README.md`:
- Around line 263-275: The README's "Instance → schema validation" text claims
"validating against the rightmost type MUST also imply conformance to all base
types by transitivity" while "Schema → schema validation" allows compatibility
checks as MAY, creating a contradiction; update the wording to either require
schema→schema compatibility checks at registry/authoring time or qualify the
MUST as conditional (e.g., "MUST imply conformance ... provided schema→schema
compatibility is enforced"); specifically edit the "Instance → schema
validation" and "Schema → schema validation" paragraphs so they reference the
same enforcement model and use consistent modal language (replace the
unconditional "MUST imply conformance" or upgrade the "MAY" to a required check)
to eliminate the inconsistency.

---

Outside diff comments:
In `@README.md`:
- Line 1: Update the top-level VERSION banner string "**VERSION**: GTS
specification draft, version 0.7" to read "0.8beta1" and similarly replace any
other occurrences labeled "version 0.7" (notably the instances around lines
94-95) so the README's header and the Document Version table consistently show
"0.8beta1"; ensure the exact formatting of the banner (bold "**VERSION**: ...")
is preserved while only changing the version token to "0.8beta1".

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Align “MUST imply conformance” with optional compatibility checks.

You state that validating an instance against the rightmost type MUST imply conformance to all base types by transitivity, but then say schema→schema compatibility checks are MAY. Without mandatory compatibility enforcement (e.g., at registry time), that transitive guarantee doesn’t hold. Consider either requiring schema→schema validation or qualifying the “MUST imply” statement to be conditional on compatibility enforcement.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@README.md` around lines 263 - 275, The README's "Instance → schema
validation" text claims "validating against the rightmost type MUST also imply
conformance to all base types by transitivity" while "Schema → schema
validation" allows compatibility checks as MAY, creating a contradiction; update
the wording to either require schema→schema compatibility checks at
registry/authoring time or qualify the MUST as conditional (e.g., "MUST imply
conformance ... provided schema→schema compatibility is enforced"); specifically
edit the "Instance → schema validation" and "Schema → schema validation"
paragraphs so they reference the same enforcement model and use consistent modal
language (replace the unconditional "MUST imply conformance" or upgrade the
"MAY" to a required check) to eliminate the inconsistency.