playbooks

home / skills / iurygdeoliveira / labsis-kit / validate-project-rules

validate-project-rules skill

/.agent/skills/validate-project-rules

This skill analyzes and enforces multi-tenant isolation, dynamic RBAC, and safe tenant deletion rules for a Laravel and Filament SaaS starter kit.

npx playbooks add skill iurygdeoliveira/labsis-kit --skill validate-project-rules

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
2.6 KB
---
name: validate-project-rules
description: Lista Técnica de Regras de Negócio do labSIS-KIT. Define comportamento esperado para isolamento, permissões e instalação.
tools: read_file, grep_search, view_file, run_command
---

# Regras de Negócio: labSIS-KIT (Referencial Educacional)

Lista priorizada de comportamentos esperados do sistema.
Estas regras garantem que o kit funcione como um referencial teórico-prático de qualidade.

---

## 🚨 P0: Críticas (O sistema NÃO pode falhar aqui)
*Se estas regras quebrarem, o kit falha em sua missão educacional de segurança e arquitetura.*

### 1. Isolamento Estrito de Tenant
- **Motivo**: Ensinar arquitetura SaaS segura evitando vazamento de dados (erro #1).
- **Regra**: Um Tenant **NUNCA** deve conseguir acessar dados de outro, nem por falha de acesso direto (URL manipulation). O isolamento deve ser garantido por Global Scopes/Policies.
- **Validação**: Testes automatizados tentando acessar recursos Cross-Tenant devem falhar (403/404).

### 2. Polimorfismo de Papéis (RBAC Dinâmico)
- **Motivo**: Refletir cenários reais onde uma pessoa possui múltiplos contextos.
- **Regra**: O sistema deve permitir que o mesmo `User` tenha papéis diferentes em Tenants diferentes (Ex: `Owner` na Empresa A, `User` na Empresa B). A role é vinculada ao relacionamento (pivot), não ao usuário absoluto.
- **Validação**: Verificar se usuário com múltiplas associações tem permissões corretas em cada contexto ativo.

### 3. Proteção Contra Destruição (Tenant Deletion)
- **Motivo**: Prevenir perda de dados acidental ou maliciosa por parte de um Owner.
- **Regra**: Apenas o **Super Admin** (Global) tem permissão para deletar um Tenant. O Owner do tenant **NÃO** deve ter acesso a essa ação destrutiva.
- **Validação**: Tentar deletar o próprio tenant logado como Owner -> Ação Bloqueada/Inexistente.

---

## ⚠️ P1: Importantes (O sistema funciona, mas a experiência degrada)
*Problemas aqui afetam a percepção de qualidade do kit.*

### 4. Onboarding "One-Click"
- **Motivo**: Facilitar a entrada de iniciantes no mundo SaaS.
- **Regra**: O script `install.php` deve realizar o setup completo (Banco, Migrations, Seeds Essenciais) sem exigir configuração manual complexa.
- **Validação**: Rodar `php install.php` em ambiente limpo e ter sistema funcional imediatamente.

---

## ℹ️ P2: Desejáveis (Escopo Futuro)

### 5. Limites de Planos (SaaS Metrics)
- **Motivo**: Ensinar monetização e quotas.
- **Regra**: Implementar lógica de limites (ex: máx usuários por plano).
- **Status**: ⏳ Adiado para V2.

---

**Gerado por**: Product Manager Agent
**Data**: 2026-01-27

Overview

This skill validates the labSIS-KIT business rules for a Laravel + Filament SaaS starter kit. It focuses on enforcing tenant isolation, dynamic role bindings per tenant, and controlled destructive actions. The goal is to ensure the kit remains a reliable educational reference for secure SaaS architecture.

How this skill works

The validator runs automated checks and integration tests against the application to confirm expected behaviors. It inspects global scopes, policies, and pivot role assignments, simulates cross-tenant access attempts, and verifies installer script behavior. It reports failures with clear status codes and actionable guidance for remediation.

When to use it

  • Before merging major tenant or permission changes
  • During CI to prevent regressions in isolation or RBAC
  • After implementing or updating the install script
  • Before releases that affect destructive actions or administrative flows
  • When auditing the kit for security or educational correctness

Best practices

  • Enforce tenant isolation at ORM/global scope level rather than relying on controllers
  • Store roles on the tenant-user relationship (pivot) so permissions vary by context
  • Restrict tenant deletion to a global Super Admin role and test that Owners cannot delete their tenant
  • Automate validation in CI with tests that assert 403/404 on cross-tenant access
  • Provide a one-command installer that runs migrations and seeds for reproducible demos

Example use cases

  • Run checks to confirm a user with Owner role in Tenant A cannot view Tenant B resources
  • Validate that the same user can hold different roles across two tenants and has appropriate permissions in each
  • Execute the install script in a fresh environment and verify the application is functional without manual steps
  • Attempt tenant deletion as an Owner and assert the action is blocked or absent
  • Include the validator in CI to catch regressions to isolation or RBAC logic

FAQ

What happens if a test detects cross-tenant data leakage?

The validator marks the build as failed and provides the failing request and expected response codes (403/404) so you can trace the offending scope or policy.

How do I verify the one-click installer works in CI?

Run php install.php in a clean container or ephemeral environment during CI and assert migrations run, essential seeds exist, and the app bootstraps without manual input.