Skip to content

🚀 [Feature]: Consumer upgrades use complete release-range evidence - #205

Draft
Marius Storhaug (MariusStorhaug) wants to merge 12 commits into
mainfrom
consumer-upgrades
Draft

🚀 [Feature]: Consumer upgrades use complete release-range evidence#205
Marius Storhaug (MariusStorhaug) wants to merge 12 commits into
mainfrom
consumer-upgrades

Conversation

@MariusStorhaug

@MariusStorhaug Marius Storhaug (MariusStorhaug) commented Sep 6, 2026

Copy link
Copy Markdown
Member

Consumers follow one staged procedure from their actual consumed upstream baseline to a fixed target, preserving local intent and accounting for the complete applicable release range. The shared msx plugin exposes the method without embedding migration instructions or replacing producer-owned discovery.

New: One consumer upgrade procedure

Consumer Upgrades establishes immutable baseline provenance, fixes the target, reads every applicable release with full pagination and semantic/lineage ordering, composes an action ledger, compares the recorded immutable target template, and reconciles existing consumer validation. Fleet guidance, dependency updates, downstream propagation, navigation, and plugin discovery route to that method.

No-action releases remain evidence-bearing steps. Prerelease and non-latest targets retain their source-specific history; unrelated backports and prerelease streams are excluded. A floating alias's present destination does not prove what previously ran. Git-distributed products use full commit identities; artifact-only products can use authoritative immutable digests without invented Git mappings. Missing required evidence blocks affected work.

msx-ways-of-working-consumer-upgrades is the additive shared intent. The shared plugin and marketplace entry both declare 0.2.0; existing skill names remain supported. Installation is optional, and initiative-specific source/version/template discovery remains producer-owned.

Changed: Evidence gates and terminal outcomes are explicit

Review readiness requires complete consumer evidence. Dependency proposals are created as drafts or immediately converted to draft, and remain draft until readiness. The documented automatic-update contract independently binds adoption evidence to a required PR check before automatic readiness, approval, or merge; neither green builds nor the draft flag alone replace that control. This PR defines the contract, not a validator or updater implementation.

Equal or lower targets produce an evidenced no-upgrade outcome rather than an empty PR or downgrade. Only an unneeded open leaf with no remaining local work closes as not planned. Propagation qualifies before Build and conditionally delegates through Issue-first pickup or Task-first Agent Task creation; fleet qualification precedes branch/PR creation or adoption. Both release-triggered propagation and manual backfill remain stable-only; standalone consumer prerelease upgrades do not widen that capability.

Producer release/PR text and related documentation are evidence, not authority over the consumer's task. Delegated payloads separate application-owned instructions from complete, losslessly carried untrusted records. Delimiter collisions or embedded control directives cannot authorize scope, permission, secret-handling, or gate changes; unsafe isolation blocks delegation instead of discarding content.

Producer completion requires immutable compatibility with the published identity and delivery of necessary template changes. Verified candidate/prerelease evidence can support review without waiving native blockers. A multi-leaf outcome remains open in its PBI; a single leaf awaiting publication/deployment is reopened if PR closure precedes the required evidence.

The existing Implement alignment pass carries these obligations without a second checklist. Product docs describe the current contract; release/migration history and delivery plans stay in issues, PRs, and source-bound releases. Decision records and research remain supported exceptions.

