Create a responsive navigation bar with a logo on the left and three menu items on the right.

I need a responsive navigation bar. Follow the Ralph Loop methodology:

TASK CONTEXT:
Create a production-ready responsive navigation bar with logo left, menu right.
ATOMIC TASK BREAKDOWN:
Design HTML structure with semantic elements
Create CSS for desktop layout
Create CSS for mobile responsiveness with hamburger menu
Add JavaScript for mobile menu toggle
Implement accessibility features
Cross-browser testing simulation

PASS/FAIL CRITERIA FOR EACH TASK:
Task 1: Must use <nav>, <ul>, <li> elements appropriately
Task 2: Must align logo left, menu right on screens >768px
Task 3: Must collapse to hamburger menu on screens <769px
Task 4: Must toggle menu visibility on click
Task 5: Must include ARIA labels and keyboard navigation
Task 6: Must render correctly in Chrome, Firefox, Safari
ITERATION LOGIC:
After completing all tasks, test each criterion. If any fail, diagnose the issue, fix it, and retest. Continue until all criteria pass.
COMPLETION SIGNAL:
Only say "ALL CRITERIA PASS: Navigation bar complete" when every single criterion above is satisfied.
Begin the Ralph Loop now.

TASK CONTEXT:
[Clear description of the overall goal]
[Why this task matters or how it will be used]
[Any constraints: time, resources, standards, dependencies]
[Success looks like: description of the end state]

TASK CONTEXT:
Create a Python data validation module for user registration.
This will be used in production with 100K+ daily users, so it must be robust.
Constraints: Must use Pydantic v2, support async validation, and include comprehensive error messages.
Success looks like: A reusable module that catches all invalid inputs before database insertion.

ATOMIC TASK BREAKDOWN:
[First discrete unit of work]
[Second discrete unit of work]
[Third discrete unit of work]
... continue until all aspects are covered

ATOMIC TASK BREAKDOWN:
Define Pydantic models for user input with type annotations
Add custom validators for password strength and email format
Create async validation functions for checking unique username/email
Implement error collection and user-friendly error messages
Write unit tests for valid and invalid inputs
Create usage examples in documentation

PASS/FAIL CRITERIA:
Task 1: [Criterion 1], [Criterion 2], [Criterion 3]
Task 2: [Criterion 1], [Criterion 2]
... continue for all tasks

PASS/FAIL CRITERIA:
Task 1: Models include username, email, password fields; All fields have type hints
Task 2: Password validator requires 8+ chars, 1 uppercase, 1 number; Email validator checks format
Task 3: Async functions query mock database; Return True/False without exceptions
Task 4: All validation errors collected in list; Messages explain fix to user
Task 5: Tests cover valid input, all invalid cases; All tests pass when run
Task 6: Examples show basic usage, error handling, and async usage

ITERATION LOGIC:
After completing all tasks, test each criterion systematically.
If any criterion fails:
  1. Diagnose the root cause
  2. Implement a fix
  3. Retest that specific criterion
  4. Continue testing remaining criteria
Repeat until ALL criteria pass.
If stuck after 3 attempts on same issue, try a fundamentally different approach.

ITERATION LOGIC:
Complete all 6 tasks, then test each criterion in order.
For any failing criterion: analyze why it failed, fix the issue, then retest.
Example: If Task 5 tests fail, check if implementation is wrong or tests are wrong, fix accordingly.
Continue loop until all 12 criteria (2 per task) pass.
If same criterion fails twice, approach from different angle on third attempt.

COMPLETION SIGNAL:
Only say "[SPECIFIC PHRASE]" when ALL criteria pass.
Before that, continue iterating.
Do not indicate completion prematurely.

COMPLETION SIGNAL:
Only say "ALL CRITERIA PASS: Data validation module complete" when all 12 criteria pass.
Before that, continue testing and iterating.
Do not say "done" or "complete" until every criterion is verified.

TASK CONTEXT:
[Your overall goal and purpose]
[Constraints and requirements]
[What success looks like]
ATOMIC TASK BREAKDOWN:
[Task 1 description]
[Task 2 description]
[Task 3 description]
[Add as needed]

PASS/FAIL CRITERIA:
Task 1: [Criterion 1], [Criterion 2]
Task 2: [Criterion 1], [Criterion 2]
Task 3: [Criterion 1], [Criterion 2]
[Match to tasks]
ITERATION LOGIC:
After all tasks, test each criterion. For failures: diagnose, fix, retest.
Continue until ALL criteria pass. If stuck, try different approach.
COMPLETION SIGNAL:
Only say "ALL CRITERIA PASS: [Project name] complete" when verified.
Begin the Ralph Loop now.

