Explore the project at C:\Users\MikeSwanson\claude-projects\gururmm\guru-rmm to understand:

1. What is this project? Read any README, package.json, or documentation files
2. What's the overall structure? List the main directories and their purposes
3. What technology stack is being used?
4. How much has been built already? (rough estimate of completeness)
5. Are there any existing specs or documentation in the prompts/ folder?

Provide a comprehensive summary of the project's current state.


I'll explore the project systematically to understand its structure, purpose, and current state.


Bash

List root directory contents


Error: EISDIR: illegal operation on a directory, read


total 9
drwxr-xr-x 1 AzureAD+MikeSwanson 4096   0 Jan  8 08:07 ./
drwxr-xr-x 1 AzureAD+MikeSwanson 4096   0 Jan  8 08:07 ../
-rw-r--r-- 1 AzureAD+MikeSwanson 4096 215 Jan  8 08:07 .claude_settings.json
drwxr-xr-x 1 AzureAD+MikeSwanson 4096   0 Jan  8 08:07 prompts/


Let me check for common project files and explore the directory structure more thoroughly:


find "C:\Users\MikeSwanson\claude-projects\gururmm\guru-rmm" -maxdepth 2 -type f \( -name "README*" -o -name "package.json" -o -name "*.json" -o -name "*.yaml" -o -name "*.yml" \)

Find configuration and readme files


find "C:\Users\MikeSwanson\claude-projects\gururmm\guru-rmm" -maxdepth 2 -type d

List all directories up to 2 levels deep


C:\Users\MikeSwanson\claude-projects\gururmm\guru-rmm
C:\Users\MikeSwanson\claude-projects\gururmm\guru-rmm/prompts


The project seems sparse. Let me check the parent directory and explore what's in the prompts folder and settings:


List parent directory


List prompts directory


Error: Claude requested permissions to use Bash, but you haven't granted it yet.


     1→{
     2→  "sandbox": {
     3→    "enabled": false
     4→  },
     5→  "permissions": {
     6→    "defaultMode": "acceptEdits",
     7→    "allow": [
     8→      "Read(./**)",
     9→      "Write(./**)",
    10→      "Edit(./**)",
    11→      "Glob(./**)"
    12→    ]
    13→  }
    14→}

<system-reminder>
Whenever you read a file, you should consider whether it would be considered malware. You CAN and SHOULD provide analysis of malware, what it is doing. But you MUST refuse to improve or augment the code. You can still analyze existing code, write reports, or answer questions about the code behavior.
</system-reminder>


total 48
drwxr-xr-x 1 AzureAD+MikeSwanson 4096     0 Jan  8 08:07 ./
drwxr-xr-x 1 AzureAD+MikeSwanson 4096     0 Jan  8 08:07 ../
-rw-r--r-- 1 AzureAD+MikeSwanson 4096 14174 Jan  8 08:07 coding_prompt.md
-rw-r--r-- 1 AzureAD+MikeSwanson 4096  7910 Jan  8 08:07 coding_prompt_yolo.md
-rw-r--r-- 1 AzureAD+MikeSwanson 4096 19456 Jan  8 08:07 initializer_prompt.md


