Ops Port Manager

Port Manager

Instructions

Primary Port Configuration

• Main Application: Port 5546 (NEVER change)
• Storybook: Port 6006 (separate from main app)
• Development Server: Always use npm run dev

Server Commands

# Start main application (port 5546)
npm run dev

# Start Storybook (port 6006)
npm run storybook

# Check if server is running
curl http://localhost:5546

Port Conflict Resolution

# Kill processes using port 5546
lsof -ti:5546 | xargs kill -9

# Or use pkill for node processes
pkill -f "vite.*5546"

# Restart server
npm run dev

Development URLs

• Main Application: http://localhost:5546
• Storybook: http://localhost:6006
• Design System: http://localhost:5546/#/design-system

Browser Access Patterns

Always reference the application using:

• http://localhost:5546 for main app
• http://localhost:6006 for Storybook
• Never hardcode other ports

Server Health Check

const checkServerHealth = async () => {
  try {
    const response = await fetch('http://localhost:5546')
    return response.ok
  } catch (error) {
    console.error('Server not accessible on port 5546:', error)
    return false
  }
}

Testing Environment Setup

# Ensure server is running before tests
npm run dev &
sleep 5  # Wait for server to start
npm run test

This skill ensures consistent use of port 5546 and proper server management for the productivity application.

MANDATORY USER VERIFICATION REQUIREMENT

Policy: No Fix Claims Without User Confirmation

CRITICAL: Before claiming ANY issue, bug, or problem is "fixed", "resolved", "working", or "complete", the following verification protocol is MANDATORY:

Step 1: Technical Verification

• Run all relevant tests (build, type-check, unit tests)
• Verify no console errors
• Take screenshots/evidence of the fix

Step 2: User Verification Request

REQUIRED: Use the AskUserQuestion tool to explicitly ask the user to verify the fix:

"I've implemented [description of fix]. Before I mark this as complete, please verify:
1. [Specific thing to check #1]
2. [Specific thing to check #2]
3. Does this fix the issue you were experiencing?

Please confirm the fix works as expected, or let me know what's still not working."

Step 3: Wait for User Confirmation

• DO NOT proceed with claims of success until user responds
• DO NOT mark tasks as "completed" without user confirmation
• DO NOT use phrases like "fixed", "resolved", "working" without user verification

Step 4: Handle User Feedback

• If user confirms: Document the fix and mark as complete
• If user reports issues: Continue debugging, repeat verification cycle

Prohibited Actions (Without User Verification)

• Claiming a bug is "fixed"
• Stating functionality is "working"
• Marking issues as "resolved"
• Declaring features as "complete"
• Any success claims about fixes

Required Evidence Before User Verification Request

1. Technical tests passing
2. Visual confirmation via Playwright/screenshots
3. Specific test scenarios executed
4. Clear description of what was changed

Remember: The user is the final authority on whether something is fixed. No exceptions.