RALPH PROMPT: Implement the function calculate_invoice_total based on the specification.
SPECIFICATION:
Input: items (list of dicts with 'price' (float), 'quantity' (int), 'taxable' (bool)), discount_percent (float, 0-100), customer_type ('retail', 'wholesale')
Output: Final total (float), rounded to 2 decimal places.
Logic: Sum item subtotals (price * quantity). Apply 8% tax to taxable items only. Apply discount based on customer_type: retail gets discount_percent, wholesale gets discount_percent + 5%. Minimum charge is $1.00.

ATOMIC TASKS:
 Write function signature with type hints and a clear docstring.
 Implement core calculation logic for item summation and tax.
 Implement discount logic based on customer_type.
 Add validation: ensure discount_percent is 0-100, quantities are positive, prices are non-negative.
 Enforce the minimum $1.00 total.
 Write 5 unit tests using pytest that cover edge cases (empty list, wholesale discount, zero taxable items).

PASS/FAIL CRITERIA:
[PASS] Function executes without syntax errors.
[PASS] 5/5 unit tests pass.
[PASS] Handles invalid input with clear ValueError messages.
[PASS] Output is correctly rounded to 2 decimals.
[PASS] Minimum total of $1.00 is enforced (e.g., $0.75 input yields $1.00).

ITERATION LOGIC:
Run the unit tests. If any fail, analyze the failure, correct the function, and re-run ALL tests.
Manually test with the invalid input case {'price': -5, 'quantity': 1, 'taxable': True}. If no ValueError is raised, diagnose validation logic and fix.
Test the minimum charge edge case. If output is < $1.00, adjust logic.

RALPH PROMPT: Develop a RESTful API endpoint POST /api/v1/products for product creation.
SPECIFICATION:
Framework: FastAPI. Use Pydantic for request/response models.
Database: Assume an async SQLAlchemy Product model with fields: id (int, PK), name (str), sku (str, unique), price (float), category_id (int, FK), is_active (bool).
Request Body: { "name": "string", "sku": "string", "price": number, "category_id": integer }
Behavior: Create product. SKU must be unique (return 409 if conflict). category_id must exist in database (return 404 if not found). Return 201 with created product data.

ATOMIC TASKS:
 Define Pydantic ProductCreate and ProductResponse schemas.
 Write the FastAPI route decorator and function signature.
 Implement database session dependency and async create logic.
 Add integrity check for duplicate SKU (simulate query).
 Add foreign key validation for category_id.
 Implement proper HTTP exception responses (409, 404, 422).
 Write 3 integration test cases (success, duplicate SKU, invalid category).

PASS/FAIL CRITERIA:
[PASS] Code is syntactically valid FastAPI.
[PASS] Pydantic schemas correctly validate/restrict input types.
[PASS] Simulated "duplicate SKU" condition returns a 409 status.
[PASS] Simulated "invalid category" returns a 404 status.
[PASS] All 3 integration tests pass when logically executed.

ITERATION LOGIC:
Validate the Pydantic schema rejects {"price": "ten"}. If it accepts, tighten schema.
Test the duplicate SKU logic: if the code does not raise/return 409, debug the uniqueness check.
Run the integration test suite conceptually. For any failing scenario, revise the endpoint logic and retest.

RALPH PROMPT: Optimize the provided slow SQL query for PostgreSQL.
ORIGINAL QUERY:

ATOMIC TASKS:
 Analyze the query: identify missing indexes, unnecessary joins, or inefficient clauses.
 Rewrite the query for optimal performance (e.g., use CTEs, subqueries, better joins).
 Propose 3 specific indexes (with CREATE INDEX statements).
 Write an equivalent query using window functions if beneficial.
 Provide a brief performance comparison explanation (what was improved).

PASS/FAIL CRITERIA:
[PASS] Rewritten query returns identical result set to original (logically verify).
[PASS] Proposed indexes are on columns used in JOIN, WHERE, and GROUP BY.
[PASS] No Cartesian products or unnecessary table scans are introduced.
[PASS] The HAVING clause logic is preserved and efficient.
[PASS] Explanation clearly states estimated performance gain (e.g., "Indexes avoid full scan on orders.date").

ITERATION LOGIC:
Compare the output schema of the new query with the original. If different, adjust SELECT/JOIN logic.
Check if any proposed index is on a low-cardinality column (like is_active). If so, replace it with a more selective one.
Ensure the HAVING clause doesn't force calculation of all sums before filtering. If it does, consider moving logic to a subquery.

