modelearth/webroot

1. This repository is a static webroot for “PartnerTools Webroot,” not a traditional application server. The primary runtime is plain file hosting: python -m http.server 8887 serves the repo directly, and paths like /team/ and /projects/ map to folders in the tree.

2. The top-level index.html is the landing page, and the many sibling directories act as route roots or microsites. The architecture is therefore directory-driven: content, pages, and assets are organized by folder rather than assembled by a build pipeline.

3. localsite/ appears to be the shared site framework or common shell used across sections. Paired folders such as home/, grid/, swiper/, and montage/ likely hold reusable layout or interaction patterns that multiple pages depend on.

4. The main functional boundaries are the named content areas: team/, projects/, reports/, trade/, community-forecasting/, data-pipeline/, comparison/, engage/, realitystream/, chat/, codechat/, and similar folders. Each seems to represent a separate subject area or mini-site with its own entry page and assets.

5. There are also product or platform-oriented sections such as cloud/, desktop/, better-auth/, and streamlit/, suggesting the repo is used to publish documentation, demos, or landing pages for multiple related tools rather than one cohesive codebase.

6. example/ is a self-contained sample site, with its own README.md and index.html, likely used as a reference implementation or test page for the webroot structure.

7. siteconfig.yaml and sites.yaml are the main configuration boundaries in the repo. These files likely define which site sections exist, how they are grouped, and potentially how cross-links or catalogs are generated.

8. docker/, .dockerignore, and .github/workflows/vector_db_sync.yml indicate lightweight operational automation around the static site. The GitHub Action suggests an external sync process for vector database or search/embedding data, but it is separate from the core static-serving path.

9. .gitmodules implies at least some directories are managed as submodules, so parts of the site may be sourced from other repositories or shared content modules. That matters for architecture because some content boundaries are actually repository boundaries.

10. The overall data flow is simple: source files live in the repo, the static server exposes them as web pages, and optional automation updates auxiliary data or synced content. There is no obvious application backend in this repo; the “system” is primarily a curated content/web delivery surface.

11. For an architecture diagram, the central node should be the static webroot, with spokes to the major site sections, a shared-site layer (localsite and common UI folders), configuration/catalog files, and external automation/submodule sources. The only explicit runtime is the local HTTP file server used for development.