[Doc]: Community help wanted — documentation site and GitHub Pages

[hsliuustc0106]

📚 The doc issue

We would like community help building a documentation site for System1-Omni and publishing it with GitHub Pages.

The repository already has a project README, frontend documentation, a Laya recipe, and contribution instructions, but no unified documentation site or Pages deployment workflow. A searchable site with clear navigation would make it easier for users to get started and for contributors to understand the project.

Suggest a potential alternative/fix

A proposed starting point is Markdown documentation in this repository, built with MkDocs and deployed to GitHub Pages through GitHub Actions. Suggestions for a simpler or better-fitting setup are welcome before implementation.

Initial scope:

• Create a small documentation site with navigation and search, reusing existing documentation rather than maintaining duplicate instructions.
• Include at least these user-facing sections:
  • Quick start: the shortest verified path to launching a working setup and sending a first request, with an example response.
  • Installation: prerequisites, dependencies, build/setup steps, and hardware/backend-specific requirements.
  • Supported models and hardware: a compatibility table showing each model, supported hardware/backends (CPU, NVIDIA CUDA, Apple Metal, as applicable), known requirements, and validation status. Clearly mark planned or unverified combinations.
  • Recipes: model-specific setup, launch commands, configuration, and example requests, starting with the existing Laya worker recipe.
• Also include an overview, architecture explanation, and contribution guide, and incorporate the existing frontend interface/configuration documentation.
• Clearly distinguish working functionality from planned model engines and CUDA/Metal backends. Examples should reflect commands and behavior verified against the code.
• Add a documentation build check for pull requests and automatic Pages deployment after merges to main.
• Link the published site from the README and document how contributors preview and edit the docs locally.

The expected default site URL is https://thinkflowlab.github.io/system1-omni/. Repository maintainers can handle enabling GitHub Pages and any repository settings needed for deployment.

Community help wanted

Contributions are welcome for site setup, GitHub Actions, writing/editing, navigation, and checking the getting-started instructions. You do not need GPU access to help with the documentation site itself.

Please comment with the part you would like to help with, or suggest a documentation structure/tooling choice. Small, focused PRs are welcome; let's coordinate here to avoid overlapping work.

Before submitting a new issue...

• Searched the open issues and reviewed the current README and documentation entry points.

[twu3202]

I'd be glad to take this on, in small PRs:

1. The site itself: mkdocs.yml with navigation and search, a build check on pull requests, deployment to Pages from main, a link from the README and a note on previewing locally. It would pull in the existing README, frontend, recipe and contributing pages rather than copying them.
2. A supported models and hardware page: each model and backend with its validation status and the hardware it was checked on, with the rest marked as unverified or planned. Models still in review would be added as they land.
3. Quick start and installation pages.

For testing, I only have an RTX 6000 Ada (sm_89) and an Apple M5, so I can run the quick start and the recipes that fit those two, and each page will say what was run where. Pages for other hardware keep the checks their authors reported.

I'll start with the structure in the first PR so it's easy to adjust before the content pages go in.

[MinhaoLi0318]

I'd like to take this.

Plan:

1. Site skeleton + CI: MkDocs (Material theme) with navigation and search, built from the existing Markdown (README, src/frontend docs, Laya recipe, CONTRIBUTING) instead of copying it. Links into source files will point to GitHub. A mkdocs build --strict check runs on every PR, and a deploy workflow publishes to Pages on pushes to main using actions/deploy-pages. Maintainers only need to set Settings → Pages → Source to "GitHub Actions".
2. Quick start + installation: the shortest path to a working setup and a first /v1/systemone request with an example response, using only commands I've checked against the current code.
3. Supported models and hardware table: working, planned and unverified combinations marked clearly. I can check CPU, NVIDIA (RTX 5090) and Apple Silicon (M5 Pro) myself.
4. README link to the published site, plus how to preview and edit the docs locally.

I'll start with PR 1 so other contributors can add pages on top of it. If you'd prefer a different tool (e.g. mdBook for a Rust project), let me know before I start. I'll report the build commands I ran, per CONTRIBUTING.

[twu3202]

Thanks for the plan. I've opened #51 with the first part: the MkDocs site built from the existing pages, the strict build check on pull requests and the Pages deployment from main, so we don't both build the same skeleton.

You can check hardware I can't (RTX 5090 and M5 Pro). Would you like to take the quick start and installation pages? I'd then do the supported models and hardware page and add your results to it. Happy to split it differently if the maintainers prefer.

[MinhaoLi0318]

Thanks for the plan. I've opened #51 with the first part: the MkDocs site built from the existing pages, the strict build check on pull requests and the Pages deployment from main, so we don't both build the same skeleton.

You can check hardware I can't (RTX 5090 and M5 Pro). Would you like to take the quick start and installation pages? I'd then do the supported models and hardware page and add your results to it. Happy to split it differently if the maintainers prefer.

Sounds good to me.

[hsliuustc0106]

GitHub Pages is live at https://thinkflowlab.github.io/system1-omni/ (enabled with build_type=workflow on 2026-10-04; deployed by the Docs workflow on every push to main). Closing as done.