Skip to content

Latest commit

 

History

History
166 lines (146 loc) · 8.52 KB

File metadata and controls

166 lines (146 loc) · 8.52 KB

LoopX Documentation

This directory is intentionally split by audience. New contributors should be able to find the stable product contracts without reading every research note, incident report, or launch draft.

Start Here

  • Project README: product positioning, showcases, and the shortest quick start.
  • User manual (Feishu/Lark): public onboarding guide with Quick Start, product/technical concepts, FAQ, and selected cases.
  • Getting started: agent-first start, manual installation, project connection, diagnosis, daily workflow, heartbeats, dashboard, development, and command reference.
  • Newcomer command path: the minimal product path for /loopx, /loopx <goal>, and one CLI quickstart before the full command catalog.
  • Auto-research command path: the shortest visible route from a clean workspace to an inspectable multi-agent auto-research rehearsal with stop and takeover controls.
  • Multi-agent product recipe: the product-author path for keeping both user config and product presets thin while the generic kernel owns runner, TUI, tick, status, and host controls.
  • Product vision: long-term product direction, Loop Agent definition, maintainer-first management surface, and open-source anchor strategy.
  • Core control-plane graphs: the interaction catalog lens, state definitions, and state machine in one product/runtime map.
  • Public adoption loop: docs-first issue and discussion template copy, triage labels, and lightweight external-attempt metrics before any .github template write.
  • Codex CLI TUI-first loop: first-class Codex CLI onboarding target where one visible TUI message starts LoopX, with session-attached automation as the preferred follow-up.
  • Codex CLI first-run rehearsal: shortest public route from no-clone install to one-message TUI bootstrap and proof-capture fixtures.
  • Architecture: core concepts and control-plane shape.
  • Integration guide: how to connect a project to LoopX, including public-safe Lark or Feishu reply card payloads.
  • Showcases: public-safe cases, reproducible demos, and frontend-ready case metadata.
  • Update notes: two-week public progress notes, archive governance, and publication automation design.
  • Release readiness: v0.x install/update paths, compatibility smoke gate, release-note checklist, and safe-to-depend-on surfaces.
  • Benchmark developer workflow: how to run, observe, and ingest benchmark slices as a developer-facing product workflow.
  • State interaction model: user, agent, and state channel flow.
  • Heartbeat automation prompt: current heartbeat prompt contract.
  • Runtime connector catalog: public v0 catalog for Codex App, Codex CLI TUI, Claude Code loop, shell, HTTP, and worker bridge connectors.
  • Quota allocation: should-run and spend semantics.
  • Dashboard budget governance: operator-facing budget, cadence, controls, and evidence mapping for the ops frontstage.
  • Status data contract: dashboard/status payload shape.
  • Public/private boundary: what may be committed, published, or retained.
  • Contributor tasks: visible public work, sorted by complexity and ownership.

Stable Reference

Concepts

Operator Workflows

Contracts

Product Direction

Research And Evidence

Outreach And Narrative Drafts

Archive

Governance Rules

  • Keep the docs/ root for stable first-line product docs that contributors are expected to read or link from public surfaces.
  • Put public-safe showcase cases, reproducible demos, and frontend-ready case metadata under docs/showcases/.
  • Put benchmark dossiers, route packets, and publication planning under docs/research/.
  • Put dated release-readiness packets, incident reports, and superseded decision records under docs/archive/.
  • Put public launch, narrative, demo, and PR copy drafts under docs/outreach/.
  • Put stable product-direction notes that cross individual contracts under docs/product/.
  • Put machine-facing protocol contracts under docs/reference/.
  • Every new doc should be linked from this index or from a subdirectory README.md. If it is not worth indexing, it probably belongs in local notes rather than the public repository.
  • Prefer concise public summaries over raw logs, private trajectories, internal links, credentials, or local filesystem paths.