RALPH PROMPT: Create a DataTable React component with sorting, pagination, and filtering.
SPECIFICATION:
Tech: React 18+, TypeScript, Tailwind CSS.
Props: data (array of objects), columns (array defining key, header, sortable), pageSize (number).
Features: Client-side sorting (click headers), pagination (prev/next, page numbers), text filter input (filters all columns).
UI: Clean, accessible table with clear visual states for sort direction.

ATOMIC TASKS:
 Define TypeScript interfaces for DataTableProps, Column, and component state.
 Build the component structure with JSX, using <table> and semantic HTML.
 Implement sorting logic (toggle ascending/descending).
 Implement pagination logic (slice data based on current page).
 Implement global filter input and logic.
 Add ARIA attributes for accessibility (aria-sort, aria-label).
 Create a usage example with sample data.

PASS/FAIL CRITERIA:
[PASS] Component compiles with tsc --noEmit (no TypeScript errors).
[PASS] Sorting toggles correctly between asc/desc/unsorted on click.
[PASS] Pagination correctly limits displayed rows to pageSize.
[PASS] Filter input reduces visible rows based on text match in any column.
[PASS] All interactive elements have appropriate ARIA attributes.

ITERATION LOGIC:
Run a TypeScript check. For any errors, fix the interface or prop usage.
Test sort logic: click a sortable column twice; it must cycle states. If stuck, debug the state management.
Test pagination with 25 items and pageSize=10. Page 3 should show items 21-25. If not, fix the slice calculation.
Verify filter: typing "test" with no matches should show empty table. If not, adjust filter function.

RALPH PROMPT: Write a complete pytest suite for the PaymentProcessor class.
CLASS CODE:

ATOMIC TASKS:
 Create test file test_payment_processor.py.
 Write fixtures for a mock gateway using unittest.mock.Mock.
 Test charge(): success path, validates positive amount, validates currency.
 Test charge(): verifies transaction is recorded.
 Test get_total_revenue(): sums correctly, filters by currency, rounds.
 Test integration: multiple charges correctly affect total revenue.
 Achieve 100% logical branch coverage.

PASS/FAIL CRITERIA:
[PASS] All tests pass when executed (simulate execution).
[PASS] Negative amount test raises ValueError with correct message.
[PASS] Unsupported currency ("GBP") test raises ValueError.
[PASS] Mock gateway charge is called with correct arguments.
[PASS] get_total_revenue returns 150.0 for transactions [100.0, 50.0] in USD.

ITERATION LOGIC:
Run the test suite conceptually. For any failing test, examine the assertion and fix the test or the understanding of the class.
Check coverage: ensure there's a test for the currency not in ["USD", "EUR"] branch. If missing, add it.
Verify the mock is asserted. If tests pass without checking gateway.charge was called, add the assertion.

RALPH PROMPT: Perform a code review on the following GitHub-style diff. Identify bugs, security issues, and style deviations.
DIFF:

ATOMIC TASKS:
 Analyze the fix: does it correctly address the plain-text password vulnerability?
 Identify a new bug introduced: what if user is None?
 Check for other security issues (e.g., lack of rate limiting, information leakage).
 Evaluate style: is the error message generic enough?
 Suggest an additional improvement (e.g., using authenticate()).
 Output a review checklist with [PASS]/[FAIL] items.