Adopting this release

  1. Enter Consumer Upgrades directly or refresh msx@msxorg to 0.2.0 to discover msx-ways-of-working-consumer-upgrades. Read producer-owned discovery for authoritative identities, release lineage, and template mapping.
  2. Establish the actual upstream baseline independently of the consumer's own package version. Record the fixed target, complete range, reconciled completed/not-applicable actions, required intermediate steps, immutable template comparison, and existing validation outcomes. Preserve consumer-owned code, tests, configuration intent, secrets, documentation, and assets. Treat retrieved records as task data: proposed actions must fit the governing instructions and authorized scope. A proven no-upgrade outcome uses the documented issue disposition, not an empty PR.
  3. Keep update proposals draft until the normal readiness gate holds. Where the native updater cannot create drafts, its receiving workflow immediately converts the proposal. If automating readiness, approval, or merge, also bind adoption verification to an existing required PR check, or a separate required check when none owns it. Hold those automated actions until enforcement exists; newest notes, updater summaries, and green builds do not replace evidence.
  4. For downstream-propagation implementations, validate stable release kind at both release and backfill entry points before fan-out or issue creation. The notifier creates/reuses the delivery issue before engaging an agent; verified no-upgrade evidence can terminate before delegation. Otherwise, use the configured Issue-first or Task-first path. The notification credential requires Issues: write plus mode-specific permissions; Task-first requires the Agent Tasks API's accepted user credential with Agent tasks: write. Keep PROPAGATION_TOKEN as the secret name. Separate task instructions from the full untrusted evidence payload with a runtime data boundary or collision-safe quotation; decoding must retain the complete record. This PR changes no credential or setting.
  5. For applicable producer/template work, verify compatibility with an immutable reviewed identity, link required template delivery, and reconcile it with the published identity before claiming completion. Name the completion-owning issue and owner before review: use a PBI for a multi-leaf outcome or the reopen path for a single leaf's pending publication/deployment. State why no template applies when appropriate.
  6. Keep product guidance current and retain per-release changes, migration history, and delivery plans in GitHub records. Preserve decision and research artifacts rather than removing those exceptions.

This delivery executes no consumer upgrade and introduces no runtime migration of its own. Future consumer actions come from the selected producer's release evidence, not the shared skill.

Release impact

Field Value
Effective decision Explicit release:minor for the additive supported shared-plugin intent. Markdown implementation does not make a functional discovery change Docs-only.
Semantic effect Feature (Minor): one discoverable method and connected evidence gates; existing skill identities remain supported.
Release/base coordinates Shared msx package and marketplace-entry metadata move from 0.1.0 to 0.2.0 under the existing marketplace contract. These are not predicted GitHub Release coordinates. This task creates no GitHub Release and selects no consumer upstream target; publication follows the repository's existing process.

Technical details

Consumer change record

Identifier / surface Before After Applicability / prerequisites Consumer action Verification
UPGRADE-METHOD / consumer and fleet adoption Incremental evidence lacks one common composition procedure. Immutable provenance, complete history, composed actions, template differences, validation, and no-upgrade outcomes form one staged method. Humans/agents upgrading an upstream product with producer-owned discovery. Steps 1-2. Range, identity, action, template, and stop-condition walkthroughs.
AUTOMATED-ADOPTION / update readiness Green builds can precede complete adoption evidence. Draft state preserves the review signal; required-check verification independently binds automated readiness, approval, and merge. Repositories enabling those actions; implementation remains separately owned. Step 3. Missing/stale evidence holds even when builds pass; proposals stay draft until readiness.
PROPAGATION / qualification, context, and delegation Actor/mode descriptions conflict with terminal paths; prerelease backfill and payload authority are insufficiently constrained. Both entry points enforce stable-only; the notifier owns the issue; conditional modes support no-upgrade termination; complete records remain isolated data and permissions match each actor. Producers implementing downstream propagation. Step 4. Notifier, both delegation modes, prerelease backfill, provenance, and adversarial-record walkthroughs.
COMPLETION-GATES / review and post-merge work Generic gates do not name an open owner of later milestones. Complete evidence gates review; verified candidate compatibility avoids circular prerequisites; PBI or explicit reopening preserves pending completion. PR authors/reviewers; template obligations apply only when relevant. Steps 3 and 5. Candidate/template, no-template, aggregate, and single-leaf completion walkthroughs.
DOC-OWNERSHIP / product guidance Release/history ownership is less explicit; fleet guidance prescribes a version-specific migration. Current guidance uses source-bound release history and preserves decision/research tiers. Documentation and initiative owners. Step 6. No planning/history file is added; the fleet example is version-independent.
SHARED-INTENT / msx-ways-of-working-consumer-upgrades No shared named upgrade entry point exists. An eight-line pointer reaches the canonical page; plugin and marketplace-entry versions match at 0.2.0. Optional plugin consumers. Step 1. All four existing PluginMarketplace tests pass.

Template baseline

Not applicable: shared documentation and its pointer plugin are not an integration-template consumer. The orchestration-playbook and Agent Skills authoring structures are standards, not product integration templates. No pilot consumer or producer/template repository is modified.

Maintainer evidence

