@bluefly/openstandardagents 0.2.5-RC → 0.2.8

package/.kiro/specs/agent-buildkit-templates/design.md

@@ -1,495 +0,0 @@
-# Design Document
-
-## Overview
-
-This design extends agent-buildkit with a centralized template management system that eliminates the need to copy configuration files across 40+ ecosystem projects. The solution adds a `templates/` directory to agent-buildkit containing reusable steering rules, hooks, MCP server configurations, spec templates, and test templates. Projects initialize with a minimal `.kiro/config.json` pointer file, and the existing `--use-kiro-context` flag is enhanced to resolve templates from agent-buildkit's package directory.
-
-The design follows the DRY principle by making agent-buildkit the single source of truth for IDE configurations across the entire ecosystem, including OSSA, Drupal modules, npm packages, and agent-studio.
-
-## Architecture
-
-### High-Level Architecture
-
-```
-agent-buildkit (npm package)
-├── templates/                    # NEW: Template directory
-│   ├── steering/                 # Steering rules
-│   ├── hooks/                    # Agent hooks
-│   ├── settings/                 # IDE settings (mcp.json, context.json)
-│   ├── specs/                    # Spec templates
-│   ├── tests/                    # Test templates
-│   └── mcp-servers/              # MCP server configs
-├── src/
-│   ├── cli/
-│   │   └── commands/
-│   │       └── init-context.ts   # NEW: Context initialization command
-│   ├── lib/
-│   │   ├── template-resolver.ts  # NEW: Template path resolution
-│   │   └── context-loader.ts     # ENHANCED: Load templates
-│   └── types/
-│       └── templates.ts          # NEW: Template type definitions
-└── docs/
-    └── templates.md              # NEW: Template documentation
-
-Consumer Project
-├── .kiro/
-│   └── config.json               # Pointer to agent-buildkit templates
-└── package.json                  # Depends on @bluefly/agent-buildkit
-```
-
-### Component Interaction Flow
-
-```mermaid
-sequenceDiagram
-    participant Dev as Developer
-    participant CLI as agent-buildkit CLI
-    participant Resolver as TemplateResolver
-    participant FS as File System
-    participant Project as Consumer Project
-
-    Dev->>CLI: npx agent-buildkit --init-context
-    CLI->>FS: Check .kiro/ exists
-    alt .kiro/ doesn't exist
-        CLI->>FS: Create .kiro/
-    end
-    CLI->>FS: Write .kiro/config.json
-    CLI->>Dev: Display template paths
-    
-    Note over Dev,Project: Later: Using templates
-    
-    Dev->>CLI: npx agent-buildkit --use-kiro-context
-    CLI->>FS: Read .kiro/config.json
-    CLI->>Resolver: Resolve template paths
-    Resolver->>FS: Locate agent-buildkit/templates/
-    Resolver->>CLI: Return template paths
-    CLI->>Project: Load steering, hooks, settings
-```
-
-## Components and Interfaces
-
-### 1. Template Directory Structure
-
-The `templates/` directory organizes reusable configurations by category:
-
-```
-templates/
-├── README.md                     # Overview of template system
-├── steering/
-│   ├── README.md
-│   ├── api-first.md              # OSSA/OpenAPI patterns
-│   ├── react-components.md       # React/studio-ui patterns
-│   ├── drupal-modules.md         # Drupal 10+ development
-│   ├── npm-packages.md           # npm package patterns
-│   └── zod-validation.md         # Zod schema validation
-├── hooks/
-│   ├── README.md
-│   ├── openapi-validate.json     # OpenAPI schema validation
-│   ├── drupal-standards.json     # Drupal coding standards
-│   └── test-on-save.json         # Run tests on file save
-├── settings/
-│   ├── README.md
-│   ├── mcp-gitlab.json           # GitLab MCP config
-│   ├── mcp-kubernetes.json       # K8s MCP config
-│   ├── mcp-orbstack.json         # OrbStack local K8s
-│   └── context-defaults.json     # Default context settings
-├── specs/
-│   ├── README.md
-│   ├── api-endpoint.md           # OpenAPI endpoint spec template
-│   ├── drupal-module.md          # Drupal module spec template
-│   ├── npm-package.md            # npm package spec template
-│   └── react-component.md        # React component spec template
-├── tests/
-│   ├── README.md
-│   ├── api-test.template.ts      # API test template
-│   ├── zod-validation.template.ts # Zod validation test
-│   └── drupal-unit.template.php  # Drupal unit test
-└── mcp-servers/
-    ├── README.md
-    ├── gitlab-ci.json            # GitLab CI/CD MCP
-    ├── kubernetes-prod.json      # Production K8s MCP
-    ├── kubernetes-local.json     # OrbStack local K8s MCP
-    └── drupal-agents.json        # Drupal AI agent MCP configs
-```
-
-### 2. CLI Command: init-context
-
-**File:** `src/cli/commands/init-context.ts`
-
-**Purpose:** Initialize a consumer project with minimal configuration
-
-**Interface:**
-```typescript
-interface InitContextOptions {
-  force?: boolean;           // Overwrite existing config
-  template?: string[];       // Copy specific templates
-  interactive?: boolean;     // Interactive template selection
-}
-
-export async function initContext(options: InitContextOptions): Promise<void>
-```
-
-**Behavior:**
-1. Check if `.kiro/` directory exists, create if missing
-2. Check if `.kiro/config.json` exists
-3. If exists and no `--force`, prompt for confirmation
-4. Write `.kiro/config.json` with agent-buildkit template reference
-5. If `--template` flag provided, copy specified templates to project
-6. Display available template paths and usage instructions
-
-### 3. Template Resolver
-
-**File:** `src/lib/template-resolver.ts`
-
-**Purpose:** Resolve template paths from agent-buildkit package
-
-**Interface:**
-```typescript
-interface TemplateResolverOptions {
-  projectRoot: string;
-  configPath?: string;
-}
-
-interface ResolvedTemplates {
-  steering: string[];
-  hooks: string[];
-  settings: string[];
-  specs: string[];
-  tests: string[];
-  mcpServers: string[];
-}
-
-export class TemplateResolver {
-  constructor(options: TemplateResolverOptions);
-  
-  // Resolve all template paths
-  resolveAll(): Promise<ResolvedTemplates>;
-  
-  // Resolve specific template category
-  resolveCategory(category: TemplateCategory): Promise<string[]>;
-  
-  // Get template content
-  getTemplate(category: TemplateCategory, name: string): Promise<string>;
-  
-  // Check for local overrides
-  hasLocalOverride(category: TemplateCategory, name: string): Promise<boolean>;
-}
-
-type TemplateCategory = 'steering' | 'hooks' | 'settings' | 'specs' | 'tests' | 'mcp-servers';
-```
-
-### 4. Context Loader (Enhanced)
-
-**File:** `src/lib/context-loader.ts`
-
-**Purpose:** Load templates when `--use-kiro-context` flag is used
-
-**Interface:**
-```typescript
-interface ContextLoaderOptions {
-  projectRoot: string;
-  useLocalOverrides?: boolean;
-}
-
-interface LoadedContext {
-  steering: SteeringRule[];
-  hooks: Hook[];
-  settings: Settings;
-  mcpServers: MCPServerConfig[];
-}
-
-export class ContextLoader {
-  constructor(options: ContextLoaderOptions);
-  
-  // Load all context
-  loadAll(): Promise<LoadedContext>;
-  
-  // Load specific category
-  loadCategory(category: TemplateCategory): Promise<any[]>;
-  
-  // Merge local overrides with package templates
-  mergeWithOverrides(templates: any[], category: TemplateCategory): Promise<any[]>;
-}
-```
-
-### 5. Configuration File Format
-
-**File:** `.kiro/config.json` (in consumer projects)
-
-```json
-{
-  "version": "1.0",
-  "templateSource": "@bluefly/agent-buildkit",
-  "templateVersion": "^2.0.0",
-  "overrides": {
-    "steering": ["./custom-steering.md"],
-    "hooks": [],
-    "settings": ["./custom-mcp.json"]
-  },
-  "disabled": {
-    "steering": [],
-    "hooks": ["test-on-save"],
-    "mcpServers": []
-  }
-}
-```
-
-## Data Models
-
-### Template Metadata
-
-```typescript
-interface TemplateMetadata {
-  name: string;
-  category: TemplateCategory;
-  description: string;
-  version: string;
-  tags: string[];
-  applicableTo: ProjectType[];
-  dependencies?: string[];
-}
-
-type ProjectType = 
-  | 'drupal-module'
-  | 'npm-package'
-  | 'react-app'
-  | 'openapi-service'
-  | 'drupal-recipe';
-```
-
-### Steering Rule
-
-```typescript
-interface SteeringRule {
-  name: string;
-  content: string;
-  inclusion: 'always' | 'conditional' | 'manual';
-  fileMatchPattern?: string;
-  priority: number;
-}
-```
-
-### Hook Configuration
-
-```typescript
-interface Hook {
-  name: string;
-  trigger: HookTrigger;
-  action: HookAction;
-  enabled: boolean;
-}
-
-type HookTrigger = 
-  | 'on-save'
-  | 'on-message'
-  | 'on-session-start'
-  | 'on-agent-complete';
-
-interface HookAction {
-  type: 'send-message' | 'execute-command';
-  payload: string;
-}
-```
-
-### MCP Server Configuration
-
-```typescript
-interface MCPServerConfig {
-  name: string;
-  command: string;
-  args: string[];
-  env?: Record<string, string>;
-  disabled: boolean;
-  autoApprove: string[];
-}
-```
-
-## Error Handling
-
-### Error Types
-
-```typescript
-enum TemplateErrorCode {
-  CONFIG_NOT_FOUND = 'CONFIG_NOT_FOUND',
-  TEMPLATE_NOT_FOUND = 'TEMPLATE_NOT_FOUND',
-  INVALID_CONFIG = 'INVALID_CONFIG',
-  PERMISSION_DENIED = 'PERMISSION_DENIED',
-  TEMPLATE_PARSE_ERROR = 'TEMPLATE_PARSE_ERROR',
-}
-
-class TemplateError extends Error {
-  constructor(
-    public code: TemplateErrorCode,
-    message: string,
-    public details?: any
-  ) {
-    super(message);
-  }
-}
-```
-
-### Error Handling Strategy
-
-1. **Missing Configuration**: If `.kiro/config.json` not found, provide helpful message suggesting `--init-context`
-2. **Template Not Found**: Fall back to default behavior, log warning
-3. **Invalid Configuration**: Validate config schema, provide specific error messages
-4. **Permission Errors**: Check file permissions, suggest fixes
-5. **Parse Errors**: Catch JSON/YAML parse errors, show line numbers
-
-## Testing Strategy
-
-### Unit Testing
-
-We'll use Jest for unit testing with the following focus areas:
-
-1. **Template Resolver Tests**
-   - Test path resolution for all template categories
-   - Test local override detection
-   - Test template content retrieval
-   - Test error handling for missing templates
-
-2. **Context Loader Tests**
-   - Test loading all context categories
-   - Test merging local overrides with package templates
-   - Test priority ordering of steering rules
-   - Test disabled template filtering
-
-3. **CLI Command Tests**
-   - Test `--init-context` creates correct directory structure
-   - Test `--init-context --force` overwrites existing config
-   - Test `--template` flag copies specific templates
-   - Test interactive mode prompts
-
-4. **Configuration Validation Tests**
-   - Test valid config.json parsing
-   - Test invalid config.json error handling
-   - Test schema validation
-
-### Property-Based Testing
-
-We'll use fast-check for property-based testing. The testing strategy will focus on universal properties that should hold across all inputs.
-
-**Property-Based Testing Library:** fast-check (for TypeScript/JavaScript)
-
-**Configuration:** Each property-based test will run a minimum of 100 iterations.
-
-**Tagging Convention:** Each property-based test will include a comment with the format:
-`// Feature: agent-buildkit-templates, Property {number}: {property_text}`
-
-
-
-## Correctness Properties
-
-*A property is a characteristic or behavior that should hold true across all valid executions of a system-essentially, a formal statement about what the system should do. Properties serve as the bridge between human-readable specifications and machine-verifiable correctness guarantees.*
-
-### Property 1: Template directory structure completeness
-
-*For any* installation of agent-buildkit, all required template subdirectories (steering, hooks, settings, specs, tests, mcp-servers) should exist in the templates/ directory.
-
-**Validates: Requirements 1.2, 8.2**
-
-### Property 2: Template accessibility via node_modules
-
-*For any* consumer project with agent-buildkit installed, the templates directory should be resolvable via standard Node.js module resolution.
-
-**Validates: Requirements 1.5**
-
-### Property 3: Template persistence across updates
-
-*For any* version update of agent-buildkit, the template resolution mechanism should continue to work without requiring manual file copying.
-
-**Validates: Requirements 2.3**
-
-### Property 4: Config file template reference
-
-*For any* initialization via `--init-context`, the created `.kiro/config.json` file should contain a valid reference to agent-buildkit's template directory.
-
-**Validates: Requirements 3.3**
-
-### Property 5: Config preservation without force flag
-
-*For any* existing `.kiro/config.json` file, running `--init-context` without `--force` should preserve the existing configuration.
-
-**Validates: Requirements 3.5**
-
-### Property 6: Config file discovery with context flag
-
-*For any* project with a `.kiro/config.json` file, invoking `--use-kiro-context` should successfully locate the configuration file.
-
-**Validates: Requirements 4.1**
-
-### Property 7: Template path resolution from config
-
-*For any* valid `.kiro/config.json` file, the template resolver should resolve paths to agent-buildkit's templates directory.
-
-**Validates: Requirements 4.2**
-
-### Property 8: Complete template category loading
-
-*For any* resolved template configuration, all template categories (steering, hooks, settings) should be loaded.
-
-**Validates: Requirements 4.3**
-
-### Property 9: MCP template JSON validity
-
-*For any* MCP server template file in templates/mcp-servers/, the file content should parse as valid JSON.
-
-**Validates: Requirements 5.4**
-
-### Property 10: Template documentation completeness
-
-*For any* MCP server template, corresponding documentation should exist either in the template directory README or the docs directory.
-
-**Validates: Requirements 5.5**
-
-### Property 11: README presence in template directories
-
-*For any* template category subdirectory, a README.md file should exist providing documentation for that category.
-
-**Validates: Requirements 8.3**
-
-### Property 12: Template copy structure preservation
-
-*For any* template copied to a consumer project using `--template`, the copied file structure should match the original template structure in agent-buildkit.
-
-**Validates: Requirements 9.3**
-
-### Property 13: Local override priority
-
-*For any* template file that exists both in agent-buildkit and locally in the consumer project, the local file should be loaded instead of the package template.
-
-**Validates: Requirements 9.4, 9.5**
-
-### Property 14: OSSA schema reference resolution
-
-*For any* OSSA schema reference in templates, the path should resolve to a valid location when `--use-kiro-context` is used.
-
-**Validates: Requirements 10.5**
-
-### Integration Tests
-
-Integration tests will verify end-to-end workflows:
-
-1. **Full Initialization Workflow**
-   - Install agent-buildkit in a new project
-   - Run `--init-context`
-   - Verify `.kiro/config.json` created
-   - Run `--use-kiro-context`
-   - Verify templates loaded correctly
-
-2. **Template Override Workflow**
-   - Initialize project with templates
-   - Copy a template locally and modify it
-   - Run `--use-kiro-context`
-   - Verify local template used instead of package template
-
-3. **Update Workflow**
-   - Initialize project with agent-buildkit v1
-   - Update to agent-buildkit v2
-   - Run `--use-kiro-context`
-   - Verify new templates accessible
-
-4. **Selective Template Copy Workflow**
-   - Run `--init-context --template steering,hooks`
-   - Verify only steering and hooks copied
-   - Verify other templates still accessible from package
-

