Repository navigation
Publish only after CI succeeds, and drop superseded docs - #77
Merged
Merged
Conversation
The release workflow waits until the CI workflow for that commit has succeeded. Issue notes 18, 42, and 66 are removed; the decisions are in the requirements. The demos show the current init pointer and fleet board. Co-authored-by: wjcjttl9 <wjcjttl9@gmail.com>
TiantianFlow
marked this pull request as ready for review
October 22, 2026 02:08
…ci-ff1f # Conflicts: # CHANGELOG.md Co-authored-by: wjcjttl9 <wjcjttl9@gmail.com>
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 free
to 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.
A tag publishes only after the CI workflow has succeeded for that commit. The issue notes that no longer describe the product are gone, and the demos match the current init pointer and fleet board.
Release
.github/workflows/release.ymlwaits, up to 30 minutes, for a completed CI run on the tagged commit. The newest finished run must be a success. A run still going, a failure, a cancellation, and a commit with no CI run do not publish. The build then checks it is still that commit. A manual rerun waits the same way. CI itself is unchanged: it runs on pushes tomainand on pull requests, so the tag has to be the merge commit onmain.Docs
The demos stay. They are the illustrated run both READMEs link to, and a test checks that they still show scenario 1's checklist. What was wrong was the sample: it ended on a project
skills/operator.mdthatinitnow deletes, and it showed mail underboard/instead offleets/main/board/. Both languages now show this version's pointer (the packaged skill on a fresh init, the global file when that exists) and the fleet board path.docs/architecture.mdno longer says it describes 0.4.0.Issues #18, #42, and #66 are removed. #18 recommended against global settings and still described an in-repo
.foil/. #42 specified one viewer process per project; the shipped viewer is one page for every project. #66 restated the requirements and the reasons for a decision that has already shipped. The behavior is indocs/requirements.md, and 0.6.0 in the changelog records the breaking change. D6 and D8 now say a plan stays as the record of that release, and an issue note does not.The old plans stay, with a line that current behavior is the requirements.
plan-v0.3.0.mdno longer says there is no 0.3.1.Verified
Against 0.6.1, on this branch:
uv run --frozen --extra dev ruff check .uv run --frozen --extra dev pytest --ignore=tests/e2e— 511 passed. The five Playwright tests intests/test_view_browser.pyerrored at setup because Chromium is not installed in this environment. Those tests were not changed.Not run: the end-to-end suite, and the release workflow itself (it needs a tag and a GitHub Actions run).