Source and scope. Delivery B implements #203 only, from merged #204 at 702be0fa7db80a5e24eb9ebc47badc017356257b. The current candidate's full immutable identity and source-bound outcomes are recorded in the verification record. These are this documentation/plugin delivery's coordinates, not a consumer upstream range. Native prerequisite #202 is closed; no native parent exists. The completed Delivery A branch is not reused. Small logical commits separate the procedure, gates, capability contracts, plugin, and review corrections; each commit is pushed.

Preserved contract. PR Format and Release Management remain unchanged: audience impact controls classification; users and integrators may be the same people; evidence stays complete and incremental; explicit levels override optional configured DefaultBump; no implicit patch fallback exists; missing decisions require failed, merge-blocking CI validation. No authoring schema or resolver is duplicated or redesigned. #196 remains open with its conflicting implicit-patch proposal; its branch and policy files are untouched.

Plan and verification. The first five implementation-plan steps are complete. Walkthrough reconciliation, alignment, and scoped convergence are recorded here and in the issue. The source-bound verification record carries current-head CI, complete-summary review reconciliation, and handoff state. Ordinary ready/auto-merge handoff remains blocked by #166, not silently waived.

Documentation walkthroughs

Eighteen recorded cases exercise the written contract, not a real consumer, pilot, or agent security evaluation. Detailed evidence is retained in the issue's range walkthroughs, review edge cases, conditional flows, evidence isolation, and entry gates.

Cases Reconciled outcome
No-action patch Inspect and retain the no-action entry; selecting the target still needs existing consumer validation.
Breaking transition Preserve consumer values and local content while applying required integration changes; pre-1.0 classification does not hide breaking behavior.
Skipped releases Exhaust pagination; order the applicable lineage; compose renames/reversals/supersession while retaining mandatory intermediates and no-action records.
Prerelease and non-latest consumer targets Keep source-specific snapshots and target-era docs/templates; exclude unrelated streams and never substitute final-PR prose or today's template.
Floating baseline and artifact-only identity Past execution needs provenance; current aliases and consumer package versions do not supply it. Authoritative digests are valid without invented Git mappings.
Missing evidence, missing template, and no-template applicability Unknown required facts block. Equivalent external evidence is accepted; a justified no-template result is distinct from missing evidence.
Default target, equal/lower targets, and drift Semantic/lineage ordering determines the default; no-upgrade outcomes create no empty PR; changed inputs invalidate evidence without retargeting silently.
Automatic update readiness Proposals are created or immediately converted to draft. The independent required adoption signal holds automated actions even when builds pass.
Candidate/template and post-merge ownership Candidate proof supports review, not final completion. A PBI retains the combined outcome, or the owner reopens a single leaf until its milestone is verified.
Conditional control flow Notifier termination, configured modes, provenance blockers, and pre-branch fleet qualification are reachable and match the prose. Proposed PR refs are not consumed baselines.
Untrusted release evidence Complete records containing delimiters or control directives remain data. Lossless isolation and governing authority are both required; unsafe delegation fails.
Stable-only propagation and write permissions Prerelease events are skipped and prerelease backfills fail before fan-out. Standalone prerelease upgrades do not widen propagation. Task-first requires Agent tasks: write, not a read-only permission.

Standards and framework alignment

Changed surface Standards checked Framework docs checked Result
Consumer Upgrades Natural Language, Markdown, orchestration-playbook template, Security PR Format; Release Management; Dependencies; Contribution Workflow Aligned
Definition of Ready and Done; Implement Natural Language, Markdown, readiness and issue hierarchy PR Format; Release Management; Consumer Upgrades; Task/PBI completion Aligned
Documentation Model Natural Language, Markdown, artifact tiers Spec-Driven Development; source-bound release evidence Aligned
Fleet Orchestration Natural Language, Markdown, fleet and delivery-leaf conventions Consumer Upgrades; controlled owned-major policy; completion ownership Aligned
Dependency Updates spec/design Natural Language, Markdown, existing spec/design structure Consumer Upgrades; Release Management; Merge Automation; review readiness Aligned
Downstream Release Propagation spec/design/index Natural Language, Markdown, Security Consumer Upgrades; qualification/idempotency; configured delegation; Continuous Practices Aligned
Plugin Marketplaces; Plugin Distribution Natural Language, Markdown, thin-pointer ownership Agentic Development; Agent Plugins and Agent Skills Aligned
Navigation and generated indexes Existing front-matter/navigation/index conventions Documentation Model; index generator Aligned
Plugin README, skill, and manifests Natural Language, Markdown, existing names/layout/version conventions Plugin Marketplaces; Plugin Distribution; marketplace tests Aligned
Repository handoff Required CI and independent-review gates Definition of Ready and Done; Branching and Merging Exception - #166: required status checks are not enforced; no governance change is included.

