{
  "id": "page:docs-user-guide-features-best-practices",
  "_kind": "Page",
  "_file": "wiki/docs/user-guide/features/best-practices.md",
  "_cluster": "wiki",
  "attributes": {
    "nodeKind": "Page",
    "sourcePath": "docs/user-guide/features/best-practices.md",
    "sourceKind": "repo-docs",
    "title": "Best Practices Guide: Comprehensive Reference for Babysitter",
    "displayName": "Best Practices Guide: Comprehensive Reference for Babysitter",
    "slug": "docs/user-guide/features/best-practices",
    "articlePath": "wiki/docs/user-guide/features/best-practices.md",
    "article": "\n[Docs](../index.md) › [Features](./index.md) › Best Practices\n\n# Best Practices Guide: Comprehensive Reference for Babysitter\n\n**Version:** 2.0\n**Last Updated:** 2026-06-23\n**Category:** Feature Guide\n\n---\n\n## Overview\n\nThis guide consolidates best practices from across the Babysitter ecosystem into a single reference. Babysitter's job is **enforcement, not assistance**: your workflow is deterministic code, the orchestrator can only do what that code permits, and a mandatory stop after every step keeps complex agentic work obedient. The practices below are about designing that enforced process well. Quality gates are *one* of the guardrail mechanisms covered here, not the headline. Whether you are designing workflows, developing [processes](../reference/glossary.md), optimizing performance, or collaborating with your team, these patterns will help you get the most out of Babysitter.\n\n## On this page\n\n- [The Four Guardrail Layers](#the-four-guardrail-layers)\n- [The Five Quality Gate Categories](#the-five-quality-gate-categories)\n- [Workflow Design Patterns](#workflow-design-patterns)\n- [Process Development Best Practices](#process-development-best-practices)\n- [Quality Convergence Best Practices](#quality-convergence-best-practices)\n- [Performance Optimization](#performance-optimization)\n- [Common Pitfalls and How to Avoid Them](#common-pitfalls-and-how-to-avoid-them)\n- [Quick Reference Checklist](#quick-reference-checklist)\n\n> **Harness-agnostic:** These practices apply unchanged across all 12 supported harnesses. Since v6, Babysitter orchestration runs on the harness-agnostic [Adapters](./adapters.md) runtime, so workflow design, guardrails, quality gates, and resumption work the same whichever harness you use. See the [Install Matrix](../harnesses/install-matrix.md) for the supported harnesses and their setup.\n\n### Core Philosophy: The Two-Loops Architecture\n\nBabysitter implements a **hybrid agentic system** where:\n\n- A **symbolic orchestrator** governs progression, journaling, and phase boundaries — and can only do what your process code permits\n- An **agentic harness** performs adaptive work with tools, but cannot advance until the orchestrator's mandatory stop and process check permit it\n\nThe key insight: **enforcement, not assistance.** Gates block progression until satisfied; they're not suggestions. One consequence of code-defined gates is that quality becomes evidence-driven, not assertion-driven.\n\n> If you don't have evidence, you don't have completion.\n\nFor deep understanding, see [Two-Loops Architecture](./two-loops-architecture.md).\n\n### How to Use This Guide\n\n- **New Users**: Start with Workflow Design Patterns and Quality Gate Varieties sections\n- **Intermediate Users**: Focus on the 90-Score Convergence Strategy and Team Collaboration sections\n- **Advanced Users**: Dive into the Four Guardrail Layers and Process Optimization sections\n- **All Users**: Keep this guide bookmarked for quick reference during development\n\n---\n\n## The Four Guardrail Layers\n\nGuardrails are **not a single feature**. They form a layered approach to safety and control.\n\n### Layer A: Capability Guardrails (What's Possible)\n\nDefine what tools and actions exist.\n\n```javascript\nconst capabilityGuardrails = {\n  allowedTools: ['read', 'write', 'shell', 'search'],\n  pathRestrictions: ['src/**', 'tests/**'],  // Only these paths\n  networkAccess: 'none',                      // No network calls\n  permissions: 'read-write',                  // vs 'read-only'\n  destructiveActions: 'require-confirmation'  // Interactive approval\n};\n```\n\n### Layer B: Budget Guardrails (How Far)\n\nPrevent runaway execution.\n\n```javascript\nconst budgetGuardrails = {\n  maxToolCalls: 100,           // Total tool invocations\n  maxWallClockMinutes: 30,     // Wall-clock timeout\n  maxTokenSpend: 50000,        // LLM token budget\n  maxIterations: 10,           // Convergence loop limit\n  maxFilesModified: 20,        // Scope control\n  rateLimits: {\n    apiCalls: '10/minute',\n    fileWrites: '50/iteration'\n  }\n};\n```\n\n### Layer C: Policy Guardrails (What's Allowed)\n\nRules that define acceptable behavior.\n\n```javascript\nconst policyGuardrails = {\n  rules: [\n    'never exfiltrate secrets',\n    'never modify production directly',\n    'always run tests before merge',\n    'security scans required for dependencies',\n    'no eval() or dynamic code execution',\n    'require explicit confirmation for destructive actions'\n  ],\n  forbiddenPatterns: [\n    /eval\\(/,\n    /exec\\(/,\n    /process\\.env\\.(API_KEY|SECRET)/,\n    /rm\\s+-rf/\n  ]\n};\n```\n\n### Layer D: Behavioral Guardrails (How Decisions Are Made)\n\nStructural consistency in outputs.\n\n```javascript\nconst behavioralGuardrails = {\n  requireStructuredOutputs: true,        // Always JSON schemas\n  requireEvidenceCitations: true,        // Cite tool outputs\n  requireUncertaintyDeclaration: true,   // \"I'm not sure\" allowed\n  requireExplanations: true,             // Justify decisions\n  outputSchemas: {\n    implementation: {\n      type: 'object',\n      required: ['filesModified', 'summary', 'confidence'],\n      properties: {\n        filesModified: { type: 'array', items: { type: 'string' } },\n        summary: { type: 'string' },\n        confidence: { type: 'number', minimum: 0, maximum: 100 }\n      }\n    }\n  }\n};\n```\n\n### Applying Guardrails in Processes\n\n```javascript\n// From methodologies/spec-driven-development.js\nexport async function process(inputs, ctx) {\n  // Apply guardrails to all tasks\n  const guardrails = {\n    capability: { pathRestrictions: ['src/**', 'docs/**'] },\n    budget: { maxIterations: 10, maxTokenSpend: 100000 },\n    policy: { rules: ['follow constitution', 'run all tests'] },\n    behavioral: { requireStructuredOutputs: true }\n  };\n\n  // Implementation task with constraints\n  const impl = await ctx.task(implementTask, {\n    feature: inputs.feature,\n    guardrails  // Passed to harness\n  });\n\n  // Symbolic validation enforces guardrails\n  if (impl.filesModified.length > guardrails.budget.maxFilesModified) {\n    throw new Error('Budget exceeded: too many files modified');\n  }\n}\n```\n\n---\n\n## The Five Quality Gate Categories\n\nQuality gates are **not a single check**. They form a layered validation system. For robust convergence, use **4-5 gate types simultaneously**.\n\n| Gate Type | What It Validates | Tools/Checks |\n|-----------|-------------------|--------------|\n| **1. Functional Tests** | Behavior correctness | Unit, integration, system, acceptance |\n| **2. Code Quality** | Maintainability | Lint, format, complexity, duplication |\n| **3. Static Analysis** | Type safety, bugs | TypeScript, SonarQube, Radon |\n| **4. Security Scanning** | Vulnerabilities | SAST, secrets, dependencies, OWASP |\n| **5. Performance** | Non-functional reqs | FCP, bundle size, API latency |\n\n**Process Library Examples:**\n- `methodologies/v-model.js` - Four test levels (unit → integration → system → acceptance)\n- `methodologies/spec-driven-development.js` - Constitution validation + checklists\n- `gsd/verify-work.js` - UAT with automated diagnosis\n\n### Implementing Multi-Gate Validation\n\n```javascript\n// Run all five gates in parallel for efficiency\nconst [tests, codeQuality, staticAnalysis, security, performance] =\n  await ctx.parallel.all([\n    () => ctx.task(testGateTask, { impl }),\n    () => ctx.task(codeQualityGateTask, { impl }),\n    () => ctx.task(staticAnalysisGateTask, { impl }),\n    () => ctx.task(securityGateTask, { impl }),\n    () => ctx.task(performanceGateTask, { impl })\n  ]);\n\n// Evidence-driven completion: all gates must pass\nconst allGatesPassed =\n  tests.passed &&\n  codeQuality.passed &&\n  staticAnalysis.passed &&\n  security.passed &&\n  performance.passed;\n```\n\nFor detailed gate configurations and the 90-score convergence pattern, see [Quality Convergence](./quality-convergence.md).\n\n---\n\n## Workflow Design Patterns\n\n### When to Use Breakpoints\n\nBreakpoints create human-in-the-loop approval gates. Use them strategically to balance automation with oversight.\n\n**Use breakpoints when:**\n\n| Scenario | Rationale |\n|----------|-----------|\n| Before production deployments | Prevents accidental production changes |\n| After plan generation | Validates approach before implementation effort |\n| Before irreversible actions | Ensures human oversight for destructive operations |\n| At quality thresholds | Allows human judgment when scores are borderline |\n| For compliance requirements | Creates audit trail of approvals |\n| At multi-phase transitions | Validates completion before proceeding |\n\n**Avoid breakpoints when:**\n\n| Scenario | Alternative |\n|----------|-------------|\n| Every minor step | Use logging instead (`ctx.log()`) |\n| Automated testing phases | Use quality convergence with auto-continue |\n| Automated pipelines (unless required) | Use `BABYSITTER_AUTO_APPROVE=true` |\n| Low-risk, reversible actions | Trust the automation |\n\n**Breakpoint placement pattern:**\n\n```javascript\nexport async function process(inputs, ctx) {\n  // Phase 1: Planning (minimal risk)\n  const plan = await ctx.task(planningTask, { feature: inputs.feature });\n\n  // BREAKPOINT: Before committing to implementation approach\n  // ctx.breakpoint() returns BreakpointResult: { approved, response?, feedback?, option?, respondedBy?, allResponses? }\n  // Supports routing: expert, tags, strategy, previousFeedback, attempt\n  const planReview = await ctx.breakpoint({\n    question: 'Review the implementation plan. Approve to proceed?',\n    title: 'Plan Approval',\n    context: { runId: ctx.runId, files: [{ path: 'artifacts/plan.md', format: 'markdown' }] }\n  });\n\n  if (!planReview.approved) {\n    return { success: false, reason: planReview.feedback };\n  }\n\n  // Phase 2: Implementation (moderate risk)\n  const impl = await ctx.task(implementTask, { plan });\n\n  // Phase 3: Quality Convergence (automated)\n  // No breakpoint needed - automated quality gates handle this\n\n  // BREAKPOINT: Before deployment (high risk)\n  const deployReview = await ctx.breakpoint({\n    question: `Quality: ${quality}. Deploy to production?`,\n    title: 'Production Deployment Approval',\n    context: { runId: ctx.runId, files: [{ path: 'artifacts/final-report.md', format: 'markdown' }] }\n  });\n\n  if (!deployReview.approved) {\n    return { success: false, reason: 'Deployment rejected', feedback: deployReview.feedback };\n  }\n\n  return await ctx.task(deployTask, { impl });\n}\n```\n\n### Iteration Limits and Quality Targets\n\nSetting appropriate limits prevents runaway processes while ensuring quality.\n\n**Recommended iteration limits by task type:**\n\n| Task Type | Iterations | Quality Target | Notes |\n|-----------|------------|----------------|-------|\n| Simple bug fixes | 3-5 | 80-85 | Limited scope, quick convergence |\n| Feature implementation | 5-10 | 85-90 | Moderate complexity |\n| Complex refactoring | 10-15 | 85-95 | May need more iterations |\n| Documentation | 2-4 | 75-85 | Faster convergence expected |\n| Test coverage improvements | 5-8 | 90-95 | Higher target for tests |\n\n**Setting realistic targets:**\n\n```javascript\n// Start conservative, adjust based on observed behavior\nconst {\n  targetQuality = 85,      // Achievable but challenging\n  maxIterations = 5,       // Reasonable upper bound\n  minImprovement = 2,      // Detect plateaus early\n  plateauThreshold = 3     // Iterations without improvement\n} = inputs;\n\n// Early exit on plateau (prevent wasted iterations)\nif (qualityHistory.length >= plateauThreshold) {\n  const recent = qualityHistory.slice(-plateauThreshold);\n  const improvement = Math.max(...recent) - Math.min(...recent);\n  if (improvement < minImprovement) {\n    ctx.log(`Quality plateaued at ${quality}, stopping early`);\n    break;\n  }\n}\n```\n\n### Task Decomposition Strategies\n\nBreak complex work into manageable, testable units.\n\n**Decomposition principles:**\n\n1. **Single Responsibility**: Each task does one thing well\n2. **Clear Inputs/Outputs**: Well-defined interfaces between tasks\n3. **Testable Units**: Each task can be validated independently\n4. **Failure Isolation**: One task's failure does not corrupt others\n5. **Resumable Checkpoints**: Natural pause points for resumption\n\n**Task granularity guidelines:**\n\n| Too Fine | Just Right | Too Coarse |\n|----------|------------|------------|\n| Write single line of code | Implement single function | Implement entire feature |\n| Check one lint rule | Run all linting checks | Build, lint, test, deploy |\n| Test one assertion | Test one module | Test entire application |\n\n**Example decomposition:**\n\n```javascript\n// Good: Clear phases with distinct responsibilities\nexport async function process(inputs, ctx) {\n  // Research phase - gather context\n  const research = await ctx.task(researchTask, { feature: inputs.feature });\n\n  // Planning phase - design approach\n  const plan = await ctx.task(planningTask, { feature: inputs.feature, research });\n\n  // Implementation phase - write code\n  const impl = await ctx.task(implementTask, { plan });\n\n  // Verification phase - run tests\n  const tests = await ctx.task(testTask, { impl });\n\n  // Quality phase - score results\n  const score = await ctx.task(scoreTask, { impl, tests });\n\n  return { success: score.overall >= inputs.targetQuality, score };\n}\n```\n\n### Parallel vs Sequential Execution\n\nChoose the right execution model based on task dependencies.\n\n**Use parallel execution when:**\n\n- Tasks are independent (no shared state)\n- Tasks access different resources\n- Order of completion does not matter\n- You want faster overall execution\n\n**Use sequential execution when:**\n\n- Tasks depend on previous results\n- Tasks modify shared resources\n- Order of execution matters\n- You need predictable behavior for debugging\n\n**Decision matrix:**\n\n| Dependency Type | Execution Model | Example |\n|-----------------|-----------------|---------|\n| No dependencies | Parallel | Lint, test, security scan |\n| Data dependency | Sequential | Build then test |\n| Resource contention | Sequential or chunked parallel | Database migrations |\n| Partial dependency | Mixed | Build first, then parallel tests |\n\n**Implementation patterns:**\n\n```javascript\n// Parallel: Independent quality checks\nconst [coverage, lint, security] = await ctx.parallel.all([\n  () => ctx.task(coverageTask, {}),\n  () => ctx.task(lintTask, {}),\n  () => ctx.task(securityTask, {})\n]);\n\n// Sequential: Dependent operations\nconst build = await ctx.task(buildTask, {});\nconst test = await ctx.task(testTask, { buildArtifacts: build.artifacts });\nconst deploy = await ctx.task(deployTask, { testReport: test.report });\n\n// Mixed: Sequential then parallel\nconst build = await ctx.task(buildTask, {});\nconst [unitTests, e2eTests, docTests] = await ctx.parallel.all([\n  () => ctx.task(unitTestTask, { build }),\n  () => ctx.task(e2eTestTask, { build }),\n  () => ctx.task(docTestTask, { build })\n]);\n```\n\n---\n\n## Process Development Best Practices\n\n### Process Structure and Organization\n\nWell-structured processes are easier to understand, maintain, and debug.\n\n**Recommended structure:**\n\n```javascript\n// 1. Imports and dependencies\nimport { defineTask } from '@a5c-ai/babysitter-sdk';\n\n// 2. Constants and configuration\nconst DEFAULT_QUALITY_TARGET = 85;\nconst DEFAULT_MAX_ITERATIONS = 5;\n\n// 3. Task definitions (reusable building blocks)\nexport const buildTask = defineTask('build', (args, taskCtx) => ({\n  kind: 'node',\n  title: `Build ${args.target}`,\n  node: {\n    entry: 'scripts/build.js',\n    args: ['--target', args.target]\n  },\n  io: {\n    inputJsonPath: `tasks/${taskCtx.effectId}/input.json`,\n    outputJsonPath: `tasks/${taskCtx.effectId}/result.json`\n  }\n}));\n\n// 4. Helper functions\nfunction calculateWeightedScore(scores, weights) {\n  return Object.entries(weights).reduce(\n    (sum, [key, weight]) => sum + (scores[key] || 0) * weight,\n    0\n  );\n}\n\n// 5. Main process function (orchestration logic)\nexport async function process(inputs, ctx) {\n  const {\n    feature,\n    targetQuality = DEFAULT_QUALITY_TARGET,\n    maxIterations = DEFAULT_MAX_ITERATIONS\n  } = inputs;\n\n  // Phase 1: Planning\n  // Phase 2: Implementation\n  // Phase 3: Verification\n  // Phase 4: Final approval\n\n  return { success, quality, iterations };\n}\n```\n\n**File organization for complex processes:**\n\n```\nmy-process/\n├── main.js              # Main process function\n├── tasks/\n│   ├── build.js         # Build-related tasks\n│   ├── test.js          # Test-related tasks\n│   └── quality.js       # Quality scoring tasks\n├── helpers/\n│   ├── scoring.js       # Scoring utilities\n│   └── validation.js    # Input validation\n├── examples/\n│   └── inputs.json      # Example inputs\n└── README.md            # Process documentation\n```\n\n### Error Handling Strategies\n\nRobust error handling prevents data loss and enables recovery.\n\n**Error handling patterns:**\n\n```javascript\nexport async function process(inputs, ctx) {\n  try {\n    // Main workflow logic\n    const result = await ctx.task(riskyTask, { data: inputs.data });\n    return { success: true, result };\n\n  } catch (error) {\n    // Log error for debugging\n    ctx.log('Task failed', { error: error.message, stack: error.stack });\n\n    // Determine if recoverable\n    if (isTransientError(error)) {\n      // Retry with backoff\n      await ctx.sleepUntil(new Date(ctx.now().getTime() + 5000).toISOString());\n      return await ctx.task(riskyTask, { data: inputs.data, retry: true });\n    }\n\n    if (isUserActionRequired(error)) {\n      // Request human intervention\n      await ctx.breakpoint({\n        question: `Error occurred: ${error.message}. How should we proceed?`,\n        title: 'Error Recovery',\n        context: { runId: ctx.runId, files: [{ path: 'artifacts/error-log.json', format: 'code', language: 'json' }] }\n      });\n\n      // Retry after human review\n      return await ctx.task(riskyTask, { data: inputs.data, retry: true });\n    }\n\n    // Unrecoverable error - fail gracefully\n    return { success: false, error: error.message };\n  }\n}\n\nfunction isTransientError(error) {\n  return error.message.includes('rate limit') ||\n         error.message.includes('timeout') ||\n         error.message.includes('ECONNRESET');\n}\n\nfunction isUserActionRequired(error) {\n  return error.message.includes('permission') ||\n         error.message.includes('authentication') ||\n         error.message.includes('invalid configuration');\n}\n```\n\n**Error categories and handling:**\n\n| Error Type | Handling Strategy | Example |\n|------------|-------------------|---------|\n| Transient | Retry with backoff | Network timeouts, rate limits |\n| Configuration | Request user input | Missing credentials |\n| Validation | Fail fast with clear message | Invalid inputs |\n| Logic | Log and investigate | Unexpected state |\n| External | Breakpoint for decision | API changes |\n\n### Idempotency and Resumability\n\nDesign processes that can be safely interrupted and resumed.\n\n**Idempotency principles:**\n\n1. **Use deterministic identifiers**: Derive IDs from inputs, not random values\n2. **Check before creating**: Verify resources do not exist before creating\n3. **Prefer upserts**: Update if exists, create if not\n4. **Record completed work**: Track what has been done in the journal\n\n**Resumable process pattern:**\n\n```javascript\nexport async function process(inputs, ctx) {\n  // Each task call is automatically idempotent\n  // If the run is resumed, completed tasks return cached results\n\n  // Task 1: Planning (if resumed, returns cached plan)\n  const plan = await ctx.task(planningTask, { feature: inputs.feature });\n\n  // Task 2: Implementation (if resumed, returns cached result)\n  const impl = await ctx.task(implementTask, { plan });\n\n  // Breakpoint: Natural pause point (if resumed after approval, continues)\n  await ctx.breakpoint({ question: 'Continue?', title: 'Checkpoint' });\n\n  // Task 3: Deployment (only executed if previous tasks complete)\n  const deploy = await ctx.task(deployTask, { impl });\n\n  return { success: true, deploy };\n}\n```\n\n**Deterministic code requirements:**\n\n```javascript\n// WRONG: Non-deterministic\nconst timestamp = Date.now();           // Different on each replay\nconst id = Math.random().toString(36);  // Different on each replay\n\n// CORRECT: Deterministic\nconst timestamp = ctx.now().getTime();  // Replayed consistently\nconst id = `task-${ctx.runId}-${iteration}`;  // Derived from stable values\n```\n\n### Testing Processes\n\nValidate processes before using them in production.\n\n**Testing strategies:**\n\n| Strategy | Purpose | Approach |\n|----------|---------|----------|\n| Unit testing | Test individual tasks | Mock dependencies, verify outputs |\n| Integration testing | Test task interactions | Use test fixtures, verify flow |\n| Dry-run testing | Validate process logic | Run with small inputs, review journal |\n| Snapshot testing | Detect regressions | Compare journal events over time |\n\n**Dry-run testing pattern:**\n\nStart a test run with minimal inputs:\n```\n/babysitter:call test my-process with small inputs\n```\n\nThen ask Claude to show you the results:\n```\nShow me what happened in the test run\n```\n\n**Process validation checklist:**\n\n- [ ] All task definitions have `io.inputJsonPath` and `io.outputJsonPath`\n- [ ] Process handles missing/invalid inputs gracefully\n- [ ] Breakpoints have clear questions and appropriate context files\n- [ ] Error paths are handled (try/catch or conditional logic)\n- [ ] Process returns meaningful output\n- [ ] No non-deterministic code (Date.now, Math.random, etc.)\n\n---\n\n## Quality Convergence Best Practices\n\n### Setting Appropriate Targets\n\nQuality targets should be achievable but challenging.\n\n**Target calibration approach:**\n\n1. **Establish baseline**: Run process once, note initial quality\n2. **Set stretch target**: 10-15 points above baseline\n3. **Monitor iterations**: Track how many iterations to converge\n4. **Adjust based on data**: Lower if never achieved, raise if too easy\n\n**Domain-specific targets:**\n\n| Domain | Typical Target | Rationale |\n|--------|----------------|-----------|\n| New feature code | 85-90 | Balance quality with speed |\n| Bug fixes | 80-85 | Focused, limited scope |\n| Refactoring | 90-95 | Must not introduce regressions |\n| Security-critical | 95+ | Cannot compromise on quality |\n| Documentation | 75-85 | Subjective, faster convergence |\n| Prototypes | 70-75 | Speed over perfection |\n\n**Progressive target pattern:**\n\n```javascript\n// Start with achievable target, progressively increase\nconst progressiveTargets = [\n  { iteration: 1, target: 70 },   // First iteration: basic functionality\n  { iteration: 3, target: 80 },   // Mid iterations: solid implementation\n  { iteration: 5, target: 85 }    // Final iterations: polish\n];\n\nfunction getCurrentTarget(iteration) {\n  const applicable = progressiveTargets.filter(t => t.iteration <= iteration);\n  return applicable[applicable.length - 1]?.target || 85;\n}\n```\n\n### Custom Scoring Strategies\n\nTailor scoring to your specific quality criteria.\n\n**Scoring weight configuration:**\n\n```javascript\n// Domain-specific weights\nconst scoringWeights = {\n  // For backend APIs\n  api: {\n    tests: 0.30,         // Test quality is critical\n    implementation: 0.25, // Code correctness\n    security: 0.25,       // Security is paramount\n    codeQuality: 0.10,    // Style and maintainability\n    alignment: 0.10       // Requirements match\n  },\n\n  // For frontend UI\n  frontend: {\n    tests: 0.20,          // Test quality\n    implementation: 0.25, // Code correctness\n    accessibility: 0.20,  // WCAG compliance\n    codeQuality: 0.15,    // Style and maintainability\n    alignment: 0.20       // Design match\n  },\n\n  // For data pipelines\n  dataPipeline: {\n    correctness: 0.35,    // Data accuracy\n    performance: 0.25,    // Processing speed\n    reliability: 0.20,    // Error handling\n    tests: 0.15,          // Test coverage\n    documentation: 0.05   // Pipeline docs\n  }\n};\n```\n\n**Multi-dimensional scoring task:**\n\n```javascript\nexport const qualityScoringTask = defineTask('quality-scorer', (args, taskCtx) => ({\n  kind: 'agent',\n  title: `Score quality (iteration ${args.iteration})`,\n  agent: {\n    name: 'quality-assessor',\n    prompt: {\n      role: 'senior quality assurance engineer',\n      task: 'Evaluate implementation quality across multiple dimensions',\n      context: {\n        implementation: args.implementation,\n        tests: args.tests,\n        qualityChecks: args.qualityChecks,\n        weights: args.weights\n      },\n      instructions: [\n        `Score each dimension from 0-100:`,\n        `- Tests: Coverage, edge cases, assertions`,\n        `- Implementation: Correctness, readability, maintainability`,\n        `- Code Quality: Lint results, type safety, complexity`,\n        `- Security: Vulnerabilities, input validation`,\n        `- Alignment: Requirements match, no scope creep`,\n        `Apply weights: ${JSON.stringify(args.weights)}`,\n        `Calculate weighted overall score`,\n        `Provide prioritized improvement recommendations`\n      ],\n      outputFormat: 'JSON with overallScore, dimensionScores, recommendations'\n    }\n  },\n  io: {\n    inputJsonPath: `tasks/${taskCtx.effectId}/input.json`,\n    outputJsonPath: `tasks/${taskCtx.effectId}/result.json`\n  }\n}));\n```\n\n### Balancing Speed vs Thoroughness\n\nOptimize the quality convergence loop for your needs.\n\n**Speed-focused configuration:**\n\n```javascript\n// Prioritize fast convergence\nconst speedConfig = {\n  maxIterations: 3,\n  targetQuality: 75,\n  parallelChecks: true,\n  skipOptionalChecks: true,\n  earlyExitOnTarget: true\n};\n```\n\n**Thoroughness-focused configuration:**\n\n```javascript\n// Prioritize comprehensive quality\nconst thoroughConfig = {\n  maxIterations: 10,\n  targetQuality: 95,\n  parallelChecks: true,\n  includeSecurityAudit: true,\n  includePerformanceCheck: true,\n  requireHumanReview: true\n};\n```\n\n**Adaptive configuration based on context:**\n\n```javascript\nfunction getQualityConfig(context) {\n  // High-stakes production changes\n  if (context.isProduction && context.affectsPayments) {\n    return { targetQuality: 95, maxIterations: 10, requireApproval: true };\n  }\n\n  // Regular feature development\n  if (context.isFeature) {\n    return { targetQuality: 85, maxIterations: 5, requireApproval: false };\n  }\n\n  // Hot fixes\n  if (context.isHotfix) {\n    return { targetQuality: 80, maxIterations: 3, requireApproval: true };\n  }\n\n  // Prototypes\n  return { targetQuality: 70, maxIterations: 2, requireApproval: false };\n}\n```\n\n---\n\n## Team Collaboration Patterns\n\n### Shared Run Management\n\nEnable multiple team members to interact with runs.\n\n**Run sharing approaches:**\n\n| Approach | Use Case | Implementation |\n|----------|----------|----------------|\n| Shared workspace | Co-located team | Shared `.a5c/runs/` directory |\n| Cloud storage | Distributed team | Sync runs to S3/GCS/Azure |\n| Git-based | Audit requirements | Commit runs to repository |\n| API access | External integration | Expose via breakpoints API |\n\n**Descriptive workflows for team clarity:**\n\nStart a clearly-named workflow:\n```\n/babysitter:call implement oauth2 authentication feature\n```\n\nTeam members can easily find and resume:\n```\n/babysitter:call resume the oauth2 authentication babysitter run\n```\n\n**Run handoff workflow:**\n\n```\n# Developer A: Start the workflow during morning\n/babysitter:call implement the API feature\n# Run reaches breakpoint requiring review\n\n# Developer B: Review and continue in evening\nWhat's the status of the API feature babysitter run?\n# Approve breakpoint via UI at http://localhost:3184, then:\n/babysitter:call resume the API feature run\n```\n\n### Code Review Workflows with Babysitter\n\nIntegrate Babysitter into your code review process.\n\n**Pre-review quality check:**\n\n```javascript\nexport async function process(inputs, ctx) {\n  // Generate implementation\n  const impl = await ctx.task(implementTask, { feature: inputs.feature });\n\n  // Run comprehensive quality checks before review\n  const [tests, lint, security, coverage] = await ctx.parallel.all([\n    () => ctx.task(testTask, { impl }),\n    () => ctx.task(lintTask, { impl }),\n    () => ctx.task(securityTask, { impl }),\n    () => ctx.task(coverageTask, { impl })\n  ]);\n\n  // Agent generates review summary\n  const reviewSummary = await ctx.task(agentReviewSummaryTask, {\n    impl,\n    tests,\n    lint,\n    security,\n    coverage\n  });\n\n  // Breakpoint for human code review\n  await ctx.breakpoint({\n    question: `Implementation ready for review. Quality score: ${reviewSummary.score}. Approve?`,\n    title: 'Code Review',\n    context: {\n      runId: ctx.runId,\n      files: [\n        { path: 'artifacts/review-summary.md', format: 'markdown' },\n        { path: 'artifacts/diff.patch', format: 'code', language: 'diff' },\n        { path: 'artifacts/coverage-report.html', format: 'html' }\n      ]\n    }\n  });\n\n  return { success: true, reviewSummary };\n}\n```\n\n**Review feedback integration:**\n\n```javascript\n// Process reviewer feedback and iterate\nawait ctx.breakpoint({\n  question: 'Review the changes. Provide feedback or approve.',\n  title: 'Code Review Round 1'\n});\n\n// After approval, feedback is captured in the journal\n// Next iteration can reference reviewer comments\n```\n\n### Communication via Breakpoints\n\nUse breakpoints for asynchronous team communication. Route them to the right people with `expert` and `tags`.\n\n**Status update pattern:**\n\n```javascript\n// Report progress to stakeholders\nawait ctx.breakpoint({\n  question: 'Phase 1 complete. 3 of 5 modules implemented. Continue to Phase 2?',\n  title: 'Progress Update',\n  expert: 'owner',\n  tags: ['status-update'],\n  context: {\n    runId: ctx.runId,\n    files: [\n      { path: 'artifacts/progress-report.md', format: 'markdown' },\n      { path: 'artifacts/metrics.json', format: 'code', language: 'json' }\n    ]\n  }\n});\n```\n\n**Decision request pattern:**\n\n```javascript\n// Request strategic decision from the architect\nawait ctx.breakpoint({\n  question: 'Two implementation approaches possible. A: Faster but limited. B: Comprehensive but slower. Which approach?',\n  title: 'Architecture Decision Required',\n  expert: 'architect',\n  tags: ['architecture', 'decision'],\n  context: {\n    runId: ctx.runId,\n    files: [\n      { path: 'artifacts/approach-comparison.md', format: 'markdown' }\n    ]\n  }\n});\n```\n\n**Multi-reviewer approval pattern:**\n\n```javascript\n// Require approval from multiple stakeholders before proceeding\nconst result = await ctx.breakpoint({\n  question: 'Approve production deployment?',\n  title: 'Production Deployment',\n  expert: ['tech-lead', 'ops-lead', 'security-lead'],\n  strategy: 'quorum',\n  tags: ['deployment', 'production'],\n  context: {\n    runId: ctx.runId,\n    files: [{ path: 'artifacts/deploy-checklist.md', format: 'markdown' }]\n  }\n});\n// result.allResponses contains each reviewer's response\n```\n\n---\n\n## Performance Optimization\n\n### Reducing Iteration Count\n\nMinimize iterations while maintaining quality.\n\n**Iteration reduction strategies:**\n\n| Strategy | Impact | Implementation |\n|----------|--------|----------------|\n| Better initial prompts | High | Provide detailed context to agent tasks |\n| Feedback loops | High | Pass previous iteration recommendations |\n| Early exit on plateau | Medium | Stop when quality stops improving |\n| Progressive targets | Medium | Lower targets for early iterations |\n| Scope control | High | Limit scope per iteration |\n\n**Feedback-driven improvement:**\n\n```javascript\nlet iteration = 0;\nlet quality = 0;\nconst iterationResults = [];\n\nwhile (iteration < maxIterations && quality < targetQuality) {\n  iteration++;\n\n  // Include feedback from previous iteration\n  const previousFeedback = iteration > 1\n    ? iterationResults[iteration - 2].recommendations\n    : null;\n\n  const impl = await ctx.task(implementTask, {\n    feature,\n    iteration,\n    previousFeedback,  // Guide improvements based on scoring feedback\n    focusAreas: previousFeedback?.slice(0, 3)  // Top 3 priorities\n  });\n\n  const score = await ctx.task(scoringTask, { impl });\n  quality = score.overall;\n\n  iterationResults.push({\n    iteration,\n    quality,\n    recommendations: score.recommendations\n  });\n\n  ctx.log(`Iteration ${iteration}: ${quality}/${targetQuality}`);\n}\n```\n\n### Parallel Execution Optimization\n\nMaximize throughput with effective parallelization.\n\n**Parallel execution guidelines:**\n\n1. **Identify independent tasks**: Tasks with no data dependencies\n2. **Use thunk wrappers**: Always wrap in `() =>` for deferred execution\n3. **Batch large workloads**: Process in chunks to avoid resource exhaustion\n4. **Handle errors individually**: Catch errors per task to avoid losing all results\n\n**Chunked parallel processing:**\n\n```javascript\nconst items = inputs.files;  // Large array\nconst chunkSize = 10;        // Process 10 at a time\nconst results = [];\n\nfor (let i = 0; i < items.length; i += chunkSize) {\n  const chunk = items.slice(i, i + chunkSize);\n\n  const chunkResults = await ctx.parallel.map(chunk, async item => {\n    try {\n      return { item, success: true, result: await ctx.task(processTask, { item }) };\n    } catch (error) {\n      return { item, success: false, error: error.message };\n    }\n  });\n\n  results.push(...chunkResults);\n  ctx.log(`Processed ${Math.min(i + chunkSize, items.length)}/${items.length}`);\n}\n```\n\n**Optimal parallel batching:**\n\n| Scenario | Chunk Size | Rationale |\n|----------|------------|-----------|\n| CPU-bound tasks | Number of cores | Match available parallelism |\n| I/O-bound tasks | 10-20 | Higher concurrency OK |\n| API calls | 5-10 | Respect rate limits |\n| Memory-intensive | 2-5 | Avoid OOM |\n\n### Efficient Task Design\n\nDesign tasks for minimal overhead and maximum reuse.\n\n**Task design principles:**\n\n1. **Right-size scope**: Neither too fine nor too coarse\n2. **Clear contracts**: Well-defined inputs and outputs\n3. **Minimal dependencies**: Only require what is needed\n4. **Fast failure**: Validate inputs early, fail fast\n5. **Meaningful results**: Return useful data for subsequent tasks\n\n**Efficient task definition:**\n\n```javascript\n// Good: Focused, well-defined task\nexport const lintTask = defineTask('lint', (args, taskCtx) => ({\n  kind: 'node',\n  title: 'Run linter',\n  node: {\n    entry: 'scripts/lint.js',\n    args: args.files ? ['--files', ...args.files] : ['--all'],\n    timeout: 60000  // Fast timeout for quick task\n  },\n  io: {\n    inputJsonPath: `tasks/${taskCtx.effectId}/input.json`,\n    outputJsonPath: `tasks/${taskCtx.effectId}/result.json`\n  }\n}));\n\n// The script itself should:\n// 1. Validate inputs\n// 2. Execute quickly\n// 3. Return structured results\n// 4. Handle errors gracefully\n```\n\n---\n\n## Debugging and Troubleshooting\n\nWhen a run isn't behaving as expected, use this decision tree:\n\n### Quick Diagnosis Flowchart\n\n```\nRun not progressing?\n    │\n    ├── Status = \"waiting\" ──────► Check for pending breakpoints\n    │                              Ask: \"Are there pending breakpoints?\"\n    │\n    ├── Status = \"failed\" ───────► Check error in journal\n    │                              Ask: \"What error caused the run to fail?\"\n    │\n    ├── Quality not improving ───► Check feedback is being passed\n    │                              Ask: \"What recommendations came from quality scoring?\"\n    │\n    └── Stuck in loop ───────────► Check iteration count and maxIterations\n                                   Add plateau detection\n```\n\n### Common Debugging Questions\n\nAsk Claude these questions to debug your workflow:\n\n```\nWhat's the status of my babysitter run?\n```\n\n```\nShow me the recent events in my workflow\n```\n\n```\nAre there any pending tasks in my babysitter run?\n```\n\n```\nWhat were the quality scores across iterations?\n```\n\n```\nShow me the result of the last completed task\n```\n\n### When to Investigate\n\n| Symptom | What to Check | Likely Cause |\n|---------|---------------|--------------|\n| Run immediately completes | Quality target too low | Raise `targetQuality` |\n| Run never completes | Quality target unreachable | Lower target or increase `maxIterations` |\n| Same quality every iteration | Feedback not being passed | Check `previousFeedback` is used |\n| Run hangs | Pending breakpoint | Approve via UI or check service |\n| Erratic quality scores | Non-deterministic scoring | Use consistent criteria |\n| \"Already running\" error | Session conflict | Wait for other session |\n\n### Recovery Procedures\n\n**If run is stuck waiting:**\nAsk Claude what it's waiting for:\n```\nWhat is my babysitter run waiting for?\n```\nIf waiting on breakpoint, approve it via UI at http://localhost:3184\n\n**If run state is corrupted:**\nAsk Claude to help recover:\n```\nMy babysitter run state seems corrupted, can you help recover it?\n```\n\n**If process code changed mid-run:**\nBest to start fresh - old state may be incompatible:\n```\n/babysitter:call start a new workflow for the same feature\n```\n\n---\n\n## Common Pitfalls and How to Avoid Them\n\n### Process Design Pitfalls\n\n| Pitfall | Symptom | Solution |\n|---------|---------|----------|\n| Non-deterministic code | Different results on resume | Use `ctx.now()` instead of `Date.now()` |\n| Missing io paths | Results not persisted | Always include `io.inputJsonPath` and `io.outputJsonPath` |\n| Code changes mid-run | Unexpected behavior on resume | Avoid modifying process code during active runs |\n| Infinite loops | Process never completes | Always set `maxIterations` |\n| No error handling | Silent failures | Wrap risky operations in try/catch |\n\n**Determinism checklist:**\n\n```javascript\n// AVOID: Non-deterministic patterns\nconst id = Math.random().toString(36);      // Random\nconst ts = Date.now();                       // Wall clock\nconst uuid = crypto.randomUUID();            // Random\n\n// USE: Deterministic patterns\nconst id = `task-${ctx.runId}-${iteration}`; // Derived\nconst ts = ctx.now().getTime();              // Replayed consistently\nconst hash = hashInputs(args);               // Derived from inputs\n```\n\n### Execution Pitfalls\n\n| Pitfall | Symptom | Solution |\n|---------|---------|----------|\n| Missing thunk wrappers | Tasks execute immediately | Wrap parallel tasks in `() =>` |\n| Parallelizing dependent tasks | Race conditions | Execute sequentially if dependent |\n| Too many parallel tasks | Resource exhaustion | Use chunked processing |\n| Forgetting to read result files | Empty results | Wait for task completion, then read |\n| Writing result.json directly | SDK errors | Use `task:post` command |\n\n**Correct patterns:**\n\n```javascript\n// WRONG: Missing thunks\nconst results = await ctx.parallel.all([\n  ctx.task(taskA, {}),  // Executes immediately!\n  ctx.task(taskB, {})   // Executes immediately!\n]);\n\n// CORRECT: With thunks\nconst results = await ctx.parallel.all([\n  () => ctx.task(taskA, {}),  // Deferred\n  () => ctx.task(taskB, {})   // Deferred\n]);\n```\n\n### Quality Convergence Pitfalls\n\n| Pitfall | Symptom | Solution |\n|---------|---------|----------|\n| Unrealistic targets | Never converges | Lower target or increase iterations |\n| No feedback loop | Quality plateaus | Pass recommendations to next iteration |\n| Inconsistent scoring | Erratic quality numbers | Use deterministic scoring criteria |\n| Sequential quality checks | Slow iterations | Parallelize independent checks |\n| No early exit | Wasted iterations | Exit on plateau detection |\n\n**Quality plateau detection:**\n\n```javascript\n// Track quality history\nconst qualityHistory = [];\n\nwhile (iteration < maxIterations && quality < targetQuality) {\n  iteration++;\n  // ... implementation ...\n  quality = score.overall;\n  qualityHistory.push(quality);\n\n  // Detect plateau (no improvement in last 3 iterations)\n  if (qualityHistory.length >= 3) {\n    const recent = qualityHistory.slice(-3);\n    const spread = Math.max(...recent) - Math.min(...recent);\n    if (spread < 2) {\n      ctx.log(`Quality plateaued at ${quality}, stopping`);\n      break;\n    }\n  }\n}\n```\n\n### Breakpoint Pitfalls\n\n| Pitfall | Symptom | Solution |\n|---------|---------|----------|\n| Context files not displaying | Missing content | Write files before calling breakpoint |\n| Automated pipeline blocking | Pipeline hangs | Use conditional breakpoints or auto-approve |\n| Too many breakpoints | Slow workflow | Only use for high-value decisions |\n\n**Conditional breakpoint for automated environments:**\n\n```javascript\n// Skip breakpoints in automated environment\nif (process.env.BABYSITTER_AUTO_APPROVE !== 'true') {\n  await ctx.breakpoint({\n    question: 'Review the plan?',\n    title: 'Plan Review'\n  });\n} else {\n  ctx.log('CI environment: auto-approving plan');\n}\n```\n\n### Resumption Pitfalls\n\n| Pitfall | Symptom | Solution |\n|---------|---------|----------|\n| Attempting to resume completed run | No effect | Check status before resuming |\n| Unresolved breakpoint | \"Waiting\" status persists | Approve breakpoint before resume |\n| State corruption | Unexpected behavior | Ask Claude to rebuild state |\n| Session conflict | \"Already running\" error | Wait for other session to complete |\n\n**Pre-resume checklist:**\n\n1. Check current status:\n   ```\n   What's the status of my babysitter run?\n   ```\n\n2. If waiting, check for pending breakpoints:\n   ```\n   Are there any pending breakpoints?\n   ```\n\n3. Resolve pending breakpoints via UI at http://localhost:3184\n\n4. Resume:\n   ```\n   /babysitter:call resume\n   ```\n\n---\n\n## Command Tips\n\nPractical tips for using Babysitter's slash commands effectively.\n\n### Diagnosing Issues\n\nWhen something isn't working, skip the manual debugging. Run:\n\n```\n/babysitter:doctor <what went wrong>\n```\n\nThe doctor performs 10 diagnostic checks: journal integrity, state cache, locks, sessions, hooks, logs, and more. It tells you exactly what's broken and how to fix it.\n\n**Example:**\n```\n/babysitter:doctor why didn't the stop hook fire?\n```\n\nIf doctor finds something unusual, share the output — it helps identify edge cases.\n\n### Choosing the Right Mode\n\n| Situation | Use This |\n|-----------|----------|\n| Learning or critical work | `/babysitter:call` — interactive, pauses for approval |\n| Trusted task, want hands-off | `/babysitter:yolo` — ship while you sleep |\n| Review approach before executing | `/babysitter:plan` — planning only |\n| Continuous/periodic work | `/babysitter:forever` — never-ending loop |\n\n### First-Time Setup\n\nBefore your first real project, run these once:\n\n```\n/babysitter:user-install    # Creates your profile\n/babysitter:project-install # Onboards your codebase\n```\n\nYour profiles personalize future runs — fewer questions, better-matched processes.\n\n### Real-Time Visibility\n\nWant to watch what's happening during a run?\n\n```\n/babysitter:observe\n```\n\nOpens a dashboard showing active runs, task progress, and journal events in real-time.\n\n### For Advanced Users\n\nExtend Babysitter with new integrations:\n\n```\n/babysitter:assimilate harness codex\n```\n\nGenerates SDK bindings for external AI agents. Contribute your integration back to join the [Hall of Fame](https://www.a5c.ai/hall-of-fame).\n\n---\n\n## Quick Reference Checklist\n\n### Before Creating a Process\n\n- [ ] Defined clear inputs and outputs\n- [ ] Identified task boundaries and dependencies\n- [ ] Planned breakpoint placement\n- [ ] Set realistic quality targets and iteration limits\n- [ ] Included error handling\n- [ ] Made all code deterministic\n\n### Before Starting a Run\n\n- [ ] Validated input file contents\n- [ ] Verified process code is stable (no pending changes)\n- [ ] Used descriptive run ID\n\n### During Execution\n\n- [ ] Monitoring iteration progress\n- [ ] Reviewing quality scores\n- [ ] Responding to breakpoints promptly\n- [ ] Checking for errors in journal\n\n### Before Resuming a Run\n\n- [ ] Verified run is in resumable state\n- [ ] Resolved any pending breakpoints\n- [ ] Process code has not changed\n- [ ] No other sessions are running the same run\n\n---\n\n## Related Documentation\n\n- [Slash Commands](../reference/slash-commands.md) - All commands (call, yolo, forever, plan, doctor, etc.)\n- [Breakpoints](./breakpoints.md) - Human-in-the-loop approval\n- [Quality Convergence](./quality-convergence.md) - Iterative improvement\n- [Process Definitions](./process-definitions.md) - Creating workflows\n- [Parallel Execution](./parallel-execution.md) - Concurrent tasks\n- [Run Resumption](./run-resumption.md) - Pause and continue\n- [Journal System](./journal-system.md) - Event sourcing\n- [Hooks](./hooks.md) - Extensible lifecycle events\n- [Process Library](./process-library.md) - SDK-managed library layout and current counts\n- [Adapters](./adapters.md) - The harness-agnostic runtime these practices run on\n- [Install Matrix](../harnesses/install-matrix.md) - The 12 supported harnesses and their setup\n\n---\n\n## Explore Methodologies and Processes\n\n**These best practices apply to ANY of Babysitter's workflows.** Whether you're using a methodology or a domain-specific process, these patterns will help you get the best results.\n\n### Methodologies (38 directories in this repo snapshot) - Development Approaches\n\nNot sure which methodology to use? Here's a quick guide:\n\n| If you need... | Try this methodology |\n|----------------|---------------------|\n| Fast, working code | GSD (Get Stuff Done) |\n| High test coverage | TDD Quality Convergence |\n| Enterprise governance | Spec-Kit |\n| Team alignment on requirements | BDD/Specification by Example |\n| Complex domain modeling | Domain-Driven Design |\n| Risk management | Spiral Model |\n\n**Browse methodologies:**\n- [Methodology overview](../reference/glossary.md#methodology)\n- [Methodologies folder](../../../library/methodologies/)\n\n### Domain Processes - Ready-to-Use Workflows\n\nBeyond methodologies, explore the current specialization catalog:\n\n<!-- best-practices:domains:start -->\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<!-- best-practices:domains:end -->\n\nSee the full catalog in the [Process Library](./process-library.md).\n\n---\n\n## Summary\n\nThis guide provides a comprehensive reference for Babysitter best practices. Key takeaways:\n\n1. **Workflow Design**: Use breakpoints strategically, set realistic iteration limits, decompose tasks appropriately, and choose the right execution model.\n\n2. **Process Development**: Structure processes clearly, handle errors gracefully, ensure idempotency for resumability, and test processes thoroughly.\n\n3. **Quality Convergence**: Set achievable targets, customize scoring for your domain, and balance speed with thoroughness based on context.\n\n4. **Team Collaboration**: Use descriptive run IDs, integrate with code review workflows, and leverage breakpoints for asynchronous communication.\n\n5. **Performance**: Reduce iterations through feedback loops, parallelize independent tasks, and design efficient task definitions.\n\n6. **Avoid Pitfalls**: Keep code deterministic, use proper thunk wrappers, detect quality plateaus, and follow proper resumption procedures.\n\nApply these patterns consistently to maximize the value of Babysitter in your development workflows.\n\n---\n\n## Next steps\n\n- **Next:** [Custom Process tutorial](../tutorials/intermediate-custom-process.md)\n- **Related:** [Quality Convergence](./quality-convergence.md), [Two-Loops Architecture](./two-loops-architecture.md), [Process Definitions](./process-definitions.md)\n",
    "documents": []
  },
  "outgoingEdges": [],
  "incomingEdges": [
    {
      "from": "page:docs-user-guide-features",
      "to": "page:docs-user-guide-features-best-practices",
      "kind": "contains_page"
    }
  ]
}