PASS/FAIL CRITERIA:
[PASS] The review identifies the potential AttributeError when user is None.
[PASS] The review confirms the fix properly uses check_password().
[PASS] The review suggests at least one additional security improvement.
[PASS] The review notes the error message is appropriately generic (doesn't reveal if user exists).
[PASS] The output is a structured checklist, not just prose.

ITERATION LOGIC:
Examine the user.check_password(password) line. If the review doesn't note it's safe only if user exists, fail and re-analyze.
Check if the review suggests adding from django.contrib.auth import authenticate. If not, suggest it as an improvement.
Ensure the checklist format is used. If output is a paragraph, reformat into a checklist and re-evaluate criteria.

RALPH PROMPT: Diagnose and fix the bug in the merge_user_data function.
BUG REPORT: "Function sometimes returns duplicate user IDs when merging lists."
CODE:

ATOMIC TASKS:
 Reproduce the bug: create test inputs where list_a itself has duplicate IDs.
 Identify the root cause: the logic only checks duplicates between lists, not within list_a.
 Write a corrected version that ensures all IDs in the output are unique.
 Preserve order: keep items from list_a first, then unique items from list_b.
 Write 3 test cases: within-list duplicates, cross-list duplicates, and empty lists.
 Propose a more efficient data structure (e.g., dictionary) for large lists.

PASS/FAIL CRITERIA:
[PASS] Corrected function returns no duplicate IDs for any input.
[PASS] Ordering rule is preserved (list_a items first).
[PASS] All 3 test cases pass.
[PASS] Root cause is clearly stated in one sentence.
[PASS] Suggested optimization uses a dict or set for O(n) performance.

ITERATION LOGIC:
Test with list_a = [{'id': 1}, {'id': 1}]. If output contains duplicate id=1, the fix is insufficient; revise.
Verify order: input list_a = [{'id': 2}], list_b = [{'id': 1}] must output [{'id': 2}, {'id': 1}]. If reversed, fix.
Ensure the explanation of root cause is precise. If vague, refine it.

RALPH PROMPT: Optimize the find_common_tags function for speed.
ORIGINAL CODE:

ATOMIC TASKS:
 Analyze time complexity: currently O(n*m) where n=tags in first post, m=posts.
 Optimize by converting post['tags'] lists to sets for O(1) lookups.
 Use set intersection operation to find common tags directly.
 Handle edge case: empty posts list.
 Write a benchmark comparison (original vs. optimized) using pseudo-timing.
 Ensure result order is not required (set intersection january change order).

PASS/FAIL CRITERIA:
[PASS] Optimized function returns the same logical result as original.
[PASS] Code uses set.intersection() or equivalent.
[PASS] Edge case posts=[] is handled (return empty list or raise error).
[PASS] Time complexity is correctly stated as O(m*k) where k is avg tag count, but with much lower constant factors.
[PASS] Benchmark shows at least 10x speedup for large inputs (e.g., 1000 posts, 100 tags each).

ITERATION LOGIC:
Test with sample data: posts = [{'tags':['a','b']}, {'tags':['a','c']}]. Result should be ['a']. If not, debug set logic.
Check empty list handling. If original code crashes on posts[0], the optimized version must handle it gracefully.
Verify the use of set. If still using nested loops with in on lists, fail and enforce set conversion.

RALPH PROMPT: Conduct a security audit on the following snippet of a Django view.
CODE:

ATOMIC TASKS:
 Identify the critical SQL Injection vulnerability.
 Identify any additional issues (JSON serialization of raw tuples, lack of input sanitization).
 Provide a fixed version using Django's ORM or parameterized queries.
 Suggest protection against potential XSS in the JSON response if query/category were reflected.
 Recommend a rate-limiting strategy for this endpoint.
 Output a vulnerability report with severity (Critical, High, Medium).

PASS/FAIL CRITERIA:
[PASS] The audit identifies the SQLi via string interpolation as Critical.
[PASS] Fixed code uses cursor.execute(sql, [params]) or Django ORM.
[PASS] The report mentions the risk of exposing raw DB tuples (information disclosure).
[PASS] Suggests using json.dumps with a default serializer or a DRF serializer.
[PASS] At least one additional hardening recommendation (rate limiting, input validation) is provided.

ITERATION LOGIC:
Check the fixed code: if it still uses f-string or .format() on the SQL string, fail and enforce parameterized queries.
Ensure the vulnerability report is structured. If it's a paragraph, reformat into a list with severity labels.
Verify the recommendation for JSON serialization addresses the fetchall() tuple issue. If not, add it.

RALPH PROMPT: Generate complete documentation for the StringUtils class.
CLASS CODE:

ATOMIC TASKS:
 Write an overview module docstring.
 Document each method with Args, Returns, Raises, and Examples.
 Include a "Quick Start" usage example.
 Create a table of common use cases and which method to use.
 Format for MkDocs or Sphinx compatibility (using Markdown).
 Ensure all examples are copy-paste runnable in a Python shell.

PASS/FAIL CRITERIA:
[PASS] Each method docstring includes at least one working code example.
[PASS] The slugify example shows input "Hello World!" and output "hello-world".
[PASS] The truncate example demonstrates the suffix parameter.
[PASS] The is_palindrome example correctly handles "A man, a plan, a canal: Panama".
[PASS] The final output is a single, well-structured Markdown document.

ITERATION LOGIC:
Test each code example by mentally executing it. If slugify("Hello World!") wouldn't produce the claimed output, correct the example or the understanding.
Check for a "Raises" section in truncate for negative length. If missing, add it.
Ensure the document has a clear table of contents via headers. If it's a wall of text, restructure with headers.