tribunal-kit 3.0.0 → 3.1.0

package/.agent/skills/api-patterns/versioning.md

@@ -1,22 +0,0 @@
-# Versioning Strategies
-
-> Plan for API evolution from day one.
-
-## Decision Factors
-
-| Strategy | Implementation | Trade-offs |
-|----------|---------------|------------|
-| **URI** | /v1/users | Clear, easy caching |
-| **Header** | Accept-Version: 1 | Cleaner URLs, harder discovery |
-| **Query** | ?version=1 | Easy to add, messy |
-| **None** | Evolve carefully | Best for internal, risky for public |
-
-## Versioning Philosophy
-
-```
-Consider:
-├── Public API? → Version in URI
-├── Internal only? → May not need versioning
-├── GraphQL? → Typically no versions (evolve schema)
-├── tRPC? → Types enforce compatibility
-```

package/.agent/skills/app-builder/agent-coordination.md

@@ -1,71 +0,0 @@
-# Agent Coordination
-
-> How App Builder orchestrates specialist agents.
-
-## Agent Pipeline
-
-```
-┌─────────────────────────────────────────────────────────────┐
-│                   APP BUILDER (Orchestrator)                 │
-└─────────────────────────────────────────────────────────────┘
-                              │
-                              ▼
-┌─────────────────────────────────────────────────────────────┐
-│                     PROJECT PLANNER                          │
-│  • Task breakdown                                            │
-│  • Dependency graph                                          │
-│  • File structure planning                                   │
-│  • Create {task-slug}.md in project root (MANDATORY)             │
-└─────────────────────────────────────────────────────────────┘
-                              │
-                              ▼
-┌─────────────────────────────────────────────────────────────┐
-│              CHECKPOINT: PLAN VERIFICATION                   │
-│  🔴 VERIFY: Does {task-slug}.md exist in project root?       │
-│  🔴 If NO → STOP → Create plan file first                    │
-│  🔴 If YES → Proceed to specialist agents                    │
-└─────────────────────────────────────────────────────────────┘
-                              │
-          ┌───────────────────┼───────────────────┐
-          ▼                   ▼                   ▼
-┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
-│ DATABASE        │ │ BACKEND         │ │ FRONTEND        │
-│ ARCHITECT       │ │ SPECIALIST      │ │ SPECIALIST      │
-│                 │ │                 │ │                 │
-│ • Schema design │ │ • API routes    │ │ • Components    │
-│ • Migrations    │ │ • Controllers   │ │ • Pages         │
-│ • Seed data     │ │ • Middleware    │ │ • Styling       │
-└─────────────────┘ └─────────────────┘ └─────────────────┘
-          │                   │                   │
-          └───────────────────┼───────────────────┘
-                              ▼
-┌─────────────────────────────────────────────────────────────┐
-│                 PARALLEL PHASE (Optional)                    │
-│  • Security Auditor → Vulnerability check                   │
-│  • Test Engineer → Unit tests                               │
-│  • Performance Optimizer → Bundle analysis                  │
-└─────────────────────────────────────────────────────────────┘
-                              │
-                              ▼
-┌─────────────────────────────────────────────────────────────┐
-│                     DEVOPS ENGINEER                          │
-│  • Environment setup                                         │
-│  • Preview deployment                                        │
-│  • Health check                                              │
-└─────────────────────────────────────────────────────────────┘
-```
-
-## Execution Order
-
-| Phase | Agent(s) | Parallel? | Prerequisite | CHECKPOINT |
-|-------|----------|-----------|--------------|------------|
-| 0 | Socratic Gate | ❌ | - | ✅ Ask 3 questions |
-| 1 | Project Planner | ❌ | Questions answered | ✅ **PLAN.md created** |
-| 1.5 | **PLAN VERIFICATION** | ❌ | PLAN.md exists | ✅ **File exists in root** |
-| 2 | Database Architect | ❌ | Plan ready | Schema defined |
-| 3 | Backend Specialist | ❌ | Schema ready | API routes created |
-| 4 | Frontend Specialist | ✅ | API ready (partial) | UI components ready |
-| 5 | Security Auditor, Test Engineer | ✅ | Code ready | Tests & audit pass |
-| 6 | DevOps Engineer | ❌ | All code ready | Deployment ready |
-
-> 🔴 **CRITICAL:** Phase 1.5 is MANDATORY. No specialist agents proceed without PLAN.md verification.

