org.yaml

version: "1.0"
org:
  name: DAOF Demo
  description: Autonomous AI organization for demonstrating the DAOF framework.
  goals:
    - generate_agents_capabilities_and_workflows
agents:
  overseer:
    provider: cursor
    model: auto
    role: Overseer
    description: Oversees the organization and its agents. Generates agents,
      capabilities, and workflows from a description.
    capabilities:
      - name: generate_agents_capabilities_and_workflows
  planner:
    provider: cursor
    model: auto
    role: Build Planner
    description: Produces PRD from user description for daof build (event build.requested)
    capabilities:
      - name: produce_prd
  generator:
    provider: cursor
    model: auto
    role: Build Generator
    description: Generates capabilities/agents/workflows YAML from PRD
    capabilities:
      - name: generate_yaml
  builder:
    provider: cursor
    model: auto
    role: Build Merger
    description: Merges generated YAML into org file and publishes build reply
    capabilities:
      - name: merge_and_write
      - name: build_reply
  verifier:
    provider: cursor
    model: auto
    role: Build Verifier
    description: Verifies build output against PRD (event build.requested)
    capabilities:
      - name: verify_build
  frontend_engineer:
    provider: cursor
    model: auto
    role: Principal Frontend Engineer
    description: Writes production-grade, architecturally sound frontend code on
      demand. Enforces principal-engineer standards including accessibility,
      performance, strict typing, and test scaffolding. Can be assigned to any
      workflow step that requires frontend implementation.
    capabilities:
      - name: frontend_code_writer
      - name: logger
  application_engineer:
    provider: cursor
    model: auto
    role: Principal Application Engineer
    description: Writes production-grade, architecturally sound framework code on
      demand. Focus on new tools and capabilities for DAOF (TypeScript/Node).
      Enforces principal-level standards including strict typing, DAOF
      capability contracts (inputs/outputs), error handling, and test
      scaffolding. Can be assigned to any workflow step that requires backend or
      framework implementation.
    capabilities:
      - name: application_code_writer
      - name: logger
  curator:
    provider: cursor
    model: auto
    role: Registry Curator
    description: Prunes stale capability/skill entries from the registry (archives
      by last_accessed). Run via registry_curation workflow.
    capabilities:
      - name: prune_registry
