@windagency/valora 2.0.1

package/data/prompts/02_context/extract-ticket-references.md

@@ -0,0 +1,157 @@
+---
+id: context.extract-ticket-references
+version: 1.0.0
+category: context
+experimental: true
+name: Extract Ticket References
+description: Extract issue and ticket references from branch name and commit messages
+tags:
+  - issue-linking
+  - ticket-extraction
+  - pr-context
+model_requirements:
+  min_context: 128000
+  recommended:
+    - claude-sonnet-4.5
+agents:
+  - lead
+dependencies:
+  requires:
+    - context.use-modern-cli-tools
+    - context.analyze-git-branch
+inputs:
+  - name: current_branch
+    description: Current branch name
+    type: string
+    required: true
+  - name: commits_ahead
+    description: Commit information from branch analysis
+    type: array
+    required: true
+outputs:
+  - related_issues
+  - ticket_numbers
+  - issue_titles
+tokens:
+  avg: 2000
+  max: 4000
+  min: 1000
+---
+
+# Extract Ticket References
+
+## Objective
+
+Parse branch names and commit messages to extract references to issues, tickets, and related work items.
+
+## Instructions
+
+### Step 1: Extract from Branch Name
+
+Parse the branch name for common ticket patterns:
+
+**Patterns to match**:
+
+- **JIRA-style**: `PROJ-123`, `ABC-456` (uppercase letters, hyphen, numbers)
+- **GitHub issues**: `#123`, `issue-123`, `gh-123`
+- **Linear**: `LIN-123`, `linear-123`
+- **Other**: Any `XXX-NNN` pattern where X is letter, N is number
+
+**Example**: `feature/PROJ-456-oauth2-implementation` → `PROJ-456`
+
+### Step 2: Extract from Commit Messages
+
+Get commit messages:
+
+```bash
+git log origin/<base>..HEAD --format=%s%n%b
+```
+
+Search for ticket references in both subject and body:
+
+**Patterns**:
+
+- `Closes #123`, `Fixes #456`, `Resolves #789`
+- `Relates to #123`, `Related to #456`, `See #789`
+- `PROJ-123`, `ABC-456` (anywhere in message)
+- `Issue: #123`, `Ticket: ABC-456`
+
+### Step 3: Query GitHub API for Issue Details
+
+For each GitHub issue number found:
+
+```bash
+gh issue view <number> --json number,title,state,url
+```
+
+Or use the GitHub API tool.
+
+**Extract**:
+
+- Issue number
+- Issue title
+- Issue state (open/closed)
+- Issue URL
+
+### Step 4: Categorize References
+
+Group references by relationship:
+
+- **Closes**: Issues this PR will close
+- **Fixes**: Bugs this PR will fix
+- **Relates to**: Related issues (context only)
+- **Mentions**: Other references
+
+### Step 5: Deduplicate and Validate
+
+- Remove duplicate ticket numbers
+- Validate ticket numbers exist (if possible)
+- Preserve unique references only
+- Sort by reference type (closes > fixes > relates > mentions)
+
+## Output Format
+
+```json
+{
+	"related_issues": [
+		{
+			"number": 456,
+			"reference": "PROJ-456",
+			"title": "Add OAuth2 authentication support",
+			"relationship": "closes",
+			"source": "branch_name",
+			"url": "https://github.com/owner/repo/issues/456"
+		},
+		{
+			"number": 789,
+			"reference": "#789",
+			"title": "Security audit findings",
+			"relationship": "relates",
+			"source": "commit_message",
+			"url": "https://github.com/owner/repo/issues/789"
+		}
+	],
+	"ticket_numbers": ["PROJ-456", "#789"],
+	"issue_titles": {
+		"PROJ-456": "Add OAuth2 authentication support",
+		"#789": "Security audit findings"
+	},
+	"closing_issues": [456],
+	"related_issues_list": [789]
+}
+```
+
+## Success Criteria
+
+- ✅ All ticket references extracted from branch name
+- ✅ All issue references extracted from commits
+- ✅ Issue details fetched from GitHub (if applicable)
+- ✅ References categorized by relationship type
+- ✅ Duplicates removed
+
+## Edge Cases
+
+- **No references found**: Return empty arrays
+- **Invalid ticket format**: Skip and continue
+- **GitHub API unavailable**: Use ticket numbers without titles
+- **Private issues**: May not be accessible, use number only

package/data/prompts/02_context/gather-git-metrics.md