package/.agent/skills/app-builder/feature-building.md

@@ -1,53 +0,0 @@
-# Feature Building
-
-> How to analyze and implement new features.
-
-## Feature Analysis
-
-```
-Request: "add payment system"
-
-Analysis:
-├── Required Changes:
-│   ├── Database: orders, payments tables
-│   ├── Backend: /api/checkout, /api/webhooks/stripe
-│   ├── Frontend: CheckoutForm, PaymentSuccess
-│   └── Config: Stripe API keys
-│
-├── Dependencies:
-│   ├── stripe package
-│   └── Existing user authentication
-│
-└── Estimated Time: 15-20 minutes
-```
-
-## Iterative Enhancement Process
-
-```
-1. Analyze existing project
-2. Create change plan
-3. Present plan to user
-4. Get approval
-5. Apply changes
-6. Test
-7. Show preview
-```
-
-## Error Handling
-
-| Error Type | Solution Strategy |
-|------------|-------------------|
-| TypeScript Error | Fix type, add missing import |
-| Missing Dependency | Run npm install |
-| Port Conflict | Suggest alternative port |
-| Database Error | Check migration, validate connection |
-
-## Recovery Strategy
-
-```
-1. Detect error
-2. Try automatic fix
-3. If failed, report to user
-4. Suggest alternative
-5. Rollback if necessary
-```

package/.agent/skills/app-builder/project-detection.md

@@ -1,34 +0,0 @@
-# Project Type Detection
-
-> Analyze user requests to determine project type and template.
-
-## Keyword Matrix
-
-| Keywords | Project Type | Template |
-|----------|--------------|----------|
-| blog, post, article | Blog | astro-static |
-| e-commerce, product, cart, payment | E-commerce | nextjs-saas |
-| dashboard, panel, management | Admin Dashboard | nextjs-fullstack |
-| api, backend, service, rest | API Service | express-api |
-| python, fastapi, django | Python API | python-fastapi |
-| mobile, android, ios, react native | Mobile App (RN) | react-native-app |
-| flutter, dart | Mobile App (Flutter) | flutter-app |
-| portfolio, personal, cv | Portfolio | nextjs-static |
-| crm, customer, sales | CRM | nextjs-fullstack |
-| saas, subscription, stripe | SaaS | nextjs-saas |
-| landing, promotional, marketing | Landing Page | nextjs-static |
-| docs, documentation | Documentation | astro-static |
-| extension, plugin, chrome | Browser Extension | chrome-extension |
-| desktop, electron | Desktop App | electron-desktop |
-| cli, command line, terminal | CLI Tool | cli-tool |
-| monorepo, workspace | Monorepo | monorepo-turborepo |
-
-## Detection Process
-
-```
-1. Tokenize user request
-2. Extract keywords
-3. Determine project type
-4. Detect missing information → forward to conversation-manager
-5. Suggest tech stack
-```

package/.agent/skills/app-builder/scaffolding.md