capabilities:
  prune_registry:
    type: tool
    description: Prune stale registry entries (archive by last_accessed). Used by Curator.
  logger:
    type: tool
    description: Log messages (bundled; console in v1)
  event_emitter:
    type: tool
    description: Publish events to backbone queue (bundled)
    config:
      queue: events
  key_value_store:
    type: tool
    description: Get/set/delete by key (bundled; Redis or in-memory)
    persistence: sql_events
  produce_prd:
    type: tool
    description: Planner; produce PRD from description (bundled)
  generate_yaml:
    type: tool
    description: Generator; produce capabilities/agents/workflows YAML (bundled)
  merge_and_write:
    type: tool
    description: Merge generated YAML into org file and write (bundled)
  verify_build:
    type: tool
    description: Verifier; compare output to PRD, output pass/fail (bundled)
  build_reply:
    type: tool
    description: Publish build result to build.replies queue (bundled)
    config:
      queue: build.replies
  generate_agents_capabilities_and_workflows:
    type: tool
    description: Overseer; generates agents, capabilities, and workflows from a
      description (bundled stub).
  frontend_code_writer:
    type: skill
    description: Accepts a task description (and optional tech stack, constraints,
      existing code context) and produces principal-engineer-quality frontend
      code. Enforces component decomposition, semantic HTML, WCAG 2.1 AA
      accessibility, performance-conscious rendering, strict TypeScript typing,
      idiomatic state management, error boundaries, and test scaffolding.
    config:
      endpoint: env(LLM_ENDPOINT)
      api_key: env(LLM_API_KEY)
    prompt: >-
      You are a principal-level frontend engineer. Generate production-grade
      frontend code for the following task. Your output must meet every standard
      below.


      == TASK ==

      {{ task }}


      == TECH STACK ==

      {{ stack }}

      If no stack is specified, default to React 18 with TypeScript and CSS
      Modules.


      == EXISTING CONTEXT ==

      {{ context }}


      == CONSTRAINTS ==

      {{ constraints }}


      == STANDARDS (mandatory) ==

      1. Component Architecture: Single-responsibility components. Compose via
      props and
         children. Clear prop contracts with explicit TypeScript interfaces. Barrel exports
         where appropriate.

      2. TypeScript: Strict mode. No `any`. Use discriminated unions for variant
      state.
         Prefer `as const` assertions and template literal types where they add clarity.

      3. Accessibility (WCAG 2.1 AA): Semantic HTML elements over generic divs.
      ARIA
         attributes only when native semantics are insufficient. Keyboard navigation and
         visible focus indicators. Announce dynamic content changes with live regions.
         Provide skip links and logical heading hierarchy.

      4. Performance: Memoize expensive computations (useMemo) and stable
      callbacks
         (useCallback) only where profiling justifies it. Lazy-load heavy routes and
         components via React.lazy/Suspense. Suggest virtualization (e.g. react-window)
         when rendering large lists. Avoid layout thrashing and unnecessary re-renders.

      5. Styling: Use the styling approach specified in the stack (CSS Modules,
      Tailwind,
         or styled-components). Maintain design-token consistency. Support dark mode via
         CSS custom properties or class strategy when relevant.

      6. Error Handling: Wrap feature boundaries with React error boundaries.
      Implement
         graceful degradation: loading skeletons, empty states, and user-friendly error
         messages. Never swallow errors silently.

      7. State Management: Use idiomatic patterns for the chosen stack
      (useState/useReducer
         for local state, context for cross-cutting concerns, external store only if
         constraints allow). Lift state only as high as necessary.

      8. Testability: Export pure logic into custom hooks or utility functions
      for unit
         testing. Include a co-located test outline (describe/it blocks with intent
         comments) for every exported component or hook.

      9. Code Organization: Group by feature, not by type. Co-locate component,
      styles,
         tests, and types. Use index files for public API of each feature module.


      == OUTPUT FORMAT ==

      Return the complete implementation code. Where an architectural decision
      is non-obvious, add a brief inline comment explaining the rationale.
      Separate each file with a header comment: // --- file: <relative-path> ---
  fetch_agent_performance:
    type: tool
    description: 'Queries the backbone run registry, checkpoint store, and metrics
      to collect per-agent stats: task completion count, failure count, average
      step duration, error rate, and last-N output quality scores. Returns a
      structured performance report per agent. Accepts an optional exclude list
      (default: ["ceo"]).'
    config:
      default_exclude:
        - ceo
      lookback_days: 7
    persistence: sql_events
  score_agent_performance:
    type: skill
    description: Takes the raw performance report from fetch_agent_performance and
      produces a scored evaluation for each agent (0–100) with a verdict
      (healthy, degraded, critical) and a plain-language summary of weaknesses.
      Uses an LLM prompt to reason over the data.
    config:
      endpoint: env(LLM_ENDPOINT)
      api_key: env(LLM_API_KEY)
    prompt: >-
      You are a senior operations analyst. You will receive a structured
      performance report for a set of AI agents. For each agent, produce a JSON
      object with:

        - agent_id: the agent identifier
        - score: integer 0–100 (100 = perfect)
        - verdict: one of "healthy", "degraded", "critical"
        - weaknesses: array of plain-language descriptions of problems

      Scoring guidelines:
        - 80–100 healthy: low error rate (<5%), high completion rate, acceptable latency.
        - 50–79 degraded: moderate error rate (5–20%), missed tasks, or latency spikes.
        - 0–49 critical: high error rate (>20%), frequent failures, or stalled tasks.

      == INPUT == {{ fetch_agent_performance.report }}

      == OUTPUT == Return a JSON array of agent evaluation objects. No
      commentary outside the JSON.
    depends_on:
      - fetch_agent_performance
  recommend_upgrades:
    type: skill
    description: "Given the scored evaluation, produces a list of concrete upgrade
      recommendations per underperforming agent: new capabilities to add,
      capability config changes, or model upgrades. Outputs structured
      YAML-ready recommendations."
    config:
      endpoint: env(LLM_ENDPOINT)
      api_key: env(LLM_API_KEY)
    prompt: >-
      You are an AI operations architect. You will receive scored evaluations
      for a set of AI agents. For every agent whose verdict is "degraded" or
      "critical", produce upgrade recommendations.

      Each recommendation must be one of:
        1. add_capability — a new capability the agent should gain (provide id, type,
           description, and rationale).
        2. update_config — a config change on an existing capability (provide
           capability_id, key, old_value, new_value, rationale).
        3. model_upgrade — change the agent's model (provide suggested_model and
           rationale).

      == INPUT == {{ score_agent_performance.evaluations }}

      == OUTPUT == Return a YAML document with top-level key "recommendations"
      mapping agent_id to an array of recommendation objects. Include a boolean
      field "has_recommendations" at the top level (true if any recommendations
      exist, false otherwise).
    depends_on:
      - score_agent_performance
  apply_capability_upgrade:
    type: tool
    description: Applies the recommended upgrades to the org manifest. For new
      capabilities, emits a build.requested event via the backbone (leveraging
      the existing build flow). For config or capability-list changes, directly
      patches the org YAML and writes the file.
    persistence: sql_events
    depends_on:
      - recommend_upgrades
      - event_emitter
  application_code_writer:
    type: skill
    description: Accepts a task description (e.g. "add a tool that does X" or "add a
      capability that does Y"), optional tech stack, constraints, and existing
      code context. Produces principal-level TypeScript implementation for DAOF
      tools/capabilities. Delivers capability implementation (e.g. under
      src/capabilities/ or generated), correct use of framework types
      (CapabilityInput/CapabilityOutput), error handling, and test scaffolding.
    config:
      endpoint: env(LLM_ENDPOINT)
      api_key: env(LLM_API_KEY)
    prompt: >-
      You are a principal-level application engineer for the DAOF framework.
      Generate production-grade TypeScript for tools and capabilities. Your
      output must meet every standard below.


      == TASK ==

      {{ task }}


      == TECH STACK ==

      {{ stack }}

      If no stack is specified, use TypeScript/Node and DAOF conventions.


      == EXISTING CONTEXT ==

      {{ context }}


      == CONSTRAINTS ==

      {{ constraints }}


      == STANDARDS (mandatory) ==

      1. Framework contract: Implement capabilities with execute(input,
      runContext?) returning Promise<CapabilityOutput>. Use CapabilityInput and
      CapabilityOutput (Record<string, JsonValue>). No new types that bypass the
      framework contract.

      2. TypeScript: Strict mode. No any. Explicit parameter and return types.
      Use Zod or existing schema where config or inputs are validated.

      3. Placement: New capabilities under src/capabilities/ (bundled or
      generated). Follow existing patterns (e.g. bundled tools/skills, config,
      depends_on).

      4. Error handling: Surface errors clearly; do not swallow. Use try/catch
      where appropriate and return structured output (e.g. success, error,
      message).

      5. Test scaffolding: Co-located test outline (describe/it with intent) or
      a test file stub for the capability. Export testable units where possible.

      6. Code organization: Single responsibility. Clear exports. Barrel files
      where appropriate. Document config keys and env vars in comments if used.


      == OUTPUT FORMAT ==

      Return the complete implementation code. Use a header comment per file: //
      --- file: <relative-path> --- Add brief inline comments for non-obvious
      architectural choices.
workflows:
  build_on_request:
    trigger: event(build.requested)
    description: "Self-upgrade; run Planner, Generator, merge, Verifier, reply.
      Payload: description, request_id, org_path?, existing_capabilities?"
    steps:
      - agent: planner
        action: produce_prd
        params:
          description: "{{ __initial.description }}"
      - agent: generator
        action: generate_yaml
        params:
          description: "{{ __initial.description }}"
          prd: "{{ planner.prd }}"
          existing_capabilities: "{{ __initial.existing_capabilities }}"
      - agent: builder
        action: merge_and_write
        params:
          org_path: "{{ __initial.org_path }}"
          generated_yaml: "{{ generator.yaml }}"
      - agent: verifier
        action: verify_build
        params:
          prd: "{{ planner.prd }}"
          summary: "{{ builder.summary }}"
      - agent: builder
        action: build_reply
        params:
          request_id: "{{ __initial.request_id }}"
          success: "{{ verifier.pass }}"
          prd: "{{ planner.prd }}"
          added_count: "{{ builder.added_count }}"
  on_demand_application_build:
    trigger: event(application.build.requested)
    description: On-demand implementation of a framework task (new tool or
      capability). Payload task, optional constraints, optional context.
    steps:
      - agent: application_engineer
        action: application_code_writer
        params:
          task: "{{ __initial.task }}"
          constraints: "{{ __initial.constraints }}"
          context: "{{ __initial.context }}"
      - agent: application_engineer
        action: logger
        params:
          message: Application build step complete
          summary: "{{ application_code_writer.summary }}"
backbone:
  type: redis
  config:
    url: redis://localhost:6379
    queues:
      - name: events
        type: pubsub
      - name: dlq
        type: fifo
      - name: build.replies
        type: fifo
middleware:
  agent:
    - agent_metrics
  capability: []
fault_tolerance:
  health_checks_interval: 5m
  retries:
    default: 3
    backoff: exponential
  circuit_breaker:
    threshold: 5 failures
    reset_after: 10m
  dead_letter_queue: true
  alerts:
    webhook: env(ALERT_WEBHOOK_URL)
    channels:
      - slack
      - email
registry:
  mongo_uri: mongodb://localhost:27017