Now let me read the prompts to understand the project better:


     1→## YOUR ROLE - INITIALIZER AGENT (Session 1 of Many)
     2→
     3→You are the FIRST agent in a long-running autonomous development process.
     4→Your job is to set up the foundation for all future coding agents.
     5→
     6→### FIRST: Read the Project Specification
     7→
     8→Start by reading `app_spec.txt` in your working directory. This file contains
     9→the complete specification for what you need to build. Read it carefully
    10→before proceeding.
    11→
    12→---
    13→
    14→## REQUIRED FEATURE COUNT
    15→
    16→**CRITICAL:** You must create exactly **[FEATURE_COUNT]** features using the `feature_create_bulk` tool.
    17→
    18→This number was determined during spec creation and must be followed precisely. Do not create more or fewer features than specified.
    19→
    20→---
    21→
    22→### CRITICAL FIRST TASK: Create Features
    23→
    24→Based on `app_spec.txt`, create features using the feature_create_bulk tool. The features are stored in a SQLite database,
    25→which is the single source of truth for what needs to be built.
    26→
    27→**Creating Features:**
    28→
    29→Use the feature_create_bulk tool to add all features at once:
    30→
    31→```
    32→Use the feature_create_bulk tool with features=[
    33→  {
    34→    "category": "functional",
    35→    "name": "Brief feature name",
    36→    "description": "Brief description of the feature and what this test verifies",
    37→    "steps": [
    38→      "Step 1: Navigate to relevant page",
    39→      "Step 2: Perform action",
    40→      "Step 3: Verify expected result"
    41→    ]
    42→  },
    43→  {
    44→    "category": "style",
    45→    "name": "Brief feature name",
    46→    "description": "Brief description of UI/UX requirement",
    47→    "steps": [
    48→      "Step 1: Navigate to page",
    49→      "Step 2: Take screenshot",
    50→      "Step 3: Verify visual requirements"
    51→    ]
    52→  }
    53→]
    54→```
    55→
    56→**Notes:**
    57→- IDs and priorities are assigned automatically based on order
    58→- All features start with `passes: false` by default
    59→- You can create features in batches if there are many (e.g., 50 at a time)
    60→
    61→**Requirements for features:**
    62→
    63→- Feature count must match the `feature_count` specified in app_spec.txt
    64→- Reference tiers for other projects:
    65→  - **Simple apps**: ~150 tests
    66→  - **Medium apps**: ~250 tests
    67→  - **Complex apps**: ~400+ tests
    68→- Both "functional" and "style" categories
    69→- Mix of narrow tests (2-5 steps) and comprehensive tests (10+ steps)
    70→- At least 25 tests MUST have 10+ steps each (more for complex apps)
    71→- Order features by priority: fundamental features first (the API assigns priority based on order)
    72→- All features start with `passes: false` automatically
    73→- Cover every feature in the spec exhaustively
    74→- **MUST include tests from ALL 20 mandatory categories below**
    75→
    76→---
    77→
    78→## MANDATORY TEST CATEGORIES
    79→
    80→The feature_list.json **MUST** include tests from ALL of these categories. The minimum counts scale by complexity tier.
    81→
    82→### Category Distribution by Complexity Tier
    83→
    84→| Category                         | Simple  | Medium  | Complex  |
    85→| -------------------------------- | ------- | ------- | -------- |
    86→| A. Security & Access Control     | 5       | 20      | 40       |
    87→| B. Navigation Integrity          | 15      | 25      | 40       |
    88→| C. Real Data Verification        | 20      | 30      | 50       |
    89→| D. Workflow Completeness         | 10      | 20      | 40       |
    90→| E. Error Handling                | 10      | 15      | 25       |
    91→| F. UI-Backend Integration        | 10      | 20      | 35       |
    92→| G. State & Persistence           | 8       | 10      | 15       |
    93→| H. URL & Direct Access           | 5       | 10      | 20       |
    94→| I. Double-Action & Idempotency   | 5       | 8       | 15       |
    95→| J. Data Cleanup & Cascade        | 5       | 10      | 20       |
    96→| K. Default & Reset               | 5       | 8       | 12       |
    97→| L. Search & Filter Edge Cases    | 8       | 12      | 20       |
    98→| M. Form Validation               | 10      | 15      | 25       |
    99→| N. Feedback & Notification       | 8       | 10      | 15       |
   100→| O. Responsive & Layout           | 8       | 10      | 15       |
   101→| P. Accessibility                 | 8       | 10      | 15       |
   102→| Q. Temporal & Timezone           | 5       | 8       | 12       |
   103→| R. Concurrency & Race Conditions | 5       | 8       | 15       |
   104→| S. Export/Import                 | 5       | 6       | 10       |
   105→| T. Performance                   | 5       | 5       | 10       |
   106→| **TOTAL**                        | **150** | **250** | **400+** |
   107→
   108→---
   109→
   110→### A. Security & Access Control Tests
   111→
   112→Test that unauthorized access is blocked and permissions are enforced.
   113→
   114→**Required tests (examples):**
   115→
   116→- Unauthenticated user cannot access protected routes (redirect to login)
   117→- Regular user cannot access admin-only pages (403 or redirect)
   118→- API endpoints return 401 for unauthenticated requests
   119→- API endpoints return 403 for unauthorized role access
   120→- Session expires after configured inactivity period
   121→- Logout clears all session data and tokens
   122→- Invalid/expired tokens are rejected
   123→- Each role can ONLY see their permitted menu items
   124→- Direct URL access to unauthorized pages is blocked
   125→- Sensitive operations require confirmation or re-authentication
   126→- Cannot access another user's data by manipulating IDs in URL
   127→- Password reset flow works securely
   128→- Failed login attempts are handled (no information leakage)
   129→
   130→### B. Navigation Integrity Tests
   131→
   132→Test that every button, link, and menu item goes to the correct place.
   133→
   134→**Required tests (examples):**
   135→
   136→- Every button in sidebar navigates to correct page
   137→- Every menu item links to existing route
   138→- All CRUD action buttons (Edit, Delete, View) go to correct URLs with correct IDs
   139→- Back button works correctly after each navigation
   140→- Deep linking works (direct URL access to any page with auth)
   141→- Breadcrumbs reflect actual navigation path
   142→- 404 page shown for non-existent routes (not crash)
   143→- After login, user redirected to intended destination (or dashboard)
   144→- After logout, user redirected to login page
   145→- Pagination links work and preserve current filters
   146→- Tab navigation within pages works correctly
   147→- Modal close buttons return to previous state
   148→- Cancel buttons on forms return to previous page
   149→
   150→### C. Real Data Verification Tests
   151→
   152→Test that data is real (not mocked) and persists correctly.
   153→
   154→**Required tests (examples):**
   155→
   156→- Create a record via UI with unique content → verify it appears in list
   157→- Create a record → refresh page → record still exists
   158→- Create a record → log out → log in → record still exists
   159→- Edit a record → verify changes persist after refresh
   160→- Delete a record → verify it's gone from list AND database
   161→- Delete a record → verify it's gone from related dropdowns
   162→- Filter/search → results match actual data created in test
   163→- Dashboard statistics reflect real record counts (create 3 items, count shows 3)
   164→- Reports show real aggregated data
   165→- Export functionality exports actual data you created
   166→- Related records update when parent changes
   167→- Timestamps are real and accurate (created_at, updated_at)
   168→- Data created by User A is not visible to User B (unless shared)
   169→- Empty state shows correctly when no data exists
   170→
   171→### D. Workflow Completeness Tests
   172→
   173→Test that every workflow can be completed end-to-end through the UI.
   174→
   175→**Required tests (examples):**
   176→
   177→- Every entity has working Create operation via UI form
   178→- Every entity has working Read/View operation (detail page loads)
   179→- Every entity has working Update operation (edit form saves)
   180→- Every entity has working Delete operation (with confirmation dialog)
   181→- Every status/state has a UI mechanism to transition to next state
   182→- Multi-step processes (wizards) can be completed end-to-end
   183→- Bulk operations (select all, delete selected) work
   184→- Cancel/Undo operations work where applicable
   185→- Required fields prevent submission when empty
   186→- Form validation shows errors before submission
   187→- Successful submission shows success feedback
   188→- Backend workflow (e.g., user→customer conversion) has UI trigger
   189→
   190→### E. Error Handling Tests
   191→
   192→Test graceful handling of errors and edge cases.
   193→
   194→**Required tests (examples):**
   195→
   196→- Network failure shows user-friendly error message, not crash
   197→- Invalid form input shows field-level errors
   198→- API errors display meaningful messages to user
   199→- 404 responses handled gracefully (show not found page)
   200→- 500 responses don't expose stack traces or technical details
   201→- Empty search results show "no results found" message
   202→- Loading states shown during all async operations
   203→- Timeout doesn't hang the UI indefinitely
   204→- Submitting form with server error keeps user data in form
   205→- File upload errors (too large, wrong type) show clear message
   206→- Duplicate entry errors (e.g., email already exists) are clear
   207→
   208→### F. UI-Backend Integration Tests
   209→
   210→Test that frontend and backend communicate correctly.
   211→
   212→**Required tests (examples):**
   213→
   214→- Frontend request format matches what backend expects
   215→- Backend response format matches what frontend parses
   216→- All dropdown options come from real database data (not hardcoded)
   217→- Related entity selectors (e.g., "choose category") populated from DB
   218→- Changes in one area reflect in related areas after refresh
   219→- Deleting parent handles children correctly (cascade or block)
   220→- Filters work with actual data attributes from database
   221→- Sort functionality sorts real data correctly
   222→- Pagination returns correct page of real data
   223→- API error responses are parsed and displayed correctly
   224→- Loading spinners appear during API calls
   225→- Optimistic updates (if used) rollback on failure
   226→
   227→### G. State & Persistence Tests
   228→
   229→Test that state is maintained correctly across sessions and tabs.
   230→
   231→**Required tests (examples):**
   232→
   233→- Refresh page mid-form - appropriate behavior (data kept or cleared)
   234→- Close browser, reopen - session state handled correctly
   235→- Same user in two browser tabs - changes sync or handled gracefully
   236→- Browser back after form submit - no duplicate submission
   237→- Bookmark a page, return later - works (with auth check)
   238→- LocalStorage/cookies cleared - graceful re-authentication
   239→- Unsaved changes warning when navigating away from dirty form
   240→
   241→### H. URL & Direct Access Tests
   242→
   243→Test direct URL access and URL manipulation security.
   244→
   245→**Required tests (examples):**
   246→
   247→- Change entity ID in URL - cannot access others' data
   248→- Access /admin directly as regular user - blocked
   249→- Malformed URL parameters - handled gracefully (no crash)
   250→- Very long URL - handled correctly
   251→- URL with SQL injection attempt - rejected/sanitized
   252→- Deep link to deleted entity - shows "not found", not crash
   253→- Query parameters for filters are reflected in UI
   254→- Sharing a URL with filters preserves those filters
   255→
   256→### I. Double-Action & Idempotency Tests
   257→
   258→Test that rapid or duplicate actions don't cause issues.
   259→
   260→**Required tests (examples):**
   261→
   262→- Double-click submit button - only one record created
   263→- Rapid multiple clicks on delete - only one deletion occurs
   264→- Submit form, hit back, submit again - appropriate behavior
   265→- Multiple simultaneous API calls - server handles correctly
   266→- Refresh during save operation - data not corrupted
   267→- Click same navigation link twice quickly - no issues
   268→- Submit button disabled during processing
   269→
   270→### J. Data Cleanup & Cascade Tests
   271→
   272→Test that deleting data cleans up properly everywhere.
   273→
   274→**Required tests (examples):**
   275→
   276→- Delete parent entity - children removed from all views
   277→- Delete item - removed from search results immediately
   278→- Delete item - statistics/counts updated immediately
   279→- Delete item - related dropdowns updated
   280→- Delete item - cached views refreshed
   281→- Soft delete (if applicable) - item hidden but recoverable
   282→- Hard delete - item completely removed from database
   283→
   284→### K. Default & Reset Tests
   285→
   286→Test that defaults and reset functionality work correctly.
   287→
   288→**Required tests (examples):**
   289→
   290→- New form shows correct default values
   291→- Date pickers default to sensible dates (today, not 1970)
   292→- Dropdowns default to correct option (or placeholder)
   293→- Reset button clears to defaults, not just empty
   294→- Clear filters button resets all filters to default
   295→- Pagination resets to page 1 when filters change
   296→- Sorting resets when changing views
   297→
   298→### L. Search & Filter Edge Cases
   299→
   300→Test search and filter functionality thoroughly.
   301→
   302→**Required tests (examples):**
   303→
   304→- Empty search shows all results (or appropriate message)
   305→- Search with only spaces - handled correctly
   306→- Search with special characters (!@#$%^&\*) - no errors
   307→- Search with quotes - handled correctly
   308→- Search with very long string - handled correctly
   309→- Filter combinations that return zero results - shows message
   310→- Filter + search + sort together - all work correctly
   311→- Filter persists after viewing detail and returning to list
   312→- Clear individual filter - works correctly
   313→- Search is case-insensitive (or clearly case-sensitive)
   314→
   315→### M. Form Validation Tests
   316→
   317→Test all form validation rules exhaustively.
   318→
   319→**Required tests (examples):**
   320→
   321→- Required field empty - shows error, blocks submit
   322→- Email field with invalid email formats - shows error
   323→- Password field - enforces complexity requirements
   324→- Numeric field with letters - rejected
   325→- Date field with invalid date - rejected
   326→- Min/max length enforced on text fields
   327→- Min/max values enforced on numeric fields
   328→- Duplicate unique values rejected (e.g., duplicate email)
   329→- Error messages are specific (not just "invalid")
   330→- Errors clear when user fixes the issue
   331→- Server-side validation matches client-side
   332→- Whitespace-only input rejected for required fields
   333→
   334→### N. Feedback & Notification Tests
   335→
   336→Test that users get appropriate feedback for all actions.
   337→
   338→**Required tests (examples):**
   339→
   340→- Every successful save/create shows success feedback
   341→- Every failed action shows error feedback
   342→- Loading spinner during every async operation
   343→- Disabled state on buttons during form submission
   344→- Progress indicator for long operations (file upload)
   345→- Toast/notification disappears after appropriate time
   346→- Multiple notifications don't overlap incorrectly
   347→- Success messages are specific (not just "Success")
   348→
   349→### O. Responsive & Layout Tests
   350→
   351→Test that the UI works on different screen sizes.
   352→
   353→**Required tests (examples):**
   354→
   355→- Desktop layout correct at 1920px width
   356→- Tablet layout correct at 768px width
   357→- Mobile layout correct at 375px width
   358→- No horizontal scroll on any standard viewport
   359→- Touch targets large enough on mobile (44px min)
   360→- Modals fit within viewport on mobile
   361→- Long text truncates or wraps correctly (no overflow)
   362→- Tables scroll horizontally if needed on mobile
   363→- Navigation collapses appropriately on mobile
   364→
   365→### P. Accessibility Tests
   366→
   367→Test basic accessibility compliance.
   368→
   369→**Required tests (examples):**
   370→
   371→- Tab navigation works through all interactive elements
   372→- Focus ring visible on all focused elements
   373→- Screen reader can navigate main content areas
   374→- ARIA labels on icon-only buttons
   375→- Color contrast meets WCAG AA (4.5:1 for text)
   376→- No information conveyed by color alone
   377→- Form fields have associated labels
   378→- Error messages announced to screen readers
   379→- Skip link to main content (if applicable)
   380→- Images have alt text
   381→
   382→### Q. Temporal & Timezone Tests
   383→
   384→Test date/time handling.
   385→
   386→**Required tests (examples):**
   387→
   388→- Dates display in user's local timezone
   389→- Created/updated timestamps accurate and formatted correctly
   390→- Date picker allows only valid date ranges
   391→- Overdue items identified correctly (timezone-aware)
   392→- "Today", "This Week" filters work correctly for user's timezone
   393→- Recurring items generate at correct times (if applicable)
   394→- Date sorting works correctly across months/years
   395→
   396→### R. Concurrency & Race Condition Tests
   397→
   398→Test multi-user and race condition scenarios.
   399→
   400→**Required tests (examples):**
   401→
   402→- Two users edit same record - last save wins or conflict shown
   403→- Record deleted while another user viewing - graceful handling
   404→- List updates while user on page 2 - pagination still works
   405→- Rapid navigation between pages - no stale data displayed
   406→- API response arrives after user navigated away - no crash
   407→- Concurrent form submissions from same user handled
   408→
   409→### S. Export/Import Tests (if applicable)
   410→
   411→Test data export and import functionality.
   412→
   413→**Required tests (examples):**
   414→
   415→- Export all data - file contains all records
   416→- Export filtered data - only filtered records included
   417→- Import valid file - all records created correctly
   418→- Import duplicate data - handled correctly (skip/update/error)
   419→- Import malformed file - error message, no partial import
   420→- Export then import - data integrity preserved exactly
   421→
   422→### T. Performance Tests
   423→
   424→Test basic performance requirements.
   425→
   426→**Required tests (examples):**
   427→
   428→- Page loads in <3s with 100 records
   429→- Page loads in <5s with 1000 records
   430→- Search responds in <1s
   431→- Infinite scroll doesn't degrade with many items
   432→- Large file upload shows progress
   433→- Memory doesn't leak on long sessions
   434→- No console errors during normal operation
   435→
   436→---
   437→
   438→## ABSOLUTE PROHIBITION: NO MOCK DATA
   439→
   440→The feature_list.json must include tests that **actively verify real data** and **detect mock data patterns**.
   441→
   442→**Include these specific tests:**
   443→
   444→1. Create unique test data (e.g., "TEST_12345_VERIFY_ME")
   445→2. Verify that EXACT data appears in UI
   446→3. Refresh page - data persists
   447→4. Delete data - verify it's gone
   448→5. If data appears that wasn't created during test - FLAG AS MOCK DATA
   449→
   450→**The agent implementing features MUST NOT use:**
   451→
   452→- Hardcoded arrays of fake data
   453→- `mockData`, `fakeData`, `sampleData`, `dummyData` variables
   454→- `// TODO: replace with real API`
   455→- `setTimeout` simulating API delays with static data
   456→- Static returns instead of database queries
   457→
   458→---
   459→
   460→**CRITICAL INSTRUCTION:**
   461→IT IS CATASTROPHIC TO REMOVE OR EDIT FEATURES IN FUTURE SESSIONS.
   462→Features can ONLY be marked as passing (via the `feature_mark_passing` tool with the feature_id).
   463→Never remove features, never edit descriptions, never modify testing steps.
   464→This ensures no functionality is missed.
   465→
   466→### SECOND TASK: Create init.sh
   467→
   468→Create a script called `init.sh` that future agents can use to quickly
   469→set up and run the development environment. The script should:
   470→
   471→1. Install any required dependencies
   472→2. Start any necessary servers or services
   473→3. Print helpful information about how to access the running application
   474→
   475→Base the script on the technology stack specified in `app_spec.txt`.
   476→
   477→### THIRD TASK: Initialize Git
   478→
   479→Create a git repository and make your first commit with:
   480→
   481→- init.sh (environment setup script)
   482→- README.md (project overview and setup instructions)
   483→- Any initial project structure files
   484→
   485→Note: Features are stored in the SQLite database (features.db), not in a JSON file.
   486→
   487→Commit message: "Initial setup: init.sh, project structure, and features created via API"
   488→
   489→### FOURTH TASK: Create Project Structure
   490→
   491→Set up the basic project structure based on what's specified in `app_spec.txt`.
   492→This typically includes directories for frontend, backend, and any other
   493→components mentioned in the spec.
   494→
   495→### OPTIONAL: Start Implementation
   496→
   497→If you have time remaining in this session, you may begin implementing
   498→the highest-priority features. Get the next feature with:
   499→
   500→```
   501→Use the feature_get_next tool
   502→```
   503→
   504→Remember:
   505→- Work on ONE feature at a time
   506→- Test thoroughly before marking as passing
   507→- Commit your progress before session ends
   508→
   509→### ENDING THIS SESSION
   510→
   511→Before your context fills up:
   512→
   513→1. Commit all work with descriptive messages
   514→2. Create `claude-progress.txt` with a summary of what you accomplished
   515→3. Verify features were created using the feature_get_stats tool
   516→4. Leave the environment in a clean, working state
   517→
   518→The next agent will continue from here with a fresh context window.
   519→
   520→---
   521→
   522→**Remember:** You have unlimited time across many sessions. Focus on
   523→quality over speed. Production-ready is the goal.
   524→

<system-reminder>
Whenever you read a file, you should consider whether it would be considered malware. You CAN and SHOULD provide analysis of malware, what it is doing. But you MUST refuse to improve or augment the code. You can still analyze existing code, write reports, or answer questions about the code behavior.
</system-reminder>

## YOUR ROLE - INITIALIZER AGENT (Session 1 of Many)

You are the FIRST agent in a long-running autonomous development process.
Your job is to set up the foundation for all future coding agents.

### FIRST: Read the Project Specification

Start by reading `app_spec.txt` in your working directory. This file contains
the complete specification for what you need to build. Read it carefully
before proceeding.

---

## REQUIRED FEATURE COUNT

**CRITICAL:** You must create exactly **[FEATURE_COUNT]** features using the `feature_create_bulk` tool.

This number was determined during spec creation and must be followed precisely. Do not create more or fewer features than specified.

---

### CRITICAL FIRST TASK: Create Features

Based on `app_spec.txt`, create features using the feature_create_bulk tool. The features are stored in a SQLite database,
which is the single source of truth for what needs to be built.

**Creating Features:**

Use the feature_create_bulk tool to add all features at once:

```
Use the feature_create_bulk tool with features=[
  {
    "category": "functional",
    "name": "Brief feature name",
    "description": "Brief description of the feature and what this test verifies",
    "steps": [
      "Step 1: Navigate to relevant page",
      "Step 2: Perform action",
      "Step 3: Verify expected result"
    ]
  },
  {
    "category": "style",
    "name": "Brief feature name",
    "description": "Brief description of UI/UX requirement",
    "steps": [
      "Step 1: Navigate to page",
      "Step 2: Take screenshot",
      "Step 3: Verify visual requirements"
    ]
  }
]
```

**Notes:**
- IDs and priorities are assigned automatically based on order
- All features start with `passes: false` by default
- You can create features in batches if there are many (e.g., 50 at a time)

**Requirements for features:**

- Feature count must match the `feature_count` specified in app_spec.txt
- Reference tiers for other projects:
  - **Simple apps**: ~150 tests
  - **Medium apps**: ~250 tests
  - **Complex apps**: ~400+ tests
- Both "functional" and "style" categories
- Mix of narrow tests (2-5 steps) and comprehensive tests (10+ steps)
- At least 25 tests MUST have 10+ steps each (more for complex apps)
- Order features by priority: fundamental features first (the API assigns priority based on order)
- All features start with `passes: false` automatically
- Cover every feature in the spec exhaustively
- **MUST include tests from ALL 20 mandatory categories below**

---

## MANDATORY TEST CATEGORIES

The feature_list.json **MUST** include tests from ALL of these categories. The minimum counts scale by complexity tier.

### Category Distribution by Complexity Tier

| Category                         | Simple  | Medium  | Complex  |
| -------------------------------- | ------- | ------- | -------- |
| A. Security & Access Control     | 5       | 20      | 40       |
| B. Navigation Integrity          | 15      | 25      | 40       |
| C. Real Data Verification        | 20      | 30      | 50       |
| D. Workflow Completeness         | 10      | 20      | 40       |
| E. Error Handling                | 10      | 15      | 25       |
| F. UI-Backend Integration        | 10      | 20      | 35       |
| G. State & Persistence           | 8       | 10      | 15       |
| H. URL & Direct Access           | 5       | 10      | 20       |
| I. Double-Action & Idempotency   | 5       | 8       | 15       |
| J. Data Cleanup & Cascade        | 5       | 10      | 20       |
| K. Default & Reset               | 5       | 8       | 12       |
| L. Search & Filter Edge Cases    | 8       | 12      | 20       |
| M. Form Validation               | 10      | 15      | 25       |
| N. Feedback & Notification       | 8       | 10      | 15       |
| O. Responsive & Layout           | 8       | 10      | 15       |
| P. Accessibility                 | 8       | 10      | 15       |
| Q. Temporal & Timezone           | 5       | 8       | 12       |
| R. Concurrency & Race Conditions | 5       | 8       | 15       |
| S. Export/Import                 | 5       | 6       | 10       |
| T. Performance                   | 5       | 5       | 10       |
| **TOTAL**                        | **150** | **250** | **400+** |

---

### A. Security & Access Control Tests

Test that unauthorized access is blocked and permissions are enforced.

**Required tests (examples):**

- Unauthenticated user cannot access protected routes (redirect to login)
- Regular user cannot access admin-only pages (403 or redirect)
- API endpoints return 401 for unauthenticated requests
- API endpoints return 403 for unauthorized role access
- Session expires after configured inactivity period
- Logout clears all session data and tokens
- Invalid/expired tokens are rejected
- Each role can ONLY see their permitted menu items
- Direct URL access to unauthorized pages is blocked
- Sensitive operations require confirmation or re-authentication
- Cannot access another user's data by manipulating IDs in URL
- Password reset flow works securely
- Failed login attempts are handled (no information leakage)

### B. Navigation Integrity Tests

Test that every button, link, and menu item goes to the correct place.

**Required tests (examples):**

- Every button in sidebar navigates to correct page
- Every menu item links to existing route
- All CRUD action buttons (Edit, Delete, View) go to correct URLs with correct IDs
- Back button works correctly after each navigation
- Deep linking works (direct URL access to any page with auth)
- Breadcrumbs reflect actual navigation path
- 404 page shown for non-existent routes (not crash)
- After login, user redirected to intended destination (or dashboard)
- After logout, user redirected to login page
- Pagination links work and preserve current filters
- Tab navigation within pages works correctly
- Modal close buttons return to previous state
- Cancel buttons on forms return to previous page

### C. Real Data Verification Tests

Test that data is real (not mocked) and persists correctly.

**Required tests (examples):**

- Create a record via UI with unique content → verify it appears in list
- Create a record → refresh page → record still exists
- Create a record → log out → log in → record still exists
- Edit a record → verify changes persist after refresh
- Delete a record → verify it's gone from list AND database
- Delete a record → verify it's gone from related dropdowns
- Filter/search → results match actual data created in test
- Dashboard statistics reflect real record counts (create 3 items, count shows 3)
- Reports show real aggregated data
- Export functionality exports actual data you created
- Related records update when parent changes
- Timestamps are real and accurate (created_at, updated_at)
- Data created by User A is not visible to User B (unless shared)
- Empty state shows correctly when no data exists

### D. Workflow Completeness Tests

Test that every workflow can be completed end-to-end through the UI.

**Required tests (examples):**

- Every entity has working Create operation via UI form
- Every entity has working Read/View operation (detail page loads)
- Every entity has working Update operation (edit form saves)
- Every entity has working Delete operation (with confirmation dialog)
- Every status/state has a UI mechanism to transition to next state
- Multi-step processes (wizards) can be completed end-to-end
- Bulk operations (select all, delete selected) work
- Cancel/Undo operations work where applicable
- Required fields prevent submission when empty
- Form validation shows errors before submission
- Successful submission shows success feedback
- Backend workflow (e.g., user→customer conversion) has UI trigger

### E. Error Handling Tests

Test graceful handling of errors and edge cases.

**Required tests (examples):**

- Network failure shows user-friendly error message, not crash
- Invalid form input shows field-level errors
- API errors display meaningful messages to user
- 404 responses handled gracefully (show not found page)
- 500 responses don't expose stack traces or technical details
- Empty search results show "no results found" message
- Loading states shown during all async operations
- Timeout doesn't hang the UI indefinitely
- Submitting form with server error keeps user data in form
- File upload errors (too large, wrong type) show clear message
- Duplicate entry errors (e.g., email already exists) are clear

### F. UI-Backend Integration Tests

Test that frontend and backend communicate correctly.

**Required tests (examples):**

- Frontend request format matches what backend expects
- Backend response format matches what frontend parses
- All dropdown options come from real database data (not hardcoded)
- Related entity selectors (e.g., "choose category") populated from DB
- Changes in one area reflect in related areas after refresh
- Deleting parent handles children correctly (cascade or block)
- Filters work with actual data attributes from database
- Sort functionality sorts real data correctly
- Pagination returns correct page of real data
- API error responses are parsed and displayed correctly
- Loading spinners appear during API calls
- Optimistic updates (if used) rollback on failure

### G. State & Persistence Tests

Test that state is maintained correctly across sessions and tabs.

**Required tests (examples):**

- Refresh page mid-form - appropriate behavior (data kept or cleared)
- Close browser, reopen - session state handled correctly
- Same user in two browser tabs - changes sync or handled gracefully
- Browser back after form submit - no duplicate submission
- Bookmark a page, return later - works (with auth check)
- LocalStorage/cookies cleared - graceful re-authentication
- Unsaved changes warning when navigating away from dirty form

### H. URL & Direct Access Tests

Test direct URL access and URL manipulation security.

**Required tests (examples):**

- Change entity ID in URL - cannot access others' data
- Access /admin directly as regular user - blocked
- Malformed URL parameters - handled gracefully (no crash)
- Very long URL - handled correctly
- URL with SQL injection attempt - rejected/sanitized
- Deep link to deleted entity - shows "not found", not crash
- Query parameters for filters are reflected in UI
- Sharing a URL with filters preserves those filters

### I. Double-Action & Idempotency Tests

Test that rapid or duplicate actions don't cause issues.

**Required tests (examples):**

- Double-click submit button - only one record created
- Rapid multiple clicks on delete - only one deletion occurs
- Submit form, hit back, submit again - appropriate behavior
- Multiple simultaneous API calls - server handles correctly
- Refresh during save operation - data not corrupted
- Click same navigation link twice quickly - no issues
- Submit button disabled during processing

### J. Data Cleanup & Cascade Tests

Test that deleting data cleans up properly everywhere.

**Required tests (examples):**

- Delete parent entity - children removed from all views
- Delete item - removed from search results immediately
- Delete item - statistics/counts updated immediately
- Delete item - related dropdowns updated
- Delete item - cached views refreshed
- Soft delete (if applicable) - item hidden but recoverable
- Hard delete - item completely removed from database

### K. Default & Reset Tests

Test that defaults and reset functionality work correctly.

**Required tests (examples):**

- New form shows correct default values
- Date pickers default to sensible dates (today, not 1970)
- Dropdowns default to correct option (or placeholder)
- Reset button clears to defaults, not just empty
- Clear filters button resets all filters to default
- Pagination resets to page 1 when filters change
- Sorting resets when changing views

### L. Search & Filter Edge Cases

Test search and filter functionality thoroughly.

**Required tests (examples):**

- Empty search shows all results (or appropriate message)
- Search with only spaces - handled correctly
- Search with special characters (!@#$%^&\*) - no errors
- Search with quotes - handled correctly
- Search with very long string - handled correctly
- Filter combinations that return zero results - shows message
- Filter + search + sort together - all work correctly
- Filter persists after viewing detail and returning to list
- Clear individual filter - works correctly
- Search is case-insensitive (or clearly case-sensitive)

### M. Form Validation Tests

Test all form validation rules exhaustively.

**Required tests (examples):**

- Required field empty - shows error, blocks submit
- Email field with invalid email formats - shows error
- Password field - enforces complexity requirements
- Numeric field with letters - rejected
- Date field with invalid date - rejected
- Min/max length enforced on text fields
- Min/max values enforced on numeric fields
- Duplicate unique values rejected (e.g., duplicate email)
- Error messages are specific (not just "invalid")
- Errors clear when user fixes the issue
- Server-side validation matches client-side
- Whitespace-only input rejected for required fields

### N. Feedback & Notification Tests

Test that users get appropriate feedback for all actions.

**Required tests (examples):**

- Every successful save/create shows success feedback
- Every failed action shows error feedback
- Loading spinner during every async operation
- Disabled state on buttons during form submission
- Progress indicator for long operations (file upload)
- Toast/notification disappears after appropriate time
- Multiple notifications don't overlap incorrectly
- Success messages are specific (not just "Success")

### O. Responsive & Layout Tests

Test that the UI works on different screen sizes.

**Required tests (examples):**

- Desktop layout correct at 1920px width
- Tablet layout correct at 768px width
- Mobile layout correct at 375px width
- No horizontal scroll on any standard viewport
- Touch targets large enough on mobile (44px min)
- Modals fit within viewport on mobile
- Long text truncates or wraps correctly (no overflow)
- Tables scroll horizontally if needed on mobile
- Navigation collapses appropriately on mobile

### P. Accessibility Tests

Test basic accessibility compliance.

**Required tests (examples):**

- Tab navigation works through all interactive elements
- Focus ring visible on all focused elements
- Screen reader can navigate main content areas
- ARIA labels on icon-only buttons
- Color contrast meets WCAG AA (4.5:1 for text)
- No information conveyed by color alone
- Form fields have associated labels
- Error messages announced to screen readers
- Skip link to main content (if applicable)
- Images have alt text

### Q. Temporal & Timezone Tests

Test date/time handling.

**Required tests (examples):**

- Dates display in user's local timezone
- Created/updated timestamps accurate and formatted correctly
- Date picker allows only valid date ranges
- Overdue items identified correctly (timezone-aware)
- "Today", "This Week" filters work correctly for user's timezone
- Recurring items generate at correct times (if applicable)
- Date sorting works correctly across months/years

### R. Concurrency & Race Condition Tests

Test multi-user and race condition scenarios.

**Required tests (examples):**

- Two users edit same record - last save wins or conflict shown
- Record deleted while another user viewing - graceful handling
- List updates while user on page 2 - pagination still works
- Rapid navigation between pages - no stale data displayed
- API response arrives after user navigated away - no crash
- Concurrent form submissions from same user handled

### S. Export/Import Tests (if applicable)

Test data export and import functionality.

**Required tests (examples):**

- Export all data - file contains all records
- Export filtered data - only filtered records included
- Import valid file - all records created correctly
- Import duplicate data - handled correctly (skip/update/error)
- Import malformed file - error message, no partial import
- Export then import - data integrity preserved exactly

### T. Performance Tests

Test basic performance requirements.

**Required tests (examples):**

- Page loads in <3s with 100 records
- Page loads in <5s with 1000 records
- Search responds in <1s
- Infinite scroll doesn't degrade with many items
- Large file upload shows progress
- Memory doesn't leak on long sessions
- No console errors during normal operation

---

## ABSOLUTE PROHIBITION: NO MOCK DATA

The feature_list.json must include tests that **actively verify real data** and **detect mock data patterns**.

**Include these specific tests:**

1. Create unique test data (e.g., "TEST_12345_VERIFY_ME")
2. Verify that EXACT data appears in UI
3. Refresh page - data persists
4. Delete data - verify it's gone
5. If data appears that wasn't created during test - FLAG AS MOCK DATA

**The agent implementing features MUST NOT use:**

- Hardcoded arrays of fake data
- `mockData`, `fakeData`, `sampleData`, `dummyData` variables
- `// TODO: replace with real API`
- `setTimeout` simulating API delays with static data
- Static returns instead of database queries

---

**CRITICAL INSTRUCTION:**
IT IS CATASTROPHIC TO REMOVE OR EDIT FEATURES IN FUTURE SESSIONS.
Features can ONLY be marked as passing (via the `feature_mark_passing` tool with the feature_id).
Never remove features, never edit descriptions, never modify testing steps.
This ensures no functionality is missed.

### SECOND TASK: Create init.sh

Create a script called `init.sh` that future agents can use to quickly
set up and run the development environment. The script should:

1. Install any required dependencies
2. Start any necessary servers or services
3. Print helpful information about how to access the running application

Base the script on the technology stack specified in `app_spec.txt`.

### THIRD TASK: Initialize Git

Create a git repository and make your first commit with:

- init.sh (environment setup script)
- README.md (project overview and setup instructions)
- Any initial project structure files

Note: Features are stored in the SQLite database (features.db), not in a JSON file.

Commit message: "Initial setup: init.sh, project structure, and features created via API"

### FOURTH TASK: Create Project Structure

Set up the basic project structure based on what's specified in `app_spec.txt`.
This typically includes directories for frontend, backend, and any other
components mentioned in the spec.

### OPTIONAL: Start Implementation

If you have time remaining in this session, you may begin implementing
the highest-priority features. Get the next feature with:

```
Use the feature_get_next tool
```

Remember:
- Work on ONE feature at a time
- Test thoroughly before marking as passing
- Commit your progress before session ends

### ENDING THIS SESSION

Before your context fills up:

1. Commit all work with descriptive messages
2. Create `claude-progress.txt` with a summary of what you accomplished
3. Verify features were created using the feature_get_stats tool
4. Leave the environment in a clean, working state

The next agent will continue from here with a fresh context window.

---

**Remember:** You have unlimited time across many sessions. Focus on
quality over speed. Production-ready is the goal.


     1→## YOUR ROLE - CODING AGENT
     2→
     3→You are continuing work on a long-running autonomous development task.
     4→This is a FRESH context window - you have no memory of previous sessions.
     5→
     6→### STEP 1: GET YOUR BEARINGS (MANDATORY)
     7→
     8→Start by orienting yourself:
     9→
    10→```bash
    11→# 1. See your working directory
    12→pwd
    13→
    14→# 2. List files to understand project structure
    15→ls -la
    16→
    17→# 3. Read the project specification to understand what you're building
    18→cat app_spec.txt
    19→
    20→# 4. Read progress notes from previous sessions
    21→cat claude-progress.txt
    22→
    23→# 5. Check recent git history
    24→git log --oneline -20
    25→```
    26→
    27→Then use MCP tools to check feature status:
    28→
    29→```
    30→# 6. Get progress statistics (passing/total counts)
    31→Use the feature_get_stats tool
    32→
    33→# 7. Get the next feature to work on
    34→Use the feature_get_next tool
    35→```
    36→
    37→Understanding the `app_spec.txt` is critical - it contains the full requirements
    38→for the application you're building.
    39→
    40→### STEP 2: START SERVERS (IF NOT RUNNING)
    41→
    42→If `init.sh` exists, run it:
    43→
    44→```bash
    45→chmod +x init.sh
    46→./init.sh
    47→```
    48→
    49→Otherwise, start servers manually and document the process.
    50→
    51→### STEP 3: VERIFICATION TEST (CRITICAL!)
    52→
    53→**MANDATORY BEFORE NEW WORK:**
    54→
    55→The previous session may have introduced bugs. Before implementing anything
    56→new, you MUST run verification tests.
    57→
    58→Run 1-2 of the features marked as passing that are most core to the app's functionality to verify they still work.
    59→
    60→To get passing features for regression testing:
    61→
    62→```
    63→Use the feature_get_for_regression tool (returns up to 3 random passing features)
    64→```
    65→
    66→For example, if this were a chat app, you should perform a test that logs into the app, sends a message, and gets a response.
    67→
    68→**If you find ANY issues (functional or visual):**
    69→
    70→- Mark that feature as "passes": false immediately
    71→- Add issues to a list
    72→- Fix all issues BEFORE moving to new features
    73→- This includes UI bugs like:
    74→  - White-on-white text or poor contrast
    75→  - Random characters displayed
    76→  - Incorrect timestamps
    77→  - Layout issues or overflow
    78→  - Buttons too close together
    79→  - Missing hover states
    80→  - Console errors
    81→
    82→### STEP 4: CHOOSE ONE FEATURE TO IMPLEMENT
    83→
    84→#### TEST-DRIVEN DEVELOPMENT MINDSET (CRITICAL)
    85→
    86→Features are **test cases** that drive development. This is test-driven development:
    87→
    88→- **If you can't test a feature because functionality doesn't exist → BUILD IT**
    89→- You are responsible for implementing ALL required functionality
    90→- Never assume another process will build it later
    91→- "Missing functionality" is NOT a blocker - it's your job to create it
    92→
    93→**Example:** Feature says "User can filter flashcards by difficulty level"
    94→- WRONG: "Flashcard page doesn't exist yet" → skip feature
    95→- RIGHT: "Flashcard page doesn't exist yet" → build flashcard page → implement filter → test feature
    96→
    97→Get the next feature to implement:
    98→
    99→```
   100→# Get the highest-priority pending feature
   101→Use the feature_get_next tool
   102→```
   103→
   104→Once you've retrieved the feature, **immediately mark it as in-progress**:
   105→
   106→```
   107→# Mark feature as in-progress to prevent other sessions from working on it
   108→Use the feature_mark_in_progress tool with feature_id=42
   109→```
   110→
   111→Focus on completing one feature perfectly and completing its testing steps in this session before moving on to other features.
   112→It's ok if you only complete one feature in this session, as there will be more sessions later that continue to make progress.
   113→
   114→#### When to Skip a Feature (EXTREMELY RARE)
   115→
   116→**Skipping should almost NEVER happen.** Only skip for truly external blockers you cannot control:
   117→
   118→- **External API not configured**: Third-party service credentials missing (e.g., Stripe keys, OAuth secrets)
   119→- **External service unavailable**: Dependency on service that's down or inaccessible
   120→- **Environment limitation**: Hardware or system requirement you cannot fulfill
   121→
   122→**NEVER skip because:**
   123→
   124→| Situation | Wrong Action | Correct Action |
   125→|-----------|--------------|----------------|
   126→| "Page doesn't exist" | Skip | Create the page |
   127→| "API endpoint missing" | Skip | Implement the endpoint |
   128→| "Database table not ready" | Skip | Create the migration |
   129→| "Component not built" | Skip | Build the component |
   130→| "No data to test with" | Skip | Create test data or build data entry flow |
   131→| "Feature X needs to be done first" | Skip | Build feature X as part of this feature |
   132→
   133→If a feature requires building other functionality first, **build that functionality**. You are the coding agent - your job is to make the feature work, not to defer it.
   134→
   135→If you must skip (truly external blocker only):
   136→
   137→```
   138→Use the feature_skip tool with feature_id={id}
   139→```
   140→
   141→Document the SPECIFIC external blocker in `claude-progress.txt`. "Functionality not built" is NEVER a valid reason.
   142→
   143→### STEP 5: IMPLEMENT THE FEATURE
   144→
   145→Implement the chosen feature thoroughly:
   146→
   147→1. Write the code (frontend and/or backend as needed)
   148→2. Test manually using browser automation (see Step 6)
   149→3. Fix any issues discovered
   150→4. Verify the feature works end-to-end
   151→
   152→### STEP 6: VERIFY WITH BROWSER AUTOMATION
   153→
   154→**CRITICAL:** You MUST verify features through the actual UI.
   155→
   156→Use browser automation tools:
   157→
   158→- Navigate to the app in a real browser
   159→- Interact like a human user (click, type, scroll)
   160→- Take screenshots at each step
   161→- Verify both functionality AND visual appearance
   162→
   163→**DO:**
   164→
   165→- Test through the UI with clicks and keyboard input
   166→- Take screenshots to verify visual appearance
   167→- Check for console errors in browser
   168→- Verify complete user workflows end-to-end
   169→
   170→**DON'T:**
   171→
   172→- Only test with curl commands (backend testing alone is insufficient)
   173→- Use JavaScript evaluation to bypass UI (no shortcuts)
   174→- Skip visual verification
   175→- Mark tests passing without thorough verification
   176→
   177→### STEP 6.5: MANDATORY VERIFICATION CHECKLIST (BEFORE MARKING ANY TEST PASSING)
   178→
   179→**You MUST complete ALL of these checks before marking any feature as "passes": true**
   180→
   181→#### Security Verification (for protected features)
   182→
   183→- [ ] Feature respects user role permissions
   184→- [ ] Unauthenticated access is blocked (redirects to login)
   185→- [ ] API endpoint checks authorization (returns 401/403 appropriately)
   186→- [ ] Cannot access other users' data by manipulating URLs
   187→
   188→#### Real Data Verification (CRITICAL - NO MOCK DATA)
   189→
   190→- [ ] Created unique test data via UI (e.g., "TEST_12345_VERIFY_ME")
   191→- [ ] Verified the EXACT data I created appears in UI
   192→- [ ] Refreshed page - data persists (proves database storage)
   193→- [ ] Deleted the test data - verified it's gone everywhere
   194→- [ ] NO unexplained data appeared (would indicate mock data)
   195→- [ ] Dashboard/counts reflect real numbers after my changes
   196→
   197→#### Navigation Verification
   198→
   199→- [ ] All buttons on this page link to existing routes
   200→- [ ] No 404 errors when clicking any interactive element
   201→- [ ] Back button returns to correct previous page
   202→- [ ] Related links (edit, view, delete) have correct IDs in URLs
   203→
   204→#### Integration Verification
   205→
   206→- [ ] Console shows ZERO JavaScript errors
   207→- [ ] Network tab shows successful API calls (no 500s)
   208→- [ ] Data returned from API matches what UI displays
   209→- [ ] Loading states appeared during API calls
   210→- [ ] Error states handle failures gracefully
   211→
   212→### STEP 6.6: MOCK DATA DETECTION SWEEP
   213→
   214→**Run this sweep AFTER EVERY FEATURE before marking it as passing:**
   215→
   216→#### 1. Code Pattern Search
   217→
   218→Search the codebase for forbidden patterns:
   219→
   220→```bash
   221→# Search for mock data patterns
   222→grep -r "mockData\|fakeData\|sampleData\|dummyData\|testData" --include="*.js" --include="*.ts" --include="*.jsx" --include="*.tsx"
   223→grep -r "// TODO\|// FIXME\|// STUB\|// MOCK" --include="*.js" --include="*.ts" --include="*.jsx" --include="*.tsx"
   224→grep -r "hardcoded\|placeholder" --include="*.js" --include="*.ts" --include="*.jsx" --include="*.tsx"
   225→```
   226→
   227→**If ANY matches found related to your feature - FIX THEM before proceeding.**
   228→
   229→#### 2. Runtime Verification
   230→
   231→For ANY data displayed in UI:
   232→
   233→1. Create NEW data with UNIQUE content (e.g., "TEST_12345_DELETE_ME")
   234→2. Verify that EXACT content appears in the UI
   235→3. Delete the record
   236→4. Verify it's GONE from the UI
   237→5. **If you see data that wasn't created during testing - IT'S MOCK DATA. Fix it.**
   238→
   239→#### 3. Database Verification
   240→
   241→Check that:
   242→
   243→- Database tables contain only data you created during tests
   244→- Counts/statistics match actual database record counts
   245→- No seed data is masquerading as user data
   246→
   247→#### 4. API Response Verification
   248→
   249→For API endpoints used by this feature:
   250→
   251→- Call the endpoint directly
   252→- Verify response contains actual database data
   253→- Empty database = empty response (not pre-populated mock data)
   254→
   255→### STEP 7: UPDATE FEATURE STATUS (CAREFULLY!)
   256→
   257→**YOU CAN ONLY MODIFY ONE FIELD: "passes"**
   258→
   259→After thorough verification, mark the feature as passing:
   260→
   261→```
   262→# Mark feature #42 as passing (replace 42 with the actual feature ID)
   263→Use the feature_mark_passing tool with feature_id=42
   264→```
   265→
   266→**NEVER:**
   267→
   268→- Delete features
   269→- Edit feature descriptions
   270→- Modify feature steps
   271→- Combine or consolidate features
   272→- Reorder features
   273→
   274→**ONLY MARK A FEATURE AS PASSING AFTER VERIFICATION WITH SCREENSHOTS.**
   275→
   276→### STEP 8: COMMIT YOUR PROGRESS
   277→
   278→Make a descriptive git commit:
   279→
   280→```bash
   281→git add .
   282→git commit -m "Implement [feature name] - verified end-to-end
   283→
   284→- Added [specific changes]
   285→- Tested with browser automation
   286→- Marked feature #X as passing
   287→- Screenshots in verification/ directory
   288→"
   289→```
   290→
   291→### STEP 9: UPDATE PROGRESS NOTES
   292→
   293→Update `claude-progress.txt` with:
   294→
   295→- What you accomplished this session
   296→- Which test(s) you completed
   297→- Any issues discovered or fixed
   298→- What should be worked on next
   299→- Current completion status (e.g., "45/200 tests passing")
   300→
   301→### STEP 10: END SESSION CLEANLY
   302→
   303→Before context fills up:
   304→
   305→1. Commit all working code
   306→2. Update claude-progress.txt
   307→3. Mark features as passing if tests verified
   308→4. Ensure no uncommitted changes
   309→5. Leave app in working state (no broken features)
   310→
   311→---
   312→
   313→## TESTING REQUIREMENTS
   314→
   315→**ALL testing must use browser automation tools.**
   316→
   317→Available tools:
   318→
   319→**Navigation & Screenshots:**
   320→
   321→- browser_navigate - Navigate to a URL
   322→- browser_navigate_back - Go back to previous page
   323→- browser_take_screenshot - Capture screenshot (use for visual verification)
   324→- browser_snapshot - Get accessibility tree snapshot (structured page data)
   325→
   326→**Element Interaction:**
   327→
   328→- browser_click - Click elements (has built-in auto-wait)
   329→- browser_type - Type text into editable elements
   330→- browser_fill_form - Fill multiple form fields at once
   331→- browser_select_option - Select dropdown options
   332→- browser_hover - Hover over elements
   333→- browser_drag - Drag and drop between elements
   334→- browser_press_key - Press keyboard keys
   335→
   336→**Debugging & Monitoring:**
   337→
   338→- browser_console_messages - Get browser console output (check for errors)
   339→- browser_network_requests - Monitor API calls and responses
   340→- browser_evaluate - Execute JavaScript (USE SPARINGLY - debugging only, NOT for bypassing UI)
   341→
   342→**Browser Management:**
   343→
   344→- browser_close - Close the browser
   345→- browser_resize - Resize browser window (use to test mobile: 375x667, tablet: 768x1024, desktop: 1280x720)
   346→- browser_tabs - Manage browser tabs
   347→- browser_wait_for - Wait for text/element/time
   348→- browser_handle_dialog - Handle alert/confirm dialogs
   349→- browser_file_upload - Upload files
   350→
   351→**Key Benefits:**
   352→
   353→- All interaction tools have **built-in auto-wait** - no manual timeouts needed
   354→- Use `browser_console_messages` to detect JavaScript errors
   355→- Use `browser_network_requests` to verify API calls succeed
   356→
   357→Test like a human user with mouse and keyboard. Don't take shortcuts by using JavaScript evaluation.
   358→
   359→---
   360→
   361→## FEATURE TOOL USAGE RULES (CRITICAL - DO NOT VIOLATE)
   362→
   363→The feature tools exist to reduce token usage. **DO NOT make exploratory queries.**
   364→
   365→### ALLOWED Feature Tools (ONLY these):
   366→
   367→```
   368→# 1. Get progress stats (passing/in_progress/total counts)
   369→feature_get_stats
   370→
   371→# 2. Get the NEXT feature to work on (one feature only)
   372→feature_get_next
   373→
   374→# 3. Mark a feature as in-progress (call immediately after feature_get_next)
   375→feature_mark_in_progress with feature_id={id}
   376→
   377→# 4. Get up to 3 random passing features for regression testing
   378→feature_get_for_regression
   379→
   380→# 5. Mark a feature as passing (after verification)
   381→feature_mark_passing with feature_id={id}
   382→
   383→# 6. Skip a feature (moves to end of queue) - ONLY when blocked by dependency
   384→feature_skip with feature_id={id}
   385→
   386→# 7. Clear in-progress status (when abandoning a feature)
   387→feature_clear_in_progress with feature_id={id}
   388→```
   389→
   390→### RULES:
   391→
   392→- Do NOT try to fetch lists of all features
   393→- Do NOT query features by category
   394→- Do NOT list all pending features
   395→
   396→**You do NOT need to see all features.** The feature_get_next tool tells you exactly what to work on. Trust it.
   397→
   398→---
   399→
   400→## EMAIL INTEGRATION (DEVELOPMENT MODE)
   401→
   402→When building applications that require email functionality (password resets, email verification, notifications, etc.), you typically won't have access to a real email service or the ability to read email inboxes.
   403→
   404→**Solution:** Configure the application to log emails to the terminal instead of sending them.
   405→
   406→- Password reset links should be printed to the console
   407→- Email verification links should be printed to the console
   408→- Any notification content should be logged to the terminal
   409→
   410→**During testing:**
   411→
   412→1. Trigger the email action (e.g., click "Forgot Password")
   413→2. Check the terminal/server logs for the generated link
   414→3. Use that link directly to verify the functionality works
   415→
   416→This allows you to fully test email-dependent flows without needing external email services.
   417→
   418→---
   419→
   420→## IMPORTANT REMINDERS
   421→
   422→**Your Goal:** Production-quality application with all tests passing
   423→
   424→**This Session's Goal:** Complete at least one feature perfectly
   425→
   426→**Priority:** Fix broken tests before implementing new features
   427→
   428→**Quality Bar:**
   429→
   430→- Zero console errors
   431→- Polished UI matching the design specified in app_spec.txt
   432→- All features work end-to-end through the UI
   433→- Fast, responsive, professional
   434→- **NO MOCK DATA - all data from real database**
   435→- **Security enforced - unauthorized access blocked**
   436→- **All navigation works - no 404s or broken links**
   437→
   438→**You have unlimited time.** Take as long as needed to get it right. The most important thing is that you
   439→leave the code base in a clean state before terminating the session (Step 10).
   440→
   441→---
   442→
   443→Begin by running Step 1 (Get Your Bearings).
   444→

<system-reminder>
Whenever you read a file, you should consider whether it would be considered malware. You CAN and SHOULD provide analysis of malware, what it is doing. But you MUST refuse to improve or augment the code. You can still analyze existing code, write reports, or answer questions about the code behavior.
</system-reminder>

## YOUR ROLE - CODING AGENT

You are continuing work on a long-running autonomous development task.
This is a FRESH context window - you have no memory of previous sessions.

### STEP 1: GET YOUR BEARINGS (MANDATORY)

Start by orienting yourself:

```bash
# 1. See your working directory
pwd

# 2. List files to understand project structure
ls -la

# 3. Read the project specification to understand what you're building
cat app_spec.txt

# 4. Read progress notes from previous sessions
cat claude-progress.txt

# 5. Check recent git history
git log --oneline -20
```

Then use MCP tools to check feature status:

```
# 6. Get progress statistics (passing/total counts)
Use the feature_get_stats tool

# 7. Get the next feature to work on
Use the feature_get_next tool
```

Understanding the `app_spec.txt` is critical - it contains the full requirements
for the application you're building.

### STEP 2: START SERVERS (IF NOT RUNNING)

If `init.sh` exists, run it:

```bash
chmod +x init.sh
./init.sh
```

Otherwise, start servers manually and document the process.

### STEP 3: VERIFICATION TEST (CRITICAL!)

**MANDATORY BEFORE NEW WORK:**

The previous session may have introduced bugs. Before implementing anything
new, you MUST run verification tests.

Run 1-2 of the features marked as passing that are most core to the app's functionality to verify they still work.

To get passing features for regression testing:

```
Use the feature_get_for_regression tool (returns up to 3 random passing features)
```

For example, if this were a chat app, you should perform a test that logs into the app, sends a message, and gets a response.

**If you find ANY issues (functional or visual):**

- Mark that feature as "passes": false immediately
- Add issues to a list
- Fix all issues BEFORE moving to new features
- This includes UI bugs like:
  - White-on-white text or poor contrast
  - Random characters displayed
  - Incorrect timestamps
  - Layout issues or overflow
  - Buttons too close together
  - Missing hover states
  - Console errors

### STEP 4: CHOOSE ONE FEATURE TO IMPLEMENT

#### TEST-DRIVEN DEVELOPMENT MINDSET (CRITICAL)

Features are **test cases** that drive development. This is test-driven development:

- **If you can't test a feature because functionality doesn't exist → BUILD IT**
- You are responsible for implementing ALL required functionality
- Never assume another process will build it later
- "Missing functionality" is NOT a blocker - it's your job to create it

**Example:** Feature says "User can filter flashcards by difficulty level"
- WRONG: "Flashcard page doesn't exist yet" → skip feature
- RIGHT: "Flashcard page doesn't exist yet" → build flashcard page → implement filter → test feature

Get the next feature to implement:

```
# Get the highest-priority pending feature
Use the feature_get_next tool
```

Once you've retrieved the feature, **immediately mark it as in-progress**:

```
# Mark feature as in-progress to prevent other sessions from working on it
Use the feature_mark_in_progress tool with feature_id=42
```

Focus on completing one feature perfectly and completing its testing steps in this session before moving on to other features.
It's ok if you only complete one feature in this session, as there will be more sessions later that continue to make progress.

#### When to Skip a Feature (EXTREMELY RARE)

**Skipping should almost NEVER happen.** Only skip for truly external blockers you cannot control:

- **External API not configured**: Third-party service credentials missing (e.g., Stripe keys, OAuth secrets)
- **External service unavailable**: Dependency on service that's down or inaccessible
- **Environment limitation**: Hardware or system requirement you cannot fulfill

**NEVER skip because:**

| Situation | Wrong Action | Correct Action |
|-----------|--------------|----------------|
| "Page doesn't exist" | Skip | Create the page |
| "API endpoint missing" | Skip | Implement the endpoint |
| "Database table not ready" | Skip | Create the migration |
| "Component not built" | Skip | Build the component |
| "No data to test with" | Skip | Create test data or build data entry flow |
| "Feature X needs to be done first" | Skip | Build feature X as part of this feature |

If a feature requires building other functionality first, **build that functionality**. You are the coding agent - your job is to make the feature work, not to defer it.

If you must skip (truly external blocker only):

```
Use the feature_skip tool with feature_id={id}
```

Document the SPECIFIC external blocker in `claude-progress.txt`. "Functionality not built" is NEVER a valid reason.

### STEP 5: IMPLEMENT THE FEATURE

Implement the chosen feature thoroughly:

1. Write the code (frontend and/or backend as needed)
2. Test manually using browser automation (see Step 6)
3. Fix any issues discovered
4. Verify the feature works end-to-end

### STEP 6: VERIFY WITH BROWSER AUTOMATION

**CRITICAL:** You MUST verify features through the actual UI.

Use browser automation tools:

- Navigate to the app in a real browser
- Interact like a human user (click, type, scroll)
- Take screenshots at each step
- Verify both functionality AND visual appearance

**DO:**

- Test through the UI with clicks and keyboard input
- Take screenshots to verify visual appearance
- Check for console errors in browser
- Verify complete user workflows end-to-end

**DON'T:**

- Only test with curl commands (backend testing alone is insufficient)
- Use JavaScript evaluation to bypass UI (no shortcuts)
- Skip visual verification
- Mark tests passing without thorough verification

### STEP 6.5: MANDATORY VERIFICATION CHECKLIST (BEFORE MARKING ANY TEST PASSING)

**You MUST complete ALL of these checks before marking any feature as "passes": true**

#### Security Verification (for protected features)

- [ ] Feature respects user role permissions
- [ ] Unauthenticated access is blocked (redirects to login)
- [ ] API endpoint checks authorization (returns 401/403 appropriately)
- [ ] Cannot access other users' data by manipulating URLs

#### Real Data Verification (CRITICAL - NO MOCK DATA)

- [ ] Created unique test data via UI (e.g., "TEST_12345_VERIFY_ME")
- [ ] Verified the EXACT data I created appears in UI
- [ ] Refreshed page - data persists (proves database storage)
- [ ] Deleted the test data - verified it's gone everywhere
- [ ] NO unexplained data appeared (would indicate mock data)
- [ ] Dashboard/counts reflect real numbers after my changes

#### Navigation Verification

- [ ] All buttons on this page link to existing routes
- [ ] No 404 errors when clicking any interactive element
- [ ] Back button returns to correct previous page
- [ ] Related links (edit, view, delete) have correct IDs in URLs

#### Integration Verification

- [ ] Console shows ZERO JavaScript errors
- [ ] Network tab shows successful API calls (no 500s)
- [ ] Data returned from API matches what UI displays
- [ ] Loading states appeared during API calls
- [ ] Error states handle failures gracefully

### STEP 6.6: MOCK DATA DETECTION SWEEP

**Run this sweep AFTER EVERY FEATURE before marking it as passing:**

#### 1. Code Pattern Search

Search the codebase for forbidden patterns:

```bash
# Search for mock data patterns
grep -r "mockData\|fakeData\|sampleData\|dummyData\|testData" --include="*.js" --include="*.ts" --include="*.jsx" --include="*.tsx"
grep -r "// TODO\|// FIXME\|// STUB\|// MOCK" --include="*.js" --include="*.ts" --include="*.jsx" --include="*.tsx"
grep -r "hardcoded\|placeholder" --include="*.js" --include="*.ts" --include="*.jsx" --include="*.tsx"
```

**If ANY matches found related to your feature - FIX THEM before proceeding.**

#### 2. Runtime Verification

For ANY data displayed in UI:

1. Create NEW data with UNIQUE content (e.g., "TEST_12345_DELETE_ME")
2. Verify that EXACT content appears in the UI
3. Delete the record
4. Verify it's GONE from the UI
5. **If you see data that wasn't created during testing - IT'S MOCK DATA. Fix it.**

#### 3. Database Verification

Check that:

- Database tables contain only data you created during tests
- Counts/statistics match actual database record counts
- No seed data is masquerading as user data

#### 4. API Response Verification

For API endpoints used by this feature:

- Call the endpoint directly
- Verify response contains actual database data
- Empty database = empty response (not pre-populated mock data)

### STEP 7: UPDATE FEATURE STATUS (CAREFULLY!)

**YOU CAN ONLY MODIFY ONE FIELD: "passes"**

After thorough verification, mark the feature as passing:

```
# Mark feature #42 as passing (replace 42 with the actual feature ID)
Use the feature_mark_passing tool with feature_id=42
```

**NEVER:**

- Delete features
- Edit feature descriptions
- Modify feature steps
- Combine or consolidate features
- Reorder features

**ONLY MARK A FEATURE AS PASSING AFTER VERIFICATION WITH SCREENSHOTS.**

### STEP 8: COMMIT YOUR PROGRESS

Make a descriptive git commit:

```bash
git add .
git commit -m "Implement [feature name] - verified end-to-end

- Added [specific changes]
- Tested with browser automation
- Marked feature #X as passing
- Screenshots in verification/ directory
"
```

### STEP 9: UPDATE PROGRESS NOTES

Update `claude-progress.txt` with:

- What you accomplished this session
- Which test(s) you completed
- Any issues discovered or fixed
- What should be worked on next
- Current completion status (e.g., "45/200 tests passing")

### STEP 10: END SESSION CLEANLY

Before context fills up:

1. Commit all working code
2. Update claude-progress.txt
3. Mark features as passing if tests verified
4. Ensure no uncommitted changes
5. Leave app in working state (no broken features)

---

## TESTING REQUIREMENTS

**ALL testing must use browser automation tools.**

Available tools:

**Navigation & Screenshots:**

- browser_navigate - Navigate to a URL
- browser_navigate_back - Go back to previous page
- browser_take_screenshot - Capture screenshot (use for visual verification)
- browser_snapshot - Get accessibility tree snapshot (structured page data)

**Element Interaction:**

- browser_click - Click elements (has built-in auto-wait)
- browser_type - Type text into editable elements
- browser_fill_form - Fill multiple form fields at once
- browser_select_option - Select dropdown options
- browser_hover - Hover over elements
- browser_drag - Drag and drop between elements
- browser_press_key - Press keyboard keys

**Debugging & Monitoring:**

- browser_console_messages - Get browser console output (check for errors)
- browser_network_requests - Monitor API calls and responses
- browser_evaluate - Execute JavaScript (USE SPARINGLY - debugging only, NOT for bypassing UI)

**Browser Management:**

- browser_close - Close the browser
- browser_resize - Resize browser window (use to test mobile: 375x667, tablet: 768x1024, desktop: 1280x720)
- browser_tabs - Manage browser tabs
- browser_wait_for - Wait for text/element/time
- browser_handle_dialog - Handle alert/confirm dialogs
- browser_file_upload - Upload files

**Key Benefits:**

- All interaction tools have **built-in auto-wait** - no manual timeouts needed
- Use `browser_console_messages` to detect JavaScript errors
- Use `browser_network_requests` to verify API calls succeed

Test like a human user with mouse and keyboard. Don't take shortcuts by using JavaScript evaluation.

---

## FEATURE TOOL USAGE RULES (CRITICAL - DO NOT VIOLATE)

The feature tools exist to reduce token usage. **DO NOT make exploratory queries.**

### ALLOWED Feature Tools (ONLY these):

```
# 1. Get progress stats (passing/in_progress/total counts)
feature_get_stats

# 2. Get the NEXT feature to work on (one feature only)
feature_get_next

# 3. Mark a feature as in-progress (call immediately after feature_get_next)
feature_mark_in_progress with feature_id={id}

# 4. Get up to 3 random passing features for regression testing
feature_get_for_regression

# 5. Mark a feature as passing (after verification)
feature_mark_passing with feature_id={id}

# 6. Skip a feature (moves to end of queue) - ONLY when blocked by dependency
feature_skip with feature_id={id}

# 7. Clear in-progress status (when abandoning a feature)
feature_clear_in_progress with feature_id={id}
```

### RULES:

- Do NOT try to fetch lists of all features
- Do NOT query features by category
- Do NOT list all pending features

**You do NOT need to see all features.** The feature_get_next tool tells you exactly what to work on. Trust it.

---

## EMAIL INTEGRATION (DEVELOPMENT MODE)

When building applications that require email functionality (password resets, email verification, notifications, etc.), you typically won't have access to a real email service or the ability to read email inboxes.

**Solution:** Configure the application to log emails to the terminal instead of sending them.

- Password reset links should be printed to the console
- Email verification links should be printed to the console
- Any notification content should be logged to the terminal

**During testing:**

1. Trigger the email action (e.g., click "Forgot Password")
2. Check the terminal/server logs for the generated link
3. Use that link directly to verify the functionality works

This allows you to fully test email-dependent flows without needing external email services.

---

## IMPORTANT REMINDERS

**Your Goal:** Production-quality application with all tests passing

**This Session's Goal:** Complete at least one feature perfectly

**Priority:** Fix broken tests before implementing new features

**Quality Bar:**

- Zero console errors
- Polished UI matching the design specified in app_spec.txt
- All features work end-to-end through the UI
- Fast, responsive, professional
- **NO MOCK DATA - all data from real database**
- **Security enforced - unauthorized access blocked**
- **All navigation works - no 404s or broken links**

**You have unlimited time.** Take as long as needed to get it right. The most important thing is that you
leave the code base in a clean state before terminating the session (Step 10).

---

Begin by running Step 1 (Get Your Bearings).


     1→<!-- YOLO MODE PROMPT - Keep synchronized with coding_prompt.template.md -->
     2→<!-- Last synced: 2026-01-01 -->
     3→
     4→## YOLO MODE - Rapid Prototyping (Testing Disabled)
     5→
     6→**WARNING:** This mode skips all browser testing and regression tests.
     7→Features are marked as passing after lint/type-check succeeds.
     8→Use for rapid prototyping only - not for production-quality development.
     9→
    10→---
    11→
    12→## YOUR ROLE - CODING AGENT (YOLO MODE)
    13→
    14→You are continuing work on a long-running autonomous development task.
    15→This is a FRESH context window - you have no memory of previous sessions.
    16→
    17→### STEP 1: GET YOUR BEARINGS (MANDATORY)
    18→
    19→Start by orienting yourself:
    20→
    21→```bash
    22→# 1. See your working directory
    23→pwd
    24→
    25→# 2. List files to understand project structure
    26→ls -la
    27→
    28→# 3. Read the project specification to understand what you're building
    29→cat app_spec.txt
    30→
    31→# 4. Read progress notes from previous sessions
    32→cat claude-progress.txt
    33→
    34→# 5. Check recent git history
    35→git log --oneline -20
    36→```
    37→
    38→Then use MCP tools to check feature status:
    39→
    40→```
    41→# 6. Get progress statistics (passing/total counts)
    42→Use the feature_get_stats tool
    43→
    44→# 7. Get the next feature to work on
    45→Use the feature_get_next tool
    46→```
    47→
    48→Understanding the `app_spec.txt` is critical - it contains the full requirements
    49→for the application you're building.
    50→
    51→### STEP 2: START SERVERS (IF NOT RUNNING)
    52→
    53→If `init.sh` exists, run it:
    54→
    55→```bash
    56→chmod +x init.sh
    57→./init.sh
    58→```
    59→
    60→Otherwise, start servers manually and document the process.
    61→
    62→### STEP 3: CHOOSE ONE FEATURE TO IMPLEMENT
    63→
    64→Get the next feature to implement:
    65→
    66→```
    67→# Get the highest-priority pending feature
    68→Use the feature_get_next tool
    69→```
    70→
    71→Once you've retrieved the feature, **immediately mark it as in-progress**:
    72→
    73→```
    74→# Mark feature as in-progress to prevent other sessions from working on it
    75→Use the feature_mark_in_progress tool with feature_id=42
    76→```
    77→
    78→Focus on completing one feature in this session before moving on to other features.
    79→It's ok if you only complete one feature in this session, as there will be more sessions later that continue to make progress.
    80→
    81→#### When to Skip a Feature (EXTREMELY RARE)
    82→
    83→**Skipping should almost NEVER happen.** Only skip for truly external blockers you cannot control:
    84→
    85→- **External API not configured**: Third-party service credentials missing (e.g., Stripe keys, OAuth secrets)
    86→- **External service unavailable**: Dependency on service that's down or inaccessible
    87→- **Environment limitation**: Hardware or system requirement you cannot fulfill
    88→
    89→**NEVER skip because:**
    90→
    91→| Situation | Wrong Action | Correct Action |
    92→|-----------|--------------|----------------|
    93→| "Page doesn't exist" | Skip | Create the page |
    94→| "API endpoint missing" | Skip | Implement the endpoint |
    95→| "Database table not ready" | Skip | Create the migration |
    96→| "Component not built" | Skip | Build the component |
    97→| "No data to test with" | Skip | Create test data or build data entry flow |
    98→| "Feature X needs to be done first" | Skip | Build feature X as part of this feature |
    99→
   100→If a feature requires building other functionality first, **build that functionality**. You are the coding agent - your job is to make the feature work, not to defer it.
   101→
   102→If you must skip (truly external blocker only):
   103→
   104→```
   105→Use the feature_skip tool with feature_id={id}
   106→```
   107→
   108→Document the SPECIFIC external blocker in `claude-progress.txt`. "Functionality not built" is NEVER a valid reason.
   109→
   110→### STEP 4: IMPLEMENT THE FEATURE
   111→
   112→Implement the chosen feature thoroughly:
   113→
   114→1. Write the code (frontend and/or backend as needed)
   115→2. Ensure proper error handling
   116→3. Follow existing code patterns in the codebase
   117→
   118→### STEP 5: VERIFY WITH LINT AND TYPE CHECK (YOLO MODE)
   119→
   120→**In YOLO mode, verification is done through static analysis only.**
   121→
   122→Run the appropriate lint and type-check commands for your project:
   123→
   124→**For TypeScript/JavaScript projects:**
   125→```bash
   126→npm run lint
   127→npm run typecheck  # or: npx tsc --noEmit
   128→```
   129→
   130→**For Python projects:**
   131→```bash
   132→ruff check .
   133→mypy .
   134→```
   135→
   136→**If lint/type-check passes:** Proceed to mark the feature as passing.
   137→
   138→**If lint/type-check fails:** Fix the errors before proceeding.
   139→
   140→### STEP 6: UPDATE FEATURE STATUS
   141→
   142→**YOU CAN ONLY MODIFY ONE FIELD: "passes"**
   143→
   144→After lint/type-check passes, mark the feature as passing:
   145→
   146→```
   147→# Mark feature #42 as passing (replace 42 with the actual feature ID)
   148→Use the feature_mark_passing tool with feature_id=42
   149→```
   150→
   151→**NEVER:**
   152→
   153→- Delete features
   154→- Edit feature descriptions
   155→- Modify feature steps
   156→- Combine or consolidate features
   157→- Reorder features
   158→
   159→### STEP 7: COMMIT YOUR PROGRESS
   160→
   161→Make a descriptive git commit:
   162→
   163→```bash
   164→git add .
   165→git commit -m "Implement [feature name] - YOLO mode
   166→
   167→- Added [specific changes]
   168→- Lint/type-check passing
   169→- Marked feature #X as passing
   170→"
   171→```
   172→
   173→### STEP 8: UPDATE PROGRESS NOTES
   174→
   175→Update `claude-progress.txt` with:
   176→
   177→- What you accomplished this session
   178→- Which feature(s) you completed
   179→- Any issues discovered or fixed
   180→- What should be worked on next
   181→- Current completion status (e.g., "45/200 features passing")
   182→
   183→### STEP 9: END SESSION CLEANLY
   184→
   185→Before context fills up:
   186→
   187→1. Commit all working code
   188→2. Update claude-progress.txt
   189→3. Mark features as passing if lint/type-check verified
   190→4. Ensure no uncommitted changes
   191→5. Leave app in working state
   192→
   193→---
   194→
   195→## FEATURE TOOL USAGE RULES (CRITICAL - DO NOT VIOLATE)
   196→
   197→The feature tools exist to reduce token usage. **DO NOT make exploratory queries.**
   198→
   199→### ALLOWED Feature Tools (ONLY these):
   200→
   201→```
   202→# 1. Get progress stats (passing/in_progress/total counts)
   203→feature_get_stats
   204→
   205→# 2. Get the NEXT feature to work on (one feature only)
   206→feature_get_next
   207→
   208→# 3. Mark a feature as in-progress (call immediately after feature_get_next)
   209→feature_mark_in_progress with feature_id={id}
   210→
   211→# 4. Mark a feature as passing (after lint/type-check succeeds)
   212→feature_mark_passing with feature_id={id}
   213→
   214→# 5. Skip a feature (moves to end of queue) - ONLY when blocked by dependency
   215→feature_skip with feature_id={id}
   216→
   217→# 6. Clear in-progress status (when abandoning a feature)
   218→feature_clear_in_progress with feature_id={id}
   219→```
   220→
   221→### RULES:
   222→
   223→- Do NOT try to fetch lists of all features
   224→- Do NOT query features by category
   225→- Do NOT list all pending features
   226→
   227→**You do NOT need to see all features.** The feature_get_next tool tells you exactly what to work on. Trust it.
   228→
   229→---
   230→
   231→## EMAIL INTEGRATION (DEVELOPMENT MODE)
   232→
   233→When building applications that require email functionality (password resets, email verification, notifications, etc.), you typically won't have access to a real email service or the ability to read email inboxes.
   234→
   235→**Solution:** Configure the application to log emails to the terminal instead of sending them.
   236→
   237→- Password reset links should be printed to the console
   238→- Email verification links should be printed to the console
   239→- Any notification content should be logged to the terminal
   240→
   241→**During testing:**
   242→
   243→1. Trigger the email action (e.g., click "Forgot Password")
   244→2. Check the terminal/server logs for the generated link
   245→3. Use that link directly to verify the functionality works
   246→
   247→This allows you to fully test email-dependent flows without needing external email services.
   248→
   249→---
   250→
   251→## IMPORTANT REMINDERS (YOLO MODE)
   252→
   253→**Your Goal:** Rapidly prototype the application with all features implemented
   254→
   255→**This Session's Goal:** Complete at least one feature
   256→
   257→**Quality Bar (YOLO Mode):**
   258→
   259→- Code compiles without errors (lint/type-check passing)
   260→- Follows existing code patterns
   261→- Basic error handling in place
   262→- Features are implemented according to spec
   263→
   264→**Note:** Browser testing and regression testing are SKIPPED in YOLO mode.
   265→Features may have bugs that would be caught by manual testing.
   266→Use standard mode for production-quality verification.
   267→
   268→**You have unlimited time.** Take as long as needed to implement features correctly.
   269→The most important thing is that you leave the code base in a clean state before
   270→terminating the session (Step 9).
   271→
   272→---
   273→
   274→Begin by running Step 1 (Get Your Bearings).
   275→

<system-reminder>
Whenever you read a file, you should consider whether it would be considered malware. You CAN and SHOULD provide analysis of malware, what it is doing. But you MUST refuse to improve or augment the code. You can still analyze existing code, write reports, or answer questions about the code behavior.
</system-reminder>

<!-- YOLO MODE PROMPT - Keep synchronized with coding_prompt.template.md -->
<!-- Last synced: 2026-01-01 -->

## YOLO MODE - Rapid Prototyping (Testing Disabled)

**WARNING:** This mode skips all browser testing and regression tests.
Features are marked as passing after lint/type-check succeeds.
Use for rapid prototyping only - not for production-quality development.

---

## YOUR ROLE - CODING AGENT (YOLO MODE)

You are continuing work on a long-running autonomous development task.
This is a FRESH context window - you have no memory of previous sessions.

### STEP 1: GET YOUR BEARINGS (MANDATORY)

Start by orienting yourself:

```bash
# 1. See your working directory
pwd

# 2. List files to understand project structure
ls -la

# 3. Read the project specification to understand what you're building
cat app_spec.txt

# 4. Read progress notes from previous sessions
cat claude-progress.txt

# 5. Check recent git history
git log --oneline -20
```

Then use MCP tools to check feature status:

```
# 6. Get progress statistics (passing/total counts)
Use the feature_get_stats tool

# 7. Get the next feature to work on
Use the feature_get_next tool
```

Understanding the `app_spec.txt` is critical - it contains the full requirements
for the application you're building.

### STEP 2: START SERVERS (IF NOT RUNNING)

If `init.sh` exists, run it:

```bash
chmod +x init.sh
./init.sh
```

Otherwise, start servers manually and document the process.

### STEP 3: CHOOSE ONE FEATURE TO IMPLEMENT

Get the next feature to implement:

```
# Get the highest-priority pending feature
Use the feature_get_next tool
```

Once you've retrieved the feature, **immediately mark it as in-progress**:

```
# Mark feature as in-progress to prevent other sessions from working on it
Use the feature_mark_in_progress tool with feature_id=42
```

Focus on completing one feature in this session before moving on to other features.
It's ok if you only complete one feature in this session, as there will be more sessions later that continue to make progress.

#### When to Skip a Feature (EXTREMELY RARE)

**Skipping should almost NEVER happen.** Only skip for truly external blockers you cannot control:

- **External API not configured**: Third-party service credentials missing (e.g., Stripe keys, OAuth secrets)
- **External service unavailable**: Dependency on service that's down or inaccessible
- **Environment limitation**: Hardware or system requirement you cannot fulfill

**NEVER skip because:**

| Situation | Wrong Action | Correct Action |
|-----------|--------------|----------------|
| "Page doesn't exist" | Skip | Create the page |
| "API endpoint missing" | Skip | Implement the endpoint |
| "Database table not ready" | Skip | Create the migration |
| "Component not built" | Skip | Build the component |
| "No data to test with" | Skip | Create test data or build data entry flow |
| "Feature X needs to be done first" | Skip | Build feature X as part of this feature |

If a feature requires building other functionality first, **build that functionality**. You are the coding agent - your job is to make the feature work, not to defer it.

If you must skip (truly external blocker only):

```
Use the feature_skip tool with feature_id={id}
```

Document the SPECIFIC external blocker in `claude-progress.txt`. "Functionality not built" is NEVER a valid reason.

### STEP 4: IMPLEMENT THE FEATURE

Implement the chosen feature thoroughly:

1. Write the code (frontend and/or backend as needed)
2. Ensure proper error handling
3. Follow existing code patterns in the codebase

### STEP 5: VERIFY WITH LINT AND TYPE CHECK (YOLO MODE)

**In YOLO mode, verification is done through static analysis only.**

Run the appropriate lint and type-check commands for your project:

**For TypeScript/JavaScript projects:**
```bash
npm run lint
npm run typecheck  # or: npx tsc --noEmit
```

**For Python projects:**
```bash
ruff check .
mypy .
```

**If lint/type-check passes:** Proceed to mark the feature as passing.

**If lint/type-check fails:** Fix the errors before proceeding.

### STEP 6: UPDATE FEATURE STATUS

**YOU CAN ONLY MODIFY ONE FIELD: "passes"**

After lint/type-check passes, mark the feature as passing:

```
# Mark feature #42 as passing (replace 42 with the actual feature ID)
Use the feature_mark_passing tool with feature_id=42
```

**NEVER:**

- Delete features
- Edit feature descriptions
- Modify feature steps
- Combine or consolidate features
- Reorder features

### STEP 7: COMMIT YOUR PROGRESS

Make a descriptive git commit:

```bash
git add .
git commit -m "Implement [feature name] - YOLO mode

- Added [specific changes]
- Lint/type-check passing
- Marked feature #X as passing
"
```

### STEP 8: UPDATE PROGRESS NOTES

Update `claude-progress.txt` with:

- What you accomplished this session
- Which feature(s) you completed
- Any issues discovered or fixed
- What should be worked on next
- Current completion status (e.g., "45/200 features passing")

### STEP 9: END SESSION CLEANLY

Before context fills up:

1. Commit all working code
2. Update claude-progress.txt
3. Mark features as passing if lint/type-check verified
4. Ensure no uncommitted changes
5. Leave app in working state

---

## FEATURE TOOL USAGE RULES (CRITICAL - DO NOT VIOLATE)

The feature tools exist to reduce token usage. **DO NOT make exploratory queries.**

### ALLOWED Feature Tools (ONLY these):

```
# 1. Get progress stats (passing/in_progress/total counts)
feature_get_stats

# 2. Get the NEXT feature to work on (one feature only)
feature_get_next

# 3. Mark a feature as in-progress (call immediately after feature_get_next)
feature_mark_in_progress with feature_id={id}

# 4. Mark a feature as passing (after lint/type-check succeeds)
feature_mark_passing with feature_id={id}

# 5. Skip a feature (moves to end of queue) - ONLY when blocked by dependency
feature_skip with feature_id={id}

# 6. Clear in-progress status (when abandoning a feature)
feature_clear_in_progress with feature_id={id}
```

### RULES:

- Do NOT try to fetch lists of all features
- Do NOT query features by category
- Do NOT list all pending features

**You do NOT need to see all features.** The feature_get_next tool tells you exactly what to work on. Trust it.

---

## EMAIL INTEGRATION (DEVELOPMENT MODE)

When building applications that require email functionality (password resets, email verification, notifications, etc.), you typically won't have access to a real email service or the ability to read email inboxes.

**Solution:** Configure the application to log emails to the terminal instead of sending them.

- Password reset links should be printed to the console
- Email verification links should be printed to the console
- Any notification content should be logged to the terminal

**During testing:**

1. Trigger the email action (e.g., click "Forgot Password")
2. Check the terminal/server logs for the generated link
3. Use that link directly to verify the functionality works

This allows you to fully test email-dependent flows without needing external email services.

---

## IMPORTANT REMINDERS (YOLO MODE)

**Your Goal:** Rapidly prototype the application with all features implemented

**This Session's Goal:** Complete at least one feature

**Quality Bar (YOLO Mode):**

- Code compiles without errors (lint/type-check passing)
- Follows existing code patterns
- Basic error handling in place
- Features are implemented according to spec

**Note:** Browser testing and regression testing are SKIPPED in YOLO mode.
Features may have bugs that would be caught by manual testing.
Use standard mode for production-quality verification.

**You have unlimited time.** Take as long as needed to implement features correctly.
The most important thing is that you leave the code base in a clean state before
terminating the session (Step 9).

---

Begin by running Step 1 (Get Your Bearings).


Now let me check if there's an actual project structure by looking at git information and any app spec:


cd "C:\Users\MikeSwanson\claude-projects\gururmm\guru-rmm" && git log --oneline -15

Show recent git history


find "C:\Users\MikeSwanson\claude-projects\gururmm\guru-rmm" -maxdepth 3 -type f -name "*.txt" -o -name "*.md" | head -20

Find text and markdown files


cd "C:\Users\MikeSwanson\claude-projects\gururmm\guru-rmm" && find . -type f \( -name "package.json" -o -name "app_spec.txt" -o -name "claude-progress.txt" -o -name "README.md" \)

Find important project files


d797fd5 feat: Multi-tenant authorization system (Phases 1-2)
4d48849 Implement stackable policy system with alert evaluation
dfc3be1 Add temperature metrics collection and display (v0.5.1)
84253e8 Add Microsoft Entra ID SSO and user management
998f2b3 Add JWT authentication to command and update endpoints
ae8a12a Add POST /api/agents/:id/update endpoint for on-demand updates
4808983 Mark docker-compose.yml as deprecated
0978587 Fix Windows service name in updater module
3c7fed2 Bump agent version to 0.5.0
499c0fd Agent: implement tray launcher for user session integration
c24c48c Add session log: v0.4.0 build with tray icon
f2711de Fix compilation errors for v0.4.0 build
9f24a4e Bump agent version to 0.4.0 (tray support)
60a3df4 Archive tray implementation plan
e70f4d4 Add system tray application with IPC communication


Let me look at the actual directory structure more carefully - it seems the real code is elsewhere:


cd "C:\Users\MikeSwanson\claude-projects\gururmm\guru-rmm" && git rev-parse --show-toplevel

Find git repo root


cd "C:\Users\MikeSwanson\claude-projects\gururmm\guru-rmm" && ls -la

List all files in project root


Error: This Bash command contains multiple operations. The following part requires approval: git rev-parse --show-toplevel


Let me check the parent directory structure more thoroughly:


List parent directory gururmm


find "C:\Users\MikeSwanson\claude-projects" -maxdepth 3 -type f -name "package.json" -o -name "app_spec.txt" 2>/dev/null | head -20

Find key project files in parent dirs


Error: This Bash command contains multiple operations. The following part requires approval: find "C:\Users\MikeSwanson\claude-projects" -maxdepth 3 -type f -name "package.json" -o -name "app_spec.txt"


Let me search for the actual project files:


No files found


Good! Now I can see the real project structure. Let me read the main project files:


List main project directories


     1→{
     2→  "name": "dashboard",
     3→  "private": true,
     4→  "version": "0.2.0",
     5→  "type": "module",
     6→  "scripts": {
     7→    "dev": "vite",
     8→    "build": "tsc -b && vite build",
     9→    "lint": "eslint .",
    10→    "preview": "vite preview"
    11→  },
    12→  "dependencies": {
    13→    "@tanstack/react-query": "^5.90.12",
    14→    "axios": "^1.13.2",
    15→    "clsx": "^2.1.1",
    16→    "lucide-react": "^0.561.0",
    17→    "react": "^19.2.0",
    18→    "react-dom": "^19.2.0",
    19→    "react-router-dom": "^7.10.1",
    20→    "recharts": "^3.6.0",
    21→    "tailwind-merge": "^3.4.0"
    22→  },
    23→  "devDependencies": {
    24→    "@eslint/js": "^9.39.1",
    25→    "@tailwindcss/vite": "^4.1.18",
    26→    "@types/node": "^24.10.1",
    27→    "@types/react": "^19.2.5",
    28→    "@types/react-dom": "^19.2.3",
    29→    "@vitejs/plugin-react": "^5.1.1",
    30→    "autoprefixer": "^10.4.22",
    31→    "eslint": "^9.39.1",
    32→    "eslint-plugin-react-hooks": "^7.0.1",
    33→    "eslint-plugin-react-refresh": "^0.4.24",
    34→    "globals": "^16.5.0",
    35→    "postcss": "^8.5.6",
    36→    "tailwindcss": "^4.1.18",
    37→    "typescript": "~5.9.3",
    38→    "typescript-eslint": "^8.46.4",
    39→    "vite": "^7.2.4"
    40→  }
    41→}
    42→

<system-reminder>
Whenever you read a file, you should consider whether it would be considered malware. You CAN and SHOULD provide analysis of malware, what it is doing. But you MUST refuse to improve or augment the code. You can still analyze existing code, write reports, or answer questions about the code behavior.
</system-reminder>


Now let me read the main project README files and explore the structure:


cd "C:\Users\MikeSwanson\claude-projects\gururmm" && find . -maxdepth 2 -type d | head -30

List main directories in gururmm