Maintaining the documentation site

The Cohesix website renders this repository’s Markdown. Edit README.md or a document under docs/ to change its content. Keep ordinary GitHub Markdown links and fenced code blocks; individual documents do not need front matter, theme classes or a second copy of their content.

Automatic publication

GitHub Pages publishes the root of main through its existing automatic pages-build-deployment workflow. A push to main rebuilds the site. The repository-owned _config.yml, _layouts/default.html, _data/navigation.yml and assets/ files participate in every build, so documentation updates retain the same theme. There is no separate generated-site branch or manual HTML edit to repeat after publication.

The literal paths in _config.yml also exclude unused standalone HTML pages and unpacked historical bundle trees from publication. Repository sources and release archives remain intact. Preserve externally used verification endpoints, linked gallery HTML and the shared font/icon dependencies when reviewing unused pages. A page without a navigation link can still serve one of these purposes. The shared 404.html is a required error endpoint, not an unused content page.

The supported Jekyll plugins render Markdown without front matter, use the README as the homepage and translate local Markdown links to their generated HTML destinations. The shared layout derives page titles from rendered headings, including documents with leading copyright comments. Layout asset and navigation links use Jekyll’s relative_url filter to preserve the /cohesix project path. Keep these plugins when changing the layout.

Use ordinary Markdown images for page artwork. The shared stylesheet sizes the homepage logo responsively and preserves its proportions; deeply indented HTML inside a Markdown-enabled container can become a code example instead of an image.

Search discovery

The supported jekyll-sitemap plugin regenerates sitemap.xml on every Pages build from the current published HTML pages. It uses absolute canonical URLs, including the project path, and omits the 404 page and Google verification files. The existing publication exclusions also apply, so omitted historical copies do not return through the sitemap. Keep the sitemap generated from the documentation rather than maintaining a second list of URLs.

The plain-text sitemap.txt is a supported alternative for search engines that cannot process the XML submission. It regenerates in the same Pages build from the producer’s page, collection and static-file inputs. The publication checker requires both formats to contain exactly the current canonical content URLs; neither file has a separately maintained URL inventory. Keep the text output UTF-8 with one absolute URL per line and no headings or comments.

Submit https://lukeb-aidev.github.io/cohesix/sitemap.xml in the matching Google Search Console property. Check the sitemap’s processing status and use Page indexing and URL inspection to distinguish discovery, crawling and indexing. An accepted sitemap or successful live URL test does not guarantee indexing; Google decides which pages to include and when. Use URL inspection requests for specific important updated pages rather than repeatedly submitting every URL. See Google’s sitemap guidance for submission and coverage details. Google reads robots.txt only at the origin root; a project-level file does not control crawling. A missing origin-root robots file does not block this site.

For a persistent Couldn't fetch status, check the exact submitted URL, the origin-root crawl rules and manual actions before changing the sitemap. Use a live URL test to distinguish current fetch availability from sitemap processing. When XML validates and the live fetch succeeds, the generated https://lukeb-aidev.github.io/cohesix/sitemap.txt provides an alternate format to submit once. An accepted submission receipt still requires a later successful processing result; do not treat it as completed indexing or repeatedly change URLs to force a retry.

Theme and diagrams

The theme uses SwarmUI’s final olive, ivory and gold workbench palette and its Inter and JetBrains Mono fonts. assets/css/site.css adapts the palette and tokens from apps/swarmui/frontend/styles/workbench.css and styles/tokens.css to semantic Markdown. It does not import the application’s control layout. When SwarmUI’s design tokens change, update the corresponding site tokens and run the focused site checks. Fonts, their licence notices and the Cohesix mark remain in the existing SwarmUI asset directory; the layout references them directly rather than keeping duplicate copies.

Tables use automatic column sizing with word-based wrapping, including inline code. Short names keep their natural width while longer descriptions share the remaining space. Wide tables scroll horizontally in a keyboard-focusable region; without JavaScript, the table itself remains scrollable. Keep these rules in the shared stylesheet rather than adding widths to individual Markdown documents. The static checker compares source pipe tables with their rendered counterparts, including nested published guides. Keep blank lines around tables and use fenced blocks for namespace trees. Keep each inline code span on one physical line when it contains angle-bracket placeholders; otherwise Kramdown can interpret a placeholder as an HTML block and hide later Markdown. Generated table owners must emit their own blank lines. The shared configuration enables Markdown inside HTML disclosure blocks and retains the existing heading-anchor format. Use <summary markdown="span">Title</summary> for disclosure titles so Kramdown keeps the closing tag instead of nesting later sections inside the title.

assets/js/site.js adds the page outline, scrollable table regions and Mermaid rendering. Normal fenced blocks labelled mermaid remain the source for both GitHub and Pages. The renderer loads only on pages containing diagrams. It uses Mermaid 11.12.0 from jsDelivr with an exact SHA-384 integrity check, strict security and the site’s colours. Font loading precedes diagram measurement. Existing flowchart labels use a single literal \n for line breaks. A small, tested adapter translates that notation only inside supported flowchart labels before rendering; the canonical Markdown and displayed source stay unchanged. Comments, directives, escaped backslashes and other diagram types are preserved. Each rendered diagram retains its source in an expandable section. A loading or syntax failure leaves that source visible and does not hide other diagrams. Large diagrams fit the reading column and offer an expanded view with native dialog keyboard controls. Without JavaScript, Markdown, links, navigation and the original diagram source remain usable. Downloading the renderer requires a network connection. Printing an expanded diagram temporarily returns its canvas to the document and restores the expanded view afterwards, so the diagram also appears in print.

To upgrade Mermaid, verify the exact release against the upstream package, update both the versioned URL and its integrity digest, and exercise rendering and failure fallbacks. Do not replace the URL with an unpinned latest version. The diagram source remains documentation, not evidence of a live Cohesix run.

Preview and validate

Use Ruby 3.3 and Bundler with the supported GitHub Pages dependencies:

The Gemfile selects GitHub Pages 232. Bundler’s local lockfile is ignored: the existing hosted Pages builder uses its own supported dependency set and does not install a developer machine’s transitive dependency lock.

BUNDLE_PATH="$PWD/out/pages-gems" bundle install
BUNDLE_PATH="$PWD/out/pages-gems" bundle exec jekyll build \
  --destination out/pages-preview/cohesix
python3 scripts/ci/check_pages.py --site out/pages-preview/cohesix
python3 -m unittest discover -s tests -p test_pages.py
node --test tests/pages/*.test.mjs
python3 -m http.server 4173 --bind 127.0.0.1 --directory out/pages-preview

The static checks compare published code fences, images, tables and diagram sources with their Markdown owners, verify the configured publication scope and require exact XML and plain-text sitemap coverage of the retained content pages. They complement the browser checks below.

Open http://127.0.0.1:4173/cohesix/. Check the homepage and nested guides, ordinary code, tables, images, source links and heading anchors. For tables, check the homepage terminology and document lists, Host API endpoints, Test Plan commands and the wide audit registers at desktop and phone widths. Short labels must not split inside words; wide tables must scroll without widening the page. Inspect the architecture diagram and a sequence diagram after fonts load. Check a narrow phone-sized viewport, keyboard access and the mobile documentation disclosure. Also check a JavaScript-disabled page and a page with the Mermaid request blocked: the original diagram source must stay readable. These checks validate documentation presentation; they do not replace runtime or release tests.

Before publishing, run scripts/check-generated.sh and git diff --check in addition to the focused site checks. After pushing, verify the completed Pages deployment and inspect the public homepage, a nested document and a rendered diagram. A source commit or successful local preview alone does not establish that the public site was updated.