@@ -1,118 +0,0 @@
-# Project Scaffolding
-
-> Directory structure and core files for new projects.
-
----
-
-## Next.js Full-Stack Structure (2025 Optimized)
-
-```
-project-name/
-├── src/
-│   ├── app/                        # Routes only (thin layer)
-│   │   ├── layout.tsx
-│   │   ├── page.tsx
-│   │   ├── globals.css
-│   │   ├── (auth)/                 # Route group - auth pages
-│   │   │   ├── login/page.tsx
-│   │   │   └── register/page.tsx
-│   │   ├── (dashboard)/            # Route group - dashboard layout
-│   │   │   ├── layout.tsx
-│   │   │   └── page.tsx
-│   │   └── api/
-│   │       └── [resource]/route.ts
-│   │
-│   ├── features/                   # Feature-based modules
-│   │   ├── auth/
-│   │   │   ├── components/
-│   │   │   ├── hooks/
-│   │   │   ├── actions.ts          # Server Actions
-│   │   │   ├── queries.ts          # Data fetching
-│   │   │   └── types.ts
-│   │   ├── products/
-│   │   │   ├── components/
-│   │   │   ├── actions.ts
-│   │   │   └── queries.ts
-│   │   └── cart/
-│   │       └── ...
-│   │
-│   ├── shared/                     # Shared utilities
-│   │   ├── components/ui/          # Reusable UI components
-│   │   ├── lib/                    # Utils, helpers
-│   │   └── hooks/                  # Global hooks
-│   │
-│   └── server/                     # Server-only code
-│       ├── db/                     # Database client (Prisma)
-│       ├── auth/                   # Auth config
-│       └── services/               # External API integrations
-│
-├── prisma/
-│   ├── schema.prisma
-│   ├── migrations/
-│   └── seed.ts
-│
-├── public/
-├── .env.example
-├── .env.local
-├── package.json
-├── tailwind.config.ts
-├── tsconfig.json
-└── README.md
-```
-
----
-
-## Structure Principles
-
-| Principle | Implementation |
-|-----------|----------------|
-| **Feature isolation** | Each feature in `features/` with its own components, hooks, actions |
-| **Server/Client separation** | Server-only code in `server/`, prevents accidental client imports |
-| **Thin routes** | `app/` only for routing, logic lives in `features/` |
-| **Route groups** | `(groupName)/` for layout sharing without URL impact |
-| **Shared code** | `shared/` for truly reusable UI and utilities |
-
----
-
-## Core Files
-
-| File | Purpose |
-|------|---------|
-| `package.json` | Dependencies |
-| `tsconfig.json` | TypeScript + path aliases (`@/features/*`) |
-| `tailwind.config.ts` | Tailwind config |
-| `.env.example` | Environment template |
-| `README.md` | Project documentation |
-| `.gitignore` | Git ignore rules |
-| `prisma/schema.prisma` | Database schema |
-
----
-
-## Path Aliases (tsconfig.json)
-
-```json
-{
-  "compilerOptions": {
-    "paths": {
-      "@/*": ["./src/*"],
-      "@/features/*": ["./src/features/*"],
-      "@/shared/*": ["./src/shared/*"],
-      "@/server/*": ["./src/server/*"]
-    }
-  }
-}
-```
-
----
-
-## When to Use What
-
-| Need | Location |
-|------|----------|
-| New page/route | `app/(group)/page.tsx` |
-| Feature component | `features/[name]/components/` |
-| Server action | `features/[name]/actions.ts` |
-| Data fetching | `features/[name]/queries.ts` |
-| Reusable button/input | `shared/components/ui/` |
-| Database query | `server/db/` |
-| External API call | `server/services/` |

package/.agent/skills/app-builder/tech-stack.md

@@ -1,40 +0,0 @@
-# Tech Stack Selection (2026)
-
-> Default and alternative technology choices for web applications.
-
-## Default Stack (Web App - 2026)
-
-```yaml
-Frontend:
-  framework: Next.js 16 (Stable)
-  language: TypeScript 5.7+
-  styling: Tailwind CSS v4
-  state: React 19 Actions / Server Components
-  bundler: Turbopack (Stable for Dev)
-
-Backend:
-  runtime: Node.js 23
-  framework: Next.js API Routes / Hono (for Edge)
-  validation: Zod / TypeBox
-
-Database:
-  primary: PostgreSQL
-  orm: Prisma / Drizzle
-  hosting: Supabase / Neon
-
-Auth:
-  provider: Auth.js (v5) / Clerk
-
-Monorepo:
-  tool: Turborepo 2.0
-```
-
-## Alternative Options
-
-| Need | Default | Alternative |
-|------|---------|-------------|
-| Real-time | - | Supabase Realtime, Socket.io |
-| File storage | - | Cloudinary, S3 |
-| Payment | Stripe | LemonSqueezy, Paddle |
-| Email | - | Resend, SendGrid |
-| Search | - | Algolia, Typesense |

