@zibby/core 0.4.6 → 0.5.0

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

@@ -1,181 +0,0 @@
-# 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/dist/templates/code-analysis/prompts/generate-code.md

@@ -1,33 +0,0 @@
-# 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/dist/templates/code-analysis/prompts/generate-test-cases.md

@@ -1,110 +0,0 @@
-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/dist/templates/code-analysis/state.js

@@ -1,48 +0,0 @@
-/**
- * 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.string(), z.any()).optional().describe('Per-node configuration overrides'),
-});
-
-// NOTE: legacy `EXECUTION_ID`, `PROGRESS_QUEUE_URL`, `PROGRESS_API_URL`,
-// `SQS_AUTH_TOKEN`, `PROJECT_API_TOKEN` fields are no longer declared in
-// this schema. They were used only by the legacy `analyze-graph` cli +
-// the analysis UI's progress reporter — never by template nodes. Zod's
-// safeParse here doesn't strip unknown keys (see graph.js:504), so the
-// legacy flow still works at runtime: analyze-graph.js injects them
-// into initialState, validation passes, nodes ignore them, the
-// progress-reporter middleware reads them off the state argument.
-//
-// Keeping them out of the schema means scaffolded user copies (via
-// `zibby workflow new -t code-analysis`) ship a clean state that
-// reflects only what the template actually needs — no false coupling
-// to internal infra fields.

package/dist/templates/generate-test-cases/README.md

@@ -1,72 +0,0 @@
-# Generate Test Cases Template
-
-Standalone slice of `code-analysis` — takes a code diff you already
-have and generates plain-English test specifications for it. Skips
-ticket-analysis and code-gen.
-
-## When to use
-
-- You have a PR diff (or `git diff` output) and want test specs for the changes.
-- You don't need the LLM to generate the code itself — that already exists.
-- You want a smaller, faster pipeline than the full code-analysis workflow.
-
-If you want the full pipeline (analyze ticket → generate code → generate
-tests in one shot), use `code-analysis` instead.
-
-## Graph
-
-```
-setup ─→ generate_test_cases
-```
-
-- `setup` — clone repos so the LLM can explore actual routing /
-  components when writing test steps
-- `generate_test_cases` — LLM reads the diff + ticket context, emits
-  4–8 plain-English test specs (with priority + category)
-
-## Required state inputs
-
-```js
-{
-  workspace: '/abs/path/to/workspace',
-  repos: [{
-    name: 'my-app',
-    url: 'https://github.com/org/my-app.git',
-    branch: 'main',
-    isPrimary: true,
-  }],
-  ticketContext: {
-    ticketKey: 'PROJ-123',
-    summary: 'short title',
-    description: 'long description',
-  },
-  codeImplementation: {
-    diff: '...unified diff string...',
-    changedFiles: ['src/auth/login.ts', 'src/components/LoginForm.tsx'],
-  },
-  githubToken: process.env.GITHUB_TOKEN,
-}
-```
-
-The `codeImplementation` field is what makes this template standalone —
-in `code-analysis` it's produced by the upstream `generate_code` node;
-here you supply it directly.
-
-See `state.js` for the full Zod schema.
-
-## Customizing the prompt
-
-The test-generation prompt is inlined in
-`nodes/generate-test-cases-node.js` (the `buildTestGenerationPrompt`
-function). Edit that to change the LLM's instructions — what
-exploration steps it follows, what test format it returns, etc.
-
-## Cloud deployment
-
-```bash
-zibby workflow deploy <your-slug>
-zibby workflow trigger <uuid> --input '{"workspace": "...", "codeImplementation": {...}, ...}'
-```
-
-Cloud runs need network access for `git clone` (the `setup` node
-shells out to `git`). Default cloud egress works.

package/dist/templates/generate-test-cases/graph.mjs

@@ -1,46 +0,0 @@
-/**
- * generate-test-cases template — standalone slice of code-analysis.
- *
- * Two-node graph:
- *
- *   setup ─→ generate_test_cases
- *
- * Use case: "I have a PR diff already; generate test cases for it."
- * Skips ticket-analysis + code-gen — the user provides the diff
- * directly as `state.codeImplementation`.
- *
- * Why duplicated nodes/setup-node.js + nodes/generate-test-cases-node.js
- * (rather than importing from `../code-analysis/nodes/...`):
- *   Templates have to be self-contained — when scaffolded into a user's
- *   project at `.zibby/workflows/<slug>/`, there's no sibling
- *   `code-analysis/` folder to import from. browser-test + code-analysis
- *   follow the same convention. The cost is keeping the duplicates in
- *   sync; the win is each template is independently editable.
- */
-
-import { WorkflowAgent, WorkflowGraph } from '@zibby/core';
-import { setupNode } from './nodes/setup-node.js';
-import { generateTestCasesNode } from './nodes/generate-test-cases-node.js';
-import { generateTestCasesStateSchema } from './state.js';
-
-export class GenerateTestCasesAgent extends WorkflowAgent {
-  buildGraph() {
-    const graph = new WorkflowGraph();
-    graph.setStateSchema(generateTestCasesStateSchema);
-
-    graph.addNode('setup', setupNode);
-    graph.addNode('generate_test_cases', generateTestCasesNode);
-
-    graph.setEntryPoint('setup');
-    graph.addEdge('setup', 'generate_test_cases');
-    graph.addEdge('generate_test_cases', 'END');
-
-    return graph;
-  }
-
-  async onComplete(result) {
-    const tests = result.state?.generate_test_cases?.tests;
-    const count = tests?.structured?.testCases?.length || 0;
-    console.log(`[generate-test-cases] complete — ${count} test case(s) generated`);
-  }
-}