Skip to content

Release and propagation guidance uses direct technical prose - #266

Open
Marius Storhaug (MariusStorhaug) wants to merge 3 commits into
mainfrom
release-capability-writing
Open

Marius Storhaug (MariusStorhaug) wants to merge 3 commits into
mainfrom
release-capability-writing

Conversation

@MariusStorhaug

@MariusStorhaug Marius Storhaug (MariusStorhaug) commented Nov 4, 2026 •

Copy link
Copy Markdown
Member

Release and downstream propagation guidance uses direct en-US statements for publication hazards, recovery, consumer qualification, and delegation. Contributors, operators, and consumers can read each condition separately. No release behavior, setting, permission, command, or consumer policy changes, and readers do not need to change configuration or references.

Changed: Release and consumer handoff guidance is explicit

The release spec separates partial publication, mutable pull-request metadata, and advancing source. It retains all three consequences of recomputing from current state: different bytes under a reserved version, omitted accumulated changes, and advertising an incomplete release. The lifecycle design separates reservation and consumer-change baselines without changing their version example or publication lineage.

Publishing-target prose separates completion, retry, and withdrawal explanations. The moved-tag guide states the trusted-remote check and exact-version-tag safeguard directly. Propagation guidance describes outdated references without idioms and separates prompt context, qualification, paused execution, completion, and failure. Guide instructions remain imperative. These changes clarify the documented target-state contract; they do not prove that a producer implements or enforces it.

Technical details

Scope and immutable evidence

The fixed review baseline and scoped PR base are 1b0d4893c8fefabe604d04393068a8ff6f848082. The completed prose head is 21c7794d00990954e059de2d7e82cbf48ebf2512. The scoped comparison is git diff 1b0d4893c8fefabe604d04393068a8ff6f848082 21c7794d00990954e059de2d7e82cbf48ebf2512 -- src/docs/Capabilities/release-management src/docs/Capabilities/downstream-release-propagation.

All eight assigned pages were read in full and changed. There are no unchanged owned pages. Only these eight paths differ from the baseline. Front matter, shared indexes, scripts/tests, workflow/configuration, dependencies, and the paths owned by #240 are unchanged. Both generated INDEX blocks are byte-identical; only handwritten index prose changes. No restructure, new tooling, or enforcement is added.

Concrete before/after evidence

Surface Before After
Release spec Problem “Publication can expose one destination before another fails, mutable pull-request metadata can change before a retry, and a later commit can reach the stable branch while an earlier artifact is still incomplete.” “Publication can expose one destination before another fails.” “Mutable pull-request metadata can change before a retry.” “A later commit can reach the stable branch while an earlier artifact is still incomplete.” All three recomputation consequences remain immediately after these statements.
Release announcements “attempts and acknowledgements”; “If acknowledgement is missing, it may resend the same logical message; receivers therefore observe…” “attempts and acknowledgments”; “If acknowledgment is missing, it may resend the same logical message. Receivers therefore observe…” At-least-once delivery and deduplication by release identity remain.
Publishing targets “Durable per-target progress keeps the release incomplete until all required targets succeed, then lets a retry resume safely.” “Durable per-target progress keeps the release incomplete until all required targets succeed. A retry uses that progress to resume safely.”
Moved-tag guide “Confirm that origin is the intended trusted producer and that no exact-version-tag integrity incident is being normalized.” “Confirm that origin is the intended trusted producer. Do not use this procedure to accept a moved exact version tag.” All backup, pruning, force-fetch, trust-boundary, and verification commands remain exact.
Propagation spec “A reference drifts the moment the producer cuts a release.” “A producer release can make a reference outdated.” The surrounding prose retains the security-fix and runtime-failure risks and mandatory assessment of every dependent.
Propagation design “The notification runs in the producer when a release is cut.” “The notification runs in the producer after a stable release.” Stable-only event/backfill gates and both delegation modes remain unchanged.

Preservation and semantic review

A one-off read-only comparison against the fixed baseline confirms unchanged front matter, heading/anchor lines, links, inline-code sequence, all 40 fenced blocks, all 182 BCP 14 keyword occurrences in their original sequence, and both generated INDEX blocks. The complete release-spec requirements and scenarios, from ## Requirements through the end of the page, are byte-identical. All eight test-first prose acceptance examples pass after reporting eight expected failures before editing. The five selected hazard/consequence sentences contain 8-16 whitespace-delimited words; that check is not a full STE-conformance claim.

Manual comparison confirms that these contracts retain their meaning: durable intent and phase-aware recovery; permanent reservations and immutable source/artifact identity; approved source and provenance; labels, defaults, version/channel/target rules; publication lineage and source-bound notes; adoption and template evidence; bounded consumer policies and narrower pinning standards; moved-tag safeguards; fixed propagation targets, no-upgrade disposition, correlated execution, untrusted evidence boundaries, permissions, and human review. A normative requirement remains a contract, not implementation or CI-enforcement evidence.

The existing Failure behaviour heading stays unchanged to preserve its anchor. Exact API states such as cancelled, technical nouns/verbs, identifiers, native syntax, examples, guide imperatives, and generated output are accepted differences. No policy contradiction or cross-owned repair is introduced or left unresolved by this diff.

Validation and plan progress

Local Markdown lint processed the exact eight assigned files and reported zero issues. The existing relative-link check passed for 130 documentation pages. The cross-repository check resolved all 7 links across 134 Markdown files. The existing pinned Pester 6.0.1 runner passed all 66 tests in 6 suites locally and again in final-head CI. No executable code or test changed. The final local build passed with existing Zensical 0.0.50; final-head CI also passed with the declared 0.0.59 requirement. No dependencies or tooling were added or changed. git diff --check passes, and the clean local/remote branch heads both equal the immutable head above.

