{
  "id": "page:docs-v6-spec-and-roadmap-package-specs",
  "_kind": "Page",
  "_file": "wiki/docs/v6-spec-and-roadmap/package-specs.md",
  "_cluster": "wiki",
  "attributes": {
    "nodeKind": "Page",
    "sourcePath": "docs/v6-spec-and-roadmap/package-specs.md",
    "sourceKind": "repo-docs",
    "title": "Package Specifications",
    "displayName": "Package Specifications",
    "slug": "docs/v6-spec-and-roadmap/package-specs",
    "articlePath": "wiki/docs/v6-spec-and-roadmap/package-specs.md",
    "article": "\n# Package Specifications\n\n→ [Documentation Index](README.md) | Previous: [V6 Vision](v6-vision.md)\n\n## Purpose\n\nThis document defines package responsibilities for the current V6 stage. It intentionally avoids large speculative API surfaces. A package appears here in one of three states:\n\n- Current: exists now and is part of the executable plan.\n- Candidate: may be extracted or renamed if a decision record justifies it.\n- Deferred: useful vocabulary, but not a committed deliverable.\n\n## 1. Current Packages\n\n### `@a5c-ai/babysitter-sdk`\n\n- State: Current\n- Role: primary orchestration core and most stable architectural anchor\n- Responsibilities:\n- event-sourced run model,\n- task definitions and replay,\n- storage, CLI commands, hooks, process-library integration, profiles, plugins, compression, harness abstractions.\n- Constraints:\n- changes here have broad blast radius,\n- extraction from the SDK requires strong evidence and explicit compatibility planning.\n\n### `@a5c-ai/babysitter`\n\n- State: Current\n- Role: primary CLI package surface\n- Responsibilities:\n- user-facing CLI packaging,\n- command routing and operational distribution of SDK-backed functionality.\n- Constraints:\n- must preserve install and operational expectations for existing users.\n\n### `@a5c-ai/genty-platform`\n\n- State: Current\n- Role: agent runtime and orchestration-facing execution layer\n- Responsibilities:\n- harness invocation flows,\n- session/runtime integration,\n- orchestration runtime behaviors that are not yet proven as standalone packages.\n- Constraints:\n- still contains multiple concerns,\n- any rename away from `@a5c-ai/genty-platform` is deferred until a decision record defines the target name, migration plan, and validation path,\n- should be improved by internal seam clarification before broad extraction.\n\n### `plugins/*`\n\n- State: Current\n- Role: real integration and packaging boundaries\n- Responsibilities:\n- harness-specific hooks, commands, skills, manifests, and packaging outputs.\n- install, configure, uninstall, update, and registry flows as exposed through current SDK plugin commands.\n- Constraints:\n- plugin manifests are a practical source of truth for compatibility,\n- compiler changes must be checked against actual generated plugin metadata, not just intended schema.\n- marketplace or governance claims must not exceed the install/update/manifest behavior evidenced by the repo.\n\n## 2. Candidate Boundaries\n\nThese are plausible extraction or rename candidates, but not yet committed deliverables.\n\n### Hook Multiplexing / Plugin Compilation Utilities\n\n- State: Candidate\n- Why it might be worth doing:\n- the concepts already exist in repo history and surrounding docs,\n- packaging and cross-harness compilation are real concerns with observable outputs.\n- Extraction trigger:\n- the subsystem can be tested and versioned with limited coupling.\n- Do not extract if:\n- the move mostly renames concepts without reducing risk or complexity.\n\n### Internal Harness Runtime Seams\n\n- State: Candidate\n- Why it might be worth doing:\n- `agent-platform` likely contains modules with cleaner ownership than the package boundary suggests.\n- Extraction trigger:\n- a subsystem has isolated tests, narrow dependencies, and clear consumers.\n- Do not extract if:\n- the seam requires widespread interface invention to stand alone.\n\n### Packaging / Manifest Validation Layer\n\n- State: Candidate\n- Why it might be worth doing:\n- packaging regressions have immediate user-visible consequences,\n- manifest generation rules are concrete and measurable.\n- Extraction trigger:\n- validation logic becomes cohesive enough to own separately.\n- Do not extract if:\n- a small internal module or compiler correction is sufficient.\n\n## 3. Deferred Package Vocabulary\n\nThe following names may be useful as future concepts, but they are not current package commitments:\n\n- `@a5c-ai/genty-runtime`\n- `@a5c-ai/genty-platform`\n- `@a5c-ai/genty-platform-meta-plugins`\n- `@a5c-ai/genty-platform-orchestration-plugin`\n\nFor now, they should be treated as directional language only. Any one of them needs a decision record, validation plan, and migration story before it becomes normative.\nDeferred vocabulary refers only to possible future rename or re-scope targets, not to the current package itself. The current package remains `@a5c-ai/genty-platform` unless a later decision record promotes one of the deferred names into scope with an explicit migration plan.\nImplementation-phase documents must therefore describe work in current-package terms unless such a decision record has already promoted the deferred name into scope. A deferred package name is not a deliverable placeholder.\n\nThis does not block metaplugins as an implemented pattern. In current V6 terms, metaplugins are higher-order capability abstractions over existing plugin and hook packaging surfaces, including on legacy non-Babysitter agents. The deferred item here is the standalone package name `@a5c-ai/genty-platform-meta-plugins`, not the ability to ship capability bundles for concerns like memory systems, governance, or policy enforcement. `@a5c-ai/extensions-adapter` remains the compiler that emits the concrete per-harness plugin outputs those metaplugins rely on.\n\n## 4. Responsibility Rules\n\nAll package changes proposed under V6 should follow these rules:\n\n1. Prefer internal module boundaries before creating a new package.\n2. Prefer compatibility shims over forced flag days.\n3. Prefer narrow responsibility tables over large imagined API contracts.\n4. Prefer plugin/install validation over abstract packaging diagrams.\n5. Prefer one proven seam over many hypothetical ones.\n\n## 5. Package Specification Template\n\nAny future package spec should fit this template:\n\n- State\n- Role\n- Responsibilities\n- Dependencies\n- Consumers\n- Validation method\n- Rollback method\n- Extraction or rename trigger\n\nIf a package cannot be described that way in one page, it is not ready.\n\n## 6. Validation Expectations\n\nFor package-level changes, the default validation set is:\n\n- build or test commands for the touched package,\n- install or packaging checks if the package ships externally,\n- manifest validation if plugin compilation is involved,\n- compatibility notes if naming changes are introduced.\n\n## 7. Invalidated Spec Style\n\nThe following spec patterns are explicitly rejected for the current V6 stage:\n\n- multi-page invented API blocks for packages that do not exist,\n- broad claims of plugin isolation or governance enforcement without implementation evidence,\n- marketplace-governance promises such as certification, revenue sharing, dispute handling, takedown programs, or automatic rollback without executable support,\n- describing metaplugins as unavailable until a future standalone package exists,\n- equating metaplugins with `extensions-adapter` or with any single concrete unified plugin bundle,\n- dependency graphs that imply committed packages without migration sequencing,\n- package lists that obscure which items are real versus hypothetical.\n\n---\n\nRelated documents: [V6 Architecture Specification](v6-architecture-specification.md), [V6 Implementation Roadmap](v6-implementation-roadmap.md), [Current State Analysis](current-state.md)\n",
    "documents": []
  },
  "outgoingEdges": [],
  "incomingEdges": [
    {
      "from": "page:docs-v6-spec-and-roadmap",
      "to": "page:docs-v6-spec-and-roadmap-package-specs",
      "kind": "contains_page"
    }
  ]
}