254 lines
53 KiB
JSON
254 lines
53 KiB
JSON
|
|
{
|
||
|
|
"model": "HuggingFaceTB/SmolLM3-3B",
|
||
|
|
"endpoint": "http://95.179.247.150/v1/chat/completions",
|
||
|
|
"max_context": 65536,
|
||
|
|
"turns": [
|
||
|
|
"I want to build a Python CLI task manager. Let's do this step by step.\n\nFirst, I want a simple Task class with:\n- id (auto-generated)\n- title (string)\n- description (string, optional)\n- completed (boolean, default false)\n- created_at (datetime)\n\nShow me just the Task class implementation. We'll build on it.",
|
||
|
|
|
||
|
|
"Good start. Now let's add a TaskManager class that can:\n- add_task(title, description=None) - create and add a task\n- list_tasks(show_completed=False) - list all tasks, optionally filter by completed\n- complete_task(task_id) - mark a task as completed\n- delete_task(task_id) - remove a task\n\nShow me the TaskManager class.",
|
||
|
|
|
||
|
|
"Now let's add persistence. I want to save tasks to a JSON file.\n- Add save_to_file(filepath) method\n- Add load_from_file(filepath) class method\n- The JSON should be an array of task objects\n\nUpdate the TaskManager class with these methods.",
|
||
|
|
|
||
|
|
"Now let's add a CLI interface using argparse. I want:\n- `python taskman.py add \"Task title\" -d \"Description\"` - add a task\n- `python taskman.py list` - list all tasks\n- `python taskman.py list --all` - list all tasks including completed\n- `python taskman.py complete <id>` - mark task as done\n- `python taskman.py delete <id>` - delete a task\n\nShow me the complete taskman.py file.",
|
||
|
|
|
||
|
|
"Let's add some improvements:\n1. Add a priority field to Task (high, medium, low, default medium)\n2. Add sorting to list_tasks - by priority or by created_at\n3. Add a `--sort` option to the CLI (priority or date)\n4. Color-coded output: high priority = red, medium = yellow, low = green\n\nShow me the updated code.",
|
||
|
|
|
||
|
|
"Let's add due dates:\n1. Add due_date field to Task (optional datetime)\n2. Add is_overdue property that returns True if due_date is past\n3. Update CLI to accept `--due \"2024-12-31\"` when adding\n4. Add `taskman.py overdue` command to show overdue tasks\n5. In list output, show [OVERDUE] for overdue tasks\n\nShow me the updated code.",
|
||
|
|
|
||
|
|
"Let's add task categories/tags:\n1. Add tags field to Task (list of strings)\n2. Update CLI: `taskman.py add \"Title\" --tags work,urgent`\n3. Add `taskman.py list --tag work` to filter by tag\n4. Add `taskman.py tags` to list all used tags\n5. Store tags as a set internally for uniqueness\n\nShow me the updated code.",
|
||
|
|
|
||
|
|
"Let's add task dependencies:\n1. Add depends_on field to Task (list of task IDs)\n2. A task cannot be completed if any dependency is not completed\n3. Add `taskman.py add \"Title\" --depends 1,3` \n4. Add `taskman.py blocked` to show tasks that can't be completed yet\n5. When listing, show [BLOCKED] for tasks with incomplete dependencies\n\nShow me the updated code.",
|
||
|
|
|
||
|
|
"Let's add task notes/comments:\n1. Create a TaskNote class with id, task_id, content, created_at\n2. Add notes list to TaskManager\n3. Add `taskman.py note <task_id> \"Note content\"` to add a note\n4. Add `taskman.py notes <task_id>` to show all notes for a task\n5. Store notes in the same JSON file under a \"notes\" key\n\nShow me the updated code.",
|
||
|
|
|
||
|
|
"Let's add undo functionality:\n1. Track the last 10 actions (add, complete, delete, note)\n2. Each action stores enough info to undo it\n3. Add `taskman.py undo` to undo the last action\n4. Add `taskman.py history` to show recent actions\n5. Store history in memory only (not persisted)\n\nShow me the updated code.",
|
||
|
|
|
||
|
|
"Let's add search functionality:\n1. Add `taskman.py search <query>` to search task titles and descriptions\n2. Support basic patterns: \"bug*\" matches \"bug\", \"bugfix\", \"bugs\"\n3. Add `--tag` filter to search within a tag\n4. Add `--completed` flag to include/exclude completed tasks\n5. Highlight matching text in output\n\nShow me the updated code.",
|
||
|
|
|
||
|
|
"Let's add export functionality:\n1. Add `taskman.py export --format csv` to export to CSV\n2. Add `taskman.py export --format markdown` to export as markdown table\n3. Add `taskman.py export --format json` (different from internal format)\n4. Add `--output file.csv` to write to file instead of stdout\n5. Include all task fields in export\n\nShow me the updated code.",
|
||
|
|
|
||
|
|
"Let's add recurring tasks:\n1. Add recurrence field to Task (none, daily, weekly, monthly)\n2. Add next_occurrence datetime field\n3. When a recurring task is completed, create a new task with next occurrence\n4. Add `taskman.py add \"Daily standup\" --recur daily` \n5. Add `taskman.py recurring` to list all recurring tasks\n\nShow me the updated code.",
|
||
|
|
|
||
|
|
"Let's add time tracking:\n1. Add time_spent field to Task (integer, seconds)\n2. Add `taskman.py start <id>` to begin tracking time on a task\n3. Add `taskman.py stop <id>` to stop tracking and add to time_spent\n4. Track currently running task in a .taskman_running file\n5. Add `taskman.py times` to show total time per task\n\nShow me the updated code.",
|
||
|
|
|
||
|
|
"Let's add subtasks:\n1. Add parent_id field to Task (None for top-level tasks)\n2. A task with parent_id is a subtask\n3. Add `taskman.py add \"Subtask\" --parent 5`\n4. When listing, indent subtasks under their parent\n5. A parent task shows completion % based on subtasks\n\nShow me the updated code.",
|
||
|
|
|
||
|
|
"Let's add a progress indicator for tasks:\n1. Add progress field (0-100 integer)\n2. Add `taskman.py progress <id> 50` to set progress\n3. Show [=====> ] style progress bar in list output\n4. Progress 100 should auto-mark as completed\n5. Add `taskman.py in-progress` to show tasks with progress > 0 and < 100\n\nShow me the updated code.",
|
||
|
|
|
||
|
|
"Let's add task templates:\n1. Create a Template class with name, title_template, default_priority, default_tags\n2. Add `taskman.py template add \"bug\" --title \"Bug: \" --priority high --tags bug`\n3. Add `taskman.py template list` to show all templates\n4. Add `taskman.py new bug \"login fails\"` creates task from template\n5. Store templates in the same JSON file\n\nShow me the updated code.",
|
||
|
|
|
||
|
|
"Let's add collaboration features:\n1. Add assigned_to field to Task (string, username)\n2. Add `taskman.py assign <id> @username` to assign\n3. Add `taskman.py mine` to show tasks assigned to current user\n4. Add `taskman.py unassign <id>` to remove assignment\n5. Add `--assign` option when creating tasks\n\nShow me the updated code.",
|
||
|
|
|
||
|
|
"Let's add task estimation:\n1. Add estimated_minutes field to Task (optional int)\n2. Add `taskman.py estimate <id> 120` to set estimate\n3. When showing tasks, display estimate vs actual time spent\n4. Add `taskman.py stats` to show estimation accuracy\n5. Show tasks that exceeded estimate in red\n\nShow me the updated code.",
|
||
|
|
|
||
|
|
"RECALL: Before we keep adding features, I want to do a consistency check. Go back to the original Task class from the very beginning of our conversation. What were the exact fields and their types? I want to compare that to what Task looks like now and make sure we haven't accidentally dropped or renamed any original fields during all these updates. Show me a side-by-side comparison.",
|
||
|
|
|
||
|
|
"RECALL: Also, look back at the save_to_file and load_from_file methods we wrote early on. We've added a ton of fields since then (tags, dependencies, notes, templates, etc). Are those serialization methods still correctly handling ALL the new fields, or did we break backwards compatibility with old JSON files? Show me exactly what the JSON structure looked like originally vs now.",
|
||
|
|
|
||
|
|
"Let's add a dashboard command:\n1. `taskman.py dashboard` shows a summary view\n2. Show total tasks, completed, in-progress, overdue\n3. Show tasks due today and tomorrow\n4. Show tasks by priority breakdown\n5. Show recently completed tasks (last 7 days)\n\nShow me the updated code.",
|
||
|
|
|
||
|
|
"Now let's add a REST API using Flask:\n1. Create Flask app with endpoints for CRUD operations\n2. GET /tasks - list all tasks\n3. POST /tasks - create a new task\n4. GET /tasks/<id> - get a specific task\n5. PUT /tasks/<id> - update a task\n6. DELETE /tasks/<id> - delete a task\n\nShow me the complete Flask app with all endpoints.",
|
||
|
|
|
||
|
|
"Add authentication to the Flask API:\n1. Use JWT tokens for authentication\n2. Add /login endpoint that returns a token\n3. Protect all task endpoints - require valid token\n4. Add user_id to tasks - each user sees only their tasks\n5. Add rate limiting - 100 requests per minute per user\n\nShow me the updated Flask app with authentication.",
|
||
|
|
|
||
|
|
"RECALL: Wait — the CLI we built earlier doesn't use any authentication. Now that we've added JWT auth to the API, go back and look at the exact argparse commands and subcommands we defined. I need to know: which CLI commands would need to be updated to send auth tokens if we point the CLI at the API instead of the local JSON file? List every subcommand name from the original CLI setup.",
|
||
|
|
|
||
|
|
"Add WebSocket support for real-time updates:\n1. Use Flask-SocketIO for WebSocket support\n2. Emit 'task_created' event when a task is created\n3. Emit 'task_updated' event when a task is updated\n4. Emit 'task_deleted' event when a task is deleted\n5. Clients can subscribe to task updates\n\nShow me the complete implementation.",
|
||
|
|
|
||
|
|
"Add a database backend using SQLAlchemy:\n1. Define Task model with all fields we've added\n2. Define User model for authentication\n3. Replace in-memory storage with database\n4. Add migrations using Flask-Migrate\n5. Support both SQLite (dev) and PostgreSQL (prod)\n\nShow me the complete database models and updated Flask app.",
|
||
|
|
|
||
|
|
"RECALL: The time tracking feature we built earlier writes the currently running task to a .taskman_running file on disk. But now we have a database backend. Go back to the exact time tracking implementation — what was the file format of .taskman_running and how did start/stop work? I need to migrate that logic to use the database instead, but I want to keep backward compatibility with any existing .taskman_running files.",
|
||
|
|
|
||
|
|
"RECALL: We stored tags as a set internally for uniqueness in the original Task class. Now with SQLAlchemy, how are we representing tags? Go back to the original tags implementation and tell me the exact internal storage approach we used, then show me if the database model preserves that uniqueness constraint or if we lost it.",
|
||
|
|
|
||
|
|
"Add unit tests using pytest:\n1. Test all API endpoints\n2. Test authentication flow\n3. Test task CRUD operations\n4. Test with different users\n5. Achieve at least 90% code coverage\n\nShow me the complete test suite.",
|
||
|
|
|
||
|
|
"Add a background task scheduler using Celery:\n1. Set up Celery with Redis as broker\n2. Add a task that sends daily email reminders for overdue tasks\n3. Add a task that auto-archives completed tasks older than 30 days\n4. Add a task that checks for recurring tasks and creates new instances\n5. Add CLI commands to trigger tasks manually\n\nShow me the complete Celery setup and tasks.",
|
||
|
|
|
||
|
|
"RECALL: The recurring task feature we built earlier had specific logic for what happens when you complete a recurring task — it creates a new task with the next occurrence date. Go back to that exact implementation. Does the Celery task for recurring tasks duplicate that logic, or does it work differently? I want to make sure we don't accidentally create double tasks if both the completion handler AND the Celery job fire.",
|
||
|
|
|
||
|
|
"Add a CLI dashboard using rich library:\n1. Create an interactive terminal dashboard\n2. Show task statistics with progress bars\n3. Show overdue tasks in red\n4. Show upcoming deadlines with countdown\n5. Add keyboard shortcuts to navigate and manage tasks\n\nShow me the complete CLI dashboard.",
|
||
|
|
|
||
|
|
"RECALL: In our original color-coded CLI output, we used specific ANSI color codes for priority levels — red for high, yellow for medium, green for low. What were the exact escape sequences or color function calls we used? I want the rich library dashboard to use the exact same colors for consistency. Also, what was the exact format string for the progress bar (the [=====> ] style)? I want to replicate it.",
|
||
|
|
|
||
|
|
"Add export functionality for the API:\n1. Export tasks to CSV format\n2. Export tasks to Excel format using openpyxl\n3. Export tasks to PDF report using reportlab\n4. Add filtering options for exports\n5. Add scheduled report generation\n\nShow me the complete export implementation.",
|
||
|
|
|
||
|
|
"RECALL: We built a CLI export feature much earlier that supported CSV, markdown, and JSON formats. Go back to that implementation. What exact columns/fields did we include in the CSV export? The API export we just built needs to match that column order exactly so that files from either export are interchangeable. Show me the original column list.",
|
||
|
|
|
||
|
|
"Add integration with external services:\n1. Slack integration - post notifications to a channel\n2. Email notifications using SendGrid\n3. Calendar sync - add tasks with due dates to Google Calendar\n4. GitHub integration - create issues from tasks\n5. Make integrations configurable per user\n\nShow me the complete integration code.",
|
||
|
|
|
||
|
|
"Add a mobile-responsive web UI using React:\n1. Create React app with TypeScript\n2. Add components for task list, task detail, task form\n3. Implement all CRUD operations via API calls\n4. Add real-time updates using Socket.IO client\n5. Add authentication with JWT tokens\n6. Use Material-UI for styling\n\nShow me the complete React app structure and key components.",
|
||
|
|
|
||
|
|
"Add a desktop application using Electron:\n1. Wrap the React app in Electron\n2. Add native notifications\n3. Add system tray icon with quick actions\n4. Add keyboard shortcuts for common actions\n5. Support offline mode with local storage sync\n\nShow me the Electron main process and preload scripts.",
|
||
|
|
|
||
|
|
"Add performance optimizations:\n1. Add Redis caching for frequently accessed tasks\n2. Implement pagination for task lists\n3. Add database indexes for common queries\n4. Implement lazy loading for task details\n5. Add request compression\n\nShow me all the performance optimizations.",
|
||
|
|
|
||
|
|
"Add audit logging:\n1. Log all task changes with user, timestamp, old value, new value\n2. Create AuditLog table in database\n3. Add API endpoint to view audit history for a task\n4. Add ability to undo changes from audit log\n5. Export audit logs for compliance\n\nShow me the complete audit logging system.",
|
||
|
|
|
||
|
|
"RECALL: We built an undo system much earlier in the CLI that tracked the last 10 actions in memory. Now we have an audit log that also supports undoing changes. Go back to the original undo implementation. What was the exact data structure we used to store undo actions? What action types did we track? I need to make sure the audit log's undo capability is a proper superset that covers all the same cases the CLI undo handled.",
|
||
|
|
|
||
|
|
"Add multi-tenancy support:\n1. Add Organization model - each org has its own tasks\n2. Add organization-level settings\n3. Add user roles within organization (admin, member, viewer)\n4. Add ability to invite users to organization\n5. Add organization-level billing\n\nShow me the multi-tenancy implementation.",
|
||
|
|
|
||
|
|
"Add an AI assistant feature:\n1. Integrate with OpenAI API\n2. Allow users to ask questions about their tasks in natural language\n3. AI can suggest task priorities based on deadlines\n4. AI can generate task descriptions from brief notes\n5. AI can identify duplicate or similar tasks\n\nShow me the AI assistant implementation.",
|
||
|
|
|
||
|
|
"Add a Kanban board view:\n1. Create columns for each status (To Do, In Progress, Done)\n2. Allow drag-and-drop between columns\n3. Auto-move tasks based on progress field\n4. Allow custom columns per organization\n5. Add WIP limits per column\n\nShow me the Kanban board implementation for both backend and frontend.",
|
||
|
|
|
||
|
|
"RECALL: The progress indicator feature we built early on auto-marks a task as completed when progress hits 100. The Kanban board auto-moves tasks based on progress. Go back to the original progress implementation — what exact threshold values and status transitions did we define? I need to make sure the Kanban auto-move rules don't conflict with the progress auto-complete. If progress=100 triggers completed AND a Kanban column move, what's the correct order of operations?",
|
||
|
|
|
||
|
|
"Add time tracking with detailed reporting:\n1. Track time per task with start/stop\n2. Allow manual time entry\n3. Generate time reports by user, project, date range\n4. Add billable/non-billable time tracking\n5. Export timesheets to CSV/PDF\n\nShow me the complete time tracking system.",
|
||
|
|
|
||
|
|
"Add project support:\n1. Create Project model with name, description, deadline\n2. Tasks belong to projects\n3. Add project-level dashboards\n4. Add project-level permissions\n5. Add Gantt chart view for project timeline\n\nShow me the project management implementation.",
|
||
|
|
|
||
|
|
"Add a commenting system:\n1. Allow comments on tasks\n2. Support markdown in comments\n3. Add @mentions that send notifications\n4. Allow file attachments on comments\n5. Add comment threading\n\nShow me the commenting system.",
|
||
|
|
|
||
|
|
"RECALL: We built a TaskNote class very early in the conversation with id, task_id, content, and created_at fields. Now we're building a full commenting system. Go back to the original TaskNote implementation. What was the exact class definition and how were notes stored in the JSON file? I need to write a migration that converts all existing TaskNotes into the new Comment format without losing data. Show me the original structure so I can map fields correctly.",
|
||
|
|
|
||
|
|
"Final polish and documentation:\n1. Add comprehensive API documentation using OpenAPI/Swagger\n2. Add inline code comments\n3. Create a README with installation and usage\n4. Add a CONTRIBUTING.md for open source\n5. Create a docker-compose.yml for easy deployment\n\nShow me the final documentation and docker setup.",
|
||
|
|
|
||
|
|
"Let's implement a comprehensive notification system:\n1. Create Notification model with type, message, read status, created_at\n2. Add in-app notifications that appear in real-time\n3. Add email notifications for important events\n4. Add push notifications for mobile users\n5. Allow users to configure notification preferences per type\n6. Add notification digest - daily or weekly summary\n7. Add notification templates with variable substitution\n8. Add notification batching to avoid spam\n9. Add notification history with pagination\n10. Add mark all as read functionality\n\nShow me the complete notification system with all models, API endpoints, and background workers.",
|
||
|
|
|
||
|
|
"Add comprehensive search functionality:\n1. Full-text search on task titles and descriptions\n2. Search by tags, priority, status\n3. Search by date ranges (created, due, completed)\n4. Search by assignee or project\n5. Add search suggestions as user types\n6. Add saved searches that can be reused\n7. Add search filters that can be combined\n8. Add search history\n9. Export search results\n10. Add Elasticsearch integration for scalability\n\nShow me the complete search implementation.",
|
||
|
|
|
||
|
|
"RECALL: We built a search feature much earlier in the CLI that supported glob-style wildcard patterns like \"bug*\". Go back to that implementation. What was the exact matching logic — did we use fnmatch, regex, or a custom implementation? The new Elasticsearch search needs a compatibility mode that accepts the same query syntax so existing CLI users aren't confused. Show me the original search code.",
|
||
|
|
|
||
|
|
"Add task templates and automation:\n1. Create TaskTemplate model with all task fields\n2. Allow creating tasks from templates\n3. Add variables in templates (e.g., {{due_date+7days}})\n4. Add automation rules - trigger actions on events\n5. Add conditions for automation (if task is high priority and overdue)\n6. Add actions (send notification, change status, reassign)\n7. Add scheduled automations (run daily at specific time)\n8. Add automation logs\n9. Allow users to enable/disable automations\n10. Add automation templates for common workflows\n\nShow me the complete automation system.",
|
||
|
|
|
||
|
|
"RECALL: We built a Template class earlier with name, title_template, default_priority, and default_tags. Now we have a TaskTemplate model with variables like {{due_date+7days}}. Go back to the original Template class. What fields did it have, and how did the `taskman.py new bug \"login fails\"` command use it to create tasks? I need the automation system's template variables to be backward-compatible with the original template format.",
|
||
|
|
|
||
|
|
"Implement a robust permission system:\n1. Create Permission model with resource, action, conditions\n2. Create Role model with many-to-many permissions\n3. Add default roles (admin, manager, member, viewer)\n4. Allow custom roles per organization\n5. Implement permission checks on all API endpoints\n6. Add permission inheritance (project > task)\n7. Add temporary permissions with expiration\n8. Add permission audit logs\n9. Add API to check user permissions\n10. Add bulk permission updates\n\nShow me the complete permission system.",
|
||
|
|
|
||
|
|
"Add a reporting and analytics dashboard:\n1. Create report model with type, parameters, schedule\n2. Add task completion rate over time chart\n3. Add average time to completion chart\n4. Add tasks by priority breakdown\n5. Add tasks by assignee workload\n6. Add overdue tasks trend\n7. Add project health indicators\n8. Add custom report builder\n9. Add scheduled report generation (daily, weekly, monthly)\n10. Add report export to PDF with charts\n\nShow me the complete reporting system.",
|
||
|
|
|
||
|
|
"Add data import functionality:\n1. Import tasks from CSV files\n2. Import tasks from JSON files\n3. Import from other task managers (Trello, Asana, Jira)\n4. Add field mapping during import\n5. Add validation and error reporting\n6. Add duplicate detection during import\n7. Add preview before import\n8. Add rollback capability for imports\n9. Add import templates\n10. Add scheduled imports from external sources\n\nShow me the complete import system.",
|
||
|
|
|
||
|
|
"RECALL: The import system needs to handle our own JSON format for round-tripping. Go back to the save_to_file method and the JSON structure we defined. What were the exact top-level keys in our JSON file? I remember we had a \"notes\" key added later and a \"templates\" key. List every top-level key the JSON file can have so the importer validates them all correctly.",
|
||
|
|
|
||
|
|
"Implement task relationships:\n1. Add related_tasks field for linking tasks\n2. Add relationship types (blocks, blocked-by, related, duplicate-of)\n3. Show related tasks in task detail view\n4. Add cascade delete for certain relationships\n5. Add relationship validation (no circular blocks)\n6. Add relationship suggestions based on content similarity\n7. Add graph view of task relationships\n8. Add relationship impact analysis\n9. Add bulk relationship updates\n10. Add relationship history\n\nShow me the complete task relationships feature.",
|
||
|
|
|
||
|
|
"RECALL: We already have a depends_on field on Task from early in the conversation that stores a list of task IDs, plus a complete_task method that blocks completion if dependencies aren't met. Now we're adding a full relationship system with types. Go back to the original dependency implementation. What was the exact validation logic in complete_task? I need to migrate depends_on entries into the new relationship model as 'blocked-by' type without breaking the CLI `blocked` command.",
|
||
|
|
|
||
|
|
"Add a knowledge base integration:\n1. Create Article model for knowledge base entries\n2. Link articles to tasks\n3. Add article suggestions when creating tasks\n4. Add article search\n5. Add article categories and tags\n6. Add article versioning\n7. Add article ratings\n8. Add \"was this helpful?\" feedback\n9. Add article analytics (views, helpfulness)\n10. Add article templates\n\nShow me the knowledge base implementation.",
|
||
|
|
|
||
|
|
"Add a chat/messaging system:\n1. Create ChatRoom model\n2. Create Message model\n3. Add direct messages between users\n4. Add channel messages (per project, per team)\n5. Add @mentions in messages\n6. Add message search\n7. Add message threading\n8. Add file attachments in messages\n9. Add message reactions\n10. Add unread message tracking\n\nShow me the complete messaging system.",
|
||
|
|
|
||
|
|
"Implement task versioning:\n1. Store all task changes as versions\n2. Show version history with diff view\n3. Allow restoring to any previous version\n4. Add version comparison view\n5. Add version comments\n6. Add version tagging (milestone versions)\n7. Limit versions stored per task\n8. Add bulk version operations\n9. Add version export\n10. Add version timeline view\n\nShow me the task versioning implementation.",
|
||
|
|
|
||
|
|
"RECALL: We now have three separate systems that track changes to tasks: (1) the undo history from early on, (2) the audit log, and (3) this new versioning system. Go back to the original undo implementation and the audit log implementation. What data does each one store? I need to consolidate — the versioning system should be the single source of truth, and undo/audit should read from it. Show me the original data structures so I can plan the migration.",
|
||
|
|
|
||
|
|
"Now let's build the React frontend. Start with the project setup and core components:\n\n1. Create a React app with TypeScript\n2. Set up the project structure with folders for components, hooks, services, types, utils\n3. Create TypeScript interfaces for Task, User, Project, Comment\n4. Set up React Router with routes for /dashboard, /tasks, /projects, /settings\n5. Create an API service layer with axios for all backend endpoints\n6. Set up authentication context with JWT token handling\n7. Create a Layout component with sidebar navigation\n8. Create a Header component with user menu and notifications bell\n\nShow me the complete project setup including package.json, tsconfig.json, and all the initial files.",
|
||
|
|
|
||
|
|
"RECALL: The TypeScript interfaces for Task need to include every field we've added throughout the conversation. Go back to the very first Task class and then trace every field addition we made: priority, due_date, tags, depends_on, recurrence, next_occurrence, time_spent, parent_id, progress, assigned_to, estimated_minutes. Did I miss any? Check the original implementations and give me the complete list so the TypeScript interface is accurate.",
|
||
|
|
|
||
|
|
"Create the TaskList component with full functionality:\n\n1. Fetch tasks from API with loading and error states\n2. Display tasks in a responsive grid layout\n3. Each task card shows: title, description preview, priority badge, due date, assignee avatar\n4. Add filtering by status (all, active, completed), priority, and assignee\n5. Add sorting by due date, priority, created date\n6. Add search input that filters tasks in real-time\n7. Add pagination with 20 tasks per page\n8. Add \"New Task\" button that opens a modal\n9. Clicking a task navigates to task detail page\n10. Add bulk selection with checkboxes and bulk actions (complete, delete, assign)\n\nShow me the complete TaskList.tsx component with all styles using Material-UI.",
|
||
|
|
|
||
|
|
"Create the TaskDetail component with all features:\n\n1. Fetch and display full task details\n2. Show all task fields: title, description, priority, status, due date, tags, assignee, time spent, progress\n3. Add edit mode for all editable fields with inline editing\n4. Show subtasks as nested list with completion checkboxes\n5. Show dependencies with links to related tasks\n6. Show comments section with add comment form\n7. Show activity history/timeline\n8. Add file attachments section with drag-drop upload\n9. Add time tracking controls (start/stop timer)\n10. Add action buttons: Edit, Delete, Complete, Add Subtask, Add Dependency\n\nShow me the complete TaskDetail.tsx with all subcomponents.",
|
||
|
|
|
||
|
|
"Create the TaskForm component for creating and editing tasks:\n\n1. Form with all task fields: title, description, priority, status, due date, tags\n2. Rich text editor for description (using react-quill or similar)\n3. Date picker for due date\n4. Multi-select for tags with ability to create new tags\n5. Dropdown for priority with colored badges\n6. Dropdown for assignee with user search\n7. Multi-select for dependencies showing task titles\n8. File upload for attachments with preview\n9. Form validation with error messages\n10. Save as draft and publish buttons\n\nShow me the complete TaskForm.tsx with validation using react-hook-form.",
|
||
|
|
|
||
|
|
"RECALL: The TaskForm needs proper validation. Go back to the original Task class — what were the exact constraints? Title was required, but what was the max length? Priority had to be one of high/medium/low — was that enforced with an enum or just a string check? What date format did we use for due_date in the CLI? I need the React form validation rules to exactly match the backend's validation.",
|
||
|
|
|
||
|
|
"Create the Dashboard component with data visualizations:\n\n1. Summary cards: Total tasks, Completed, In Progress, Overdue\n2. Bar chart showing tasks by priority\n3. Pie chart showing tasks by status\n4. Line chart showing task completion over time\n5. Upcoming deadlines list (next 7 days)\n6. Recently completed tasks list\n7. Activity feed showing recent changes\n8. Quick add task input at top\n9. Team workload distribution chart\n10. Project progress overview\n\nShow me the complete Dashboard.tsx using recharts for visualizations.",
|
||
|
|
|
||
|
|
"Create the ProjectList and ProjectDetail components:\n\n1. ProjectList shows all projects as cards with progress bars\n2. Each project card: name, description, deadline, member avatars, task count\n3. Create new project modal with form\n4. ProjectDetail shows project overview and all project tasks\n5. Add Kanban board view for project tasks\n6. Add Gantt chart view for project timeline\n7. Project settings page for editing project details\n8. Project members management with role assignment\n9. Project statistics and charts\n10. Export project data as PDF/CSV\n\nShow me both components with full functionality.",
|
||
|
|
|
||
|
|
"Create a full Kanban board component:\n\n1. Columns for each status: Backlog, To Do, In Progress, Review, Done\n2. Drag and drop cards between columns using react-beautiful-dnd\n3. Each card shows task preview with priority indicator\n4. Click card to open detail modal\n5. Add new task button in each column\n6. Column header shows task count\n7. WIP limits with warning when exceeded\n8. Swimlanes option to group by assignee\n9. Quick edit on card hover\n10. Filter and search within board\n\nShow me the complete KanbanBoard.tsx with drag-and-drop.",
|
||
|
|
|
||
|
|
"Create the Calendar view component:\n\n1. Full calendar view using react-big-calendar\n2. Tasks shown on their due dates\n3. Color coding by priority and project\n4. Click task to open detail modal\n5. Drag tasks to reschedule\n6. Month, week, and day views\n7. Filter by project, assignee, priority\n8. Show overdue tasks in red\n9. Add task directly from calendar click\n10. Mini calendar in sidebar for navigation\n\nShow me the complete Calendar.tsx with all features.",
|
||
|
|
|
||
|
|
"RECALL: The calendar needs to show recurring tasks properly. Go back to the recurring task implementation. When a daily recurring task is completed, does it create the next occurrence from today's date or from the original due_date + interval? What exactly is stored in the next_occurrence field? The calendar view needs to show future occurrences as ghost entries, so I need to understand the exact recurrence calculation logic.",
|
||
|
|
|
||
|
|
"Create the Notifications system:\n\n1. Notifications dropdown in header\n2. Real-time notifications using WebSocket/SSE\n3. Notification types: task assigned, comment, due soon, mentioned\n4. Mark as read functionality\n5. Mark all as read button\n6. Notification preferences page\n7. Email digest settings\n8. Push notification support\n9. Notification history page with pagination\n10. Unread count badge\n\nShow me NotificationsDropdown.tsx and NotificationSettings.tsx.",
|
||
|
|
|
||
|
|
"Create the User Profile and Settings pages:\n\n1. Profile page with avatar upload\n2. Edit name, email, timezone, bio\n3. Change password form\n4. Notification preferences\n5. Theme settings (light/dark mode)\n6. Language preferences\n7. Connected accounts (Google, GitHub, etc.)\n8. API token management\n9. Session management (view active sessions, logout)\n10. Account deletion with confirmation\n\nShow me ProfilePage.tsx and SettingsPage.tsx.",
|
||
|
|
|
||
|
|
"Create the Search functionality with advanced filters:\n\n1. Global search bar in header with keyboard shortcut (Cmd+K)\n2. Search across tasks, projects, comments\n3. Show results grouped by type\n4. Advanced filter builder UI\n5. Save search filters\n6. Search history\n7. Recent searches\n8. Search suggestions as you type\n9. Filter by date range, assignee, project, tags\n10. Export search results\n\nShow me GlobalSearch.tsx and SearchResults.tsx.",
|
||
|
|
|
||
|
|
"Create the Comments and Activity components:\n\n1. Comment list with threading support\n2. Rich text editor for comments\n3. @mention users with autocomplete\n4. Edit and delete own comments\n5. Reply to comments\n6. React to comments with emojis\n7. Attachment support in comments\n8. Activity timeline showing all task changes\n9. Filter activity by type\n10. Show diffs for field changes\n\nShow me CommentSection.tsx and ActivityTimeline.tsx.",
|
||
|
|
|
||
|
|
"Create the Time Tracking components:\n\n1. Timer component with start/stop/pause\n2. Manual time entry form\n3. Time log list for a task\n4. Daily/weekly timesheet view\n5. Time summary by project\n6. Billable vs non-billable toggle\n7. Time estimates vs actual comparison\n8. Export timesheet as CSV/PDF\n9. Timer in browser tab title\n10. Idle detection warning\n\nShow me TimeTracker.tsx and Timesheet.tsx.",
|
||
|
|
|
||
|
|
"RECALL: The time tracking components need to match the backend. Go back to the original CLI time tracking implementation. What unit did we use for time_spent — seconds, minutes, or milliseconds? And the estimation feature used estimated_minutes. So we have time_spent in one unit and estimates in another. What's the exact conversion we need in the frontend display? Check the original implementations and confirm the units.",
|
||
|
|
|
||
|
|
"Create the Reports and Analytics pages:\n\n1. Overview dashboard with key metrics\n2. Team productivity report\n3. Task completion trends chart\n4. Project health indicators\n5. Time tracking reports\n6. Custom report builder\n7. Schedule reports to run automatically\n8. Export reports as PDF/Excel\n9. Share report link\n10. Comparison reports (week over week, etc)\n\nShow me ReportsPage.tsx and CustomReportBuilder.tsx.",
|
||
|
|
|
||
|
|
"Create the Team Management components:\n\n1. Team members list with roles\n2. Invite new member form with email\n3. Role assignment dropdown\n4. Remove member with confirmation\n5. Team settings page\n6. Team permissions matrix\n7. Team activity log\n8. Workload distribution view\n9. Team performance metrics\n10. Bulk invite via CSV upload\n\nShow me TeamMembers.tsx and TeamSettings.tsx.",
|
||
|
|
|
||
|
|
"Create the Mobile Responsive design:\n\n1. Responsive sidebar that collapses to hamburger\n2. Mobile-friendly task cards\n3. Touch-friendly drag and drop\n4. Pull to refresh on lists\n5. Swipe actions on task cards (complete, delete)\n6. Bottom navigation for mobile\n7. Full-screen modals on mobile\n8. Touch-friendly date/time pickers\n9. Mobile-optimized forms\n10. Offline mode indicator\n\nShow me the responsive CSS and mobile-specific components.",
|
||
|
|
|
||
|
|
"Create the File Attachments components:\n\n1. File upload with drag-drop\n2. Multiple file upload support\n3. Progress indicator for uploads\n4. File preview for images, PDFs\n5. File type icons for different formats\n6. Download file button\n7. Delete attachment with confirmation\n8. File size display\n9. Image gallery view\n10. File search and filter\n\nShow me FileUpload.tsx and AttachmentList.tsx.",
|
||
|
|
|
||
|
|
"Create the Tags and Labels management:\n\n1. Tags list page with color swatches\n2. Create new tag with color picker\n3. Edit tag name and color\n4. Delete tag with task count warning\n5. Merge tags functionality\n6. Tag usage statistics\n7. Suggested tags based on task content\n8. Tag groups/categories\n9. Bulk tag operations\n10. Export/import tags\n\nShow me TagsPage.tsx and TagPicker.tsx.",
|
||
|
|
|
||
|
|
"Create the Keyboard Shortcuts system:\n\n1. Global shortcut handler\n2. Cmd+K for search\n3. Cmd+N for new task\n4. Cmd+/ for shortcuts help\n5. Arrow keys for navigation\n6. Enter to open selected item\n7. Escape to close modals\n8. Custom shortcut configuration\n9. Shortcuts help modal\n10. Conflict detection for shortcuts\n\nShow me the shortcuts system and help modal.",
|
||
|
|
|
||
|
|
"Create the Dark Mode theme system:\n\n1. Theme provider with context\n2. Dark and light theme definitions\n3. System preference detection\n4. Toggle in settings\n5. Persist preference in localStorage\n6. Smooth transition between themes\n7. Custom theme colors option\n8. High contrast mode support\n9. Theme preview in settings\n10. All components styled for both themes\n\nShow me the theme system with all MUI theme overrides.",
|
||
|
|
|
||
|
|
"Create the Onboarding flow for new users:\n\n1. Welcome modal on first login\n2. Step-by-step tour of features\n3. Create first task prompt\n4. Invite team members prompt\n5. Set up profile prompt\n6. Keyboard shortcuts introduction\n7. Feature discovery tooltips\n8. Progress indicator for onboarding\n9. Skip option\n10. Restart onboarding in settings\n\nShow me OnboardingFlow.tsx with all steps.",
|
||
|
|
|
||
|
|
"Create the Integrations settings page:\n\n1. List available integrations (Slack, GitHub, Google Calendar, etc)\n2. Connect/disconnect buttons for each\n3. Integration-specific settings forms\n4. OAuth flow handling\n5. Sync status indicators\n6. Configure what syncs\n7. Integration activity log\n8. Test connection button\n9. Revoke access\n10. Add custom webhook integration\n\nShow me IntegrationsPage.tsx with integration cards.",
|
||
|
|
|
||
|
|
"Create the Custom Fields functionality:\n\n1. Custom field definitions (text, number, date, dropdown, checkbox)\n2. Add custom field form\n3. Custom field display in task detail\n4. Edit custom field values\n5. Custom field in task list columns\n6. Filter by custom field\n7. Required vs optional fields\n8. Field validation rules\n9. Custom field groups\n10. Import/export field definitions\n\nShow me CustomFields.tsx and CustomFieldEditor.tsx.",
|
||
|
|
|
||
|
|
"Create the Task Templates UI:\n\n1. Templates list page\n2. Create template from existing task\n3. Create new template form\n4. Template preview\n5. Use template to create task\n6. Edit template\n7. Delete template\n8. Template categories\n9. Template sharing\n10. Default template selection\n\nShow me TemplatesPage.tsx and TemplatePicker.tsx.",
|
||
|
|
|
||
|
|
"Create the Audit Log page:\n\n1. Activity log table with sorting\n2. Filter by user, action type, date range\n3. Search in log entries\n4. Detail view for each log entry\n5. Export audit log\n6. Show changed fields with before/after\n7. Pagination with date jump\n8. Real-time log updates\n9. IP address and user agent display\n10. Bulk export for compliance\n\nShow me AuditLog.tsx with all features.",
|
||
|
|
|
||
|
|
"Create the Billing and Subscription pages:\n\n1. Current plan display\n2. Plan comparison table\n3. Upgrade/downgrade flows\n4. Payment method management\n5. Invoice history\n6. Usage limits display\n7. Seat management\n8. Promo code input\n9. Cancel subscription flow\n10. Billing contact information\n\nShow me BillingPage.tsx and PricingPage.tsx.",
|
||
|
|
|
||
|
|
"Create the Error Handling and Loading states:\n\n1. Global error boundary component\n2. Error fallback UI with retry\n3. Network error handling\n4. 404 page\n5. Loading skeletons for all components\n6. Skeleton pulse animation\n7. Toast notifications for errors\n8. Offline indicator banner\n9. Rate limit handling\n10. Session expired handling with re-login\n\nShow me ErrorBoundary.tsx, LoadingSkeleton.tsx, and Toast.tsx.",
|
||
|
|
|
||
|
|
"RECALL: The error handling needs to account for the specific rate limiting we set up in the Flask API. Go back to the authentication implementation — what was the exact rate limit? Was it 100 per minute per user, or did we change it? What HTTP status code and response body does the API return when rate-limited? The frontend error handler needs to parse that exact response format to show the user a proper retry countdown.",
|
||
|
|
|
||
|
|
"Create the Accessibility features:\n1. ARIA labels on all interactive elements\n2. Keyboard navigation throughout\n3. Focus management in modals\n4. Screen reader announcements\n5. High contrast mode\n6. Reduced motion support\n7. Focus visible indicators\n8. Skip to content link\n9. Alt text for images\n10. Accessible drag and drop\n\nShow me accessibility implementations across components.",
|
||
|
|
|
||
|
|
"Create the Performance Optimizations:\n\n1. React.memo for expensive components\n2. useMemo and useCallback usage\n3. Virtual scrolling for long lists\n4. Code splitting with React.lazy\n5. Image lazy loading\n6. Debounced search input\n7. Optimistic UI updates\n8. Service worker for caching\n9. Bundle size optimization\n10. Performance monitoring\n\nShow me the optimization implementations.",
|
||
|
|
|
||
|
|
"Create the Testing setup:\n\n1. Jest configuration\n2. React Testing Library setup\n3. Unit tests for utility functions\n4. Component tests for TaskList\n5. Component tests for TaskDetail\n6. Integration tests for task creation flow\n7. Mock API handlers with MSW\n8. E2E test setup with Cypress\n9. Test coverage configuration\n10. CI/CD test running\n\nShow me the test setup and sample tests.",
|
||
|
|
|
||
|
|
"Create the Internationalization (i18n) setup:\n\n1. React-i18next configuration\n2. Language files structure\n3. Translation keys for all UI text\n4. Language selector component\n5. RTL support for Arabic/Hebrew\n6. Date/number formatting per locale\n7. Pluralization rules\n8. Missing translation fallback\n9. Language-specific content\n10. Lazy load language files\n\nShow me the complete i18n setup with sample translations.",
|
||
|
|
|
||
|
|
"Create the PWA features:\n\n1. Service worker registration\n2. Manifest.json configuration\n3. Offline task creation\n4. Background sync for offline actions\n5. Push notification handling\n6. Install prompt banner\n7. App icons for all platforms\n8. Splash screen configuration\n9. Cache strategies\n10. Update notification\n\nShow me the complete PWA implementation.",
|
||
|
|
|
||
|
|
"Create the CLI Dashboard using Ink (React for CLI):\n\n1. Ink project setup with TypeScript\n2. Task list view in terminal\n3. Task detail view\n4. Add task form\n5. Keyboard navigation\n6. Color-coded output\n7. Progress bars\n8. Live refresh\n9. Configuration file\n10. Cross-platform support\n\nShow me the complete CLI dashboard implementation.",
|
||
|
|
|
||
|
|
"Create the API Documentation:\n\n1. OpenAPI/Swagger specification\n2. All endpoints documented\n3. Request/response schemas\n4. Authentication documentation\n5. Error codes reference\n6. Rate limiting documentation\n7. Webhook documentation\n8. SDK usage examples\n9. Postman collection\n10. Changelog\n\nShow me the OpenAPI spec and documentation.",
|
||
|
|
|
||
|
|
"RECALL: The API docs need to document every field on every model. Go back through our entire conversation — starting from the original Task class with its 5 fields, through every addition we made. I need a complete, canonical field list for the Task model with the field name, type, default value, and which turn we added it. This is the schema reference for the API docs and it needs to be 100% accurate to what we implemented.",
|
||
|
|
|
||
|
|
"Create the Docker deployment setup:\n\n1. Dockerfile for API\n2. Dockerfile for frontend\n3. docker-compose.yml\n4. Development docker-compose\n5. Production docker-compose\n6. Environment variable configuration\n7. Volume management\n8. Health check endpoints\n9. Logging configuration\n10. Backup/restore scripts\n\nShow me all Docker configuration files.",
|
||
|
|
|
||
|
|
"Create the Kubernetes deployment:\n\n1. Deployment YAML for API\n2. Deployment YAML for frontend\n3. Service definitions\n4. Ingress configuration\n5. ConfigMap for env vars\n6. Secret management\n7. Horizontal Pod Autoscaler\n8. Resource limits\n9. Liveness/readiness probes\n10. Helm chart\n\nShow me the complete Kubernetes setup.",
|
||
|
|
|
||
|
|
"Create the CI/CD pipeline:\n\n1. GitHub Actions workflow\n2. Build and test stages\n3. Docker image building\n4. Push to container registry\n5. Deploy to staging\n6. Run E2E tests\n7. Deploy to production\n8. Rollback capability\n9. Notification on failure\n10. Version tagging\n\nShow me the complete CI/CD pipeline configuration.",
|
||
|
|
|
||
|
|
"Create the Monitoring and Observability:\n\n1. Prometheus metrics endpoint\n2. Custom metrics for tasks\n3. Grafana dashboard configuration\n4. Log aggregation setup\n5. Error tracking with Sentry\n6. Performance monitoring\n7. Alert configuration\n8. Health check dashboard\n9. Uptime monitoring\n10. Custom dashboards\n\nShow me the monitoring setup.",
|
||
|
|
|
||
|
|
"Create the Security implementation:\n\n1. CSRF protection\n2. XSS prevention\n3. SQL injection prevention\n4. Rate limiting middleware\n5. Input validation\n6. Output sanitization\n7. Secure headers\n8. CORS configuration\n9. Secrets management\n10. Security audit logging\n\nShow me all security implementations.",
|
||
|
|
|
||
|
|
"RECALL: Before we finalize security, I need to do a full audit. Go back to every place we handle user input across the entire conversation: the original argparse CLI, the Flask API endpoints, the React forms. What input validation did we implement at each layer? I'm worried we have inconsistent validation — for example, does the CLI allow task titles longer than what the database column supports? Check the original implementations.",
|
||
|
|
|
||
|
|
"Final documentation and polish:\n\n1. Comprehensive README.md\n2. CONTRIBUTING.md guide\n3. Architecture diagram\n4. API changelog\n5. Migration guides\n6. FAQ document\n7. Video tutorial outline\n8. Security policy\n9. Code of conduct\n10. License file\n\nShow me all documentation files.",
|
||
|
|
|
||
|
|
"Now let's write comprehensive unit tests for the Task model with verbose output. Create a test file that:\n\n1. Tests Task creation with all fields\n2. Tests Task validation - title required, priority must be valid enum\n3. Tests is_overdue() method with various date scenarios\n4. Tests is_blocked() method with dependency scenarios\n5. Tests complete_task() with and without dependencies\n6. Tests to_dict() serialization\n7. Tests Task state transitions\n\nFor each test, print a verbose banner before and after with emojis, show the test data being used, print intermediate states, and show a summary table at the end. Use verbose assertions that print expected vs actual with colors.\n\nShow me the complete test file with all the verbose output formatting.",
|
||
|
|
|
||
|
|
"RECALL: These unit tests need to test is_overdue() and is_blocked(). Go back to the original implementations of those methods. What were the exact boolean conditions? For is_overdue, did we compare against datetime.now() or datetime.utcnow()? For is_blocked, did we check if ALL dependencies are completed or just ANY? I need the test assertions to match the exact logic we wrote.",
|
||
|
|
|
||
|
|
"Create comprehensive integration tests for TaskManager with verbose output:\n\n1. Test add_task creates task with auto-increment ID\n2. Test list_tasks with various filter combinations\n3. Test complete_task updates status and timestamps\n4. Test delete_task removes task and cleans up references\n5. Test save_to_file and load_from_file persistence\n6. Test undo functionality for each action type\n7. Test search with various patterns and filters\n8. Test concurrent operations\n\nEach test should:\n- Print a decorative header with test name\n- Show setup data in a formatted table\n- Log each operation with timestamp\n- Show state before and after each operation\n- Print detailed assertion messages with pass/fail indicators\n- Generate a final test report with timing, memory usage, and results\n\nShow me the complete integration test file.",
|
||
|
|
|
||
|
|
"Create comprehensive API endpoint tests with verbose request/response logging:\n\n1. Test GET /tasks with pagination, filtering, sorting\n2. Test POST /tasks with validation scenarios\n3. Test PUT /tasks/:id with partial updates\n4. Test DELETE /tasks/:id with cleanup verification\n5. Test authentication required on protected endpoints\n6. Test rate limiting kicks in after threshold\n7. Test error responses have correct format\n\nFor each test:\n- Print request details (method, URL, headers, body) in a formatted box\n- Print response details (status, headers, body) in a formatted box\n- Log timing for each request\n- Show database state before and after\n- Validate response schema with detailed error messages\n- Print a summary table at the end\n\nShow me the complete API test file.",
|
||
|
|
|
||
|
|
"Create comprehensive React component tests with verbose rendering output:\n\n1. Test TaskList renders tasks correctly\n2. Test TaskList filtering and sorting\n3. Test TaskList pagination\n4. Test TaskDetail displays all fields\n5. Test TaskDetail edit mode\n6. Test TaskForm validation\n7. Test TaskForm submission\n8. Test Dashboard shows correct statistics\n9. Test KanbanBoard drag and drop\n\nFor each test:\n- Print component tree structure\n- Log all props passed to component\n- Show rendered HTML with indentation\n- Log all user interactions\n- Show state changes after each action\n- Print accessibility tree\n- Generate visual diff of DOM changes\n- Summary report with render counts and timing\n\nShow me the complete component test file.",
|
||
|
|
|
||
|
|
"Create comprehensive database model tests with verbose SQL logging:\n\n1. Test Task model CRUD operations\n2. Test User model with password hashing\n3. Test Project model with relationships\n4. Test Comment model with threading\n5. Test cascade delete behavior\n6. Test unique constraints\n7. Test index performance\n8. Test transaction rollback\n9. Test concurrent access\n\nFor each test:\n- Print the SQL query being executed with formatting\n- Show query execution plan\n- Log query execution time\n- Show affected rows count\n- Display table state before and after\n- Print foreign key checks\n- Generate slow query report\n- Summary with query statistics\n\nShow me the complete database test file.",
|
||
|
|
|
||
|
|
"Create comprehensive WebSocket event tests with verbose logging:\n\n1. Test task_created event broadcasts to subscribers\n2. Test task_updated event with partial data\n3. Test task_deleted event cleanup\n4. Test user notifications delivered in real-time\n5. Test reconnection handling\n6. Test room join/leave\n7. Test event ordering\n8. Test backpressure handling\n\nFor each test:\n- Print connection lifecycle events\n- Log all messages sent/received with timestamps\n- Show subscriber counts at each step\n- Display event payload with pretty formatting\n- Log latency measurements\n- Show reconnection attempts\n- Generate message flow diagram (ASCII)\n- Summary with event statistics\n\nShow me the complete WebSocket test file.",
|
||
|
|
|
||
|
|
"RECALL: The WebSocket tests need to verify the exact event names and payload structures. Go back to the Flask-SocketIO implementation. What were the exact event names — was it 'task_created' or 'taskCreated' or 'task:created'? What fields were in each event payload? The test assertions need to match the exact strings and shapes from the original implementation.",
|
||
|
|
|
||
|
|
"Create comprehensive performance tests with detailed metrics:\n\n1. Test API response time under load\n2. Test database query performance with large datasets\n3. Test concurrent user handling\n4. Test memory usage during operations\n5. Test rendering performance for large lists\n6. Test bundle size and load time\n7. Test cache hit/miss ratios\n8. Test time to first byte\n\nFor each test:\n- Print detailed timing breakdown\n- Show percentile distribution (p50, p90, p99)\n- Display memory snapshots\n- Log CPU usage during test\n- Show operation count per second\n- Generate flame graph data\n- Compare against baseline\n- Detailed performance report\n\nShow me the complete performance test file.",
|
||
|
|
|
||
|
|
"Create comprehensive security tests with verbose vulnerability reporting:\n\n1. Test SQL injection prevention\n2. Test XSS attack prevention\n3. Test CSRF token validation\n4. Test authentication bypass attempts\n5. Test authorization boundary violations\n6. Test input validation edge cases\n7. Test session hijacking prevention\n8. Test rate limiting effectiveness\n9. Test secure header presence\n\nFor each test:\n- Print attack vector being tested\n- Show malicious input payload\n- Log system response\n- Display whether attack was blocked\n- Show vulnerability severity if found\n- Print remediation steps\n- Generate security scorecard\n- Summary with CVE references\n\nShow me the complete security test file.",
|
||
|
|
|
||
|
|
"RECALL: Final comprehensive review. Go back to the very first Task class from turn 1 and the very first TaskManager from turn 2. Compare them to what we have now. I want to see: (1) the original method signatures for add_task, list_tasks, complete_task, delete_task vs their current signatures, (2) every field the Task class has gained, (3) every CLI command we registered, (4) every API endpoint we created. This is for the final README and I need it to be exhaustive and accurate to what we actually built."
|
||
|
|
]
|
||
|
|
}
|