package/.agent/skills/architecture/context-discovery.md

@@ -1,43 +0,0 @@
-# Context Discovery
-
-> Before suggesting any architecture, gather context.
-
-## Question Hierarchy (Ask User FIRST)
-
-1. **Scale**
-   - How many users? (10, 1K, 100K, 1M+)
-   - Data volume? (MB, GB, TB)
-   - Transaction rate? (per second/minute)
-
-2. **Team**
-   - Solo developer or team?
-   - Team size and expertise?
-   - Distributed or co-located?
-
-3. **Timeline**
-   - MVP/Prototype or long-term product?
-   - Time to market pressure?
-
-4. **Domain**
-   - CRUD-heavy or business logic complex?
-   - Real-time requirements?
-   - Compliance/regulations?
-
-5. **Constraints**
-   - Budget limitations?
-   - Legacy systems to integrate?
-   - Technology stack preferences?
-
-## Project Classification Matrix
-
-```
-                    MVP              SaaS           Enterprise
-┌─────────────────────────────────────────────────────────────┐
-│ Scale        │ <1K           │ 1K-100K      │ 100K+        │
-│ Team         │ Solo          │ 2-10         │ 10+          │
-│ Timeline     │ Fast (weeks)  │ Medium (months)│ Long (years)│
-│ Architecture │ Simple        │ Modular      │ Distributed  │
-│ Patterns     │ Minimal       │ Selective    │ Comprehensive│
-│ Example      │ Next.js API   │ NestJS       │ Microservices│
-└─────────────────────────────────────────────────────────────┘
-```

package/.agent/skills/architecture/examples.md

@@ -1,94 +0,0 @@
-# Architecture Examples
-
-> Real-world architecture decisions by project type.
-
----
-
-## Example 1: MVP E-commerce (Solo Developer)
-
-```yaml
-Requirements:
-  - <1000 users initially
-  - Solo developer
-  - Fast to market (8 weeks)
-  - Budget-conscious
-
-Architecture Decisions:
-  App Structure: Monolith (simpler for solo)
-  Framework: Next.js (full-stack, fast)
-  Data Layer: Prisma direct (no over-abstraction)
-  Authentication: JWT (simpler than OAuth)
-  Payment: Stripe (hosted solution)
-  Database: PostgreSQL (ACID for orders)
-
-Trade-offs Accepted:
-  - Monolith → Can't scale independently (team doesn't justify it)
-  - No Repository → Less testable (simple CRUD doesn't need it)
-  - JWT → No social login initially (can add later)
-
-Future Migration Path:
-  - Users > 10K → Extract payment service
-  - Team > 3 → Add Repository pattern
-  - Social login requested → Add OAuth
-```
-
----
-
-## Example 2: SaaS Product (5-10 Developers)
-
-```yaml
-Requirements:
-  - 1K-100K users
-  - 5-10 developers
-  - Long-term (12+ months)
-  - Multiple domains (billing, users, core)
-
-Architecture Decisions:
-  App Structure: Modular Monolith (team size optimal)
-  Framework: NestJS (modular by design)
-  Data Layer: Repository pattern (testing, flexibility)
-  Domain Model: Partial DDD (rich entities)
-  Authentication: OAuth + JWT
-  Caching: Redis
-  Database: PostgreSQL
-
-Trade-offs Accepted:
-  - Modular Monolith → Some module coupling (microservices not justified)
-  - Partial DDD → No full aggregates (no domain experts)
-  - RabbitMQ later → Initial synchronous (add when proven needed)
-
-Migration Path:
-  - Team > 10 → Consider microservices
-  - Domains conflict → Extract bounded contexts
-  - Read performance issues → Add CQRS
-```
-
----
-
-## Example 3: Enterprise (100K+ Users)
-
-```yaml
-Requirements:
-  - 100K+ users
-  - 10+ developers
-  - Multiple business domains
-  - Different scaling needs
-  - 24/7 availability
-
-Architecture Decisions:
-  App Structure: Microservices (independent scale)
-  API Gateway: Kong/AWS API GW
-  Domain Model: Full DDD
-  Consistency: Event-driven (eventual OK)
-  Message Bus: Kafka
-  Authentication: OAuth + SAML (enterprise SSO)
-  Database: Polyglot (right tool per job)
-  CQRS: Selected services
-
-Operational Requirements:
-  - Service mesh (Istio/Linkerd)
-  - Distributed tracing (Jaeger/Tempo)
-  - Centralized logging (ELK/Loki)
-  - Circuit breakers (Resilience4j)
-  - Kubernetes/Helm
-```