@@ -0,0 +1,237 @@
+---
+id: context.gather-git-metrics
+version: 1.0.0
+category: context
+experimental: true
+name: Gather Git Metrics
+description: Collect objective metrics from git, GitHub, and CI/CD for feedback analysis
+tags:
+  - git-analysis
+  - metrics
+  - feedback
+  - ci-status
+model_requirements:
+  min_context: 128000
+  recommended:
+    - claude-sonnet-4.5
+agents:
+  - product-manager
+dependencies:
+  requires:
+    - context.use-modern-cli-tools
+inputs:
+  - name: pr_number
+    description: Optional PR number for detailed metrics
+    type: number
+    required: false
+outputs:
+  - commits_created
+  - files_modified
+  - lines_changed
+  - test_coverage_delta
+  - ci_status
+  - review_comments_count
+tokens:
+  avg: 2000
+  max: 4000
+  min: 1000
+---
+
+# Gather Git Metrics
+
+## Objective
+
+Collect quantitative metrics from version control and CI/CD systems to objectively assess workflow outcomes.
+
+## Instructions
+
+### Available Tools
+
+**Use these tools:**
+
+1. **Git commands** via `run_terminal_cmd`:
+   - `git rev-list`, `git diff`, `git log`, `git show`
+   - Use `--numstat`, `--format=`, `--porcelain` for machine-readable output
+   - These are the primary tools for gathering git metrics
+
+2. **`jq`** - For parsing JSON output from GitHub API or coverage reports:
+   - Extract specific fields instead of dumping entire JSON files
+   - Example: `jq '.total.lines.pct' coverage/coverage-summary.json`
+
+3. **`rg`** - For searching through git output or log files:
+   - Pattern matching across commit messages or diff output
+   - Example: `git log --format='%s' | rg "fix|feat|breaking"`
+
+4. **query_session** - For execution timing data:
+   - `action: "get", session_id: "<id>"` - Get command durations
+
+**DO NOT use:**
+
+- `npm test`, `npm run test:coverage`, `pnpm test` - too slow, set coverage to null
+- `npm run lint`, `pnpm lint` - not needed for metrics
+- `read_file` on `.valora/sessions/` - use `query_session` instead
+- `grep` - use `rg` instead for faster, `.gitignore`-aware search
+- `cat file.json` - use `jq '.' file.json` to extract specific fields
+
+**For test coverage:** Set to `null` - do not attempt to run tests.
+
+### Step 1: Count Commits
+
+```bash
+git rev-list --count HEAD --since="24 hours ago"
+```
+
+Or if base branch known:
+
+```bash
+git rev-list --count main..HEAD
+```
+
+**Output**: Number of commits created during workflow
+
+### Step 2: Calculate Files Modified
+
+```bash
+# Count files changed (machine-readable numstat)
+git diff --numstat main...HEAD | wc -l
+```
+
+Get detailed statistics:
+
+```bash
+git diff --stat main...HEAD
+```
+
+**Output**: Count of files changed
+
+### Step 3: Measure Lines Changed
+
+```bash
+# Extract additions, deletions, and total from structured numstat output
+git diff --numstat main...HEAD | awk '{add+=$1; del+=$2} END {print "additions=" add, "deletions=" del, "total=" add+del}'
+```
+
+**Output**:
+
+- Lines added
+- Lines deleted
+- Total lines changed
+
+### Step 4: Fetch PR Metrics (if `pr_number` provided)
+
+Use GitHub MCP:
+
+```javascript
+mcp_github({
+	tool_name: 'get_pull_request',
+	arguments: {
+		owner: '<owner>',
+		repo: '<repo>',
+		pull_number: pr_number
+	}
+});
+```
+
+Extract:
+
+- PR status (open/merged/closed)
+- CI check statuses
+- Review count
+- Comment count
+- Time to first review
+- Merge status
+
+### Step 5: Get CI Status
+
+From PR checks or run locally:
+
+```bash
+# If CI is configured
+gh pr checks <pr-number>
+```
+
+Or parse from PR status checks.
+
+**Statuses:**
+
+- `passed`: All checks green
+- `failed`: One or more checks failed
+- `pending`: Checks still running
+- `skipped`: No checks configured
+
+### Step 6: Assess Test Coverage (if available)
+
+**Look for existing coverage reports (do NOT run tests):**
+
+Use `jq` to extract coverage metrics from existing JSON reports:
+
+```bash
+# Parse Jest/Vitest coverage-summary.json
+jq '{
+  statements: .total.statements.pct,
+  branches: .total.branches.pct,
+  functions: .total.functions.pct,
+  lines: .total.lines.pct
+}' coverage/coverage-summary.json
+```
+
+Use `fd` to locate coverage report files:
+
+```bash
+fd -g 'coverage-summary.json' --type f
+```
+
+Compare before/after if possible.
+
+**Output**: Coverage percentage and delta
+
+## Output Format
+
+```json
+{
+	"commits_created": 3,
+	"files_modified": 12,
+	"lines_changed": {
+		"additions": 456,
+		"deletions": 89,
+		"total": 545
+	},
+	"test_coverage_delta": {
+		"before": 78.5,
+		"after": 82.3,
+		"delta": "+3.8%",
+		"available": true
+	},
+	"ci_status": "passed",
+	"ci_checks": {
+		"total": 5,
+		"passed": 5,
+		"failed": 0,
+		"pending": 0
+	},
+	"pr_metrics": {
+		"pr_number": 123,
+		"status": "merged",
+		"review_comments_count": 7,
+		"reviews_count": 2,
+		"time_to_first_review_hours": 4.5,
+		"time_to_merge_hours": 24.3,
+		"approvals": 2
+	}
+}
+```
+
+## Success Criteria
+
+- ✅ Commit count accurate
+- ✅ File and line changes calculated
+- ✅ CI status determined
+- ✅ PR metrics fetched (if applicable)
+- ✅ Coverage data included (if available)
+
+## Error Handling
+
+- **No PR number**: Skip PR-specific metrics, use git only
+- **Coverage unavailable**: Mark as `null` with `available: false`
+- **CI not configured**: Return `ci_status: "not_configured"`
+- **Cannot access GitHub**: Fall back to local git metrics only

