Re-vendor the drifted workflow contract and record the hub debt - #17
Merged
Conversation
The carried CI/CD contract had fallen one revision behind the hub on the release-classification guarantee, where the hub describes the smoke-build case in terms the local copy had lost. The deploy this repo now performs has no destination in that contract, and the shape it needs is a variant of the existing registry-push leaf rather than a new release surface: the same dispatch-gated leaf publishing to its own destination, differing only in the build tool and the transport. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
This pull request updates the repository’s workflow contract documentation to match the hub’s current specification and records the remaining spec “debt” that needs to be upstreamed for this repo’s deploy/publish shape.
Changes:
- Re-vendored
WORKFLOW.mdD2.2 wording to align with the hub contract, clarifying smoke-build behavior (early-exit check vs job-level skip) and its downstream implications forneeds:. - Added an “Owed to the hub” section to
TODO.mddocumenting the required hub spec update for this repo’s publish/deploy destination and verification guarantee.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| WORKFLOW.md | Updates the D2.2 contract text to match the hub’s expected smoke-build validation semantics without changing the repo’s release model. |
| TODO.md | Records the remaining upstream contract work needed for the repo’s deploy destination/verification shape, linked to the hub issue. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Expected correctness of the release flow is defined by
WORKFLOW.md, so the flow was audited against it rather than against the run output. That surfaced two things.The carried contract had drifted.
WORKFLOW.mdis carried from the hub, and the local copy had fallen one revision behind on D2.2, where the hub describes the smoke-build case in terms this copy had lost. Re-vendored, and it now matches the hub exactly modulo line endings, which differ deliberately because this repo declareslineEndings: "lf".The deploy has no destination in the contract.
Output Seam by Destinationlists a file on the release, a package-registry push, an image-registry push, and no-file-target. A built tree shipped to a host the project owns is none of those.The shape it needs
Recorded in
TODO.mdunder "Owed to the hub", and reported to ProjectTemplate#456, which was already open and waiting on exactly this measurement.It is a variant of the existing registry-push leaf, not a fourth release surface. A NuGet or PyPI leaf builds an artifact and pushes it to its own destination, contributing no
release-asset-*. This repo does the same, dispatch-gated like every other publish. Only the build tool and the transport differ, and neither touches the seam.So the concern in that issue, that a content push to a host conflicts with the never-publish-on-merge rule, does not arise. The release model, the branching model, and that rule all hold unchanged.
What the type genuinely needs is a destination row plus one guarantee: that a deploy is verified against the running host by release id rather than by the transport exiting zero. That part is new, and it is new because of what the destination is rather than how it is reached. A package registry dedupes server-side and can be asked what version exists; a filesystem does neither.
Verification
The release dispatched from
developbefore this change conformed to D4.1 through D4.3: dispatch-only publish, prerelease because the branch is not the public-release ref,target_commitishon the built commit, and a release carrying the source archives plusREADMEandLICENSE.WORKFLOW.mdcontent-matches the hub. Markdownlint, cspell, and editorconfig-checker are clean.🤖 Generated with Claude Code