package/.kiro/specs/agent-buildkit-templates/requirements.md

@@ -1,165 +0,0 @@
-# Requirements Document
-
-## Introduction
-
-This feature extends agent-buildkit to centralize IDE configuration templates, steering rules, hooks, MCP server configurations, and spec templates across a complex multi-project ecosystem. The ecosystem includes OSSA (OpenAPI schema master), gitlab_components, 20+ Drupal custom modules, 15+ npm packages, agent-studio IDE, and multiple domain models. Instead of copying configuration folders to 40+ projects, developers use agent-buildkit's new template management features, with updates propagating through standard npm update workflows. This extends the existing `--use-kiro-context` flag and integrates with OSSA schema sync and GitLab CI infrastructure.
-
-## Glossary
-
-- **Agent Buildkit**: The existing npm package at `/Users/flux423/Sites/LLM/agent-buildkit` that will be extended with template management capabilities
-- **Template System**: The collection of reusable configuration files for steering, hooks, settings, specs, tests, and MCP servers stored within agent-buildkit
-- **Context Initialization**: The new `--init-context` command in agent-buildkit for setting up projects with templates
-- **Consumer Project**: Any of the 40+ projects that use agent-buildkit and will access centralized templates
-- **Configuration Pointer**: A minimal `.kiro/config.json` file that references agent-buildkit's template directory
-- **MCP Server**: Model Context Protocol server configuration
-- **Steering Rules**: IDE guidance files that influence agent behavior
-- **OSSA**: Open Standard Agents specification at `/Users/flux423/Sites/LLM/openstandardagents` - the master OpenAPI and schema source
-- **GitLab Components**: CI/CD library at `/Users/flux423/Sites/LLM/gitlab_components`
-- **Ecosystem Projects**: The 40+ projects including Drupal modules, npm packages, models, and recipes
-- **Agent Studio**: Monorepo IDE tool at `/Users/flux423/Sites/LLM/common_npm/agent-studio` for macOS, iOS, Electron, VS Code extension, and web IDE
-
-## Requirements
-
-### Requirement 1
-
-**User Story:** As a developer managing multiple projects, I want agent-buildkit to provide centralized templates, so that I can avoid copying configuration folders across 40+ projects.
-
-#### Acceptance Criteria
-
-1. WHEN agent-buildkit is installed THEN the Agent Buildkit SHALL include a `templates/` directory in its package structure
-2. WHEN the templates directory exists THEN the Agent Buildkit SHALL provide subdirectories for steering, hooks, settings, specs, tests, and mcp-servers
-3. WHEN a developer runs `npx agent-buildkit --init-context` THEN the Agent Buildkit SHALL create a minimal `.kiro/config.json` file
-4. WHEN the initialization completes THEN the Agent Buildkit SHALL display available template paths and next steps
-5. THE Agent Buildkit SHALL make templates accessible to all consumer projects via node_modules resolution
-
-### Requirement 2
-
-**User Story:** As a developer, I want to update all projects' templates by updating agent-buildkit, so that I can maintain consistency across my entire project portfolio.
-
-#### Acceptance Criteria
-
-1. WHEN a developer publishes a new version of agent-buildkit THEN the Package Manager SHALL make the updated version available on npm
-2. WHEN a developer runs `npm update @bluefly/agent-buildkit` in a Consumer Project THEN the Package Manager SHALL fetch and install the latest version
-3. WHEN agent-buildkit updates THEN the Template System SHALL provide the new templates without requiring manual file copying
-4. THE Agent Buildkit SHALL use semantic versioning for all releases
-5. WHEN template breaking changes are introduced THEN the Agent Buildkit SHALL document migration steps in CHANGELOG
-
-### Requirement 3
-
-**User Story:** As a developer, I want agent-buildkit to initialize my project with minimal configuration, so that I can start using templates quickly.
-
-#### Acceptance Criteria
-
-1. WHEN a developer runs `npx agent-buildkit --init-context` THEN the Agent Buildkit SHALL check if `.kiro` directory exists
-2. IF the `.kiro` directory does not exist THEN the Agent Buildkit SHALL create it
-3. WHEN creating the configuration THEN the Agent Buildkit SHALL write a `.kiro/config.json` file with a reference to agent-buildkit's template directory
-4. WHEN the initialization is complete THEN the Agent Buildkit SHALL output the paths to available templates
-5. THE Agent Buildkit SHALL not overwrite existing `.kiro/config.json` files without user confirmation
-
-### Requirement 4
-
-**User Story:** As a developer, I want agent-buildkit's existing `--use-kiro-context` flag to work with the new template system, so that I can use context in my build processes.
-
-#### Acceptance Criteria
-
-1. WHEN agent-buildkit is invoked with `--use-kiro-context` flag THEN the Agent Buildkit SHALL locate the `.kiro/config.json` file
-2. WHEN the configuration pointer is found THEN the Agent Buildkit SHALL resolve template paths from its own templates directory
-3. WHEN templates are resolved THEN the Agent Buildkit SHALL load steering rules, hooks, and settings
-4. THE Agent Buildkit SHALL export a programmatic API for template path resolution
-5. THE Agent Buildkit SHALL provide TypeScript type definitions for all template-related APIs
-
-### Requirement 5
-
-**User Story:** As a developer working with GitLab and Kubernetes, I want default MCP configurations for K8s agents and CI/CD, so that I can quickly set up agent-based workflows.
-
-#### Acceptance Criteria
-
-1. THE Agent Buildkit SHALL include MCP server templates for GitLab integration in templates/mcp-servers/
-2. THE Agent Buildkit SHALL include MCP server templates for Kubernetes agent operations
-3. THE Agent Buildkit SHALL include MCP server templates for CI/CD pipeline automation
-4. WHEN a developer accesses MCP templates THEN the Template System SHALL provide configuration files in JSON format
-5. THE Agent Buildkit SHALL include documentation for each MCP server template
-
-### Requirement 6
-
-**User Story:** As a developer using OrbStack for local development, I want MCP integration for local Kubernetes clusters, so that I can test agent workflows locally before deploying.
-
-#### Acceptance Criteria
-
-1. THE Agent Buildkit SHALL include MCP server templates for OrbStack Kubernetes integration
-2. WHEN using OrbStack templates THEN the Template System SHALL provide localhost connection configurations
-3. THE Agent Buildkit SHALL include examples for local K8s agent testing
-4. THE Agent Buildkit SHALL document the differences between local and production MCP configurations
-5. WHEN local configurations are used THEN the MCP Server SHALL connect to OrbStack's Kubernetes API
-
-### Requirement 7
-
-**User Story:** As a developer following API-first principles with OSSA as the schema master, I want agent-buildkit to support React, OpenAPI, Zod, and Drupal templates, so that my templates align with my technology stack across all ecosystem projects.
-
-#### Acceptance Criteria
-
-1. THE Agent Buildkit SHALL include spec templates for OpenAPI-based projects that reference OSSA schemas
-2. THE Agent Buildkit SHALL include steering rules for React component development used in studio-ui and agent-studio
-3. THE Agent Buildkit SHALL include test templates that use Zod for schema validation synced with OSSA
-4. THE Agent Buildkit SHALL include steering rules for Drupal module development covering the 20+ custom modules
-5. THE Agent Buildkit SHALL provide templates for npm package development used across the 15+ common_npm packages
-
-### Requirement 8
-
-**User Story:** As a package maintainer, I want a clear directory structure for templates within agent-buildkit, so that users can easily understand and extend the templates.
-
-#### Acceptance Criteria
-
-1. THE Agent Buildkit SHALL organize templates in a `templates/` directory at the package root
-2. THE Template System SHALL use subdirectories for each template category: steering, hooks, settings, specs, tests, mcp-servers
-3. WHEN a user browses agent-buildkit THEN the Template System SHALL provide a README in each template directory
-4. THE Agent Buildkit SHALL include template documentation in its existing docs directory
-5. THE Agent Buildkit SHALL maintain its existing npm package structure while adding the templates directory
-
-### Requirement 9
-
-**User Story:** As a developer, I want to selectively use templates from agent-buildkit, so that I can customize my project configuration while still benefiting from centralized updates.
-
-#### Acceptance Criteria
-
-1. WHEN a developer references a template THEN the Template System SHALL allow copying individual templates to the project
-2. THE Agent Buildkit SHALL provide a `--template` flag to copy specific template categories
-3. WHEN templates are copied THEN the Agent Buildkit SHALL preserve the original template structure
-4. THE Agent Buildkit SHALL allow projects to override package templates with local files
-5. WHEN local overrides exist THEN the Template System SHALL prioritize local files over agent-buildkit templates
-
-### Requirement 10
-
-**User Story:** As a developer working with OSSA schemas, I want agent-buildkit to integrate with OSSA schema sync and Apidog, so that my templates stay synchronized with the master OpenAPI specifications.
-
-#### Acceptance Criteria
-
-1. THE Agent Buildkit SHALL include steering rules that reference OSSA schema locations
-2. WHEN OSSA schemas are updated THEN the Template System SHALL provide guidance for syncing with Apidog
-3. THE Agent Buildkit SHALL include spec templates for API-first development using OSSA patterns
-4. THE Agent Buildkit SHALL provide hooks for validating OpenAPI schema compliance
-5. WHEN agent-buildkit uses `--use-kiro-context` THEN the Agent Buildkit SHALL resolve OSSA schema references
-
-### Requirement 11
-
-**User Story:** As a developer managing Drupal recipes and modules, I want templates specific to Drupal development, so that I can maintain consistency across llm_platform, secure_drupal recipes and 20+ custom modules.
-
-#### Acceptance Criteria
-
-1. THE Agent Buildkit SHALL include steering rules for Drupal 10+ module development
-2. THE Agent Buildkit SHALL include spec templates for Drupal recipe creation
-3. THE Agent Buildkit SHALL include hooks for Drupal coding standards validation
-4. THE Agent Buildkit SHALL provide MCP server templates for Drupal AI agent modules (OSSA, KAgent, Claude, Cursor, etc.)
-5. WHEN developing Drupal modules THEN the Template System SHALL provide guidance for recipe integration
-
-### Requirement 12
-
-**User Story:** As a developer, I want agent-buildkit to maintain its existing npm package quality while adding template features, so that all 40+ ecosystem projects can benefit from the updates.
-
-#### Acceptance Criteria
-
-1. THE Agent Buildkit SHALL continue to be published to npm under the `@bluefly` scope
-2. WHEN published THEN the Agent Buildkit SHALL update package.json to document new template features
-3. THE Agent Buildkit SHALL update its README.md with template initialization and usage instructions
-4. THE Agent Buildkit SHALL maintain its existing Node.js version requirements
-5. THE Agent Buildkit SHALL update its CHANGELOG.md to document template system additions