@bluefly/openstandardagents 0.3.3 → 0.3.5

package/dist/spec/v0.3.1/taxonomy.yaml

@@ -1,256 +0,0 @@
-# =============================================================================
-# OSSA v0.3.1 - Agent Taxonomy Specification
-# =============================================================================
-# Hierarchical classification system for agents with cross-cutting concerns
-# Issue: https://gitlab.com/blueflyio/openstandardagents/-/issues/194
-# =============================================================================
-
-apiVersion: ossa/v0.3.1
-kind: TaxonomySpec
-version: "1.0.0"
-
-# =============================================================================
-# PRIMARY DOMAINS
-# Top-level classification - every agent belongs to exactly one domain
-# =============================================================================
-domains:
-  security:
-    description: "Authentication, authorization, encryption, compliance, vulnerability management"
-    subdomains:
-      - auth                 # Authentication & authorization
-      - encryption          # Encryption & key management
-      - compliance          # Regulatory compliance (SOC2, ISO, GDPR)
-      - vulnerability       # Vulnerability scanning & remediation
-      - secrets             # Secrets management & rotation
-      - threat-detection    # Threat detection & response
-    examples:
-      - security-scanner
-      - compliance-checker
-      - secret-detector
-      - threat-modeler
-
-  infrastructure:
-    description: "DevOps, CI/CD, deployment, configuration, cloud resources"
-    subdomains:
-      - ci-cd               # CI/CD pipeline management
-      - gitops              # GitOps workflows
-      - deployment          # Deployment automation
-      - configuration       # Configuration management
-      - networking          # Network configuration
-      - storage             # Storage management
-      - kubernetes          # Kubernetes orchestration
-      - cloud               # Cloud provider management
-    examples:
-      - deployment-manager
-      - pipeline-fixer
-      - infrastructure-provisioner
-      - incident-responder
-
-  documentation:
-    description: "Documentation, wiki, guides, knowledge management"
-    subdomains:
-      - api-docs            # API documentation
-      - user-guides         # User guides & tutorials
-      - wiki                # Wiki management
-      - knowledge-base      # Knowledge base management
-      - changelog           # Changelog & release notes
-    examples:
-      - documentation-generator
-      - wiki-manager
-      - api-docs-generator
-
-  backend:
-    description: "API, database, services, business logic"
-    subdomains:
-      - api                 # API design & implementation
-      - database            # Database management
-      - services            # Microservices
-      - messaging           # Message queues & events
-      - caching             # Caching strategies
-      - integration         # System integration
-    examples:
-      - api-builder
-      - database-migrator
-      - service-orchestrator
-
-  frontend:
-    description: "UI/UX, web, mobile interfaces"
-    subdomains:
-      - web                 # Web applications
-      - mobile              # Mobile applications
-      - design-system       # Design system components
-      - accessibility       # Accessibility (a11y)
-      - performance         # Frontend performance
-    examples:
-      - ui-reviewer
-      - accessibility-checker
-      - design-system-manager
-
-  data:
-    description: "Data engineering, analytics, ML/AI operations"
-    subdomains:
-      - analytics           # Business analytics
-      - ml-ops              # ML operations
-      - etl                 # Extract, transform, load
-      - data-quality        # Data quality & validation
-      - data-governance     # Data governance
-      - streaming           # Real-time data streaming
-    examples:
-      - analytics-collector
-      - ml-model-manager
-      - data-quality-checker
-
-  agents:
-    description: "OSSA agents, automation, orchestration, meta-operations"
-    subdomains:
-      - orchestration       # Multi-agent orchestration
-      - workers             # Worker agents
-      - supervisors         # Supervisor agents
-      - mesh                # Agent mesh networking
-      - training            # Agent training & improvement
-      - registry            # Agent registry management
-    examples:
-      - master-orchestrator
-      - agent-trainer
-      - workflow-builder
-
-  development:
-    description: "Software development, code quality, testing"
-    subdomains:
-      - code-review         # Code review automation
-      - testing             # Test generation & execution
-      - refactoring         # Code refactoring
-      - debugging           # Debugging assistance
-      - ide                 # IDE integration
-    examples:
-      - code-reviewer
-      - test-generator
-      - refactoring-assistant
-
-  content:
-    description: "Content management, editing, publishing"
-    subdomains:
-      - authoring           # Content authoring
-      - editing             # Content editing
-      - publishing          # Content publishing
-      - research            # Research & knowledge gathering
-      - localization        # Internationalization & localization
-    examples:
-      - content-orchestrator
-      - editor
-      - researcher
-      - publisher
-
-# =============================================================================
-# CROSS-CUTTING CONCERNS
-# Tags that can apply to any agent regardless of domain
-# An agent can have multiple concerns
-# =============================================================================
-concerns:
-  quality:
-    description: "Testing, code quality, standards enforcement"
-    applies_to: ["development", "backend", "frontend", "infrastructure"]
-
-  observability:
-    description: "Metrics, logging, tracing, monitoring"
-    applies_to: ["*"]  # All domains
-
-  governance:
-    description: "Policies, compliance, audit trails"
-    applies_to: ["*"]
-
-  performance:
-    description: "Optimization, caching, scaling"
-    applies_to: ["*"]
-
-  architecture:
-    description: "Design patterns, system structure"
-    applies_to: ["development", "backend", "infrastructure", "agents"]
-
-  cost:
-    description: "FinOps, resource optimization, budget management"
-    applies_to: ["infrastructure", "data", "agents"]
-
-  reliability:
-    description: "SRE, uptime, resilience, disaster recovery"
-    applies_to: ["infrastructure", "backend", "agents"]
-
-# =============================================================================
-# AGENT TYPE CLASSIFICATION
-# Based on OSSA spec.type field
-# =============================================================================
-agent_types:
-  worker:
-    description: "Executes specific tasks, no delegation"
-    typical_domains: ["development", "security", "documentation"]
-
-  supervisor:
-    description: "Coordinates other agents, can delegate"
-    typical_domains: ["agents", "infrastructure"]
-
-  orchestrator:
-    description: "High-level coordination, workflow management"
-    typical_domains: ["agents"]
-
-  specialist:
-    description: "Deep expertise in narrow domain"
-    typical_domains: ["security", "data", "backend"]
-
-# =============================================================================
-# USAGE IN AGENT MANIFESTS
-# =============================================================================
-# Example usage in OSSA agent manifest:
-#
-# metadata:
-#   name: security-scanner
-#   labels:
-#     domain: security
-#     subdomain: vulnerability
-#     concerns: quality,compliance
-#
-# spec:
-#   type: worker
-#   taxonomy:
-#     domain: security
-#     subdomain: vulnerability
-#     capability: scan_vulnerabilities
-#     concerns:
-#       - quality
-#       - compliance
-
-# =============================================================================
-# VALIDATION RULES
-# =============================================================================
-validation:
-  rules:
-    - name: valid-domain
-      description: "Domain must be from approved list"
-      severity: error
-
-    - name: valid-subdomain
-      description: "Subdomain must belong to specified domain"
-      severity: error
-
-    - name: concerns-applicable
-      description: "Concerns must be applicable to domain"
-      severity: warning
-
-    - name: type-domain-match
-      description: "Agent type should match typical domains"
-      severity: info
-
-# =============================================================================
-# MIGRATION FROM LEGACY
-# =============================================================================
-migration:
-  deprecated_domains:
-    ci-cd: { domain: infrastructure, subdomain: ci-cd }
-    gitops: { domain: infrastructure, subdomain: gitops }
-    deployment: { domain: infrastructure, subdomain: deployment }
-    configuration: { domain: infrastructure, subdomain: configuration }
-    cost-management: { domain: infrastructure, concerns: [cost] }
-    database: { domain: backend, subdomain: database }
-    performance: { concerns: [performance] }
-    observability: { concerns: [observability] }
-    governance: { concerns: [governance] }
-    architecture: { concerns: [architecture] }

