@jjdenhertog/ai-driven-development

# Scaffolding Task Type Classification ## Overview The `scaffolding` task type is a proposed addition to the AI-driven development system. It provides a streamlined handler for project setup, configuration, and infrastructure tasks that don't require the full 7-phase pipeline. ## Current Task Types 1. **`feature`** - Full 7-phase pipeline with architecture, testing, and implementation 2. **`pattern`** - Multi-phase pipeline for creating reusable code patterns 3. **`instruction`** - Single-phase handler for documentation tasks ## Proposed: Scaffolding Type 4. **`scaffolding`** - Streamlined handler for setup/configuration tasks ## When to Classify as "Scaffolding" A task should be classified as `scaffolding` when it involves project setup, configuration, or infrastructure work with these characteristics: ### Core Characteristics 1. **Primarily runs commands** (npm install, prisma init, etc.) 2. **Updates configuration files** (package.json, tsconfig.json, etc.) 3. **Sets up project infrastructure** (not features) 4. **Success is binary** - it either works or doesn't 5. **Doesn't need architecture design or test specifications** ### Examples of Scaffolding Tasks ✅ **Definitely Scaffolding:** - Installing dependencies (`npm install @mui/material`) - Setting up Prisma with database connection - Configuring ESLint and Prettier - Setting up testing framework (Vitest, Jest) - Creating environment variable files - Setting up Docker configuration - Initializing git hooks (Husky) - Configuring build tools (Webpack, Vite) - Setting up CI/CD pipelines - Installing and configuring authentication providers - Setting up monitoring/logging infrastructure - Creating project folder structure - Configuring TypeScript settings ❌ **NOT Scaffolding (Use Other Types):** - Creating a login form → `feature` - Creating error handling pattern → `pattern` - Writing deployment guide → `instruction` - Building API endpoints → `feature` - Creating reusable component template → `pattern` - Implementing business logic → `feature` - Writing tests → `feature` ## Key Distinctions | Type | Purpose | Example | |------|---------|---------| | **scaffolding** | Setup/config with no business logic | Install dependencies, configure tools | | **feature** | User-facing functionality | Login form, dashboard, API endpoints | | **pattern** | Reusable code templates | Error handler, base components | | **instruction** | Documentation only | README, deployment guides | ## Why Scaffolding Needs Its Own Type ### Current Problem The 7-phase pipeline expects: - Component design specifications - Test specifications for features - Architectural decisions - Complex implementation planning ### Scaffolding Reality Scaffolding tasks only need: - What to install/configure - Commands to run - Verification steps - Success criteria ### Example Mismatch When "Install Core Dependencies" goes through the architect phase, it produces: - Test specifications for... checking if packages are installed - Architecture decisions about... package.json - Component design for... no components This creates unnecessary complexity and confusing outputs. ## Decision Framework ``` Is it installing/configuring tools without creating features? YES → scaffolding NO → Continue... Does it create user-facing functionality? YES → feature NO → Continue... Is it creating reusable code templates? YES → pattern NO → Continue... Is it purely documentation? YES → instruction NO → Default to feature ``` ## Key Phrases Indicating Scaffolding - "Install..." - "Set up..." - "Configure..." - "Initialize..." - "Create boilerplate for..." - "Add development tooling..." - "Set up environment..." - "Create project structure..." - "Add build configuration..." - "Set up database connection..." - "Configure deployment..." ## Implementation Benefits Using a dedicated `scaffolding` type would: 1. **Simplify execution** - Direct command running without unnecessary phases 2. **Improve clarity** - No confusing test specs for dependency installation 3. **Speed up development** - Skip inappropriate planning phases 4. **Better outputs** - Focus on what was done and how to verify ## Edge Cases ### Setting up vs Using - **Scaffolding**: `npm install @tanstack/react-query` + basic provider setup - **Feature**: Implementing data fetching with React Query in components ### Configuration vs Implementation - **Scaffolding**: Setting up NextAuth with providers in config - **Feature**: Creating login/logout UI and flows ### Structure vs Content - **Scaffolding**: Creating folder structure for features - **Feature**: Implementing the actual features in those folders ## Proposed Workflow Scaffolding tasks would: 1. Load task requirements 2. Check current state 3. Execute setup commands 4. Update configuration files 5. Verify successful setup 6. Document what was done 7. Complete in single phase No need for: - Architecture design - Test specifications - Component planning - Multi-phase validation