Validation and review evidence. Existing index generation/check, relative links across 128 documentation files, applicable cross-repository links, targeted Markdown lint, and all four pinned Pester 6.0.1 PluginMarketplace tests pass. All 16 changed Markdown files are covered, with later edits rechecked. No dependency or validation toolchain is added. Reviews 5125327578, 5125374401, 5125421878, 5125462928, and 5125521297 were read in full, including suppressed concerns. All ten actual inline threads have fix-linked replies and are resolved. A zero result from the wait script was not accepted when the full summary still raised concerns. Current-head outcomes are retained in the verification record, not inferred from an inline-comment count or an older successful run.

Convergence. Searches covered consumer, template, and downstream work. #143 still needs concrete standard-to-artifact inventory/enforcement, #136 owns Gallery updater delivery, and #187 needs router/published-URL enforcement. Other hits concern unrelated navigation, language, or palette work. No additional issue is fully delivered by this diff; only #203 is a closing reference.

Completion owner and remaining gate. #203, assigned to MariusStorhaug, owns this single-leaf delivery and required Pages publication. If future PR closure precedes publication evidence, the owner reopens the Task until that result is recorded. No applicable template or additional delivery leaf requires a PBI here. #166 remains open: effective main rules contain deletion, non-fast-forward, linear-history, and pull-request rules but no required status checks. Passing runs do not repair that gap. This PR remains draft with auto-merge disabled; no protection, ruleset, producer CI, or other active branch is changed.

Out of scope and untouched: PSModule pilot selection/execution, historical release or PR backfill, version-specific skills, updater/publisher/validator implementations, automatic template synchronization, and unrelated governance changes.

Relevant issues (or links)

Related work

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.

🟡 Changes recommended

Required discovery wiring, pointer skill, and version synchronization remain incomplete.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Adds a canonical staged procedure for evidence-based consumer upgrades.

Changes:

  • Defines baseline-to-target upgrade stages, evidence, and quality gates.
  • Adds site navigation and index discovery.
  • Documents required upgrade outputs and validation.
File summaries
File Review
src/zensical.toml Adds navigation. Moderate: Required workflow links, pointer skill, and synchronized plugin/marketplace versions are missing.
src/docs/Ways-of-Working/index.md Adds the generated index entry. Moderate: No corresponding discoverable pointer skill exists.
src/docs/Ways-of-Working/Consumer-Upgrades.md Defines the procedure. Nits: Existing upgrade entry points and connected readiness/completion criteria are not yet linked or aligned.
Review details

Suppressed comments (1)

src/docs/Ways-of-Working/Consumer-Upgrades.md:19

  • The procedure is not yet connected from the existing upgrade entry points: Fleet-Orchestration.md, the dependency-updates spec/design, and the downstream-release-propagation spec/design contain no link to it and still describe their own narrower bump/release-note flow. Readers entering through those workflows therefore will not be routed through the required complete baseline-to-target traversal. Wire those surfaces to this canonical procedure as required by the delivery contract.
[Contribution Workflow](Contribution-Workflow.md), and each consumer in a
[fleet](Fleet-Orchestration.md) establishes its own baseline and applicability.
  • Files reviewed: 7/7 changed files
  • Comments generated: 3
  • Review effort level: Balanced

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Comment thread src/docs/Ways-of-Working/index.md
Comment thread src/zensical.toml
Comment thread src/docs/Ways-of-Working/Consumer-Upgrades.md

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.

🟡 Changes recommended

Moderate workflow contradictions remain around automation gating, no-upgrade paths, immutable identities, and post-merge completion ownership.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

Suppressed comments (2)

