Skip to content

Developer roles and privileges

This document defines what each developer role can access and do within the mcc-systems codebase and infrastructure. New developers should read this alongside the getting started guide.


Roles

Glenn — lead developer (full access)

Glenn has full access to all areas of the codebase, infrastructure, and deployment.

Area Access
Codebase All files in both apps and all shared infrastructure
Database (dev) Full read/write via MCP and Supabase CLI
Database (prod) Full access — deploys migrations via deploy-prod.ps1
Edge Functions Create, modify, and deploy any function
GitHub Commit, push, merge to master
Vercel Full access — runs all production deployments
Supabase Full access to both dev and prod projects
Documentation site Full access

Jordan — developer (defined scope, restricted deployment)

Jordan has developer access to the codebase with a defined scope agreed with Glenn before each body of work begins. His specific folder, database, and Edge Function permissions vary by task and are documented in the relevant brief or dev guide before work starts. The constants across all of Jordan's work are below.

Area Access
Codebase Defined scope agreed with Glenn — documented per body of work
Database (dev) Read any table; write access scoped to the task — documented per body of work
Database (prod) No direct access
Edge Functions Scoped to the task — documented per body of work; cannot modify existing functions outside his scope
GitHub Commit and push — does not trigger auto-deployment to production
Vercel No access — production deployment is run by Glenn
Supabase Dev branch only, via MCP
Documentation site No access

Production deployment: Jordan commits and pushes to GitHub, then notifies Glenn. Glenn runs the production deployment manually. Nothing goes live until Glenn deploys.


Adding a new developer

When onboarding a new developer, Glenn needs to:

  1. Send a GitHub invitation to the glenn-mcc/mcc-systems repo with the appropriate permission level
  2. Invite them to the Supabase organisation (dev branch access only unless full access is required)
  3. Define their role scope — which app(s), which folders, which database tables
  4. Document their role in this file before they begin work
  5. Point them to the getting started guide and their role-specific documentation

New roles should be documented here before the developer's first session, not after. This ensures CC knows the intended boundaries from the start.


Principles

Access is least-privilege by default. New developers start with the minimum access needed to do their work. Additional access is granted explicitly as needed.

Codebase boundaries are enforced, not trusted. Where possible, role restrictions are enforced at build time (ESLint isolation rules) or by infrastructure configuration, not just by convention. Convention alone is not sufficient for production software.

Production deployment stays with Glenn. No other developer has a path to deploy to production autonomously. All production changes are deliberate, manual, and verified by Glenn.