@zibby/core 0.1.0

package/templates/code-analysis/prompts/analyze-ticket.md

@@ -0,0 +1,181 @@
+# Analyze Ticket: {{ticketKey}}
+
+## Ticket Information
+
+**Type:** {{ticketType}}  
+**Priority:** {{ticketPriority}}  
+**Summary:** {{{ticketSummary}}}
+
+**Description:**
+{{{ticketDescription}}}
+
+{{#if ticketLabels}}
+**Labels:** {{ticketLabels}}
+{{/if}}
+
+{{#if ticketComponents}}
+**Components:** {{ticketComponents}}
+{{/if}}
+
+{{#if additionalContext}}
+## Additional Context
+
+{{{additionalContext}}}
+
+{{/if}}
+---
+
+## Repository Information
+
+Your workspace contains ONLY these top-level repository directories:
+
+{{#each repositories}}
+- **{{name}}** — {{language}}{{#if framework}}, {{framework}}{{/if}}{{#if packageManager}} ({{packageManager}}){{/if}}
+{{/each}}
+
+**IMPORTANT:** These are the ONLY repositories. Sub-directories or internal modules (e.g. Maven modules, packages within a monorepo) are NOT separate repositories. All file paths in your analysis MUST start with one of the repository names listed above (e.g. `{{repositories.[0].name}}/path/to/file`).
+
+---
+
+## Your Task
+
+Analyze this ticket **BY EXAMINING THE ACTUAL CODEBASE** and provide:
+1. **Validation** - Determine if the ticket has enough information to implement
+2. **Suggested improvements** to the ticket's summary, description, or labels
+
+### Analysis Steps
+
+1. **REPO RELEVANCE CHECK (MANDATORY FIRST STEP)** - Read the repo's `README.md` or `package.json` to understand what this project is. If the ticket's domain/features do not genuinely belong to this codebase, stop immediately — set `canProceed: false`, `status: 'invalid_ticket'`. Do NOT force-fit: files with similar names (e.g. `auth.js`) do not make a ticket relevant.
+
+2. **VALIDATE THE TICKET** - Determine if we can proceed:
+   - Does the ticket make sense? Is it clear what needs to be done?
+   - Is there enough context to understand the requirements?
+   - Are the requirements technically feasible based on the codebase?
+   - Is the ticket specific enough, or is it too vague?
+   - Are there obvious blockers (missing dependencies, architectural issues)?
+   
+   **If validation fails**, set:
+   - `canProceed: false`
+   - `status`: One of: 'insufficient_context', 'unclear_requirements', 'invalid_ticket', 'needs_clarification'
+   - `reasoning`: Clear explanation of what's missing or unclear
+   - `blockers`: List specific issues preventing implementation
+   
+   **If validation passes**, set:
+   - `canProceed: true`
+   - `status: 'valid'`
+   - `reasoning`: Brief confirmation that ticket is ready
+   - `blockers`: [] or omit
+
+3. **Review the ticket** - Read the summary, description, and labels carefully
+4. **Explore the codebase** - Examine the relevant files, functions, and components
+   - Use file search, grep, and read tools to understand existing patterns
+   - Identify the exact files and code that will be affected
+   - Assess the complexity of the changes required
+5. **Identify improvements** - Look for:
+   - Typos, grammar, or incorrect terminology (use real codebase names)
+   - Missing acceptance criteria or ambiguous requirements
+   - Better ways to phrase the summary based on codebase terminology
+   - Missing or incorrect labels based on actual components affected
+
+---
+
+## IMPORTANT: Output Format
+
+You MUST return your analysis as valid JSON in the following structure:
+
+```json
+{
+  "validation": {
+    "canProceed": true,
+    "status": "valid",
+    "reasoning": "Ticket has clear requirements and matches existing codebase patterns. Implementation is straightforward.",
+    "blockers": []
+  },
+  "suggestedChanges": [
+    {
+      "field": "summary",
+      "original": "<the current ticket summary>",
+      "suggested": "Your improved summary here",
+      "reasoning": "Why this change improves clarity (reference actual codebase structure)"
+    },
+    {
+      "field": "description",
+      "original": "<the current ticket description — full text>",
+      "suggested": "<paste the full corrected description here exactly as it should appear — same structure as original, with typos corrected, terminology updated to match the codebase, and any missing details filled in>",
+      "reasoning": "Why this change helps developers (based on codebase)"
+    },
+    {
+      "field": "labels",
+      "original": "<the current labels or None>",
+      "suggested": "frontend, backend, api-change",
+      "reasoning": "These labels reflect the actual components affected (based on code)"
+    }
+  ],
+  "technicalAnalysis": {
+    "requirements": [
+      "Key requirement 1",
+      "Key requirement 2"
+    ],
+    "affectedFiles": [
+      "repo-name/src/components/Feature.js",
+      "repo-name/src/api/endpoint.js"
+    ],
+    "complexity": "simple|medium|complex",
+    "risks": [
+      "Potential risk 1"
+    ]
+  },
+  "overallSummary": "Brief 1-2 sentence summary of findings based on codebase review",
+  "implementationPlan": "## Summary\nBrief description of what to build.\n\n## Repositories\nChanges needed in: `repo-a`, `repo-b` (read-only reference: `repo-c`).\nThese MUST be top-level workspace directories listed in Repository Information above.\n\n## TODO\n1. In `repo-a/submodule/src/path/to/NewFile.java` — create new entity following `ExistingEntity` pattern\n2. In `repo-a/submodule/src/path/to/Controller.java` — add POST endpoint `/api/thing`\n3. In `repo-b/config/routes.json` — add route entry\n4. ...\n\nEvery path MUST start with a top-level repo name (repo-a/, repo-b/, etc.), never a sub-directory or internal module name.\n\n## Technical Details\n- Follow pattern in `repo-a/submodule/src/.../ExistingService.java` for the service layer\n- Table name: `snake_case_name` (see existing migration `V1.0.100__example.sql`)\n- Risk: watch out for X"
+}
+```
+
+### EXAMPLE: Validation Failed (Insufficient Context)
+
+```json
+{
+  "validation": {
+    "canProceed": false,
+    "status": "insufficient_context",
+    "reasoning": "The ticket asks to 'fix the login bug' but does not specify what the bug is, how to reproduce it, or what the expected behavior should be. Cannot determine what needs to be fixed.",
+    "blockers": [
+      "No description of the actual bug or issue",
+      "No reproduction steps provided",
+      "No expected vs actual behavior specified",
+      "Cannot identify which part of login flow is broken"
+    ]
+  },
+  "suggestedChanges": [
+    {
+      "field": "description",
+      "original": "Fix the login bug",
+      "suggested": "Fix the login bug\n\n**Bug Description:** [describe the bug]\n\n**Steps to Reproduce:**\n1. Go to /login\n2. Enter valid credentials\n3. Click submit\n\n**Expected:** Should redirect to dashboard\n**Actual:** [describe what happens]\n\n**Environment:** Browser, OS",
+      "reasoning": "Description is a single sentence with no reproduction steps or expected behavior — added template for required information."
+    }
+  ],
+  "technicalAnalysis": {
+    "requirements": [],
+    "affectedFiles": [],
+    "complexity": "simple",
+    "risks": ["Cannot proceed without more information"]
+  },
+  "overallSummary": "Ticket is blocked due to insufficient information. Need bug description, reproduction steps, and expected behavior."
+}
+```
+
+### Rules for Suggested Changes:
+
+1. **`suggested` MUST be the actual replacement text** - The `suggested` value replaces `original` directly. It must be the COMPLETE corrected text, NOT instructions or a summary of changes (e.g. "Fix typos: X → Y" is WRONG). The UI diffs `original` vs `suggested` word-by-word.
+2. **For summary**: Use correct codebase terminology and fix typos. Output the full corrected summary.
+3. **For description**: **Enrich, don't rewrite** - You explored the actual codebase, so use that knowledge to improve the ticket: fix typos, correct terminology to match the codebase (e.g. use the real class/component names), add missing acceptance criteria, clarify ambiguous requirements, and add useful technical context you discovered. Keep the original structure and intent — do NOT rewrite from scratch unless the description is fundamentally broken. When adding NEW technical content, use proper Markdown: wrap file paths, function/class/variable names, and inline code references in backticks (e.g. `src/Foo.java`, `toggleLike`), use fenced code blocks for multi-line snippets, but do NOT reformat existing text — only apply formatting to content YOU are adding.
+4. **For labels**: Use comma-separated values that reflect actual components affected (frontend, backend, api-change, etc.)
+5. **Skip fields that are already good** - Only include a field in suggestedChanges if it genuinely benefits from changes.
+
+### CRITICAL Guidelines:
+
+- **ALWAYS read the codebase first** - Use tools to search and read files
+- **Base ALL suggestions on actual code** - Don't make assumptions
+- **Reference real files** - Include actual file paths in your analysis
+- **Follow existing patterns** - Respect the codebase architecture
+
+Return ONLY the JSON object, no additional text before or after.

package/templates/code-analysis/prompts/generate-code.md

@@ -0,0 +1,33 @@
+# Implement: {{ticketKey}} — {{{ticketSummary}}}
+
+## Description
+{{{ticketDescription}}}
+
+{{#if acceptanceCriteria}}
+## Acceptance Criteria
+{{{acceptanceCriteria}}}
+
+{{/if}}
+{{#if analysisContext}}
+## Technical Plan
+{{{analysisContext}}}
+
+{{/if}}
+{{#if repositories}}
+## Workspace
+The following repositories are cloned in your workspace:
+{{#each repositories}}
+- `{{name}}` — {{language}}{{#if framework}}, {{framework}}{{/if}}
+{{/each}}
+Make changes in whichever repositories the Technical Plan and ticket require. If the plan references files in multiple repos, modify all of them.
+
+{{/if}}
+## Instructions
+1. Read the codebase — understand existing patterns and conventions
+2. Implement the feature — clean code, proper error handling, no unnecessary comments
+3. Write tests for new functionality
+4. Verify everything works
+
+{{#if isCommitting}}Changes will be committed and pushed to a feature branch.{{else}}Changes will be captured via git diff.{{/if}}
+
+Now implement the changes!

package/templates/code-analysis/prompts/generate-test-cases.md

@@ -0,0 +1,110 @@
+You are an AI test automation engineer creating human-readable test specifications.
+
+WORKSPACE: {{workspace}}
+
+TICKET: {{ticketKey}} - {{{ticketSummary}}}
+{{#if ticketDescription}}
+Description: {{{ticketDescription}}}
+{{/if}}
+
+MODIFIED FILES:
+{{#each changedFiles}}
+  - {{this}}
+{{/each}}
+
+FULL CODE DIFF:
+```diff
+{{{codeDiff}}}
+```
+
+{{#if hasTestContext}}
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+PROVIDED TEST CONTEXT (USE THESE IN TEST CASES)
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+{{#if testBaseUrl}}Test Base URL: {{testBaseUrl}}{{/if}}
+{{#if adminUsername}}Admin Username: {{adminUsername}}{{/if}}
+{{#if adminPassword}}Admin Password: {{adminPassword}}{{/if}}
+{{#if testAccountUsername}}Test Account Username: {{testAccountUsername}}{{/if}}
+{{#if testAccountPassword}}Test Account Password: {{testAccountPassword}}{{/if}}
+
+**IMPORTANT**: Use these exact values in your test cases. Do NOT make up URLs or credentials.
+
+{{/if}}
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+YOUR JOB: Generate 4-8 test specifications in plain-text format that AI agents can interpret.
+
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+STEP 1: EXPLORE THE CODEBASE (MANDATORY - DO NOT SKIP)
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+YOU MUST explore the codebase to understand the application structure BEFORE writing tests.
+
+REQUIRED EXPLORATION:
+
+1. **Find and Read Routing Files**
+   - Search the workspace for routing files: look for common names like App, routes, router, main, index files in .js/.jsx/.ts/.tsx format
+   - Check common locations: src/, app/, client/, web/, components/, pages/ directories
+   - Identify ALL routes and their URL patterns
+   - Pay special attention to routes with parameters (e.g., /stores/:storeId/products, /users/:userId/orders, /items/:itemId)
+   
+2. **Understand Route Parameters**
+   - Dynamic segments in routes (marked with :paramName or {paramName}) are PLACEHOLDERS
+   - You MUST include navigation steps to select/create that resource first
+   - Example: To reach /stores/:storeId/products, you must first navigate to /stores list and select a specific store
+   - Example: To reach /orders/:orderId/details, you must first navigate to /orders list and click on a specific order
+
+3. **Map Navigation Flow**
+   - Understand the hierarchy: authentication → landing/home → resource lists → individual resources → sub-features
+   - Find what links, buttons, tabs exist on each page to navigate to the next level
+   - Read page components to understand the UI structure and navigation elements
+
+4. **Find Authentication**
+   - Check for login/signin routes, auth components, protected routes, authentication guards
+   - Look for HOCs, route wrappers, or middleware that handle authentication
+   - Understand if authentication is required and what the login flow looks like
+
+5. **Identify Page Components**
+   - Find the actual page/view components referenced in routes
+   - Read their code to understand imports, props, state management, and structure
+   - Understand what data they load, what APIs they call, and what user actions they support
+
+CRITICAL RULES:
+- Routes with dynamic parameters (like :id, :userId, :orderId) REQUIRE parent resource selection
+- You CANNOT jump directly to a URL with an ID - you must navigate through the parent list and SELECT that item
+- Base your test steps on ACTUAL navigation paths you discover in the codebase
+- If you don't explore properly, your tests will have WRONG navigation and be unusable by AI agents
+
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+STEP 2: GENERATE TEST SPECIFICATIONS
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+For each test, provide:
+- **title**: Test name (e.g., "Filter Orders by Status")
+- **application**: Application name (infer from package.json or codebase)
+- **url**: Base application URL (usually http://localhost:3000 or staging URL if found)
+- **testerRole**: Who performs this test (e.g., "Admin user", "End user", "Guest")
+- **feature**: Feature being tested (match the modified files)
+- **ticketId**: Use the ticket key provided above
+- **testCredentials**: Array of credentials needed (if authentication required):
+  - field: "Email" / "Password" / "Username" / "API Key", etc.
+  - value: Use realistic test data (e.g., "admin@example.com", "TestPass123")
+- **testObjective**: One clear sentence describing what this test verifies
+- **testSteps**: Plain English steps - MUST match actual navigation flow you discovered
+- **expectedResults**: Bullet points of what should happen
+- **priority**: Critical, High, Medium, or Low
+- **category**: Test category (e.g., "Smoke Test", "Regression", "Integration")
+
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+FINAL REMINDERS
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+1. ALWAYS explore routing files FIRST
+2. NEVER skip navigation steps - include full path from login to feature
+3. If routes have :parameters, include parent resource selection
+4. Use ACTUAL URLs and paths from the codebase
+5. Write plain English steps - no technical jargon
+6. Base tests on REAL navigation flow, not assumptions
+
+Now generate test specifications for the ticket above.

package/templates/code-analysis/state.js

@@ -0,0 +1,40 @@
+/**
+ * Analysis Workflow State Schema
+ */
+
+import { z } from 'zod';
+
+export const analysisStateSchema = z.object({
+  workspace: z.string().describe('Local workspace path'),
+  
+  repos: z.array(z.object({
+    name: z.string(),
+    url: z.string().url(),
+    path: z.string().optional(),
+    branch: z.string().default('main'),
+    isPrimary: z.boolean().default(false),
+  })).optional().describe('Repository configurations'),
+  
+  ticketContext: z.object({
+    key: z.string().regex(/^[A-Z]+-\d+$/, 'Invalid ticket format (expected PROJ-123)').optional(),
+    ticketKey: z.string().optional(),
+    summary: z.string().min(1).describe('Ticket summary/title'),
+    description: z.any().optional().describe('Ticket description (string or ADF object)'),
+    acceptanceCriteria: z.string().optional(),
+    type: z.string().optional(),
+    priority: z.string().optional(),
+    labels: z.array(z.string()).optional(),
+    components: z.array(z.string()).optional(),
+  }).describe('Jira/ticket context'),
+  
+  promptsDir: z.string().optional().describe('Path to prompts directory'),
+  githubToken: z.string().optional().describe('GitHub personal access token'),
+  model: z.string().default('auto').describe('AI model to use'),
+  nodeConfigs: z.record(z.any()).optional().describe('Per-node configuration overrides'),
+  
+  EXECUTION_ID: z.string().nullable().optional(),
+  PROGRESS_QUEUE_URL: z.string().url().nullable().optional(),
+  PROGRESS_API_URL: z.string().url().nullable().optional(),
+  SQS_AUTH_TOKEN: z.string().nullable().optional(),
+  PROJECT_API_TOKEN: z.string().nullable().optional(),
+});

package/templates/code-implementation/graph.js

@@ -0,0 +1,35 @@
+/**
+ * Implementation Graph - Apply code changes AND create PR
+ * 
+ * Flow:
+ * 1. setup - Clone repos and init git baseline
+ * 2. implement_code - Apply changes, commit, push to branch
+ * 3. generate_tests - Generate test cases
+ * 4. create_pr - Create GitHub Pull Request
+ * 5. finalize - Upload results to API
+ */
+
+import { setupNode } from '../code-analysis/nodes/setup-node.js';
+import { implementCodeNode } from '../code-analysis/nodes/generate-code-node.js';
+import { generateTestCasesNode } from '../code-analysis/nodes/generate-test-cases-node.js';
+import { createPRNode } from '../code-analysis/nodes/create-pr-node.js';
+import { finalizeNode } from '../code-analysis/nodes/finalize-node.js';
+import { implementationStateSchema } from './state.js';
+
+export function buildImplementationGraph(graph) {
+  graph.setStateSchema(implementationStateSchema);
+  
+  graph
+    .addNode('setup', setupNode)                   // ← Reused from analysis!
+    .addNode('implement_code', implementCodeNode)  // ← Real changes + push
+    .addNode('generate_test_cases', generateTestCasesNode)  // ← Generate human-readable test specs
+    .addNode('create_pr', createPRNode)            // ← Create GitHub PR
+    .addNode('finalize', finalizeNode)             // ← Reused from analysis!
+    .setEntryPoint('setup')
+    .addEdge('setup', 'implement_code')
+    .addEdge('implement_code', 'generate_test_cases')
+    .addEdge('generate_test_cases', 'create_pr')
+    .addEdge('create_pr', 'finalize');
+  
+  return graph;
+}

package/templates/code-implementation/index.js

@@ -0,0 +1,7 @@
+/**
+ * Code Implementation Module
+ * Workflow for applying code changes and creating PRs
+ */
+
+export { implementationStateSchema } from './state.js';
+export { buildImplementationGraph } from './graph.js';

package/templates/code-implementation/state.js

@@ -0,0 +1,14 @@
+/**
+ * Implementation Workflow State Schema
+ */
+
+import { z } from 'zod';
+import { analysisStateSchema } from '../code-analysis/state.js';
+
+/**
+ * Implementation workflow state schema (extends analysis)
+ */
+export const implementationStateSchema = analysisStateSchema.extend({
+  branchName: z.string().optional().describe('Git branch name for changes'),
+  prTitle: z.string().optional().describe('Pull request title template'),
+});

package/templates/global-setup.js

@@ -0,0 +1,56 @@
+export default async function globalSetup() {
+  console.log('🎭 Zibby global setup - enabling visual feedback...');
+}
+
+export async function setupRippleEffect(page) {
+  await page.addInitScript(`
+    const style = document.createElement('style');
+    style.textContent = \`
+      @keyframes zibby-ripple {
+        0% {
+          transform: scale(0);
+          opacity: 0.7;
+        }
+        100% {
+          transform: scale(4);
+          opacity: 0;
+        }
+      }
+      .zibby-ripple {
+        position: absolute;
+        border-radius: 50%;
+        background: rgba(59, 130, 246, 0.7);
+        pointer-events: none;
+        animation: zibby-ripple 0.6s ease-out;
+        z-index: 999999;
+      }
+    \`;
+    
+    document.addEventListener('DOMContentLoaded', () => {
+      if (document.head && !document.getElementById('zibby-ripple-style')) {
+        style.id = 'zibby-ripple-style';
+        document.head.appendChild(style);
+      }
+    });
+    
+    if (document.head && !document.getElementById('zibby-ripple-style')) {
+      style.id = 'zibby-ripple-style';
+      document.head.appendChild(style);
+    }
+
+    window.__zibbyShowRipple = function(x, y) {
+      const ripple = document.createElement('div');
+      ripple.className = 'zibby-ripple';
+      ripple.style.left = (x - 10) + 'px';
+      ripple.style.top = (y - 10) + 'px';
+      ripple.style.width = '20px';
+      ripple.style.height = '20px';
+      
+      if (document.body) {
+        document.body.appendChild(ripple);
+        setTimeout(() => ripple.remove(), 600);
+      }
+    };
+  `);
+}
+

package/templates/index.js

@@ -0,0 +1,94 @@
+import { join, dirname } from 'path';
+import { fileURLToPath } from 'url';
+import { existsSync } from 'fs';
+
+const __filename = fileURLToPath(import.meta.url);
+const __dirname = dirname(__filename);
+
+export const TEMPLATES = {
+  'browser-test-automation': {
+    name: 'browser-test-automation',
+    displayName: 'Browser Test Automation (Full Workflow)',
+    description: 'Complete browser test automation workflow with title generation, live execution, and script generation',
+    path: join(__dirname, 'browser-test-automation'),
+    default: true,
+    features: [
+      'Preflight analysis: extract title + assertion checklist from spec',
+      'Execute test live with AI + browser (Claude or Cursor)',
+      'Generate Playwright script with stable IDs',
+      'Real-time streaming output',
+      'Video recording of browser sessions'
+    ]
+  }
+};
+
+export class TemplateFactory {
+  static listTemplates() {
+    return Object.values(TEMPLATES);
+  }
+
+  static getDefault() {
+    return Object.values(TEMPLATES).find(t => t.default) || TEMPLATES['browser-test-automation'];
+  }
+
+  static getTemplate(name) {
+    const template = TEMPLATES[name];
+    if (!template) {
+      const available = Object.keys(TEMPLATES).join(', ');
+      throw new Error(`Template "${name}" not found. Available: ${available}`);
+    }
+    return template;
+  }
+
+  static validateTemplate(templatePath) {
+    const requiredFiles = ['graph.js', 'nodes', 'README.md'];
+    
+    for (const file of requiredFiles) {
+      const filePath = join(templatePath, file);
+      if (!existsSync(filePath)) {
+        throw new Error(`Template missing required file: ${file}`);
+      }
+    }
+    
+    return true;
+  }
+
+  static getTemplateFiles(templateName) {
+    const template = this.getTemplate(templateName);
+    this.validateTemplate(template.path);
+    
+    const resultHandlerPath = join(template.path, 'result-handler.js');
+    return {
+      graphPath: join(template.path, 'graph.js'),
+      nodesPath: join(template.path, 'nodes'),
+      readmePath: join(template.path, 'README.md'),
+      resultHandlerPath: existsSync(resultHandlerPath) ? resultHandlerPath : null,
+      template
+    };
+  }
+
+  static registerCustomTemplate(name, config) {
+    if (TEMPLATES[name]) {
+      throw new Error(`Template "${name}" already exists`);
+    }
+    
+    if (!config.path || !config.displayName) {
+      throw new Error('Custom template must have "path" and "displayName"');
+    }
+    
+    this.validateTemplate(config.path);
+    
+    TEMPLATES[name] = {
+      name,
+      displayName: config.displayName,
+      description: config.description || '',
+      path: config.path,
+      features: config.features || [],
+      custom: true
+    };
+    
+    return TEMPLATES[name];
+  }
+}
+
+export default TemplateFactory;

package/templates/register-nodes.js

@@ -0,0 +1,24 @@
+/**
+ * Template node registrations
+ * 
+ * Import this module as a side-effect to register all built-in
+ * template nodes with the framework's node registry.
+ * 
+ * Usage: import '@zibby/core/templates/register-nodes.js';
+ */
+
+import { registerNode } from '../src/framework/node-registry.js';
+import { setupNode } from './code-analysis/nodes/setup-node.js';
+import { analyzeTicketNode } from './code-analysis/nodes/analyze-ticket-node.js';
+import { generateCodeNode, implementCodeNode } from './code-analysis/nodes/generate-code-node.js';
+import { generateTestCasesNode } from './code-analysis/nodes/generate-test-cases-node.js';
+import { finalizeNode } from './code-analysis/nodes/finalize-node.js';
+import { createPRNode } from './code-analysis/nodes/create-pr-node.js';
+
+registerNode('setup', setupNode);
+registerNode('analyze_ticket', analyzeTicketNode);
+registerNode('generate_code', generateCodeNode);
+registerNode('generate_test_cases', generateTestCasesNode);
+registerNode('finalize', finalizeNode);
+registerNode('implement_code', implementCodeNode);
+registerNode('create_pr', createPRNode);