Current-head verification Result Evidence
Docs workflow Success: Lint, Build, Links, and Test pass; Publish is skipped for this PR Run 41830087744, bound to 21c7794d00990954e059de2d7e82cbf48ebf2512
Declared site toolchain Zensical 0.0.59; “No issues found” Build job logs the pinned requirement and successful build
Pester 66 passed, 0 failed, 6 suites; pinned 6.0.1 Test job
Cross-repository links Success Run 41830087692, bound to the same immutable head
Automated review Approved; 0 new inline comments; existing review script exits 0 Review, bound to the same immutable head

The Task's source review, all-page reading, test-first examples, first complete improvement, early draft PR, producer prose, consumer prose, and final verification are complete. The Task body records the full path dispositions, before/after evidence, validation links, accepted differences, and immutable delivery record. The work is delivered in three small, pushed commits. No remaining blocker is identified.

This PR remains open and draft, assigned to its author, by request. No ready transition or merge is requested. GitHub auto-merge is absent, Agent merge is disabled and has never run, and there are no release:* labels.

The scoped convergence sweep searched open MSXOrg/docs issues for "release-management" in:title,body and "downstream release propagation" in:title,body. It found the closing Task and separate campaign Tasks #246, #247, #249, #253, and #255. Their separately owned deliverables are not closed by this eight-page diff. No additional issue converges.

Standards and framework alignment

The standard set is fixed at the review baseline: Documentation Model, Natural Language, Technical Writing Guide, Markdown, Documentation, and the applicable specification/design/guide templates. The official STEMG overview and FAQ were read; relevant Issue 9 rules and dictionary entries were consulted from the verified local PDF/extract. The PDF MD5 is 9c720341c350ed77943b2c73d01c716f. Reference copies remain local and are not republished. These checks do not claim full STE conformance.

Changed surface Standards checked Framework docs checked Result
src/docs/Capabilities/release-management/spec.md Fixed standard set; specification template Release requirements FR1-FR17 and NFR1-NFR4; release design Fixed in this PR; normative requirements/scenarios unchanged
src/docs/Capabilities/release-management/design.md Fixed standard set; design template Durable lifecycle, source-bound notes, publication lineage, consumer policies Fixed in this PR; contracts and exact version example preserved
src/docs/Capabilities/release-management/design-publishing-targets.md Fixed standard set; design template Seven-dimension target contract and all five target mappings Fixed in this PR; mappings, constraints, and safeguards preserved
src/docs/Capabilities/release-management/accept-moved-release-tags.md Fixed standard set; guide template Owned aliases, immutable exact tags, artifact-specific pinning Fixed in this PR; commands and warnings preserved
src/docs/Capabilities/release-management/index.md Fixed standard set; navigation conventions Release capability scope Fixed in this PR; generated table unchanged
src/docs/Capabilities/downstream-release-propagation/spec.md Fixed standard set; specification template Qualification, complete-range adoption, idempotency, human review Fixed in this PR; obligations preserved
src/docs/Capabilities/downstream-release-propagation/design.md Fixed standard set; design template Trigger, fixed target, evidence trust boundary, both delegation modes, retry states Fixed in this PR; native states, gates, and stable anchors preserved
src/docs/Capabilities/downstream-release-propagation/index.md Fixed standard set; navigation conventions Propagation and evidenced no-upgrade scope Fixed in this PR; generated table unchanged

The effective repository route in .github/workflows/Docs.yml builds documentation and deploys Pages. The workflow set has no versioned release route. A Pages deployment alone does not invoke Release Management, so there is no release-decision block, publication-baseline claim, or release:* label.

Related references

@MariusStorhaug Marius Storhaug (MariusStorhaug) changed the title Release guidance separates publication and recovery hazards Release and propagation guidance uses direct technical prose Nov 4, 2026

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟢 Approved

No active review issues remain for the release-management and downstream-propagation documentation clarifications.

No open issues 🎉

What changed in this PR

This documentation-only PR clarifies release management and downstream propagation guidance with direct technical prose. It preserves the existing release contracts, commands, safeguards, and consumer policies.

Changes:

  • Separates publication hazards, recovery rules, and version-baseline explanations into clearer statements.
  • Clarifies moved-tag safeguards, consumer qualification, and delegation states.
  • Uses en-US prose while preserving existing anchors, technical identifiers, and generated indexes.
File Description
src/​docs/​Capabilities/​release-management/​spec.md Clarifies release entry paths, publication hazards, and durable intent.
src/​docs/​Capabilities/​release-management/​index.md Simplifies the capability overview.
src/​docs/​Capabilities/​release-management/​design.md Clarifies lifecycle rules, version baselines, and announcement delivery.
src/​docs/​Capabilities/​release-management/​design-publishing-targets.md Separates completion, retry, withdrawal, and target constraints.
src/​docs/​Capabilities/​release-management/​accept-moved-release-tags.md States trusted-remote and exact-version-tag safeguards directly.
src/​docs/​Capabilities/​downstream-release-propagation/​spec.md Clarifies dependency risks, delegated upgrades, and backfill.
src/​docs/​Capabilities/​downstream-release-propagation/​index.md Simplifies upgrade and no-upgrade outcome descriptions.
src/​docs/​Capabilities/​downstream-release-propagation/​design.md Clarifies triggers, prompt context, qualification, and execution states.

Review effort: Balanced

@MariusStorhaug
Marius Storhaug (MariusStorhaug) marked this pull request as ready for review November 4, 2026 14:43

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[documentation-writing-alignment] Clarify release and propagation capability prose

2 participants