[miroslavpojer]

Overview

CONTRIBUTING.md now states the ecosystem's development rules that no page held: the release order, the version rules, changes across repositories, the repository conventions with the composite-action template, and the canon and review rules of a PR. Each is stated once, and links the page that holds its details.

Per criterion:

• The seven rules, each once, linked:
  • Release order and version rules: § Releasing the ecosystem. Its steps link docs/_integration/README.md § Release go/no-go and § Run a milestone target, each component's DEVELOPER.md § Release, and the v0.1.0 release notes as the model of the compatibility table. The version rules link living-doc-utilities docs/api.md § Versioning for pinning and bumping.
  • Changes across repositories: § Changes across repositories.
  • Repository conventions and the composite-action template: § Ecosystem conventions, linking living-doc-generator-markdown's action.yml and DEVELOPER.md § Action venv. The template states only what action.yml does at v0.1.0 (005a058, today's master).
  • Canon check and review: § PR Description.
  • ## Purpose, ## Contents and the level table's D row name the new sections; root CONTEXT.md § Conventions points to them.
• Checks: all of AGENTS.md § Check passes locally: pytest over tests/examples, tests/docs and tests/integration (354 passed); examples_check.py; retired_names_check.py --strict at the pins; the agentic scripts and agentskills validate; sync-canon-copies.sh all and regen-collector-snapshots.sh with no change; run-testbed-stage.sh; lychee over every tracked page (0 errors).
• Follow-ups, canon, framework: the sections below.

Three points go past the issue's wording, each from a source it names:

• Step 2: each component's release PR sets its version as well as re-pinning living-doc-utilities (step 1 of its § Release). The tag is cut at the commit the go/no-go ran, so the bump comes first; for v0.1.0 each component's "Prepare the release" PR did both.
• The version rules say "contract or public-API change", as living-doc-utilities § Versioning does.
• § Ecosystem conventions covers living-doc-utilities and the components only: this repository has no Makefile, and its tutorial workflow calls actions by tag.

Follow-ups: component pages that contradict the version rules

• living-doc-collector-gh DEVELOPER.md § Versioning: "MAJOR: a breaking change to a schema or API contract" and "MINOR: a new feature or a non-breaking enhancement". Under 0.x a minor may break, and a contract change is a living-doc-utilities minor. Its § Release example tag, v1.0.1, is a 1.x tag.
• living-doc-toolkit SPEC.md § 4 Cross-cutting contract changes: "additive (no bump), or breaking (major bump of the affected package)". Under 0.x a breaking change is a minor.
• living-doc-toolkit .github/copilot-review-rules.md: "breaking (major bump of the affected package)", citing the same section.

Checked, no contradiction: living-doc-utilities docs/api.md § Versioning; living-doc-toolkit and living-doc-generator-markdown DEVELOPER.md § Versioning. living-doc-collector-ad and living-doc-generator-pdf state no package version rule.

Canon rules relied on

• docs/introduction/principles.md § The frame, F5: living-doc-utilities holds the contract models, so a contract change is its release, and the consumers re-pin.
• Same page, F7: no component mirrors a model, so each consumer pins living-doc-utilities instead of copying it.
• CONTRIBUTING.md § Writing documentation: level D, flow rule 3 (a reference fact is linked, never restated), and the page anatomy.
• docs/CONTEXT.md § Conventions: a link to a component page points at master.

No disagreement with the canon came up.

Release Notes

• CONTRIBUTING.md § Releasing the ecosystem states the release order across the repositories and the version rules.
• CONTRIBUTING.md § Changes across repositories: one issue per repository, a Pointer issue here, and a "Cross-repo change — N of M" block in each PR.
• CONTRIBUTING.md § Ecosystem conventions: living-doc-generator-markdown is the reference repository, and its venv step is the composite-action template.
• CONTRIBUTING.md § PR Description: a PR names the canon rules it implements, and gets a Copilot review before the owner's.

Framework

• Stays inside the frame (F1–F7)
• Bends frame row F_ — exception E_ added to docs/introduction/principles.md in this PR

Contributor documentation only: no part's responsibility changes. The version rules rest on F5 and F7.

Related

Closes #108