[documentation-writing-alignment] Resolve the bootstrap major-bump policy conflict #573

Context and request

Module authors receive conflicting versioning guidance after bootstrap. The bootstrap guide says that only a change to the core's own contract is a major bump. The semantic-versioning reference requires a major bump for any incompatible public-API change. A reader needs one approved version policy that covers both the core and later exported functions.

This discrepancy is found during #559. Its prose-only draft #565 preserves the requested bootstrap contract and does not choose a new version policy. Searches of open issues for "bootstrap" "major" and "version policy" find no separate issue that owns this conflict.

Evidence and reproduction

Environment: documentation at PSModule/Process-PSModule@64ffb1d87f86bd5d487891fdb140b78385a00531; no runtime or workflow change is involved.

1. Read Module bootstrap: After the core lands. It says that "only a change to the core's own contract" is a major bump.
2. Read the versioning reference. It defines the public API as all exported functions, variables, classes, and enums, and requires a major bump for incompatible changes.
3. Compare the guidance for an incompatible change to a later exported function outside the bootstrap core. The two statements do not give the same rule.

Observed result: The bootstrap wording restricts major changes to the core contract; the reference applies major changes to the complete public API.

Expected result: Both pages state the same approved rule, including any explicit and justified exception. Do not infer the decision from a prose-only writing change.

Regression status: Unknown. The conflict exists in the pinned snapshot; no last known consistent version is established.

Workaround: No verified workaround is recorded. The version-policy owner must resolve the conflict before a reader relies on the core-only restriction.

Acceptance criteria

• The version-policy owner records one approved interpretation and its source.
• Bootstrap and the canonical versioning reference agree for incompatible changes to both the core and later exported functions.
• The initial bootstrap branch and release contract remains unchanged unless an explicit policy decision requires a separately reviewed change.
• Examples or a repeatable text review cover both core and non-core public-API changes.
• No prose-only fix claims that runtime or CI enforcement changes with the wording.

Technical decisions

The verified root-cause boundary is conflicting documentation scope: the bootstrap core versus the complete exported public API. The policy decision is unresolved. Keep the correction to one focused PR after that decision. This issue does not select a version bump, alter release labels, or upgrade a workflow.

A runtime regression test cannot decide the intended documentation policy. Before implementation, use a repeatable two-case review: an incompatible core change and an incompatible non-core exported-function change. Record the approved expected result for each case, demonstrate the disagreement in the baseline text, and show agreement after the correction.

Implementation plan

• Reproduce the two-case policy disagreement from the pinned source before editing.
• Record the version-policy owner's decision and identify the canonical source.
• Establish the expected core and non-core results for the repeatable documentation review.
• Correct only the affected guidance and links, preserving unrelated bootstrap procedures.
• Repeat the two-case review and run the existing Markdown and site checks. Record the evidence without claiming new runtime enforcement.