dc11e3b3bc
`release.py release` gains two flags. They can be used together. --skip-bundles ships only the claim, the GitHub release, the final tag and the Docker image. No desktop, Termux or PM bundle job runs. The final tag records candidateManifestSha256: null. Publication moves only the Docker stable/latest aliases. The R2 stable head, feeds, APT, the downloads page, the signed-package baseline and the Store stay on the previous bundle release. --skip-tests builds, signs and publishes every artifact and runs no test job: source CI, Nix, PM bundle check, Termux, Windows live, install/update E2E, bootstrap identity, native smokes, upgrade acceptance, tests/docker and the in-build vitest step. The candidate manifest records each smoke as skipped, never as passed. The flags live in the claim message (skipBundles, skipTests), next to autopublish. They are not workflow inputs, so a rerun cannot change them. admit emits them, and every job condition and gate reads them. stable.validate_claim and stable.validate_final are now the one shape check for stable.py and the sequencer. The gates stay strict. SKIPPED_BY in stable.py maps each job to the flags that remove it. `gate` requires those jobs to report skipped and every other gated job to report success. A job that ran although a flag removes it blocks the release. A release that skipped bundles never moves the R2 stable head. Two readers depended on that head: - The next version was derived from it, so the next cut would reuse the version. It now takes the newer of the R2 head and the newest published non-prerelease GitHub release with a vX.Y.Z tag. Bare v* tags do not count, because those refs are not protected yet. - The sequencer used it to decide which published releases still need their publication pass, so a bundle-less release would re-advance every 15 minutes. The head is now the newer of the R2 head and the published release whose final tag binds the Docker stable alias digest. `release` also refuses a cut when its next version already has a final tag. That closes the window between the final tag and the public release, where the published identity still names the old version. Tests: 42 release test files, 546 passed. Three tests fail on this Windows host, and they fail the same way on a clean HEAD worktree: - test_stable_release_graph::test_docker_recovery_refuses_to_replace_a_divergent_version_tag - test_release_artifacts::test_windows_metadata_is_read_from_package_and_stale_stamp_is_rejected - test_tag_builds_summary::test_admitted_failure_publishes_tag_info_without_promoting_channel[True] Not verified: no real Stable Release dispatch ran with either flag, and actionlint is not installed on this host. The workflow changes are checked by the graph tests and by running the phase-result step script.
Website
This website is built using Docusaurus, a modern static website generator.
Reading the docs on GitHub? The Markdown under
docs/is authored for the rendered site at https://hermes-agent.nousresearch.com/docs/. Cross-page links are relative Markdown paths, so they follow through on GitHub's file viewer too. Every page on the site has an Edit this page link that opens the source file here.
Authoring links in docs/
- Link to another page with a relative Markdown path, anchors included:
[Profiles](../user-guide/profiles.md),[Bundles](../user-guide/features/skills.md#skill-bundles). Docusaurus turns the file path into the page route; GitHub follows the same path. Site routes (/user-guide/profiles,/docs/user-guide/profiles) only work on the rendered site — GitHub resolves them as repository paths and 404s, and the/docs/form also emits/docs/zh-Hans/docs/...404s in the zh-Hans build becausebaseUrlis already/docs/. python3 website/scripts/check_doc_links.pyfails on any route-style link in hand-authored pages (EN and the zh-Hans mirror);--fixrewrites them. It runs in theDocs Site Checksworkflow. Generated pages (user-guide/skills/{bundled,optional},reference/*skills-catalog.md) are produced byscripts/generate-skill-docs.py, which emits the same relative form.- Pin
{#anchor}on cross-linked headings so the zh-Hans mirror keeps the same id.
Installation
yarn
Local Development
yarn start
This command starts a local development server and opens up a browser window. Most changes are reflected live without having to restart the server.
Build
yarn build
This command generates static content into the build directory and can be served using any static contents hosting service.
Deployment
Using SSH:
USE_SSH=true yarn deploy
Not using SSH:
GIT_USER=<Your GitHub username> yarn deploy
If you are using GitHub pages for hosting, this command is a convenient way to build the website and push to the gh-pages branch.
Diagram Linting
CI runs ascii-guard to lint docs for ASCII box diagrams. Use Mermaid (````mermaid`) or plain lists/tables instead of ASCII boxes to avoid CI failures.