{
  "id": "page:docs-user-guide-reference-glossary",
  "_kind": "Page",
  "_file": "wiki/docs/user-guide/reference/glossary.md",
  "_cluster": "wiki",
  "attributes": {
    "nodeKind": "Page",
    "sourcePath": "docs/user-guide/reference/glossary.md",
    "sourceKind": "repo-docs",
    "title": "Babysitter Glossary",
    "displayName": "Babysitter Glossary",
    "slug": "docs/user-guide/reference/glossary",
    "articlePath": "wiki/docs/user-guide/reference/glossary.md",
    "article": "\n# Babysitter Glossary\n\n**Version:** 1.1\n**Last Updated:** 2026-01-26\nLast refreshed: 2026-04-25\n**Audience:** All users\n\nThis glossary provides definitions for technical terms and concepts used in Babysitter documentation. Terms are organized alphabetically with cross-references to related concepts and links to detailed documentation.\n\n---\n\n## Quick Reference for Beginners\n\n**New to Babysitter?** Here are the 10 most important terms to know:\n\n| Term | Plain English | Example |\n|------|--------------|---------|\n| **Run** | One execution of a workflow | \"I started a run to build my feature\" |\n| **Process** | A reusable workflow template | \"The TDD process writes tests first\" |\n| **Iteration** | One try-and-improve cycle | \"It took 3 iterations to pass all tests\" |\n| **Quality Gate** | A check that must pass | \"The tests are a quality gate\" |\n| **Breakpoint** | A pause for your approval | \"It stopped at a breakpoint for me to review\" |\n| **Journal** | A record of everything that happened | \"I can see in the journal what the AI did\" |\n| **Task** | A single unit of work | \"The 'run tests' task checks if tests pass\" |\n| **Effect** | Something the AI wants to do | \"The effect was to create a file\" |\n| **Convergence** | Getting better until target met | \"Quality converged from 60% to 95%\" |\n| **Artifact** | A file created during the run | \"The plan.md artifact shows the AI's plan\" |\n\n**Start here:** Read the [Getting Started guide](../getting-started/README.md) to see these concepts in action.\n\n---\n\n## Table of Contents\n\n- [A](#a) | [B](#b) | [C](#c) | [D](#d) | [E](#e) | [F](#f) | [G](#g) | [H](#h) | [I](#i) | [J](#j) | [K](#k) | [L](#l) | [M](#m) | [N](#n) | [O](#o) | [P](#p) | [Q](#q) | [R](#r) | [S](#s) | [T](#t) | [U](#u) | [V](#v) | [W](#w)\n\n---\n\n## A\n\n### Agent\n\nA **task type** representing LLM-powered operations within a process. Agents perform intelligent tasks like planning, scoring, code review, and analysis.\n\n**Example:**\n```javascript\n{\n  kind: 'agent',\n  agent: {\n    name: 'quality-scorer',\n    prompt: { role: 'QA engineer', task: 'Score results 0-100' }\n  }\n}\n```\n\n**Related:** [Task](#task), [Skill](#skill), [Effect](#effect)\n\n**See Also:** [Process Definitions](../features/process-definitions.md)\n\n---\n\n### Agent Task\n\nA task definition that invokes an LLM agent to perform intelligent operations. Agent tasks specify the agent name, prompt configuration, and expected output schema.\n\n**Example:**\n```javascript\nconst agentTask = defineTask('scorer', (args, ctx) => ({\n  kind: 'agent',\n  title: 'Score quality',\n  agent: {\n    name: 'quality-scorer',\n    prompt: {\n      role: 'QA engineer',\n      task: 'Score the implementation',\n      outputFormat: 'JSON'\n    },\n    outputSchema: { type: 'object', required: ['score'] }\n  }\n}));\n```\n\n**Related:** [Agent](#agent), [Task Definition](#task-definition)\n\n---\n\n### Approval Gate\n\nSee [Breakpoint](#breakpoint).\n\n---\n\n### Artifact\n\nAny file produced during a run, stored in the `artifacts/` directory. Common artifacts include plans, specifications, reports, and generated documentation.\n\n**Location:** `.a5c/runs/<runId>/artifacts/`\n\n**Examples:**\n- `process.md` - Process description\n- `plan.md` - Implementation plan\n- `specs.md` - Specifications document\n\n**Related:** [Run Directory](#run-directory)\n\n---\n\n## B\n\n### Babysitter\n\nThe orchestration framework for Claude Code that enables deterministic, event-sourced workflow management. Babysitter provides structured multi-step workflows with quality gates, human approval checkpoints, and session persistence.\n\n**Components:**\n- Main CLI (`@a5c-ai/babysitter`) - Recommended end-user install for `babysitter`\n- SDK (`@a5c-ai/babysitter-sdk`) - Public SDK/library and core CLI implementation\n- Runtime CLI (`@a5c-ai/babysitter-agent`) - Optional runtime/orchestration commands\n- Plugin (`babysitter@a5c.ai`) - Claude Code integration\n\n**Related:** [SDK](#sdk), [Plugin](#plugin)\n\n---\n\n### Babysitter Skill\n\nThe primary Claude Code skill for orchestrating runs. The skill manages the orchestration loop, executing iterations until completion.\n\n**Location:** `plugins/babysitter-unified/skills/babysit/SKILL.md`\n\n**Invocation:**\n```bash\n/babysitter:call Build a REST API with TDD\n```\n\n**Equivalent verbs:** The following commands are functionally identical:\n- `/babysitter:call build a feature`\n- `/babysitter:call create a feature`\n- `/babysitter:call implement a feature`\n\nAll verbs (build, create, implement) trigger the same orchestration workflow.\n\n**Related:** [Skill](#skill), [In-Session Loop](#in-session-loop)\n\n---\n\n### Breakpoint\n\nA pause point in a process that requires human approval before continuing. Breakpoints enable human-in-the-loop workflows for critical decisions like deployment approval, plan review, or security-sensitive changes. `ctx.breakpoint()` returns a `BreakpointResult` containing `{ approved: boolean; response?: string; feedback?: string; option?: string; respondedBy?: string; allResponses?: array }`.\n\nBreakpoints support **routing** to direct approval requests to specific experts via the `expert` field (a string, array of strings, or `'owner'`), categorization via `tags`, and multi-reviewer resolution via `strategy` (`'single'`, `'first-response-wins'`, `'collect-all'`, or `'quorum'`). The `previousFeedback` and `attempt` fields provide retry context when a breakpoint is re-presented after rejection.\n\n**Example:**\n```javascript\nconst result = await ctx.breakpoint({\n  question: 'Approve the deployment?',\n  title: 'Production Deployment',\n  expert: 'ops-lead',\n  tags: ['deployment', 'production'],\n  context: {\n    files: [{ path: 'artifacts/plan.md', format: 'markdown' }]\n  }\n});\nif (!result.approved) {\n  ctx.log('Deployment rejected', { feedback: result.feedback, by: result.respondedBy });\n}\n```\n\n**See Also:** [Breakpoints Feature](../features/breakpoints.md)\n\n---\n\n## C\n\n### CLI (Command-Line Interface)\n\nThe command-line tool for managing Babysitter runs. Provides commands for run lifecycle management, task operations, and state inspection.\n\n**Binary Names:** `babysitter`, `babysitter-sdk`\n\n**Installation:**\n```bash\nnpm install -g @a5c-ai/babysitter\n```\n\n**Related:** [SDK](#sdk)\n\n**See Also:** [CLI Reference](./cli-reference.md)\n\n---\n\n### Completion Promise\n\nA special XML tag that signals the end of an in-session loop. When Claude outputs `<promise>TEXT</promise>` where TEXT matches the completion proof, the loop exits.\n\n**Format:** `<promise>COMPLETION_PROOF</promise>`\n\n**Usage:** Only output when the run status is `completed`.\n\n**Related:** [In-Session Loop](#in-session-loop), [Completion Proof](#completion-proof)\n\n---\n\n### Completion Proof\n\nA unique string emitted by `run:iterate` and `run:status` when a run completes successfully. Used with the completion promise to exit the in-session loop.\n\n**Example Output:**\n```json\n{\n  \"status\": \"completed\",\n  \"completionProof\": \"run-abc123-completed-xyz789\"\n}\n```\n\n**Related:** [Completion Promise](#completion-promise)\n\n---\n\n### Context API\n\nThe interface available to process functions for interacting with the orchestration system. Provides methods for executing tasks, creating breakpoints, parallel execution, and state management.\n\n**Methods:**\n- `ctx.task(taskDef, inputs)` - Execute a task\n- `ctx.breakpoint(payload)` - Request human approval, returns `BreakpointResult`. Supports `expert`, `tags`, `strategy`, `previousFeedback`, and `attempt` routing fields.\n- `ctx.sleepUntil(timestamp)` - Time gate\n- `ctx.parallel.all(tasks)` - Parallel execution\n- `ctx.hook(name, payload)` - Call custom hooks\n- `ctx.log(message)` - Log to journal\n- `ctx.now()` - Get deterministic timestamp\n\n**Related:** [Process](#process), [Intrinsic](#intrinsic)\n\n---\n\n### Convergence\n\nSee [Quality Convergence](#quality-convergence).\n\n---\n\n## D\n\n### Deterministic Replay\n\nThe ability to reproduce the exact same execution path given the same inputs and journal. Achieved through event sourcing where all state changes are recorded as immutable events.\n\n**Benefits:**\n- Time-travel debugging\n- Reliable session resumption\n- Audit trail verification\n\n**Related:** [Event Sourcing](#event-sourcing), [Journal](#journal)\n\n---\n\n## E\n\n### Effect\n\nA side-effect request generated by process execution. Effects include tasks, breakpoints, and sleep gates. Each effect has a unique `effectId` and tracks status through the journal.\n\n**Effect Kinds:**\n- `node` - Node.js script execution\n- `agent` - LLM agent invocation\n- `skill` - Claude Code skill invocation\n- `breakpoint` - Human approval gate\n- `sleep` - Time-based wait\n\n**Related:** [Effect ID](#effect-id), [Task](#task)\n\n---\n\n### Effect ID\n\nA unique identifier assigned to each effect within a run. Used for tracking, posting results, and state management.\n\n**Format:** `effect-<ulid>`\n\n**Example:** `effect-01HJKMNPQR3STUVWXYZ012345`\n\n**Related:** [Effect](#effect)\n\n---\n\n### Entry Point\n\nThe JavaScript/TypeScript file and export that defines a process. Specified when creating a run using the `--entry` flag.\n\n**Format:** `<path>#<export>`\n\n**Example:** `.a5c/processes/build/process.js#buildProcess`\n\n**Related:** [Process](#process), [run:create](#runcreate)\n\n---\n\n### Event\n\nA single immutable record in the journal representing a state change. Events have a type, recordedAt timestamp, data object, and checksum. The sequence number is derived from the filename, not stored in the event body.\n\n**Event Types:**\n- `RUN_CREATED` - Run initialization\n- `EFFECT_REQUESTED` - Effect requested (includes breakpoints with `kind: \"breakpoint\"`)\n- `EFFECT_RESOLVED` - Effect completed (with `status: \"ok\"` or `\"error\"`)\n- `RUN_COMPLETED` - Successful completion\n- `RUN_FAILED` - Run failure\n\n**Related:** [Journal](#journal), [Event Sourcing](#event-sourcing)\n\n---\n\n### Event Sourcing\n\nAn architectural pattern where all state changes are recorded as immutable events. State is derived by replaying the event history. This enables deterministic replay, audit trails, and time-travel debugging.\n\n**Benefits:**\n- Complete audit trail\n- Deterministic behavior\n- Resumable sessions\n- Debug-friendly\n\n**Related:** [Journal](#journal), [Deterministic Replay](#deterministic-replay)\n\n---\n\n## G\n\n### GSD (Get Stuff Done)\n\nA methodology focused on rapid task completion. GSD emphasizes pragmatic execution over extensive planning.\n\n**Location:** `library/methodologies/gsd/`\n\n**Related:** [Methodology](#methodology), [TDD](#tdd-test-driven-development)\n\n---\n\n## H\n\n### Hook\n\nA shell script executed at specific lifecycle points during orchestration. Hooks enable custom behavior for task execution, notifications, logging, and integrations.\n\n**Discovery Priority:**\n1. Per-repo: `.a5c/hooks/<hook-name>/`\n2. Per-user: `~/.config/babysitter/hooks/<hook-name>/`\n3. Plugin: `plugins/babysitter-unified/hooks/<hook-name>/`\n\n**Hook Types:**\n- `on-run-start` - When run is created\n- `on-run-complete` - When run completes\n- `on-iteration-start` - Before iteration (core orchestration)\n- `on-iteration-end` - After iteration\n- `on-task-start` - Before task execution\n- `on-task-complete` - After task execution\n- `on-breakpoint` - Breakpoint notification\n\n**Related:** [Hook Dispatcher](#hook-dispatcher)\n\n**See Also:** [Configuration Reference](./configuration.md)\n\n---\n\n### Hook Dispatcher\n\nThe component that discovers and executes hooks. The maintained hook source lives under `plugins/babysitter-unified/hooks/`. It is responsible for finding hooks, executing them with payloads, and collecting results.\n\n**Related:** [Hook](#hook)\n\n---\n\n### Human-in-the-Loop\n\nA workflow pattern that includes human approval checkpoints. Implemented through breakpoints that pause execution until a human reviews and approves.\n\n**Use Cases:**\n- Production deployments\n- Security-sensitive changes\n- Major architectural decisions\n- Plan and specification review\n\n**Related:** [Breakpoint](#breakpoint)\n\n---\n\n## I\n\n### In-Session Loop\n\nA mechanism for continuous iteration within a single Claude Code session. The stop hook intercepts exit attempts and continues the loop until completion or max iterations reached.\n\n**Components:**\n- State file: `$CLAUDE_PLUGIN_ROOT/state/${SESSION_ID}.md`\n\n**Invocation:**\n```bash\n/babysitter:call Build feature --max-iterations 20\n```\n\n**Related:** [Stop Hook](#stop-hook), [Completion Promise](#completion-promise)\n\n---\n\n### Inputs\n\nThe initial data provided to a process when creating a run. Stored in `inputs.json` at the run root.\n\n**Location:** `.a5c/runs/<runId>/inputs.json`\n\n**Example:**\n```json\n{\n  \"feature\": \"user-authentication\",\n  \"targetQuality\": 85,\n  \"maxIterations\": 5\n}\n```\n\n**Related:** [Run](#run), [Process](#process)\n\n---\n\n### Intrinsic\n\nA built-in SDK function callable from within a process. Intrinsics provide the core capabilities for task execution, breakpoints, parallel operations, and state management.\n\n**Core Intrinsics:**\n- `ctx.task()` - Execute a task\n- `ctx.breakpoint()` - Request approval, returns `BreakpointResult`. Supports routing (`expert`, `tags`, `strategy`) and retry context (`previousFeedback`, `attempt`).\n- `ctx.sleepUntil()` - Time gate\n- `ctx.parallel.all()` - Batch execution\n- `ctx.hook()` - Custom hooks\n- `ctx.log()` - Logging\n- `ctx.now()` - Timestamp\n\n**Related:** [Context API](#context-api)\n\n---\n\n### Invocation Key\n\nA unique identifier for a specific call to a task within a process. Used to track and deduplicate task executions.\n\n**Format:** `<taskId>:<sequence>`\n\n**Example:** `task/build:1`\n\n**Related:** [Task](#task), [Effect](#effect)\n\n---\n\n### Iteration\n\nA single pass through the orchestration loop. Each iteration processes pending effects, executes tasks, and updates state.\n\n**Iteration Status Values:**\n- `executed` - Tasks executed, continue looping\n- `waiting` - Breakpoint or sleep active\n- `completed` - Run finished successfully\n- `failed` - Run failed with error\n- `none` - No pending effects\n\n**Related:** [Orchestration Loop](#orchestration-loop)\n\n---\n\n## J\n\n### Journal\n\nThe append-only event log recording all state changes. Located at `.a5c/runs/<runId>/journal/`. Each event is stored as a separate JSON file.\n\n**File Naming:** `<sequence>.<ulid>.json`\n\n**Example:** `000042.01HJKMNPQR3STUVWXYZ012345.json`\n\n**Benefits:**\n- Complete audit trail\n- Deterministic replay\n- State reconstruction\n- Time-travel debugging\n\n**Related:** [Event](#event), [Event Sourcing](#event-sourcing)\n\n**See Also:** [Journal System](../features/journal-system.md)\n\n---\n\n### JSON Lines (JSONL)\n\nA format where each line is a complete JSON object. Used for streaming data.\n\n> **Note:** The Babysitter journal does **not** use JSONL format. It stores individual JSON files, one per event.\n\n---\n\n## K\n\n### Kind\n\nThe type classification of an effect or task. Determines how the effect is executed.\n\n**Effect Kinds:**\n- `node` - Node.js script\n- `shell` - Shell command\n- `agent` - LLM agent\n- `skill` - Claude Code skill\n- `breakpoint` - Human approval\n- `sleep` - Time gate\n\n**Related:** [Effect](#effect), [Task](#task)\n\n---\n\n## L\n\n### Label\n\nAn optional descriptive string attached to tasks for identification in logs and UI.\n\n**Example:**\n```javascript\n{\n  kind: 'node',\n  label: 'Build workspace',\n  node: { entry: './scripts/build.js' }\n}\n```\n\n**Related:** [Task](#task)\n\n---\n\n## M\n\n### Methodology\n\nA high-level structured approach or pattern for software development. Methodologies define the *conceptual framework* - the \"what\" and \"why\" of a development approach.\n\n**Key distinction:** Methodology = high-level concept/pattern; Process = low-level code implementation of a methodology.\n\n**You can use ANY methodology and get great results.** In this repository snapshot, Babysitter includes 38 methodology directories under `library/methodologies/` - pick the one that fits your project style, or let Babysitter choose automatically based on your request.\n\n**Built-in Methodologies (examples from the current library):**\n\n| Methodology | Description | Source |\n|-------------|-------------|--------|\n| **TDD Quality Convergence** | Test-first development with iterative quality improvement | `library/tdd-quality-convergence.js` |\n| **GSD (Get Stuff Done)** | Rapid, pragmatic 8-phase execution | [gsd/](../../../library/methodologies/gsd/README.md) |\n| **Spec-Kit** | Specification-driven development with governance | [spec-kit/](../../../library/methodologies/spec-kit/README.md) |\n| **ATDD/TDD** | Acceptance test-driven and test-driven development | [atdd-tdd/](../../../library/methodologies/atdd-tdd/README.md) |\n| **BDD/Specification by Example** | Behavior-driven development with Gherkin | [bdd-specification-by-example/](../../../library/methodologies/bdd-specification-by-example/README.md) |\n| **Domain-Driven Design** | Strategic and tactical DDD patterns | [domain-driven-design/](../../../library/methodologies/domain-driven-design/README.md) |\n| **Feature-Driven Development** | Feature-centric with parking lot tracking | [feature-driven-development/](../../../library/methodologies/feature-driven-development/README.md) |\n| **Hypothesis-Driven Development** | Experimentation and validation framework | [hypothesis-driven-development/](../../../library/methodologies/hypothesis-driven-development/README.md) |\n| **Example Mapping** | BDD workshop technique for requirements | [example-mapping/](../../../library/methodologies/example-mapping/README.md) |\n| **Scrum** | Sprint-based iterative development | [scrum/](../../../library/methodologies/scrum/README.md) |\n| **Kanban** | Pull-based system with WIP limits | [kanban/](../../../library/methodologies/kanban/README.md) |\n\nEach methodology has one or more [Process](#process) implementations in the codebase. Browse all methodologies at [`library/methodologies/`](../../../library/methodologies/).\n\n**Related:** [Process](#process), [TDD Quality Convergence](#tdd-quality-convergence), [Process Library](../features/process-library.md)\n\n---\n\n## N\n\n### Node Task\n\nA task type that executes a Node.js script. The most common task type for running build scripts, tests, and automation.\n\n**Example:**\n```javascript\n{\n  kind: 'node',\n  node: {\n    entry: './scripts/build.js',\n    timeout: 300000\n  }\n}\n```\n\n**Related:** [Task](#task), [Effect](#effect)\n\n---\n\n## O\n\n### Orchestration\n\nThe process of managing run execution and state. Orchestration coordinates task execution, handles effects, and maintains the event journal.\n\n**Related:** [Orchestration Loop](#orchestration-loop), [Run](#run)\n\n---\n\n### Orchestration Loop\n\nThe iterative cycle that drives run execution. Each loop iteration: runs `run:iterate`, checks pending effects, executes tasks, posts results.\n\n**Flow:**\n```\niterate -> get effects -> perform effects -> post results -> repeat\n```\n\n**Related:** [Iteration](#iteration), [run:iterate](#runiterate)\n\n---\n\n## P\n\n### Parallel Execution\n\nThe ability to execute multiple tasks concurrently. Implemented via `ctx.parallel.all()`.\n\n**Example:**\n```javascript\nconst [build, lint, test] = await ctx.parallel.all([\n  () => ctx.task(buildTask, {}),\n  () => ctx.task(lintTask, {}),\n  () => ctx.task(testTask, {})\n]);\n```\n\n**Related:** [Context API](#context-api)\n\n**See Also:** [Parallel Execution](../features/parallel-execution.md)\n\n---\n\n### Pending Effect\n\nAn effect that has been requested but not yet resolved. Listed via `task:list --pending`.\n\n**Related:** [Effect](#effect)\n\n---\n\n### Plugin\n\nA Claude Code extension package. The Babysitter plugin (`babysitter@a5c.ai`) provides skills, hooks, and commands for orchestration.\n\n**Installation:**\n```bash\nclaude plugin marketplace add a5c-ai/babysitter-claude\nclaude plugin install --scope user babysitter@a5c.ai\n```\n\n**Related:** [Babysitter Skill](#babysitter-skill)\n\n---\n\n### Process\n\nA JavaScript/TypeScript function that is the *low-level code implementation* of a workflow. Processes use the Context API to execute tasks, create breakpoints, and manage state.\n\n**Key distinction:** Process = low-level code implementation; [Methodology](#methodology) = high-level concept/pattern that a process implements.\n\n<!-- glossary:process-library:start -->\n**Babysitter currently exposes 2,239 JavaScript process files in the live repository tree** organized across methodologies, shared processes, and specializations.\n\n| Domain | Processes | Browse |\n|--------|-----------|--------|\n| **Development and technical specializations** | 837 | [Browse →](../../../library/specializations/) |\n| **Business domains** | 490 | [Browse →](../../../library/specializations/domains/business/) |\n| **Science & engineering domains** | 551 | [Browse →](../../../library/specializations/domains/science/) |\n| **Social sciences & humanities** | 160 | [Browse →](../../../library/specializations/domains/social-sciences-humanities/) |\n<!-- glossary:process-library:end -->\n\n**Structure:**\n```javascript\nexport async function process(inputs, ctx) {\n  const plan = await ctx.task(planTask, inputs);\n  const review = await ctx.breakpoint({ question: 'Approve plan?' });\n  if (!review.approved) return { success: false, feedback: review.feedback };\n  const result = await ctx.task(buildTask, { plan });\n  return result;\n}\n```\n\n**Location:** `.a5c/runs/<runId>/code/main.js`\n\n**Related:** [Methodology](#methodology), [Context API](#context-api), [Entry Point](#entry-point)\n\n**See Also:** [Process Definitions](../features/process-definitions.md), [Process Library](../features/process-library.md)\n\n---\n\n### Process Definition\n\nSee [Process](#process).\n\n---\n\n### Process ID\n\nA unique identifier for a process type. Used when creating runs to specify which process to execute.\n\n**Format:** `<namespace>/<name>`\n\n**Example:** `dev/build`, `ci/test`, `tdd/feature`\n\n**Related:** [Process](#process), [run:create](#runcreate)\n\n---\n\n## Q\n\n### Quality Convergence\n\nAn iterative methodology that repeats execution until quality metrics meet targets. Each iteration measures quality and refines implementation.\n\n**Example Flow:**\n```\nimplement -> measure quality -> below target? -> refine -> repeat\n```\n\n**Related:** [Quality Score](#quality-score), [TDD](#tdd-test-driven-development)\n\n**See Also:** [Quality Convergence](../features/quality-convergence.md)\n\n---\n\n### Quality Score\n\nA **multi-dimensional** assessment of implementation quality. Quality scores are not a single number - they comprise multiple dimensions that are weighted and combined into an overall score.\n\n**Dimensions typically include:**\n- **Tests**: Pass rate and coverage percentage\n- **Code Quality**: Lint errors, complexity, formatting\n- **Security**: Vulnerability scans, secrets detection\n- **Performance**: Response times, bundle size (when applicable)\n- **Type Safety**: TypeScript errors, static analysis\n\n**Example:**\n```json\n{\n  \"overall\": 85,\n  \"dimensions\": {\n    \"tests\": 92,\n    \"codeQuality\": 88,\n    \"security\": 100,\n    \"performance\": 75\n  },\n  \"weights\": {\n    \"tests\": 0.30,\n    \"codeQuality\": 0.25,\n    \"security\": 0.25,\n    \"performance\": 0.20\n  }\n}\n```\n\n**See Also:** [Quality Convergence](../features/quality-convergence.md) for the five quality gate categories and detailed scoring formulas in [Best Practices](../features/best-practices.md#custom-scoring-strategies).\n\n**Related:** [Quality Convergence](#quality-convergence), [Agent](#agent)\n\n---\n\n## R\n\n### Result\n\nThe output from a completed task. Stored at `tasks/<effectId>/result.json`.\n\n**Schema:**\n```json\n{\n  \"status\": \"ok\",\n  \"value\": { /* task output */ },\n  \"metadata\": { /* execution metadata */ }\n}\n```\n\n**Related:** [Task](#task), [task:post](#taskpost)\n\n---\n\n### Resume\n\nContinuing a previously interrupted run. The journal enables exact state reconstruction for seamless resumption.\n\n**Command:**\n```bash\n/babysitter:babysit resume --run-id <runId>\n```\n\n**Related:** [Run](#run), [Deterministic Replay](#deterministic-replay)\n\n**See Also:** [Run Resumption](../features/run-resumption.md)\n\n---\n\n### Run\n\nA single execution of a process. Each run has a unique ID, directory, journal, and state. Runs are resumable across sessions.\n\n**Directory:** `.a5c/runs/<runId>/`\n\n**Lifecycle:**\n`created` -> `running` -> `completed` | `failed`\n\n**Related:** [Run ID](#run-id), [Run Directory](#run-directory)\n\n---\n\n### Run Directory\n\nThe directory containing all data for a run.\n\n**Structure:**\n```\n.a5c/runs/<runId>/\n├── run.json           # Run metadata\n├── inputs.json        # Initial inputs\n├── code/\n│   └── main.js        # Process implementation\n├── artifacts/         # Generated files\n├── journal/           # Event log\n├── state/\n│   └── state.json     # State cache\n└── tasks/             # Task artifacts\n```\n\n**Related:** [Run](#run)\n\n---\n\n### Run ID\n\nA unique identifier for a run. Typically includes timestamp and description.\n\n**Format:** `run-<YYYYMMDD>-<HHMMSS>[-<description>]`\n\n**Example:** `run-20260125-143012-auth-feature`\n\n**Related:** [Run](#run)\n\n---\n\n## S\n\n### SDK (Software Development Kit)\n\nThe core Babysitter package providing the orchestration runtime, CLI, and APIs.\n\n**Package:** `@a5c-ai/babysitter-sdk`\n\n**Installation:**\n```bash\nnpm install @a5c-ai/babysitter-sdk\n```\n\n**Components:**\n- Runtime - Process execution engine\n- CLI - Command-line interface\n- Storage - Journal and state management\n- Tasks - Task definition and execution\n\n**Related:** [CLI](#cli-command-line-interface)\n\n---\n\n### Session ID\n\nA unique identifier for a Claude Code session. Used for state isolation in in-session loops.\n\n**Environment Variable:** `AGENT_SESSION_ID`\n\n**Related:** [In-Session Loop](#in-session-loop)\n\n---\n\n### Shell Task\n\nA task type that executes shell commands.\n\n**Example:**\n```javascript\n{\n  kind: 'shell',\n  shell: {\n    command: 'npm run build',\n    cwd: './packages/app'\n  }\n}\n```\n\n**Related:** [Task](#task)\n\n---\n\n### Skill\n\nA Claude Code capability that provides specialized functionality. The Babysitter skill (`babysit`) orchestrates runs.\n\n**Invocation:**\n```bash\n/babysitter:babysit <prompt>\n```\n\n**Related:** [Babysitter Skill](#babysitter-skill)\n\n---\n\n### Skill Task\n\nA task type that invokes a Claude Code skill.\n\n**Example:**\n```javascript\n{\n  kind: 'skill',\n  skill: {\n    name: 'codebase-analyzer',\n    context: { scope: 'src/', depth: 3 }\n  }\n}\n```\n\n**Related:** [Skill](#skill), [Task](#task)\n\n---\n\n### Sleep\n\nA time gate that pauses execution until a specified timestamp.\n\n**Example:**\n```javascript\nawait ctx.sleepUntil(new Date('2026-01-26T10:00:00Z'));\n```\n\n**Related:** [Effect](#effect)\n\n---\n\n### State\n\nThe current status of a run derived from replaying the journal. Cached at `state/state.json` for performance.\n\n**Schema:**\n```json\n{\n  \"runId\": \"run-...\",\n  \"status\": \"running\",\n  \"version\": 42,\n  \"invocations\": {},\n  \"pendingEffects\": []\n}\n```\n\n**Note:** State cache is gitignored (derived from journal).\n\n**Related:** [State Cache](#state-cache), [Journal](#journal)\n\n---\n\n### State Cache\n\nA derived snapshot of current state stored for fast access. Rebuilt from journal if missing or stale.\n\n**Location:** `.a5c/runs/<runId>/state/state.json`\n\n**Related:** [State](#state)\n\n---\n\n### State Version\n\nA monotonically increasing number tracking state changes. Increments with each journal event.\n\n**Related:** [State](#state)\n\n---\n\n### Stop Hook\n\nA Claude Code hook that intercepts exit attempts during in-session loops. Decides whether to allow exit or continue the loop.\n\n**Location:** generated from `plugins/babysitter-unified/hooks/stop.sh`\n\n**Output (block):**\n```json\n{\n  \"decision\": \"block\",\n  \"reason\": \"<prompt>\",\n  \"systemMessage\": \"Babysitter iteration N\"\n}\n```\n\n**Related:** [In-Session Loop](#in-session-loop), [Hook](#hook)\n\n---\n\n## T\n\n### Task\n\nThe core primitive for external work in processes. Tasks define what to execute and how to handle results.\n\n**Task Kinds:**\n- `node` - Node.js script\n- `shell` - Shell command\n- `agent` - LLM agent\n- `skill` - Claude Code skill\n\n**Example:**\n```javascript\nconst result = await ctx.task(buildTask, { target: 'app' });\n```\n\n**Related:** [Effect](#effect), [Task Definition](#task-definition)\n\n---\n\n### Task Definition\n\nA JavaScript object or function that specifies how to create a task. Defines kind, configuration, and I/O paths.\n\n**Example:**\n```javascript\nconst buildTask = defineTask('build', (args, ctx) => ({\n  kind: 'node',\n  title: 'Build project',\n  node: { entry: './scripts/build.js' },\n  io: {\n    inputJsonPath: `tasks/${ctx.effectId}/input.json`,\n    outputJsonPath: `tasks/${ctx.effectId}/result.json`\n  }\n}));\n```\n\n**Related:** [Task](#task)\n\n---\n\n### TDD Quality Convergence\n\nThe full name for Babysitter's test-driven development methodology. TDD Quality Convergence combines traditional TDD (writing tests before implementation) with iterative quality improvement until targets are met.\n\n**Process:**\n1. Write tests first\n2. Implement code to pass tests\n3. Measure quality (tests, coverage, lint, security, etc.)\n4. Iterate until quality target is achieved\n\n**Shorthand:** \"TDD\" is acceptable after first mention in a document.\n\n**Related:** [Quality Convergence](#quality-convergence), [Methodology](#methodology)\n\n**See Also:** [Quality Convergence Guide](../features/quality-convergence.md)\n\n---\n\n### TDD (Test-Driven Development)\n\nSee [TDD Quality Convergence](#tdd-quality-convergence).\n\n**Note:** In Babysitter documentation, \"TDD\" typically refers to the full TDD Quality Convergence methodology, not just traditional test-driven development.\n\n---\n\n## U\n\n### ULID (Universally Unique Lexicographically Sortable Identifier)\n\nA time-sortable unique identifier used for event and effect IDs.\n\n**Example:** `01HJKMNPQR3STUVWXYZ012345`\n\n**Related:** [Event](#event), [Effect ID](#effect-id)\n\n---\n\n## V\n\n### Value\n\nThe main output data from a task result. Passed via `--value` flag when posting results.\n\n**Example:**\n```bash\n$CLI task:post <runId> <effectId> --status ok --value output.json\n```\n\n**Related:** [Result](#result), [task:post](#taskpost)\n\n---\n\n## W\n\n### Waiting\n\nA run status indicating a blocking effect (breakpoint or sleep) is active. Orchestration pauses until the effect is resolved.\n\n**Related:** [Breakpoint](#breakpoint), [Sleep](#sleep), [Iteration](#iteration)\n\n---\n\n## Quick Reference Index\n\n### By Category\n\n**Core Concepts:**\n[Run](#run), [Process](#process), [Journal](#journal), [Event](#event), [Effect](#effect), [Task](#task), [State](#state)\n\n**Task Types:**\n[Node Task](#node-task), [Agent Task](#agent-task), [Skill Task](#skill-task), [Shell Task](#shell-task)\n\n**Workflow:**\n[Orchestration Loop](#orchestration-loop), [Iteration](#iteration), [Quality Convergence](#quality-convergence), [Breakpoint](#breakpoint)\n\n**Architecture:**\n[SDK](#sdk-software-development-kit), [CLI](#cli-command-line-interface), [Plugin](#plugin), [Hook](#hook)\n\n**Session Management:**\n[In-Session Loop](#in-session-loop), [Completion Promise](#completion-promise), [Stop Hook](#stop-hook)\n\n---\n\n## Related Documentation\n\n- [CLI Reference](./cli-reference.md) - Complete CLI command documentation\n- [Configuration Reference](./configuration.md) - Environment variables and settings\n- [FAQ](./faq.md) - Frequently asked questions\n- [Troubleshooting](./troubleshooting.md) - Common issues and solutions\n",
    "documents": []
  },
  "outgoingEdges": [],
  "incomingEdges": [
    {
      "from": "page:docs-user-guide-reference",
      "to": "page:docs-user-guide-reference-glossary",
      "kind": "contains_page"
    }
  ]
}