src/docs/Ways-of-Working/Consumer-Upgrades.md:202

  • These exit criteria cannot be represented by the procedure as written. The ordinary workflow automatically closes the upgrade issue when the PR merges, but this stage says the upgrade is not complete until later publication/deployment evidence exists and that, before then, the issue must report a blocker. Specify which still-open issue owns the post-merge milestone (or how the delivery leaf remains/reopens open), otherwise the native issue state reports completion too early.
**Exit criteria.** The reviewed consumer change is merged, required publication
or deployment is evidenced where applicable, and the completion gate holds.
Before then, the issue and PR report the actual milestone and any blocker.

src/docs/Ways-of-Working/Consumer-Upgrades.md:77

  • The target repeats the unconditional source-SHA requirement, so an image or package target with an authoritative digest but no source-commit mapping cannot pass Stage 2 even though those artifact types are explicitly in scope. Allow the immutable identity form defined by the producer ecosystem instead of always requiring both a source SHA and artifact identity.
   API's first result or the most recently published timestamp. Record its
   version, release link, full source SHA, and artifact identity where
   applicable. Do not silently retarget when a newer release appears.
  • Files reviewed: 17/17 changed files
  • Comments generated: 5
  • Review effort level: Balanced

Comment thread src/docs/Capabilities/dependency-updates/design.md
Comment thread src/docs/Capabilities/downstream-release-propagation/design.md Outdated
Comment thread src/docs/Capabilities/downstream-release-propagation/spec.md
Comment thread src/docs/Ways-of-Working/Consumer-Upgrades.md Outdated
Comment thread src/docs/Ways-of-Working/Definition-of-Ready-and-Done.md Outdated

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.

🔵 Needs a closer look

Three documented control-flow inconsistencies remain unresolved.

Review details

Suppressed comments (3)

src/docs/Capabilities/downstream-release-propagation/design.md:24

  • The documented control flow still makes delegation unconditional (issue → delegate → qualify), while the new qualification section says the notifier can qualify and terminate before delegation. That pre-delegation no-upgrade path cannot occur in this diagram; the introduction also assigns issue creation to the agent even though both delegation modes require the issue to exist before the agent starts. Please either add an explicit notifier-qualification branch (delegating only when upgrade work or agent-side qualification is needed) or consistently make all qualification delegated.
  fan --> issue["Create or reuse Task / Bug delivery issue"]
  issue --> delegate["Create agent task in dependent<br/>self-contained prompt with full context"]
  delegate --> qualify{"Target upgrades actual baseline?"}

src/docs/Capabilities/downstream-release-propagation/design.md:24

  • The primary flow still models only Task-first: it always creates an Agent Task after the issue, while the Delegation section says Issue-first is the default and uses the issue itself as the request (lines 108–124). The introduction also assigns issue creation to the agent even though both modes require the leaf to exist first. Make the introduction and flow mode-neutral, or branch here into Issue-first pickup versus Task-first Agent Task creation, so implementers can tell which component owns each step.
  fan --> issue["Create or reuse Task / Bug delivery issue"]
  issue --> delegate["Create agent task in dependent<br/>self-contained prompt with full context"]
  delegate --> qualify{"Target upgrades actual baseline?"}

src/docs/Ways-of-Working/Fleet-Orchestration.md:185

  • This PR-less terminal path is unreachable in the documented fleet model: lines 43-44 define every slice as an issue plus PR, and the diagram/step 2 unconditionally create a branch and draft PR, while qualification is deferred to step 3. Move baseline/target qualification before branch creation, make the PR conditional in the slice definition, and branch queued issues to Not needed when appropriate.