package/.agent/skills/architecture/pattern-selection.md

@@ -1,68 +0,0 @@
-# Pattern Selection Guidelines
-
-> Decision trees for choosing architectural patterns.
-
-## Main Decision Tree
-
-```
-START: What's your MAIN concern?
-
-┌─ Data Access Complexity?
-│  ├─ HIGH (complex queries, testing needed)
-│  │  → Repository Pattern + Unit of Work
-│  │  VALIDATE: Will data source change frequently?
-│  │     ├─ YES → Repository worth the indirection
-│  │     └─ NO  → Consider simpler ORM direct access
-│  └─ LOW (simple CRUD, single database)
-│     → ORM directly (Prisma, Drizzle)
-│     Simpler = Better, Faster
-│
-├─ Business Rules Complexity?
-│  ├─ HIGH (domain logic, rules vary by context)
-│  │  → Domain-Driven Design
-│  │  VALIDATE: Do you have domain experts on team?
-│  │     ├─ YES → Full DDD (Aggregates, Value Objects)
-│  │     └─ NO  → Partial DDD (rich entities, clear boundaries)
-│  └─ LOW (mostly CRUD, simple validation)
-│     → Transaction Script pattern
-│     Simpler = Better, Faster
-│
-├─ Independent Scaling Needed?
-│  ├─ YES (different components scale differently)
-│  │  → Microservices WORTH the complexity
-│  │  REQUIREMENTS (ALL must be true):
-│  │    - Clear domain boundaries
-│  │    - Team > 10 developers
-│  │    - Different scaling needs per service
-│  │  IF NOT ALL MET → Modular Monolith instead
-│  └─ NO (everything scales together)
-│     → Modular Monolith
-│     Can extract services later when proven needed
-│
-└─ Real-time Requirements?
-   ├─ HIGH (immediate updates, multi-user sync)
-   │  → Event-Driven Architecture
-   │  → Message Queue (RabbitMQ, Redis, Kafka)
-   │  VALIDATE: Can you handle eventual consistency?
-   │     ├─ YES → Event-driven valid
-   │     └─ NO  → Synchronous with polling
-   └─ LOW (eventual consistency acceptable)
-      → Synchronous (REST/GraphQL)
-      Simpler = Better, Faster
-```
-
-## The 3 Questions (Before ANY Pattern)
-
-1. **Problem Solved**: What SPECIFIC problem does this pattern solve?
-2. **Simpler Alternative**: Is there a simpler solution?
-3. **Deferred Complexity**: Can we add this LATER when needed?
-
-## Red Flags (Anti-patterns)
-
-| Pattern | Anti-pattern | Simpler Alternative |
-|---------|-------------|-------------------|
-| Microservices | Premature splitting | Start monolith, extract later |
-| Clean/Hexagonal | Over-abstraction | Concrete first, interfaces later |
-| Event Sourcing | Over-engineering | Append-only audit log |
-| CQRS | Unnecessary complexity | Single model |
-| Repository | YAGNI for simple CRUD | ORM direct access |

package/.agent/skills/architecture/patterns-reference.md

