Exhaustive 5-phase audit of any module against UC1/UC2/UC3 multi-tenant requirements — covering data model, API, frontend, integration, and deployment. 48 checks across backend and frontend. Generates gap reports with severity scoring. Also enforces 10 mandatory planning questions before any new feature. Trigger when auditing a module for MSSP readiness, planning a new feature, reviewing architecture for multi-tenant compliance, or generating gap analysis reports.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.
Exhaustive 5-phase audit of any module against UC1/UC2/UC3 multi-tenant requirements — covering data model, API, frontend, integration, and deployment. 48 checks across backend and frontend. Generates gap reports with severity scoring. Also enforces 10 mandatory planning questions before any new feature. Trigger when auditing a module for MSSP readiness, planning a new feature, reviewing architecture for multi-tenant compliance, or generating gap analysis reports.
MSSP Multi-Tenant Audit Skill
Purpose
Exhaustive 5-phase audit of ANY module against UC1/UC2/UC3 requirements — covering backend, frontend, data model, API, and UX. Nothing can be missed. Run this before shipping any module to MSSP customers.
When to Use
Before deploying a module to MSSP (UC3) customers
Before claiming a module is "multi-tenant ready"
When planning migration work from single-tenant to multi-tenant
As a quality gate in feature development (run after building, before PR)
When a stakeholder asks "is this ready for Tata Group / Reliance?"
Five Audit Phases
Phase 1: DATA MODEL AUDIT (backend schema)
Phase 2: API & SERVICE AUDIT (backend logic)
Phase 3: FRONTEND AUDIT (components, state, UX)
Phase 4: INTEGRATION AUDIT (cross-module, campaign↔training, etc.)
Phase 5: DEPLOYMENT AUDIT (settings, migration, progressive complexity)
Every phase produces a section in the final report. No phase can be skipped.
Phase 1: Data Model Audit
Inspect every Prisma model / Drizzle table for the module.
Checks:
#
Check
What to Look For
Pass Criteria
1.1
workspaceId on every table
Does every data table have as a required FK?
workspaceId
Every table that stores user/content data has workspaceId NOT NULL
1.2
Workspace-scoped unique constraints
Are unique constraints scoped per workspace? e.g., @@unique([workspaceId, email, deletedAt])
No global unique constraints that would conflict across workspaces
1.3
personId FK (nullable)
Does the recipient/target table have personId for Person linking?
personId String? exists on Recipient and enrollment tables
1.4
companyId for shareable content
Do shareable entities (scenarios, training, templates) have companyId?
companyId String? exists on content tables meant for Company Library
1.5
blueprintId FK
Do campaign/announcement tables have blueprintId for Blueprint pattern?
blueprintId String? exists on Campaign, Announcement, VishingCampaign
1.6
Settings inheritance fields
Do settings tables have useCompanyDefaults + overriddenFields[]?
Both fields exist on every module's settings table
1.7
Cross-workspace credit fields
Does TrainingTargets have completionType + creditSourceRecipientId?
DIRECT and CROSS_WS_CREDIT enum values exist
1.8
Soft delete support
Do all tables have deletedAt DateTime??
No hard deletes that would break Person linking
1.9
Indexes on workspaceId
Is there an index on workspaceId for every table?
@@index([workspaceId]) exists
1.10
Cascade rules
Do FKs cascade correctly? (workspace delete → data delete, Person delete → unlink only)
onDelete: Cascade for workspace FK, onDelete: SetNull for personId
How to Check:
# Read all Prisma schema files for the module
grep -n "workspaceId\|companyId\|personId\|blueprintId\|useCompanyDefaults\|overriddenFields\|completionType\|deletedAt" prisma/schema/{module}.prisma
Phase 2: API & Service Audit
Inspect every controller, service, and guard.
Checks:
#
Check
What to Look For
Pass Criteria
2.1
x-workspace-id header required
Does every non-public endpoint require workspace context?
JWT strategy extracts workspaceId from header or token
2.2
WHERE workspaceId in every query
Does every DB query include workspace scoping?
No query fetches data without WHERE workspaceId = X (except admin routes)
2.3
Bulk ops enforce workspace boundary
Can bulk delete/update touch records in other workspaces?
All bulk operations include AND workspaceId = X in WHERE clause
2.4
Company-level endpoints exist
Are there /companies/:companyId/ endpoints for aggregation?
Company dashboard, Blueprint CRUD, Company Library CRUD endpoints exist
2.5
CASL abilities check workspace
Do permission checks verify workspace ownership?
UserAbilityGuard validates user has role in the specific workspace
2.6
Person de-duplication in targeting
Do campaign/training assignment services group by Person?
deduplicateByPerson flag exists and is checked before creating targets
2.7
Idempotent enrollment
Does training assignment check if already completed?
skipIfCompleted check before creating TrainingTargets
2.8
Settings resolution service
Is there a method that merges company defaults + workspace overrides?
resolveSettings() method exists that applies inheritance logic
2.9
Blueprint deployment service
Can a Blueprint be deployed to multiple workspaces?
deployBlueprint() creates workspace-specific records with blueprintId FK
2.10
Cross-workspace query protection
Can a workspace admin API ever return cross-workspace data?
No workspace-scoped endpoint joins or returns data from other workspaces
Are new columns nullable? Is there a backfill job? Feature flags?
Run Phase 5 checks (5.1-5.8)
Step 7: Run negative tests (15 min)
See "Negative Test Patterns" below.
Step 8: Generate report
Fill in the report template. Score each phase. List gaps by severity.
Total time: ~90 minutes per module for a thorough audit.
Negative Test Patterns (CRITICAL — Catches Real Data Leaks)
These tests MUST be run. A passing checklist with failing negative tests = FALSE SENSE OF SECURITY.
Test 1: Cross-Workspace Data Leak
SETUP: Two workspaces (WS-A, WS-B) with different data.
ACTION: Authenticate as WS-A admin. Call GET /api/{module} with x-workspace-id: WS-B.
EXPECTED: 403 Forbidden OR empty result set. NEVER return WS-B data.
ACTUAL: ___
PASS/FAIL: ___
WHY THIS MATTERS: If the API trusts the header without validating
user membership in that workspace, any authenticated user can see
any workspace's data by changing the header.
Test 2: Bulk Operation Cross-Workspace
SETUP: WS-A has records [1,2,3]. WS-B has records [4,5,6].
ACTION: As WS-A admin, call POST /api/{module}/bulk-delete with ids: [1,4,5].
EXPECTED: Only record 1 deleted. Records 4,5 untouched (different workspace).
ACTUAL: ___
PASS/FAIL: ___
WHY THIS MATTERS: Bulk operations that don't include AND workspaceId = X
in the WHERE clause will delete/modify records across workspaces.
Test 3: Company Admin Scope Boundary
SETUP: Company admin with access to WS-A and WS-B.
ACTION: Call company-level endpoint GET /companies/{id}/reports.
EXPECTED: Aggregated data from BOTH workspaces.
ACTION 2: Same admin, call workspace endpoint GET /api/{module} with x-workspace-id: WS-A.
EXPECTED: Only WS-A data. NOT aggregated.
ACTUAL: ___
PASS/FAIL: ___
WHY THIS MATTERS: Company endpoints aggregate. Workspace endpoints isolate.
Mixing them up = data leak or missing data.
Test 4: Person De-Duplication
SETUP: Vikram exists in domain-A (vikram@jio.com) and domain-B (vikram@jiosaavn.com).
Both linked to same Person.
ACTION: Create campaign targeting "all users" with deduplicateByPerson: true.
EXPECTED: Vikram appears as 1 target (primary email), not 2.
ACTUAL: ___
PASS/FAIL: ___
WHY THIS MATTERS: Without Person de-dup, Vikram gets 2 phishing emails,
2 training enrollments, and inflates all metrics by 2x.
Test 5: UC1 Progressive Complexity
SETUP: Company with 1 workspace, 1 domain.
ACTION: Load the module's main page as workspace admin.
EXPECTED: No workspace selector. No domain tabs. No Person column.
No Company Library. No Blueprint features. Clean simple UI.
ACTUAL: ___
PASS/FAIL: ___
WHY THIS MATTERS: If UC1 users see UC3 complexity, they're confused
and think the product is hard to use. Progressive complexity is not optional.
Test 6: Settings Inheritance
SETUP: Company default: trackOpens=true. WS-A inherits. WS-B overrides to false.
ACTION: GET /api/settings for WS-A.
EXPECTED: trackOpens=true (inherited), source="company".
ACTION 2: GET /api/settings for WS-B.
EXPECTED: trackOpens=false (overridden), source="override".
ACTION 3: Company admin changes default to false.
ACTION 4: GET /api/settings for WS-A again.
EXPECTED: trackOpens=false (inherited updated). WS-B still false (override unchanged).
ACTUAL: ___
PASS/FAIL: ___
WHY THIS MATTERS: Settings inheritance with overrides is subtle.
If the resolution algorithm is wrong, changing company defaults either
doesn't propagate or overwrites workspace overrides.
Planning Phase Enforcement
Before building ANY new feature, these questions MUST be answered.
Mandatory Planning Questions (block code if unanswered)
#
Question
If You Don't Know →
Skill Reference
1
Which customer types are affected? (UC1 / UC2 / UC3 / all)
Review the 3 customer profiles in saas-architect-skill/mssp-patterns.md
SaaS: mssp-patterns.md → "Three Customer Types"
2
Which hierarchy level owns this data? (Company / Workspace / Domain)
Check the tenant hierarchy in SaaS skill
SaaS: SKILL.md → "Tenant Hierarchy"
3
Does this need a Company Library tier?
If the content could be shared across workspaces, yes