package/data/prompts/02_context/gather-validation-context.md

@@ -0,0 +1,281 @@
+---
+id: context.gather-validation-context
+version: 1.0.0
+category: context
+experimental: true
+name: Gather Validation Context
+description: Collect all necessary context for assertion validation including standards, requirements, and quality gates
+tags:
+  - context-gathering
+  - validation
+  - quality-assurance
+model_requirements:
+  min_context: 128000
+  recommended:
+    - claude-haiku-4.5
+    - gpt-5-mini
+agents:
+  - asserter
+dependencies:
+  requires:
+    - context.use-modern-cli-tools
+inputs:
+  - name: implementation_details
+    description: Recent changes, modified files, commit context
+    type: object
+    required: true
+  - name: requirements
+    description: User stories, acceptance criteria, technical specifications
+    type: object
+    required: false
+outputs:
+  - coding_standards
+  - architectural_guidelines
+  - quality_gates
+  - acceptance_criteria
+tokens:
+  avg: 2000
+  max: 4000
+  min: 1000
+---
+
+# Gather Validation Context
+
+## Objective
+
+Collect all necessary context to perform comprehensive assertion validation, including coding standards, architectural guidelines, quality gates, and acceptance criteria.
+
+## Context Collection Strategy
+
+### Step 1: Identify Implementation Scope
+
+Analyze the implementation details to understand what needs to be validated:
+
+**IMPORTANT: Exclude Infrastructure Paths**
+
+VALORA is a tool for building projects, not for updating itself. Always exclude the following paths from validation scope:
+
+- `data/` - VALORA infrastructure (agents, prompts, commands, tooling)
+- `.valora/` - VALORA runtime data (sessions, cache)
+- `.git/` - Git internal state
+- `node_modules/` - Package dependencies
+
+These paths are considered **infrastructure** and should never be included in project validation.
+
+1. **Modified files and components**
+   - List all changed files from implementation_details
+   - **Filter out** any files in `data/`, `.valora/`, `.git/`, or `node_modules/`
+   - Identify component types (UI, API, utilities, tests)
+   - Determine validation scope (frontend, backend, full-stack)
+
+2. **Implementation approach**
+   - Review commit messages and change descriptions
+   - Identify patterns used (e.g., hooks, services, components)
+   - Note any architectural decisions made
+
+3. **Features added/changed**
+   - Extract feature descriptions from commits
+   - Map to requirements if available
+   - Identify critical vs. non-critical changes
+
+### Step 2: Load Project Standards
+
+Gather all quality standards and configurations:
+
+1. **Coding standards**
+   - Read `.eslintrc*`, `prettier.config.*`, or similar
+   - Extract key rules and conventions
+   - Note any custom or overridden rules
+
+2. **TypeScript configuration**
+   - Read `tsconfig.json`
+   - Check strict mode settings
+   - Identify compiler options
+
+3. **Build configuration**
+   - Check build tool config (vite.config, webpack.config, etc.)
+   - Note build targets and environments
+   - Identify optimization settings
+
+4. **Package dependencies**
+   - Read `package.json` for dependency list
+   - Check for security-sensitive packages
+   - Note version constraints
+
+### Step 3: Load Architectural Guidelines
+
+If available in knowledge base:
+
+1. **Architecture documentation**
+   - System architecture patterns
+   - Module boundaries and layer rules
+   - API design standards
+
+2. **Design patterns**
+   - Preferred patterns (Repository, Factory, etc.)
+   - Anti-patterns to avoid
+   - Dependency injection guidelines
+
+3. **Architectural Decision Records (ADRs)**
+   - Recent architectural decisions
+   - Constraints and trade-offs
+   - Rationale for patterns
+
+### Step 4: Load Quality Gates
+
+Extract quality thresholds:
+
+1. **Coverage thresholds**
+   - From Jest/Vitest config or package.json
+   - Line, branch, function coverage targets
+   - Critical path coverage requirements
+
+2. **Complexity limits**
+   - Cyclomatic complexity thresholds
+   - Cognitive complexity limits
+   - File/function size limits
+
+3. **Bundle size limits**
+   - Maximum bundle sizes
+   - Code splitting requirements
+   - Asset optimization targets
+
+4. **Security policies**
+   - OWASP compliance requirements
+   - Secrets management policies
+   - Authentication/authorization patterns
+
+5. **Accessibility requirements**
+   - WCAG level target (A, AA, or AAA)
+   - ARIA usage guidelines
+   - Semantic HTML requirements
+
+### Step 5: Extract Acceptance Criteria
+
+From requirements input:
+
+1. **User stories**
+   - Parse user story format
+   - Extract "As a... I want... So that..."
+   - Identify actors and goals
+
+2. **Acceptance criteria**
+   - Extract Given-When-Then scenarios
+   - List must-have vs. nice-to-have criteria
+   - Identify edge cases and error scenarios
+
+3. **Non-functional requirements**
+   - Performance requirements
+   - Security requirements
+   - Accessibility requirements
+   - Scalability requirements
+
+### Step 6: Check for Frontend Changes
+
+Determine if accessibility validation is needed:
+
+```javascript
+const hasFrontendChanges = modifiedFiles.some(
+	(file) =>
+		(file.match(/\.(tsx?|jsx?|vue|svelte)$/) && file.includes('component')) ||
+		file.includes('page') ||
+		file.includes('ui')
+);
+```
+
+Set `frontend_changes` flag for conditional accessibility validation.
+
+## Output Format
+
+Return a structured context object:
+
+```json
+{
+	"implementation_scope": {
+		"modified_files": ["src/components/Button.tsx", "src/api/users.ts"],
+		"component_types": ["ui", "api"],
+		"frontend_changes": true,
+		"backend_changes": true,
+		"test_changes": true
+	},
+	"coding_standards": {
+		"linter": "eslint",
+		"linter_config": ".eslintrc.json",
+		"formatter": "prettier",
+		"key_rules": {
+			"max_line_length": 100,
+			"quote_style": "single",
+			"indent": 2
+		},
+		"custom_rules": ["no-console: error", "no-unused-vars: error"]
+	},
+	"architectural_guidelines": {
+		"patterns": ["Repository", "Dependency Injection", "Factory"],
+		"layer_rules": "UI -> Services -> Repository -> Data",
+		"module_boundaries": ["No direct database access from UI", "Services must be stateless"],
+		"api_standards": "RESTful with versioning",
+		"adrs": [
+			{
+				"id": "ADR-001",
+				"title": "Use Repository Pattern",
+				"constraints": ["All data access must go through repositories"]
+			}
+		]
+	},
+	"quality_gates": {
+		"coverage": {
+			"lines": 80,
+			"branches": 75,
+			"functions": 80,
+			"statements": 80
+		},
+		"complexity": {
+			"cyclomatic": 10,
+			"cognitive": 15
+		},
+		"bundle_size": {
+			"max_js": "500kb",
+			"max_css": "100kb"
+		},
+		"security": {
+			"owasp_compliance": true,
+			"no_secrets": true,
+			"dependency_scan": true
+		},
+		"accessibility": {
+			"wcag_level": "AA",
+			"target_version": "2.1"
+		}
+	},
+	"acceptance_criteria": [
+		{
+			"story": "US-123",
+			"title": "User login with email/password",
+			"criteria": [
+				"Given valid credentials, when user submits login form, then user is authenticated",
+				"Given invalid credentials, when user submits login form, then error message is displayed",
+				"Given missing fields, when user submits login form, then validation errors are shown"
+			],
+			"nfrs": ["Response time < 500ms", "WCAG AA compliant", "Secure password handling"]
+		}
+	]
+}
+```
+
+## Success Criteria
+
+- ✅ All coding standards files identified and parsed
+- ✅ Quality gates extracted with numeric thresholds
+- ✅ Architectural guidelines documented (or noted as missing)
+- ✅ Acceptance criteria mapped from requirements
+- ✅ Frontend/backend changes correctly identified
+- ✅ Output is structured and complete for validation stages
+
+## Notes
+
+- If configuration files are missing, use sensible defaults and note in output
+- If requirements are unavailable, set acceptance_criteria to empty array
+- Always set frontend_changes flag to determine accessibility validation need
+- Keep output concise - don't duplicate entire config files, just extract key rules
+- **CRITICAL**: Never include files from `data/`, `.valora/`, `.git/`, or `node_modules/` in the validation scope. VALORA validates the project being built, NOT its own infrastructure
+- If no project files are modified (only infrastructure files), report an empty scope with a message indicating no project files to validate