opentide Website
Source for the opentide web presence — deployed on GitHub Pages at opentide.org.
Built with Next.js and Fumadocs, exported as a static site for GitHub Pages.
What's here
| Section | Source | Path |
|---|
| Landing page | This repo | / |
| Documentation | Synced at build time | /docs |
| Specifications | specifications repo | /docs/specifications |
| RFCs | specifications rfcs/ | /docs/specifications/rfcs |
| Usage, CLI, MCP, SDK | opentide docs/ | /docs/{usage,cli,mcp,sdk} |
| Blog | This repo content/blog/ | /blog/ |
| Releases | opentide's release notes, and the CHANGELOG.md of language-server, vscode-extension and explorer synced into content/releases/ | /releases/, /releases/<project>/ |
Documentation prose is synced from the opentide and specifications repos via pnpm sync:content and committed under content/docs/ as .mdx so Fumadocs can compile JSX and private-repo CI can build without cross-repository access. content/docs/.sync-stamp.json records the vendor SHAs; pnpm check:docs fails if those gitlinks moved without a refresh. A GitHub Actions workflow (sync-docs.yml) does this on a schedule and on repository_dispatch, then deploys — you do not need to run sync by hand after a package release.
Local development
Prerequisites
Monorepo layout (recommended)
If you clone opentide repos as siblings:
opentide/
├── opentide/
├── specifications/
└── website/ ← you are here
pnpm install
OPENTIDE_DOCS_PATH=../opentide/docs SPECIFICATIONS_PATH=../specifications pnpm dev
Submodule layout (CI / production)
git submodule update --init --recursive
pnpm install
pnpm dev
Environment overrides (first match wins):
| Variable | Default candidates |
|---|
OPENTIDE_DOCS_PATH | vendor/opentide/docs, ../opentide/docs |
SPECIFICATIONS_PATH | vendor/specifications, ../specifications |
Scripts
| Command | Description |
|---|
pnpm dev | Sync docs + start dev server |
pnpm fetch:pypi | Snapshot the current PyPI version for local/dev first paint |
pnpm sync:content | Copy opentide + specifications docs into content/docs/ as .mdx |
pnpm check:docs | Fail if content/docs does not match the pinned vendor gitlinks |
pnpm test | Unit tests for sync, freshness, and GitHub source URLs |
pnpm verify:demos | Run the landing demo objects through opentide validate --strict, lint --strict and a dry-run deploy (needs pip install opentide) |
pnpm build | Snapshot PyPI + sync docs + static export to out/ |
pnpm lint | ESLint |
pnpm types:check | TypeScript + Fumadocs MDX types |
Release notes
/releases/ reads each project's notes in one shape, the release-notes standard every project's
repository carries as its release-notes skill (opentide: .agents/skills/release-notes/,
language-server: skills/release-notes/, vscode-extension and explorer:
.agents/skills/release-notes/). lib/releases.ts parses it:
| In the notes | On the page |
|---|
| The first paragraph under a version | The summary, large |
Upgrade | Numbered steps in a tinted panel, ahead of the changes, and "N upgrade steps" in the counts |
Breaking, Added, Changed, Deprecated, Removed, Fixed, Security | One list each, in that order whatever order they were written in, under an icon, the label and a count; the counts again beside every earlier version |
#### under a category | A group inside that category's list |
An entry starting **Breaking: …** under another category | A breaking tag on the entry and on the release, and a place in the breaking count |
See the [CHANGELOG](…) for every change. | A "Full changelog" link beside the install command |
| Any other heading | Its list, as written, after the categories |
Headings are ### in a Keep a Changelog file and bold lines (**Added**) in opentide's
docs/usage/releases.md. Older spellings still parse (What this version fixes is Fixed,
Security: regenerate GitHub CI is Security). Categories are told apart by icon and label,
never by colour. A part added to or renamed in the standard changes CHANGE_CATEGORIES and
classifyHeading here, and the four skills, together.
Writing a blog post
Add an MDX file under content/blog/:
---
title: Your post title
description: One sentence summary for listings and SEO.
author: Your Name
date: 2026-06-25
tags:
- detection-engineering
---
Your content here.
Open a pull request. Posts appear at /blog/<filename-without-extension>/.
Deployment
Prerequisites
- opentide submodule tracks the
development branch (Fumadocs-formatted docs under docs/).
- specifications content must exist in the specifications repository — until published, local builds fall back to
../specifications when the vendor submodule is empty.
Pushes to main deploy to GitHub Pages via .github/workflows/deploy.yml. Custom domain is opentide.org (public/CNAME, siteUrl in lib/shared.ts, and the Pages custom-domain field). Apex DNS is four GitHub A records plus AAAA; www CNAMEs to opentidehq.github.io. Do not attach blog.opentide.org to this Pages site — forward it to /blog/ at the registrar.
Package releases
The landing page reads the current opentide version from the PyPI JSON API in the browser. Publishing a wheel does not require a website rebuild for that number to update.
This is the beginning of the README. Read the rest at the original. Read the full README ↗