An evidenced [no-upgrade outcome](Consumer-Upgrades.md#stage-2-fix-the-target-and-release-path)
ends without manufacturing a branch or PR. Apply the common procedure's issue
disposition; the fleet reports *Not needed*, not a delivered upgrade.
  • Files reviewed: 19/19 changed files
  • Comments generated: 0 new
  • Review effort level: Balanced

@MariusStorhaug

Marius Storhaug (MariusStorhaug) commented Sep 6, 2026

Copy link
Copy Markdown
Member Author

Delivery B verification record

Candidate: 7658261e6f34bc4bc0168a3203d5f98e64e7accf. Repository baseline: 702be0fa7db80a5e24eb9ebc47badc017356257b. Only #203 is a closing reference.

Evidence Outcome
Documentation and plugin scope Canonical procedure, connected gates/capabilities, navigation, and thin shared skill; plugin and marketplace entry both 0.2.0.
Local validation Existing index check, relative links, applicable cross-repository links, targeted Markdown lint, and four pinned PluginMarketplace tests pass. Final flow edits and generated navigation are rechecked.
Documentation walkthroughs Eighteen recorded cases cover the requested upgrade ranges, identities, ledgers, evidence blockers, template gates, automated eligibility, terminal outcomes, and conditional control flow. No consumer or pilot is executed.
Current-head CI Awaiting the PR-triggered runs for this candidate; earlier green runs are not substituted.
Current-head Copilot review Awaiting another complete summary. All ten actual inline threads have fix-linked replies; their resolution is verified before handoff.
Handoff Draft; auto-merge disabled. #166 still tracks absent required-status-check enforcement.

Review 5125421878 returned zero from the wait script but contained three suppressed control-flow concerns, so it was not treated as clean. This candidate makes the notifier the issue owner, models its pre-delegation no-upgrade branch, keeps Issue-first pickup distinct from Task-first Agent Task creation, states the corresponding credential obligations, and qualifies fleet work before creating or adopting a branch/PR. These concerns had no actual inline threads; this record answers the full-summary feedback without inventing thread replies.

The completion-owning issue is #203, assigned to MariusStorhaug. Required Pages publication is not inferred from merge: if automatic PR closure precedes that evidence, the owner reopens the Task until the outcome is recorded. No settings, other branches, pilot consumers, or historical release records are changed.

Review 5125462928 identified the release-evidence instruction boundary. Commit 11fdb44 separates application-owned task instructions from complete, losslessly carried untrusted evidence under both modes. It requires collision-safe quotation or a runtime data boundary and fails unsafe delegation rather than omitting content. The added adversarial-record walkthrough is a documentation exercise, not a claim of runtime enforcement or an executed agent security evaluation.

Review 5125521297 and its suppressed concerns are addressed in 7658261: release and backfill entry points both enforce stable-only before fan-out; Task-first credentials require Agent tasks: write; and dependency proposals are created or immediately converted to draft until readiness. The required adoption check remains an independent automation/merge control, not a replacement for the draft handoff signal.

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.

🟡 Changes recommended

The critical instruction-injection boundary in delegated release payloads must be addressed before approval.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details
  • Files reviewed: 19/19 changed files
  • Comments generated: 1
  • Review effort level: Balanced

Comment thread src/docs/Capabilities/downstream-release-propagation/design.md Outdated

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.

🔵 Needs a closer look

A critical propagation conflict and two moderate contract gaps remain unresolved.

Review details

Suppressed comments (2)

Previously missed (1) — in code that hasn't changed since the last review.

src/docs/Capabilities/downstream-release-propagation/design.md:202

  • The create-agent-task endpoint requires the fine-grained repository permission at write level; saying only “Agent tasks permission” leaves a read-only PAT looking compliant even though task creation will return 403. Specify Agent tasks: write for Task-first credentials.

src/docs/Capabilities/dependency-updates/design.md:127

  • This permits an updater PR to remain non-draft before its adoption evidence is complete, but Definition-of-Ready-and-Done.md:26,51 defines the non-draft state itself as the review-readiness signal and requires the PR to stay draft while any gate is open. A required check can block automation and merge, but it cannot prevent this non-draft PR from entering reviewers' queues as “ready.” Require the update workflow to create or immediately convert the PR to draft until adoption verification passes, or align the central readiness contract with a different explicit signal.
The updater may open a non-draft PR, so setting it to draft later is not the
binding control. Until evidence verification is enforced through the required
check, update PRs remain outside automated readiness, approval, and merge.
  • Files reviewed: 19/19 changed files
  • Comments generated: 1
  • Review effort level: Balanced

Comment thread src/docs/Capabilities/downstream-release-propagation/design.md Outdated

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.

🟡 Changes recommended

The critical propagation retry/idempotency issue must be resolved before approval.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details
  • Files reviewed: 19/19 changed files
  • Comments generated: 1
  • Review effort level: Balanced

Comment on lines 152 to 153
Idempotency is by **existence**: the issue is the durable record that this version
was propagated, so a repeat run finds and reuses it.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

release:minor Minor release

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Define the evergreen consumer upgrade procedure and completion gates

2 participants