| advance live-docs on a release, and track it from a packaging workspace (#3877) * feat(ci): advance live-docs on a release, and track it from a workspace A packaging workspace cloned `master`, which carries the SDK that has not shipped: today its `projects/start-sdk` is 2.0.10 while every published package pins `@start9labs/start-sdk` 2.0.9. The guide, the package template and the SDK source a packager reads therefore ran ahead of what `npm install` resolves, and the local copy of the guide disagreed with docs.start9.com. `live-docs` is the branch that should answer this — it is what is published — but nothing has ever advanced its code. It was branched off master's tip on 2026-08-10 (#3652) and only `projects/<p>/docs` has moved since, so its `projects/start-sdk/lib` is still that day's in-progress 2.0.10, and `shared-libs/`, `.github/` and the repo root are all three weeks stale and drifting. docs-sync-on-tag now takes the tagged tree whole and puts every *other* `projects/*` back on the release it is on. A tag advances its own project, the shared libraries beneath it, and the repo root; it speaks for nothing another product owns. `projects/start-docs` rides along only with a product that ships a book, so a bookless release still refreshes the tree without triggering a site deploy. The stale-tag guard now covers the whole tree rather than the site alone: a backfilled tag still publishes its book and nothing else. `init-workspace` then clones `live-docs`, so `git pull --ff-only` stays the session-start sync and a workspace gets published-guide corrections the moment they go live, rather than at the next release. This does not repair the tree live-docs inherited on 2026-08-10; each project converges at its own next tag. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * ci: fail a live-docs pull request that changes anything but a book live-docs now carries published code as well as published books, and nothing gated a pull request into it. A PR touching code would put a tree there that no release produced, and docs-backport pushes whatever merges into live-docs onto master unattended — so it would land on master unreviewed as a code change. The predicate is a rule rather than a mirror of docs-deploy's paths, so a new product's book is covered the moment it exists. The package template is the one thing under docs/ that it rejects: `s9pk init-package` scaffolds from it, and `manage-release.sh pre-check start-sdk` verifies its SDK pin against the release being cut, which an edit landing on live-docs would never face. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * say why the package template is not PR-able to live-docs Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(start-cli): say when start-cli is behind the published release start-cli installs outside the workspace, so nothing tied it to the guide the workspace carries. On Debian the installer adds an apt repo and `apt upgrade` carries it forward; on macOS and every other Linux it drops a binary in ~/.local/bin with no update path, and the guide never said to re-run the installer. Those packagers drift indefinitely against a guide that keeps advancing. The checkout tracks published releases and `projects/start-cli` only moves on a start-cli tag, so its manifest names exactly the version a packager should be running. Comparing it to the version baked in at build time is a file read with no network, printed once per process, and silent on anything unreadable. It rides on the workspace lookups s9pk work already does — signing (pack, publish, edit) and init-package — so it fires where a stale binary would bite and nowhere else. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * ci: judge a release against its own product's earlier syncs The rollback guard compared every tag against the newest sync of any product, but deb releases tag the commit alpha built, which is routinely behind a tag cut before it. Such a release was judged stale and never advanced its own tree; a bookless one crashed on the book-only path. The watermark was also read only from commits touching projects/start-docs, which a bookless sync no longer touches, so an older tag arriving after one rolled shared-libs and the root back. Two watermarks now. A product's own tree is behind only if an earlier release of the same product was synced from a descendant of the tagged commit. The shared trees are behind if any release was, and then stay where the newer release put them. Every earlier sync is consulted, not the newest, because syncs land out of ancestry order. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * ci: let a retarget onto live-docs re-run the guard check-pr-retarget-workflows.py audits every workflow with a pull_request trigger, and the guard was not registered. It is a direct listener like conflict-markers rather than a retarget-called target: its verdict depends on the base, and the branch filter is evaluated against the new base, so taking `edited` is what checks a PR moved onto live-docs before its next push. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> --------- Co-authored-by: Matt Hill <9935159+MattDHill@users.noreply.github.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> | 4 天前 |