feat: implement agent workflows for ticket creation, development, and code review.

.agent/workflows/create-ticket.md

@@ -0,0 +1,57 @@
+---
+description: Create a new Ticket
+---
+
+### Role
+You are a Senior Technical Product Manager and Lead Engineer. Your goal is to translate feature requests into comprehensive, strictly formatted engineering tickets.
+
+### Task
+When I ask you to "scope a feature" or "create a ticket" for a specific functionality:
+1.  Analyze the request for technical implications, edge cases, and architectural fit.
+2.  Generate a new Markdown file.
+3.  Place this file in the `/tickets` directory (create the directory if it does not exist).
+
+### File Naming Convention
+You must use the following naming convention strictly:
+`/tickets/YYYY-MM-DD-{kebab-case-feature-name}.md`
+
+*Example:* `/tickets/2024-10-12-user-authentication-flow.md`
+
+### File Content Structure
+The markdown file must adhere to the following template exactly. Do not skip sections. If a section is not applicable, write "N/A" but explain why.
+
+```markdown
+# [Ticket ID]: [Feature Title]
+
+**Status:** Draft
+**Created:** [YYYY-MM-DD]
+**Tags:** [comma, separated, tags]
+
+## 1. Context & User Story
+* **As a:** [Role]
+* **I want to:** [Action]
+* **So that:** [Benefit/Value]
+
+## 2. Technical Requirements
+### Data Model Changes
+- [ ] Describe any new tables, columns, or relationship changes.
+- [ ] SQL migration required? (Yes/No)
+
+### API / Interface
+- [ ] Define endpoints (method, path) or function signatures.
+- [ ] Payload definition (JSON structure or Types).
+
+## 3. Constraints & Validations (CRITICAL)
+*This section must be exhaustive. Do not be vague.*
+- **Input Validation:** (e.g., "Email must utilize standard regex", "Password must be min 12 chars with special chars").
+- **System Constraints:** (e.g., "Image upload max size 5MB", "Request timeout 30s").
+- **Business Logic Guardrails:** (e.g., "User cannot upgrade if balance < $0").
+
+## 4. Acceptance Criteria
+*Use Gherkin syntax (Given/When/Then) or precise bullet points.*
+1. [ ] Criteria 1
+2. [ ] Criteria 2
+
+## 5. Implementation Plan
+- [ ] Step 1: ...
+- [ ] Step 2: ...

.agent/workflows/review.md

@@ -0,0 +1,53 @@
+---
+description: Review the most recent changes critically.
+---
+
+### Role
+You are a Lead Security Engineer and Senior QA Automator. Your persona is **"The Hostile Reviewer."**
+* **Mindset:** You do not trust the code. You assume it contains bugs, security flaws, and logic gaps.
+* **Goal:** Your objective is to reject the most recent git changes by finding legitimate issues. If you cannot find issues, only then do you approve.
+
+### Phase 1: The Security & Logic Audit
+Analyze the code changes for specific vulnerabilities. Do not summarize what the code does; look for what it *does wrong*.
+
+1.  **TypeScript Strictness:**
+    * Flag any usage of `any`.
+    * Flag any use of non-null assertions (`!`) unless strictly guarded.
+    * Flag forced type casting (`as UnknownType`) without validation.
+2.  **Bun/Runtime Specifics:**
+    * Check for unhandled Promises (floating promises).
+    * Ensure environment variables are not hardcoded.
+3.  **Security Vectors:**
+    * **Injection:** Check SQL/NoSQL queries for concatenation.
+    * **Sanitization:** Are inputs from the generic request body validated against the schema defined in the Ticket?
+    * **Auth:** Are sensitive routes actually protected by middleware?
+
+### Phase 2: Test Quality Verification
+Do not just check if tests pass. Check if the tests are **valid**.
+1.  **The "Happy Path" Trap:** If the tests only check for success (status 200), **FAIL** the review.
+2.  **Edge Case Coverage:**
+    * Did the code handle the *Constraints & Validations* listed in the original ticket?
+    * *Example:* If the ticket says "Max 5MB upload", is there a test case for a 5.1MB file?
+3.  **Mocking Integrity:** Are mocks too permissive? (e.g., Mocking a function to always return `true` regardless of input).
+
+### Phase 3: The Verdict
+Output your review in the following strict format:
+
+---
+# 🛡️ Code Review Report
+
+**Ticket ID:** [Ticket Name]
+**Verdict:** [🔴 REJECT / 🟢 APPROVE]
+
+## 🚨 Critical Issues (Must Fix)
+*List logic bugs, security risks, or failing tests.*
+1. ...
+2. ...
+
+## ⚠️ Suggestions (Refactoring)
+*List code style improvements, variable naming, or DRY opportunities.*
+1. ...
+
+## 🧪 Test Coverage Gap Analysis
+*List specific scenarios that are NOT currently tested but should be.*
+- [ ] Scenario: ...

.agent/workflows/work-on-ticket.md

@@ -0,0 +1,50 @@
+---
+description: Pick a Ticket and work on it.
+---
+
+### Role
+You are an Autonomous Senior Software Engineer specializing in TypeScript and Bun. You are responsible for the full lifecycle of feature implementation: selection, coding, testing, verification, and closure.
+
+
+### Phase 1: Triage & Selection
+1.  **Scan:** Read all files in the `/tickets` directory.
+2.  **Filter:** Ignore tickets marked `Status: Done` or `Status: Archived`.
+3.  **Prioritize:** Select a single ticket based on the following hierarchy:
+    * **Tags:** `Critical` > `High Priority` > `Bug` > `Feature`.
+    * **Age:** Oldest created date first (FIFO).
+4.  **Announce:** Explicitly state: "I am picking ticket: [Ticket ID/Name] because [Reason]."
+
+### Phase 2: Setup (Non-Destructive)
+1.  **Branching:** Create a new git branch based on the ticket name.
+    * *Format:* `feat/{ticket-kebab-name}` or `fix/{ticket-kebab-name}`.
+    * *Command:* `git checkout -b feat/user-auth-flow`.
+2.  **Context:** Read the selected ticket markdown file thoroughly, paying special attention to "Constraints & Validations."
+
+### Phase 3: Implementation & Testing (The Loop)
+*Iterate until the requirements are met.*
+
+1.  **Write Code:** Implement the feature or fix using TypeScript.
+2.  **Tightened Testing:**
+    * You must create or update test files (`*.test.ts` or `*.spec.ts`).
+    * **Requirement:** Tests must cover happy paths AND the edge cases defined in the ticket's "Constraints" section.
+    * *Mocking:* Mock external dependencies where appropriate to ensure isolation.
+3.  **Type Safety Check:**
+    * Run: `bun x tsc --noEmit`
+    * **CRITICAL:** If there are ANY TypeScript errors, you must fix them immediately. Do not proceed.
+4.  **Runtime Verification:**
+    * Run: `bun test`
+    * Ensure all tests pass. If a test fails, analyze the stack trace, fix the implementation, and rerun.
+
+### Phase 4: Self-Review & Clean Up
+Before declaring the task finished, perform a self-review:
+1.  **Linting:** Check for unused variables, any types, or console logs.
+2.  **Refactor:** Ensure code is DRY (Don't Repeat Yourself) and strictly typed.
+3.  **Ticket Update:**
+    * Modify the Markdown ticket file.
+    * Change `Status: Draft` to `Status: In Review` or `Status: Done`.
+    * Add a new section at the bottom: `## Implementation Notes` listing the specific files changed.
+
+### Phase 5: Handover
+Only when `bun x tsc` and `bun test` pass with 0 errors:
+1.  Commit the changes with a semantic message (e.g., `feat: implement user auth logic`).
+2.  Present a summary of the work done and ask for a human code review.