@@ -1,50 +0,0 @@
-# Architecture Patterns Reference
-
-> Quick reference for common patterns with usage guidance.
-
-## Data Access Patterns
-
-| Pattern | When to Use | When NOT to Use | Complexity |
-|---------|-------------|-----------------|------------|
-| **Active Record** | Simple CRUD, rapid prototyping | Complex queries, multiple sources | Low |
-| **Repository** | Testing needed, multiple sources | Simple CRUD, single database | Medium |
-| **Unit of Work** | Complex transactions | Simple operations | High |
-| **Data Mapper** | Complex domain, performance | Simple CRUD, rapid dev | High |
-
-## Domain Logic Patterns
-
-| Pattern | When to Use | When NOT to Use | Complexity |
-|---------|-------------|-----------------|------------|
-| **Transaction Script** | Simple CRUD, procedural | Complex business rules | Low |
-| **Table Module** | Record-based logic | Rich behavior needed | Low |
-| **Domain Model** | Complex business logic | Simple CRUD | Medium |
-| **DDD (Full)** | Complex domain, domain experts | Simple domain, no experts | High |
-
-## Distributed System Patterns
-
-| Pattern | When to Use | When NOT to Use | Complexity |
-|---------|-------------|-----------------|------------|
-| **Modular Monolith** | Small teams, unclear boundaries | Clear contexts, different scales | Medium |
-| **Microservices** | Different scales, large teams | Small teams, simple domain | Very High |
-| **Event-Driven** | Real-time, loose coupling | Simple workflows, strong consistency | High |
-| **CQRS** | Read/write performance diverges | Simple CRUD, same model | High |
-| **Saga** | Distributed transactions | Single database, simple ACID | High |
-
-## API Patterns
-
-| Pattern | When to Use | When NOT to Use | Complexity |
-|---------|-------------|-----------------|------------|
-| **REST** | Standard CRUD, resources | Real-time, complex queries | Low |
-| **GraphQL** | Flexible queries, multiple clients | Simple CRUD, caching needs | Medium |
-| **gRPC** | Internal services, performance | Public APIs, browser clients | Medium |
-| **WebSocket** | Real-time updates | Simple request/response | Medium |
-
----
-
-## Simplicity Principle
-
-**"Start simple, add complexity only when proven necessary."**
-
-- You can always add patterns later
-- Removing complexity is MUCH harder than adding it
-- When in doubt, choose simpler option

package/.agent/skills/architecture/trade-off-analysis.md

@@ -1,77 +0,0 @@
-# Trade-off Analysis & ADR
-
-> Document every architectural decision with trade-offs.
-
-## Decision Framework
-
-For EACH architectural component, document:
-
-```markdown
-## Architecture Decision Record
-
-### Context
-- **Problem**: [What problem are we solving?]
-- **Constraints**: [Team size, scale, timeline, budget]
-
-### Options Considered
-
-| Option | Pros | Cons | Complexity | When Valid |
-|--------|------|------|------------|-----------|
-| Option A | Benefit 1 | Cost 1 | Low | [Conditions] |
-| Option B | Benefit 2 | Cost 2 | High | [Conditions] |
-
-### Decision
-**Chosen**: [Option B]
-
-### Rationale
-1. [Reason 1 - tied to constraints]
-2. [Reason 2 - tied to requirements]
-
-### Trade-offs Accepted
-- [What we're giving up]
-- [Why this is acceptable]
-
-### Consequences
-- **Positive**: [Benefits we gain]
-- **Negative**: [Costs/risks we accept]
-- **Mitigation**: [How we'll address negatives]
-
-### Revisit Trigger
-- [When to reconsider this decision]
-```
-
-## ADR Template
-
-```markdown
-# ADR-[XXX]: [Decision Title]
-
-## Status
-Proposed | Accepted | Deprecated | Superseded by [ADR-YYY]
-
-## Context
-[What problem? What constraints?]
-
-## Decision
-[What we chose - be specific]
-
-## Rationale
-[Why - tie to requirements and constraints]
-
-## Trade-offs
-[What we're giving up - be honest]
-
-## Consequences
-- **Positive**: [Benefits]
-- **Negative**: [Costs]
-- **Mitigation**: [How to address]
-```
-
-## ADR Storage
-
-```
-docs/
-└── architecture/
-    ├── adr-001-use-nextjs.md
-    ├── adr-002-postgresql-over-mongodb.md
-    └── adr-003-adopt-repository-pattern.md
-```