Phase 5 Week 2 Plan: Team Member Management + Beta Launch Preparation¶

Status: ⏳ IN PROGRESS Timeline: 5 days (November 4-8, 2025) Goal: Complete team member management features and prepare for beta user recruitment

Week 2 Overview¶

Objectives¶

Team Member Management: Implement UI for inviting, managing, and removing team members
Beta Launch Preparation: Test complete payment flow and finalize onboarding experience
Documentation: Update all user-facing documentation
First Payment: Process first real Stripe payment to validate billing integration

Success Criteria¶

✅ Team owners can invite members via email
✅ Team members can accept invitations and join teams
✅ Role management (owner/member) working correctly
✅ Complete payment test from checkout → webhook → database update
✅ All documentation updated with correct URLs
✅ Ready to recruit first 5 beta users

Daily Breakdown¶

🚨 Day 0 (CRITICAL): Team-Scoped Code Analysis¶

Status: 🚨 CRITICAL - Must be fixed before beta launch Priority: P0 (Blocks billing, quotas, team collaboration)

Objective: Add team context to code analysis flow to enable quota enforcement, team attribution, and audit logging

Problem: Currently, all code analyses are orphaned (not linked to any team), preventing: - Quota enforcement (can't track team usage) - Team collaboration (no shared analysis history) - Billing attribution (can't bill teams) - Audit trails (analyses don't appear in team logs)

Tasks:

Add team context to /analyze page (2 hours):
Create team selector dropdown in analyze page header
Store selected team in session storage
Show current team context: "Analyzing as: {Team Name}"
Redirect to team selector if no team selected
Update API endpoint to accept teamId (1 hour):
Add teamId to /api/analyze request body
Validate user is member of the team
Pass teamId to trackIndividualAnalysis()
Implement quota enforcement (2 hours):
Create checkTeamQuota() function
Query team's current usage from database
Return 429 error if quota exceeded
Include upgrade CTA in error response
Update analytics tracking (1 hour):
Modify trackIndividualAnalysis() to store teamId
Update usageAnalytics table schema (add team_id column)
Ensure team attribution is preserved
Show analyses in team audit logs (2 hours):
Query analyses by teamId in /api/teams/{id}/audit
Display analysis summary in audit log
Link to analysis results (if stored)
Update UI components (1 hour):
Add team badge to analyze page
Show quota usage: "{used}/{limit} analyses this month"
Add "Switch Team" option in header

Database Migration:

ALTER TABLE "usageAnalytics"
ADD COLUMN IF NOT EXISTS team_id UUID REFERENCES teams(id) ON DELETE SET NULL;

CREATE INDEX IF NOT EXISTS idx_usage_analytics_team_id
ON "usageAnalytics"(team_id);

Deliverables: - Team context selector in /analyze page - teamId parameter in /api/analyze endpoint - Quota enforcement before analysis - Team attribution in analytics - Analyses visible in team audit logs - Database migration for team_id column - 15+ tests for team-scoped analysis

Estimated Time: 8-9 hours (1 full day)

Acceptance Criteria: - ✅ User must select a team before analyzing code - ✅ Analysis request includes teamId - ✅ Quota is checked and enforced - ✅ Analysis is tracked with team attribution - ✅ Analysis appears in team audit log - ✅ All existing tests still pass

See: PHASE_5_WEEK_2_CRITICAL_GAP.md for full analysis and rationale

Day 1 (Monday): Team Members List UI¶

Objective: Display current team members with their roles and permissions

Tasks:

Read current team settings implementation
Review /teams/[id]/settings/page.tsx (4 tabs: General, Members, Billing, Danger Zone)
Understand current Members tab structure
Create Members List Component (src/components/team/MembersList.tsx):
Fetch team members from database
Display member cards with:
- Avatar (GitHub profile picture)
- Name and email
- Role badge (owner/member)
- Join date
- Last activity
Owner-only actions:
- Change role button
- Remove member button (with confirmation)
Empty state: "No members yet. Invite your first team member!"

Create API endpoint (/api/teams/[id]/members/route.ts):

GET /api/teams/{id}/members
- Returns: Array of team members
- Auth: Must be team member
- Filter: Can optionally filter by role

Test members list:
Create test with multiple team members
Verify owner sees all actions
Verify members see read-only view

Deliverables: - src/components/team/MembersList.tsx (150-200 lines) - /api/teams/[id]/members/route.ts (80-100 lines) - 5+ tests for members list - Updated Members tab in Settings page

Estimated Time: 4-5 hours

Day 2 (Tuesday): Team Member Invitations¶

Objective: Allow team owners to invite new members via email

Tasks:

Create Invite Modal Component (src/components/team/InviteMemberModal.tsx):
Form fields:
- Email address (required, validation)
- Role selection (member/owner)
- Optional: Personal message
Send invitation button
Loading states and error handling

Create database schema for invitations (team_invitations table):

- id (uuid, primary key)
- team_id (uuid, foreign key)
- email (text)
- role (text: 'member' | 'owner')
- invited_by_user_id (uuid, foreign key)
- token (text, unique)
- status (text: 'pending' | 'accepted' | 'expired')
- expires_at (timestamp)
- created_at (timestamp)
- accepted_at (timestamp, nullable)

Create API endpoints:

POST /api/teams/{id}/invitations
- Body: { email, role, message? }
- Auth: Must be team owner
- Creates invitation, sends email
- Returns: { invitation, success }

GET /api/teams/{id}/invitations
- Returns: Pending invitations
- Auth: Must be team owner

Email notification (for now, just log to console):
Subject: "You've been invited to join {teamName} on CodeSlick"
Body: Invitation link: /teams/invitations/{token}
Include team name, inviter name, role

Deliverables: - InviteMemberModal.tsx component - Database migration for team_invitations - API routes for invitations - 8+ tests for invitation flow - Email template (console log for now)

Estimated Time: 5-6 hours

Day 3 (Wednesday): Accept Invitation Flow¶

Objective: Allow invited users to accept invitations and join teams

Tasks:

Create invitation acceptance page (/teams/invitations/[token]/page.tsx):
Fetch invitation details by token
Display team information:
- Team name and logo
- Invited by (user name)
- Role you'll have
Two buttons:
- "Accept Invitation" (green)
- "Decline" (gray)
Handle expired/invalid tokens

Create API endpoint:

POST /api/teams/invitations/{token}/accept
- Validates token not expired
- Creates team_members record
- Updates invitation status to 'accepted'
- Returns: { team, success }
- Redirect to: /teams/{teamId}

Edge cases:
User not signed in: Redirect to /auth/signin?callbackUrl=/teams/invitations/{token}
After sign-in, process invitation automatically
User already member: Show "Already a member" message
Invitation expired: Show error with "Request new invitation" option
Invitation already accepted: Redirect to team dashboard
Update sign-in flow:
If callbackUrl contains /teams/invitations/, auto-process after auth

Deliverables: - Invitation acceptance page - API endpoint for accepting invitations - Edge case handling - 10+ tests for acceptance flow - Integration test: invite → accept → verify team membership

Estimated Time: 5-6 hours

Day 4 (Thursday): Role Management + Member Removal¶

Objective: Complete member management with role changes and removal

Tasks:

Role management:
Add "Change Role" modal

API endpoint:

PATCH /api/teams/{id}/members/{memberId}
- Body: { role: 'owner' | 'member' }
- Auth: Must be team owner
- Validation: Cannot demote last owner

Member removal:
Add confirmation modal: "Remove {name} from {team}?"

API endpoint:

DELETE /api/teams/{id}/members/{memberId}
- Auth: Must be team owner
- Validation: Cannot remove last owner
- Soft delete or hard delete?

Permission checks throughout app:
Review all team settings pages
Ensure only owners can:
- Invite members
- Change roles
- Remove members
- Update team settings
- Access billing
- Delete team
Members can:
- View team dashboard
- View audit logs
- View team settings (read-only)

Add permission helpers:

// src/lib/permissions/team.ts
export function canManageTeam(role: string): boolean
export function canInviteMembers(role: string): boolean
export function canRemoveMembers(role: string): boolean

Deliverables: - Role change modal and API - Member removal with confirmation - Permission system implemented - 12+ tests for permissions - Documentation: "Team Roles & Permissions"

Estimated Time: 5-6 hours

Day 5 (Friday): Payment Testing + Beta Preparation¶

Objective: Complete end-to-end payment test and prepare for beta launch

Tasks:

Complete Payment Flow Test:
Use Stripe test card: 4242 4242 4242 4242
Test complete flow:
1. Click "Upgrade to Team Plan" in team settings
2. Complete Stripe Checkout
3. Verify webhook received
4. Check database: teams.plan updated to 'team'
5. Check database: teams.stripeCustomerId populated
6. Verify team dashboard shows "Team Plan" badge
Document any issues
Test Customer Portal:
Click "Manage Billing" in team settings
Opens Stripe Customer Portal
Test:
- Update payment method
- View invoices
- Cancel subscription
Verify cancellation webhook updates database
Onboarding Experience Review:
New user signs in → Sees onboarding (0 teams)
Clicks "Install GitHub App" → Installs on repo
Team auto-created → Redirected to team dashboard
Review: Is anything confusing? Missing?
Documentation Update:
Update README.md with current status
Create BETA_LAUNCH_CHECKLIST.md
Create TEAM_MEMBER_GUIDE.md (how to invite, manage members)
Beta Recruitment Preparation:
Draft beta invitation email template
Create list of 10-15 potential beta testers:
- LinkedIn connections (developers)
- Twitter followers interested in DevSecOps
- Reddit communities (r/devops, r/security)
- Personal network contacts
Prepare beta pricing: Team plan free for 4 weeks, then 50% off (€49/month for 3 months)

Deliverables: - Complete payment test documentation - Beta launch checklist - Team member guide - Beta invitation email template - List of 10-15 beta candidates - All tests passing (536+ tests)

Estimated Time: 6-7 hours

Technical Architecture¶

Database Schema Changes¶

New Table: `team_invitations`¶

CREATE TABLE team_invitations (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  team_id UUID NOT NULL REFERENCES teams(id) ON DELETE CASCADE,
  email TEXT NOT NULL,
  role TEXT NOT NULL CHECK (role IN ('owner', 'member')),
  invited_by_user_id UUID NOT NULL REFERENCES users(id),
  token TEXT NOT NULL UNIQUE,
  message TEXT,
  status TEXT NOT NULL DEFAULT 'pending' CHECK (status IN ('pending', 'accepted', 'declined', 'expired')),
  expires_at TIMESTAMP NOT NULL DEFAULT (NOW() + INTERVAL '7 days'),
  created_at TIMESTAMP NOT NULL DEFAULT NOW(),
  accepted_at TIMESTAMP,
  INDEX idx_team_invitations_team_id (team_id),
  INDEX idx_team_invitations_token (token),
  INDEX idx_team_invitations_email (email)
);

API Endpoints Summary¶

Method	Endpoint	Auth	Purpose
GET	`/api/teams/{id}/members`	Team member	List team members
POST	`/api/teams/{id}/invitations`	Owner	Send invitation
GET	`/api/teams/{id}/invitations`	Owner	List pending invitations
POST	`/api/teams/invitations/{token}/accept`	Authenticated	Accept invitation
PATCH	`/api/teams/{id}/members/{memberId}`	Owner	Change member role
DELETE	`/api/teams/{id}/members/{memberId}`	Owner	Remove member

Component Structure¶

src/components/team/
├── MembersList.tsx           (Day 1)
├── MemberCard.tsx            (Day 1)
├── InviteMemberModal.tsx     (Day 2)
├── ChangeRoleModal.tsx       (Day 4)
├── RemoveMemberModal.tsx     (Day 4)

src/app/teams/
├── [id]/settings/page.tsx    (Update Members tab)
├── invitations/
│   └── [token]/page.tsx      (Day 3)

src/lib/permissions/
└── team.ts                   (Day 4)

Risk Assessment¶

High Priority Risks¶

Email Delivery (Day 2):
Risk: No email service configured yet
Mitigation: For Week 2, log invitation links to console. Set up email service (SendGrid/Resend) in Week 3
Stripe Webhook Failures (Day 5):
Risk: Webhook might fail to update database
Mitigation: Add retry logic, webhook signature verification already in place
Permission Bypass (Day 4):
Risk: Non-owners might access restricted actions
Mitigation: Server-side validation on all API routes, never trust client

Medium Priority Risks¶

Invitation Expiry:
Risk: Users might try to accept expired invitations
Mitigation: Show clear error message, allow re-sending invitations
Last Owner Protection:
Risk: Team left with no owners
Mitigation: Prevent removing/demoting last owner, show warning

Testing Strategy¶

Unit Tests (50+ new tests)¶

MembersList component rendering
Invitation modal validation
API route authentication
Permission helpers
Token generation/validation

Integration Tests (10+ new tests)¶

Complete invitation flow: send → email → accept → verify membership
Role change flow: owner → change role → verify database
Member removal: owner → remove → verify gone from team
Payment flow: checkout → webhook → plan upgrade

E2E Tests (5+ new tests)¶

New user: sign in → install app → team created → invite member → member accepts
Owner: invite member → member signs up → joins team → sees dashboard
Payment: upgrade plan → complete checkout → verify billing page

Success Metrics¶

Week 2 Completion Criteria¶

✅ All API endpoints implemented and tested
✅ UI components complete and styled
✅ Database migrations applied
✅ Permission system enforced
✅ 536+ → 586+ tests (minimum +50 new tests)
✅ All tests passing (100%)
✅ Complete payment test successful
✅ Documentation updated
✅ Beta invitation template ready

Key Metrics to Track¶

Development Velocity: 5 days to complete member management
Code Quality: 100% test coverage for new features
User Experience: Invitation flow takes <2 minutes
Security: Zero permission bypass vulnerabilities

Post-Week 2: Beta Launch Timeline¶

Week 3 (Nov 11-15): Beta Recruitment¶

Send invitations to 10-15 beta candidates
Goal: 5 beta signups
1:1 onboarding calls
Gather initial feedback

Week 4 (Nov 18-22): Beta Testing¶

Monitor usage
Fix critical bugs
Improve onboarding based on feedback
First payment processing

Week 5 (Nov 25-29): Public Launch Preparation¶

Landing page redesign
Pricing page update
User documentation
SEO optimization

Notes¶

Week 2 is critical: After this week, we'll be ready for beta users
Focus on quality: Every feature must be polished and tested
Keep scope tight: No feature creep, stick to the plan
Document everything: Beta users will need clear documentation

Next Actions (After Week 2): 1. Send beta invitations (Week 3 Monday) 2. Schedule onboarding calls with beta users 3. Monitor first week of beta usage closely 4. Begin landing page redesign (Week 3)

Author: Claude Code Created: November 3, 2025 Phase: 5 Week 2 Status: Ready to begin

Phase 5 Week 2 Plan: Team Member Management + Beta Launch Preparation¶

Week 2 Overview¶

Objectives¶

Success Criteria¶

Daily Breakdown¶

🚨 Day 0 (CRITICAL): Team-Scoped Code Analysis¶

Day 1 (Monday): Team Members List UI¶

Day 2 (Tuesday): Team Member Invitations¶

Day 3 (Wednesday): Accept Invitation Flow¶

Day 4 (Thursday): Role Management + Member Removal¶

Day 5 (Friday): Payment Testing + Beta Preparation¶

Technical Architecture¶

Database Schema Changes¶

New Table: team_invitations¶

API Endpoints Summary¶

Component Structure¶

Risk Assessment¶

High Priority Risks¶

Medium Priority Risks¶

Testing Strategy¶

Unit Tests (50+ new tests)¶

Integration Tests (10+ new tests)¶

E2E Tests (5+ new tests)¶

Success Metrics¶

Week 2 Completion Criteria¶

Key Metrics to Track¶

Post-Week 2: Beta Launch Timeline¶

Week 3 (Nov 11-15): Beta Recruitment¶

Week 4 (Nov 18-22): Beta Testing¶

Week 5 (Nov 25-29): Public Launch Preparation¶

Notes¶

New Table: `team_invitations`¶