Flyto2 Docs

Flyto2 Docs is the public technical documentation and citation surface for Flyto2 Warroom, evidence-backed CTEM, attack surface management, code intelligence, dark web and threat intelligence, automated security testing, red-team workflows, MCP security, scoring, reports, and the deterministic execution engine.

Use this repo when you need source-of-truth docs for Flyto2 Core, Flyto2 AI, Flyto2 Indexer, Flyto2 Blueprint, Flyto2 Warroom CE, MCP transport, module reference, self-hosted deployment, AI-search citation files, or multilingual technical pages.

Read online:

• Website: https://docs.flyto2.com
• Product site: https://flyto2.com
• Self-hosted CE: https://docs.flyto2.com/warroom/self-hosted-ce
• GitHub CE: https://github.com/flytohub/flyto-warroom
• Docker Hub CE: https://hub.docker.com/r/chesterhsu/flyto-warroom

Contents

Area	Purpose
guide/	Start path for onboarding, installation, first workflow, and configuration
warroom/	Warroom, CTEM, surfaces, scoring, BYO integrations, CE install, and APIs
core/	Deterministic execution, evidence replay, and runtime architecture
core/reference/	Source-backed Core CLI, HTTP, configuration, recipe, source, and declaration reference
modules/	Flyto2 module reference generated from flyto-core
mcp/	MCP server setup and transport reference
indexer/	flyto-indexer code intelligence and MCP tools
ai/	flyto-ai providers, agents, prompts, and CLI
blueprint/	Workflow blueprint docs
community/	Contribution routing, showcases, and social syndication rules
public/llms*.txt	AI/search-readable citation indexes

Features

• Source-backed documentation for 452 active modules, 467 literal module registrations, 24 CLI parser commands, 22 HTTP operations, 93 environment names, 41 packaged recipes, and 5,383 Python declarations.
• Fifteen generated module locales with identical page and module inventories.
• VitePress search, clean URLs, canonical metadata, structured data, hreflang, sitemap, image sitemap, crawler rules, and AI-readable citation files.
• Build-time internal-link, SEO score, brand, email, generated-reference, and documentation ownership gates.
• Warroom, Core, MCP, AI, Indexer, Blueprint, community, and product-line guides organized by user intent instead of repository layout.

Requirements

• Node.js 22 and npm for VitePress, SEO, link, and deployment checks.
• Python 3.11 or newer for documentation/reference generators.
• Sibling flyto-core and flyto-i18n checkouts only when regenerating their source-backed artifacts; normal site builds use committed generated output.

Configuration

VitePress navigation, metadata, locale links, and build transforms live under .vitepress/. SEO thresholds and discovery inputs live under .seo/ and public/; generator behavior lives under scripts/. Public builds must not depend on sibling repositories or private credentials because generated Core and locale artifacts are committed.

Architecture

Authored guides are grouped by user intent, while generated module and Core references remain in dedicated trees. scripts/generate-code-reference.py documents this repository's own executable source; scripts/sync-core-reference.py imports reviewed Core references; VitePress then builds canonical, localized, search-indexed pages. See ARCHITECTURE.md for ownership and dependency boundaries.

Navigation Model

The public docs menu is organized by user intent:

• Start: onboarding, installation, first workflow, and configuration.
• Build: core runtime, MCP server, module reference, and workflow mechanics.
• Reference: flyto-ai, flyto-indexer, and flyto-blueprint.
• Security: Warroom, self-hosted CE, security surfaces, BYO integrations, and scoring.
• Resources: product lines, blog, product site, and public repositories.

Keep the top navigation short. Put deep module categories and Warroom surfaces in sidebars, with broad groups collapsed by default so the first screen remains scannable.

Install

npm install

Usage

npm run docs:dev      # local VitePress dev server
npm run verify        # public docs audit + build
npm run docs:preview  # preview built site
npm run docs:check    # all Markdown, source ownership, brand, and inventories
npm run core:sync     # refresh public Core reference from ../flyto-core

npm run verify runs the public docs audit and VitePress build. The audit checks the self-hosted CE entry, sidebar, GitHub/Docker links, and AI-readable llms files so docs, landing, GitHub, and Docker Hub stay aligned.

Testing

npm run verify is the release gate. It validates all 1,000-plus Markdown files, regenerable inventories, approved @flyto2.com mailboxes, all built internal links and anchors, representative page SEO scores, sitemap and hreflang coverage, crawler/LLM files, then performs a production VitePress build. The separate scheduled SEO workflow adds Lighthouse and live external link checks.

Generated Documentation

Module pages are generated by scripts/generate-docs.py from the flyto-core registry and flyto-i18n locale data. Core narrative and method-level pages are synced by scripts/sync-core-reference.py; the 5,383 Python declarations are split by responsibility to keep the public reference usable. Docs' own generators and SEO functions are indexed by scripts/generate-code-reference.py. Do not hand-edit generated pages.

API And Citation Policy

Docs are the technical source of truth. Use flyto2.com for product positioning, docs.flyto2.com for mechanics and contracts, and blog.flyto2.com for educational explanations.

When adding public pages, update:

• VitePress navigation/sidebar when the page should be discoverable;
• public/llms.txt and public/llms-full.txt for AI/search citation;
• community/index.md when contribution, showcase, or social syndication rules change;
• related landing/blog references when the page changes product positioning;
• scripts/audit-docs-public.mjs when a new launch-critical route becomes mandatory.

Contributing

Small typo and clarity fixes can go directly through a pull request. Larger structural changes should keep docs, landing, blog, GitHub, and Docker Hub wording consistent. Do not publish credentials, customer data, private implementation details, or unreleased customer claims.

License And Reuse

This documentation repository does not currently declare one blanket license for prose, screenshots, trademarks, generated references, and third-party assets. Linked open-source projects retain their own licenses, including Apache-2.0 for Flyto2 Core. Check the owning source or contact team@flyto2.com before reuse.