package/dist/spec/v0.3.2/MIGRATION-v0.3.1-to-v0.3.2.md

@@ -1,293 +0,0 @@
-# Migration Guide: OSSA v0.3.3 → v0.3.3
-
-> **Status**: Draft  
-> **Last Updated**: 2025-12-28
-
----
-
-## Overview
-
-OSSA v0.3.3 introduces **Access Tiers & Separation of Duties** while maintaining backward compatibility with v0.3.3 manifests.
-
-### Key Changes
-
-- ✅ **Backward Compatible**: v0.3.3 manifests validate against v0.3.3 schema
-- ✅ **Optional Features**: Access tiers are optional - existing agents work without changes
-- ✅ **Progressive Enhancement**: Add access tiers when ready
-
----
-
-## Migration Path
-
-### Option 1: No Changes Required (Recommended for Existing Agents)
-
-**v0.3.3 agents continue to work without modification:**
-
-```yaml
-apiVersion: ossa/v0.3.3
-kind: Agent
-metadata:
-  name: my-agent
-spec:
-  role: You are a helpful assistant.
-  llm:
-    provider: anthropic
-    model: claude-sonnet
-```
-
-**This manifest validates against v0.3.3 schema** - no changes needed.
-
-### Option 2: Update API Version Only
-
-Simply update the `apiVersion` field:
-
-```yaml
-apiVersion: ossa/v0.3.3  # Changed from v0.3.3
-kind: Agent
-metadata:
-  name: my-agent
-spec:
-  role: You are a helpful assistant.
-  llm:
-    provider: anthropic
-    model: claude-sonnet
-```
-
-### Option 3: Add Access Tiers (Recommended for New Agents)
-
-Add access tier configuration for privilege separation:
-
-```yaml
-apiVersion: ossa/v0.3.3
-kind: Agent
-metadata:
-  name: my-agent
-  labels:
-    access_tier: tier_1_read  # Optional label
-spec:
-  type: analyzer  # Agent type
-  
-  # Access Tier Configuration (NEW in v0.3.3)
-  access:
-    tier: tier_1_read
-    permissions:
-      - read_code
-      - read_configs
-    prohibited:
-      - write_*
-    audit_level: standard
-  
-  # Separation of Duties (NEW in v0.3.3)
-  separation:
-    role: analyzer
-    conflicts_with:
-      - executor
-      - approver
-  
-  role: You are a helpful assistant.
-  llm:
-    provider: anthropic
-    model: claude-sonnet
-```
-
----
-
-## Access Tier Selection Guide
-
-### Tier 1: Read Only (Analyzers)
-
-**Use for**: Scanners, reviewers, auditors, monitors
-
-```yaml
-access:
-  tier: tier_1_read
-  permissions:
-    - read_code
-    - read_configs
-    - read_logs
-    - execute_queries
-  prohibited:
-    - write_*
-    - delete_*
-    - execute_commands
-```
-
-**Examples**: Security scanners, code critics, compliance auditors
-
-### Tier 2: Write Limited (Workers)
-
-**Use for**: Doc generators, test writers, scaffolders
-
-```yaml
-access:
-  tier: tier_2_write_limited
-  permissions:
-    - read_*
-    - write_docs
-    - write_tests
-    - write_scaffolds
-    - create_issues
-    - create_mrs_draft
-  prohibited:
-    - write_production_code
-    - merge_mrs
-    - modify_infrastructure
-```
-
-**Examples**: Documentation generators, test generators, module scaffolders
-
-### Tier 3: Write Elevated (Operators)
-
-**Use for**: Deployers, infrastructure operators, incident responders
-
-```yaml
-access:
-  tier: tier_3_write_elevated
-  permissions:
-    - read_*
-    - write_*
-    - execute_deployments
-    - modify_pipelines
-    - merge_mrs  # With approval
-  prohibited:
-    - delete_production
-    - modify_secrets_direct
-    - bypass_approvals
-  requires_approval: true
-  approval_chain: standard
-```
-
-**Examples**: Deployment agents, CI/CD operators, infrastructure managers
-
-### Tier 4: Policy (Governors)
-
-**Use for**: Policy definers, compliance governors
-
-```yaml
-access:
-  tier: tier_4_policy
-  permissions:
-    - read_*
-    - define_policies
-    - publish_policies
-    - audit_compliance
-  prohibited:
-    - execute_*
-    - write_code
-    - modify_infrastructure
-  isolation: strict
-```
-
-**Examples**: Compliance policy engines, security policy managers
-
----
-
-## Separation of Duties Rules
-
-### Critic-Executor Separation
-
-Agents that review **cannot** also execute:
-
-```yaml
-separation:
-  role: reviewer
-  conflicts_with:
-    - executor
-    - approver
-  prohibited_actions:
-    - execute
-    - merge
-    - approve
-```
-
-### Governor-Executor Separation
-
-Policy definers **cannot** execute:
-
-```yaml
-separation:
-  role: governor
-  conflicts_with:
-    - operator
-    - enforcer
-  prohibited_actions:
-    - execute
-    - remediate_direct
-```
-
----
-
-## Validation
-
-### Validate v0.3.3 Manifest Against v0.3.3 Schema
-
-```bash
-# Using OSSA CLI
-ossa validate agent.ossa.yaml
-
-# Schema accepts both v0.3.3 and v0.3.3
-```
-
-### Validate Access Tier Configuration
-
-```bash
-# Check separation of duties
-ossa validate agent.ossa.yaml --check-separation
-
-# Audit tier violations
-ossa audit --tier-violations
-```
-
----
-
-## Breaking Changes
-
-**None** - v0.3.3 is fully backward compatible with v0.3.3.
-
-### Deprecations
-
-None in v0.3.3.
-
----
-
-## Examples
-
-See `spec/v0.3.3/examples/access-tiers/` for complete examples:
-
-- `security-scanner.ossa.yaml` - Tier 1 (Read Only)
-- `code-critic.ossa.yaml` - Tier 1 (Read Only)
-- `doc-generator.ossa.yaml` - Tier 2 (Write Limited)
-- `deployment-operator.ossa.yaml` - Tier 3 (Write Elevated)
-- `compliance-governor.ossa.yaml` - Tier 4 (Policy)
-
----
-
-## FAQ
-
-### Do I need to migrate immediately?
-
-**No**. v0.3.3 manifests continue to work. Migrate when you need access tier features.
-
-### Can I mix v0.3.3 and v0.3.3 agents?
-
-**Yes**. Both versions validate against v0.3.3 schema.
-
-### What if I don't specify an access tier?
-
-**Agents work without access tiers**. They're optional for backward compatibility.
-
-### How do I choose the right tier?
-
-See [Access Tier Selection Guide](#access-tier-selection-guide) above.
-
----
-
-## Related Documentation
-
-- [Access Tiers Specification](access_tiers.yaml)
-- [Schema Reference](ossa-0.3.3.schema.json)
-- [Examples](../examples/access-tiers/)
-
----
-
-**Last Updated**: 2025-12-28

package/dist/spec/v0.3.2/UNIFIED-SCHEMA.md

@@ -1,120 +0,0 @@
-# OSSA v0.3.3 - Unified Agent Schema
-
-## The Rocketship 🚀
-
-This schema unifies OSSA, GitLab Duo, Google A2A, and MCP into a single universal agent platform.
-
-### What Changed
-
-**Before (v0.2.x):**
-```yaml
-llm:
-  provider: anthropic
-  model: claude-sonnet-4-20250514
-```
-
-**After (v0.3.3):**
-```yaml
-llm:
-  provider: ${LLM_PROVIDER:-anthropic}
-  model: ${LLM_MODEL:-claude-sonnet}
-  profile: ${LLM_PROFILE:-balanced}
-  fallback_models:
-    - provider: ${LLM_FALLBACK_PROVIDER_1:-openai}
-      model: ${LLM_FALLBACK_MODEL_1:-gpt-4o}
-```
-
-### Key Features
-
-1. **Zero Hardcoded Models** - All LLM config is runtime-configurable
-2. **Execution Profiles** - Google A2A compatible (fast/balanced/deep/safe)
-3. **Multi-Runtime Support** - Works with Duo, A2A, OSSA, MCP
-4. **Fallback Models** - Multi-provider resilience
-5. **Structured Functions** - A2A/OpenAI function calling format
-6. **Extensions** - Pluggable external behaviors
-
-### Compatibility Matrix
-
-| Feature | OSSA v0.2.x | Duo | A2A | v0.3.3 |
-|---------|-------------|-----|-----|--------|
-| Runtime-configurable models | ❌ | ❌ | ✅ | ✅ |
-| Execution profiles | ❌ | ❌ | ✅ | ✅ |
-| Multi-provider fallback | partial | ❌ | ✅ | ✅ |
-| Structured functions | ❌ | partial | ✅ | ✅ |
-| Extensions | partial | partial | ✅ | ✅ |
-
-### Migration
-
-```bash
-# Auto-migrate all agents
-./scripts/migrate-to-unified-llm.sh
-
-# Generate new agent
-./scripts/generate-agent.sh my-agent worker
-
-# Validate
-ossa validate examples/
-```
-
-### Environment Variables
-
-```bash
-# Primary LLM
-export LLM_PROVIDER=anthropic
-export LLM_MODEL=claude-sonnet-4
-export LLM_PROFILE=balanced
-
-# Fallbacks
-export LLM_FALLBACK_PROVIDER_1=openai
-export LLM_FALLBACK_MODEL_1=gpt-4o
-
-# Runtime
-export AGENT_RUNTIME=unified
-export AGENT_SCHEDULING=fair
-export AGENT_PRIORITY=normal
-```
-
-### Execution Profiles
-
-- **fast** - Quick responses (4K tokens, temp=0.0)
-- **balanced** - General ops (16K tokens, temp=0.1)
-- **deep** - Analysis (32K tokens, temp=0.2, reasoning enabled)
-- **safe** - Compliance (temp=0.0, validation required)
-
-### CI Enforcement
-
-Add to `.gitlab-ci.yml`:
-
-```yaml
-include:
-  - local: .gitlab/ci/validate-no-hardcoded-models.yml
-```
-
-This blocks any MR with hardcoded model names.
-
-### Example Agent
-
-See: `examples/unified/security-scanner.ossa.yaml`
-
-### Schema Files
-
-- `schemas/unified-llm.yaml` - LLM configuration
-- `schemas/runtime.yaml` - Runtime declaration
-- `schemas/capabilities.yaml` - Capability definitions
-- `schemas/functions.yaml` - Function declarations
-- `schemas/agent-unified.yaml` - Complete agent schema
-
-### Why This Matters
-
-1. **No More Breaking Changes** - Model updates don't require code changes
-2. **Multi-Provider** - Switch between Anthropic/OpenAI/Google/Groq instantly
-3. **Future-Proof** - New runtimes (A2A, Duo) work without modification
-4. **Cost Optimization** - Use cheap models for triage, expensive for analysis
-5. **Compliance** - Audit trail of which models were used when
-
-### Next Steps
-
-1. Run migration: `./scripts/migrate-to-unified-llm.sh`
-2. Update CI: Add validation rule
-3. Test: `ossa validate examples/`
-4. Deploy: Agents auto-detect runtime