{
  "id": "page:docs-v6-spec-and-roadmap-system-overview",
  "_kind": "Page",
  "_file": "wiki/docs/v6-spec-and-roadmap/system-overview.md",
  "_cluster": "wiki",
  "attributes": {
    "nodeKind": "Page",
    "sourcePath": "docs/v6-spec-and-roadmap/system-overview.md",
    "sourceKind": "repo-docs",
    "title": "System Overview",
    "displayName": "System Overview",
    "slug": "docs/v6-spec-and-roadmap/system-overview",
    "articlePath": "wiki/docs/v6-spec-and-roadmap/system-overview.md",
    "article": "\n# System Overview\n\n→ [Documentation Index](README.md) | Next: [Current State Analysis](current-state.md)\n\n## Purpose\n\nThis document describes the current Babysitter system and the bounded scope of V6. It is not a promise of a future fully decomposed platform. It is a grounding document for what exists now, what V6 is trying to improve, and what remains intentionally out of scope.\n\n## Current System Shape\n\nThe repository currently works as a monorepo with a strong operational center:\n\n- `packages/babysitter-sdk` contains the core orchestration model, storage, task system, replay, CLI infrastructure, hooks, harness abstractions, profiles, plugin management, and process-library support.\n- `packages/babysitter` exposes the primary CLI package.\n- `packages/genty/platform` provides the agent runtime layer and operational orchestration support.\n- `packages/adapters/*` provide harness dispatch, adapter normalization, gateway, and user-facing agent interaction surfaces.\n- `packages/adapters/hooks/*`, `packages/extensions-adapter`, and `packages/tasks-adapter` provide focused cross-harness support rather than a separate speculative platform tier.\n- `plugins/*` packages encode real harness-specific integration, packaging, install, and manifest constraints.\n\nThis means V6 begins from a working but tightly coupled system, not from a clean-slate layered platform.\n\n## Package Families And Ownership\n\nThe easiest way to read the repo is by package family:\n\n- **Orchestration core**: `packages/babysitter-sdk`, `packages/babysitter`, and `packages/genty/platform` own runs, replay, effect dispatch, CLI surfaces, and runtime orchestration behavior.\n- **Dispatch family**: `packages/adapters/*` owns harness-facing invocation, adapter normalization, gateway delivery, and shared user-facing agent interaction contracts.\n- **Support adapter family**: `packages/adapters/hooks/*`, `packages/extensions-adapter`, and `packages/tasks-adapter` own hook normalization, plugin compilation, and human approval routing.\n- **Distribution surfaces**: `plugins/babysitter-unified/` is the canonical authoring surface, while `plugins/babysitter-*` remain the concrete installable compatibility bundles.\n- **Workflow content**: `library/`, project-local `.a5c/processes/`, and `~/.a5c` hold reusable processes, local process definitions, and active operational state.\n\n## Current Operational Flow\n\nFrom an operator perspective, the live execution path is:\n\n1. A harness surface such as Codex, Claude Code, Cursor, Gemini, Copilot, Pi, or OpenCode loads a concrete plugin bundle from `plugins/babysitter-*`.\n2. That bundle is produced from the unified source in `plugins/babysitter-unified/` with help from `packages/extensions-adapter` and, where relevant, `packages/adapters/hooks/*`.\n3. The harness integration reaches the operational CLI/runtime surface in `packages/babysitter` and `packages/genty/platform`.\n4. The CLI/runtime delegates run creation, replay, task lifecycle, journal/state handling, and process-library access to `packages/babysitter-sdk`.\n5. The SDK executes workflows from `library/` or project-local `.a5c/processes/`, while `packages/tasks-adapter` handles structured human approval routing when a process needs it.\n6. Where agent dispatch or richer user-facing interaction is required, the runtime integrates with `packages/adapters/*` rather than replacing the orchestration core.\n\n## What The System Must Continue To Do\n\nAny V6 change must preserve the repository's core operational capabilities:\n\n- multi-harness orchestration,\n- event-sourced run execution and replay,\n- plugin discovery, installation, and packaging,\n- session and harness integration,\n- process-library and workflow execution,\n- CLI-driven developer and automation workflows.\n\n## V6 Scope In System Terms\n\nV6 is a maturity program around this existing system. Its near-term goals are:\n\n- document the real boundaries that already exist,\n- reduce ambiguity around candidate seams,\n- make packaging and validation failures easier to catch,\n- create a decision framework for future extraction rather than assuming extraction is always correct.\n\n## Explicit Non-Scope\n\nThe current V6 stage does not require:\n\n- conversion of the system into many new top-level packages,\n- a fully formalized runtime/platform/application split,\n- new distributed coordination infrastructure as a baseline expectation,\n- broad new governance or security subsystems described as if already committed.\n\n## External Integration Reality\n\nThe system integrates with external model providers, local CLIs, development environments, and filesystem-backed operational workflows. V6 must respect those realities. Claims about isolation, performance, and deployment flexibility are only mature when they are tied to implementation and verification in that environment.\n\n## First Executable V6 Slice\n\nThe current V6 program is not \"split the monorepo everywhere.\" The first executable slice is narrower:\n\n- make the `@a5c-ai/genty-platform` seam contract explicit,\n- validate that seam with repo-level checks,\n- keep naming and ownership honest while larger extractions remain deferred.\n\nThe active repo-level validation command for that slice is:\n\n- `npm run verify:v6:seams`\n\nThat command is the operational cue for whether the current V6 seam contract is still holding.\n\n## Validation And Honesty Cues\n\nTwo rules keep the overview grounded:\n\n- Prefer validation-backed seams over vocabulary-backed seams. If the repo does not have a package, command, or decision record for a concept, it is not yet a committed V6 boundary.\n- Describe placeholders honestly. For example, `packages/transport-adapter` is currently documented as a placeholder seam with design and migration docs, not as an already-cut-over runtime.\n\n## Architectural Reading Rule\n\nUse the rest of the V6 documents with this framing:\n\n- current repo reality first,\n- small validated change second,\n- broader future architecture only as deferred exploration.\n\n---\n\n**Related Documents**: [V6 Vision](v6-vision.md) | [V6 Architecture Specification](v6-architecture-specification.md) | [Package Specifications](package-specs.md)\n",
    "documents": []
  },
  "outgoingEdges": [],
  "incomingEdges": [
    {
      "from": "page:docs-v6-spec-and-roadmap",
      "to": "page:docs-v6-spec-and-roadmap-system-overview",
      "kind": "contains_page"
    }
  ]
}