tribunal-kit 1.0.0 → 2.4.2

package/.agent/skills/realtime-patterns/SKILL.md

@@ -0,0 +1,296 @@
+---
+name: realtime-patterns
+description: Real-time and collaborative application patterns. WebSockets, Server-Sent Events for AI streaming, CRDTs for conflict-free collaboration, presence, and sync engines. Use when building live collaboration, AI streaming UIs, live dashboards, or multiplayer features.
+allowed-tools: Read, Write, Edit, Glob, Grep
+version: 1.0.0
+last-updated: 2026-03-12
+applies-to-model: gemini-2.5-pro, claude-3-7-sonnet
+---
+
+# Real-Time Patterns
+
+> The hardest part of real-time systems is not the latency — it's the concurrent state.
+> Two users editing the same document at the same millisecond must both win.
+
+---
+
+## Transport Selection
+
+Choose the transport based on what the data flow looks like:
+
+| Transport | Direction | Best For | Avoid When |
+|---|---|---|---|
+| **WebSocket** | Bidirectional | Chat, multiplayer, collaboration | Simple server push |
+| **SSE (Server-Sent Events)** | Server → client only | AI streaming, dashboards, notifications | Client needs to send data |
+| **WebRTC** | Peer-to-peer | Video/audio, P2P file transfer | Server coordination needed |
+| **HTTP Polling** | Client pull | Low-frequency updates, fallback | > 1 update per second |
+| **HTTP Streaming** | Server → client | Large response streaming, AI output | Need bidirectionality |
+
+---
+
+## WebSocket Patterns
+
+### Connection Lifecycle
+
+```ts
+class WebSocketManager {
+  private ws: WebSocket | null = null;
+  private reconnectDelay = 1000;
+  private maxReconnectDelay = 30000;
+
+  connect(url: string) {
+    this.ws = new WebSocket(url);
+
+    this.ws.onopen = () => {
+      this.reconnectDelay = 1000;  // Reset on successful connect
+      this.authenticate();
+    };
+
+    this.ws.onclose = (event) => {
+      if (!event.wasClean) {
+        // Exponential backoff reconnect — never hammer the server
+        setTimeout(() => this.connect(url), this.reconnectDelay);
+        this.reconnectDelay = Math.min(this.reconnectDelay * 2, this.maxReconnectDelay);
+      }
+    };
+
+    this.ws.onerror = (err) => {
+      console.error('WebSocket error:', err);
+      // onclose fires after onerror — let it handle reconnect
+    };
+  }
+
+  private authenticate() {
+    // ✅ Always authenticate AFTER connection — never trust URL params for auth
+    this.ws!.send(JSON.stringify({
+      type: 'auth',
+      token: getAccessToken(),
+    }));
+  }
+}
+```
+
+### Backpressure
+
+```ts
+// ❌ Unbounded send — crashes if network is slow
+for (const item of hugeArray) {
+  ws.send(JSON.stringify(item));  // Buffers infinitely if slow
+}
+
+// ✅ Check bufferedAmount before sending
+function sendWhenReady(ws: WebSocket, data: string) {
+  if (ws.bufferedAmount > 65536) {  // 64KB threshold
+    setTimeout(() => sendWhenReady(ws, data), 50);
+    return;
+  }
+  ws.send(data);
+}
+```
+
+---
+
+## SSE for AI Streaming
+
+The right transport for one-directional AI text streaming:
+
+### Server (Node.js / Hono)
+
+```ts
+app.get('/api/chat/stream', async (c) => {
+  const { message } = c.req.query();
+
+  // Set SSE headers
+  c.res.headers.set('Content-Type', 'text/event-stream');
+  c.res.headers.set('Cache-Control', 'no-cache');
+  c.res.headers.set('Connection', 'keep-alive');
+
+  const stream = await openai.chat.completions.create({
+    model: 'gpt-4o',
+    messages: [{ role: 'user', content: message }],
+    stream: true,
+  });
+
+  const encoder = new TextEncoder();
+  const readable = new ReadableStream({
+    async start(controller) {
+      for await (const chunk of stream) {
+        const text = chunk.choices[0]?.delta?.content ?? '';
+        if (text) {
+          controller.enqueue(encoder.encode(`data: ${JSON.stringify({ text })}\n\n`));
+        }
+      }
+      controller.enqueue(encoder.encode('data: [DONE]\n\n'));
+      controller.close();
+    },
+  });
+
+  return new Response(readable);
+});
+```
+
+### Client (React)
+
+```tsx
+function useAIStream(prompt: string) {
+  const [text, setText] = useState('');
+  const [done, setDone] = useState(false);
+
+  useEffect(() => {
+    const source = new EventSource(`/api/chat/stream?message=${encodeURIComponent(prompt)}`);
+
+    source.onmessage = (e) => {
+      if (e.data === '[DONE]') {
+        setDone(true);
+        source.close();
+        return;
+      }
+      const { text: chunk } = JSON.parse(e.data);
+      setText(prev => prev + chunk);
+    };
+
+    source.onerror = () => source.close();
+
+    return () => source.close();  // Cleanup on unmount
+  }, [prompt]);
+
+  return { text, done };
+}
+```
+
+---
+
+## CRDTs: Conflict-Free Collaboration
+
+CRDTs (Conflict-free Replicated Data Types) guarantee that concurrent edits from multiple users always merge to the same result, regardless of order or network conditions.
+
+### When to Use CRDTs vs Last-Write-Wins
+
+```
+Last-Write-Wins (LWW):
+  ✅ Settings, preferences, single-value fields
+  ❌ Text editing — loses concurrent edits
+
+Operational Transform (OT):
+  ✅ Google Docs-style (centralized server required)
+  ❌ Peer-to-peer, offline-first (server is the truth arbiter)
+
+CRDTs:
+  ✅ Collaborative text (Yjs), presence, shared lists
+  ✅ Offline-first, peer-to-peer
+  ✅ No central server required for convergence
+```
+
+### Yjs — The Standard CRDT Library
+
+```ts
+import * as Y from 'yjs';
+import { WebsocketProvider } from 'y-websocket';
+
+// Create a shared document
+const doc = new Y.Doc();
+
+// Connect to sync server — providers handle conflict resolution
+const provider = new WebsocketProvider('wss://your-server.com', 'room-id', doc);
+
+// Y.Text — CRDT for collaborative text editing
+const yText = doc.getText('document');
+
+// Bind to a rich text editor (Tiptap, ProseMirror, CodeMirror)
+const editor = new Editor({
+  extensions: [Collaboration.configure({ document: doc })],
+});
+
+// Y.Map — CRDT for key-value shared state
+const awareness = new Y.Map();
+awareness.set('cursor', { userId, position });
+```
+
+---
+
+## Presence Patterns
+
+Presence = "who is online and what are they doing":
+
+```ts
+// Server: track presence via WebSocket lifecycle
+const presence = new Map<string, { userId: string; cursor: Position }>();
+
+wss.on('connection', (ws, req) => {
+  const userId = authenticate(req);
+
+  ws.on('message', (data) => {
+    const msg = JSON.parse(data.toString());
+    if (msg.type === 'cursor') {
+      presence.set(userId, { userId, cursor: msg.position });
+      broadcast({ type: 'presence', users: [...presence.values()] });
+    }
+  });
+
+  ws.on('close', () => {
+    presence.delete(userId);
+    broadcast({ type: 'presence', users: [...presence.values()] });
+  });
+});
+```
+
+---
+
+## Sync Engine Selection
+
+| Engine | Model | Best For |
+|---|---|---|
+| **PartyKit** | WebSocket-native, Durable Objects | Multiplayer apps, AI + realtime |
+| **Liveblocks** | Managed CRDT + presence | Collaborative SaaS (Figma-style) |
+| **Supabase Realtime** | PostgreSQL change streams | Postgres-centric apps |
+| **ElectricSQL** | Local-first sync from Postgres | Offline-first apps |
+| **Replicache** | Client-side mutations + sync | Highly interactive, offline-capable |
+
+---
+
+## Output Format
+
+When this skill produces or reviews code, structure your output as follows:
+
+```
+━━━ Realtime Patterns Report ━━━━━━━━━━━━━━━━━━━━━━━━
+Skill:       Realtime Patterns
+Language:    [detected language / framework]
+Scope:       [N files · N functions]
+─────────────────────────────────────────────────
+✅ Passed:   [checks that passed, or "All clean"]
+⚠️  Warnings: [non-blocking issues, or "None"]
+❌ Blocked:  [blocking issues requiring fix, or "None"]
+─────────────────────────────────────────────────
+VBC status:  PENDING → VERIFIED
+Evidence:    [test output / lint pass / compile success]
+```
+
+**VBC (Verification-Before-Completion) is mandatory.**
+Do not mark status as VERIFIED until concrete terminal evidence is provided.
+
+
+---
+
+## 🏛️ Tribunal Integration (Anti-Hallucination)
+
+**Slash command: `/tribunal-backend`**
+**Active reviewers: `logic` · `security` · `performance`**
+
+### ❌ Forbidden AI Tropes in Real-Time Engineering
+
+1. **Auth in URL params** — `ws://server.com?token=abc123` — tokens in URLs appear in logs and browser history. Authenticate via first message after handshake.
+2. **No reconnect logic** — all WebSocket connections will drop. No reconnect = broken app on any network hiccup.
+3. **Unbounded broadcast** — `wss.clients.forEach(ws => ws.send(data))` with no grouping = O(n) for every event.
+4. **Polling instead of streaming** — `setInterval(() => fetch('/api/ai-status'), 500)` for AI responses = wasteful; use SSE.
+5. **No backpressure handling** — sending data faster than the client can process = WebSocket buffer OOM.
+
+### ✅ Pre-Flight Self-Audit
+
+```
+✅ Are WebSocket connections authenticated via first message, not URL params?
+✅ Is there exponential backoff reconnect logic on unexpected disconnect?
+✅ Are broadcasts scoped to rooms/channels — not sent to all connected clients?
+✅ Is backpressure handled (bufferedAmount check before send)?
+✅ Is SSE used for one-directional AI streaming instead of WebSocket?
+```

package/.agent/skills/red-team-tactics/SKILL.md

@@ -1,199 +1,201 @@
 ---
 name: red-team-tactics
 description: Red team tactics principles based on MITRE ATT&CK. Attack phases, detection evasion, reporting.
-allowed-tools: Read, Glob, Grep
+allowed-tools: Read, Write, Edit, Glob, Grep
+version: 1.0.0
+last-updated: 2026-03-12
+applies-to-model: gemini-2.5-pro, claude-3-7-sonnet
 ---
 
-# Red Team Tactics
+# Red Team & Penetration Testing Principles
 
-> Adversary simulation principles based on MITRE ATT&CK framework.
+> A red team engagement is a controlled attack.
+> The goal is to find what a real attacker would find — before they do.
+
+⚠️ **These techniques are for authorized security testing only. Unauthorized use is illegal.**
 
 ---
 
-## 1. MITRE ATT&CK Phases
+## Engagement Scope First
 
-### Attack Lifecycle
+Before any testing activity:
 
-```
-RECONNAISSANCE → INITIAL ACCESS → EXECUTION → PERSISTENCE
-       ↓              ↓              ↓            ↓
-   PRIVILEGE ESC → DEFENSE EVASION → CRED ACCESS → DISCOVERY
-       ↓              ↓              ↓            ↓
-LATERAL MOVEMENT → COLLECTION → C2 → EXFILTRATION → IMPACT
-```
+1. **Written authorization** — who authorized this engagement and in what scope?
+2. **Scope definition** — which systems, IPs, domains, time windows are in scope?
+3. **Rules of engagement** — what is prohibited? (production data access, social engineering of specific roles, DDoS)
+4. **Emergency contact** — who do you call if you discover a critical live breach mid-engagement?
+5. **Deconfliction** — does the blue team know an engagement is running, or is it blind?
 
-### Phase Objectives
-
-| Phase | Objective |
-|-------|-----------|
-| **Recon** | Map attack surface |
-| **Initial Access** | Get first foothold |
-| **Execution** | Run code on target |
-| **Persistence** | Survive reboots |
-| **Privilege Escalation** | Get admin/root |
-| **Defense Evasion** | Avoid detection |
-| **Credential Access** | Harvest credentials |
-| **Discovery** | Map internal network |
-| **Lateral Movement** | Spread to other systems |
-| **Collection** | Gather target data |
-| **C2** | Maintain command channel |
-| **Exfiltration** | Extract data |
+No authorization = no testing.
 
 ---
 
-## 2. Reconnaissance Principles
+## Attack Phases (Based on MITRE ATT&CK)
 
-### Passive vs Active
+### 1. Reconnaissance
+Passive and active information gathering before touching the target.
 
-| Type | Trade-off |
-|------|-----------|
-| **Passive** | No target contact, limited info |
-| **Active** | Direct contact, more detection risk |
+**Passive (no target contact):**
+- DNS lookup: `nslookup`, `dig`, certificate transparency logs
+- OSINT: LinkedIn for employee names/roles, GitHub for leaked configs, Shodan for exposed infrastructure
 
-### Information Targets
+**Active (target is contacted):**
+- Port scanning: `nmap -sV -sC <target>`
+- Web tech detection: `whatweb`, `wappalyzer`
+- Subdomain enumeration: `amass`, `subfinder`
 
-| Category | Value |
-|----------|-------|
-| Technology stack | Attack vector selection |
-| Employee info | Social engineering |
-| Network ranges | Scanning scope |
-| Third parties | Supply chain attack |
+### 2. Initial Access
+How does an attacker get their first foothold?
 
----
+Common vectors:
+- Phishing (credential harvest or malicious attachment)
+- Exposed admin interfaces with default or weak credentials
+- Publicly exposed vulnerable services (`searchsploit`, `nuclei`)
+- Supply chain compromise (malicious npm package, CI/CD injection)
 
-## 3. Initial Access Vectors
+### 3. Persistence
+Maintaining access after initial compromise:
 
-### Selection Criteria
+- Scheduled tasks / cron jobs
+- Web shells on compromised web servers
+- New user accounts with admin rights
+- SSH authorized_keys injection
 
-| Vector | When to Use |
-|--------|-------------|
-| **Phishing** | Human target, email access |
-| **Public exploits** | Vulnerable services exposed |
-| **Valid credentials** | Leaked or cracked |
-| **Supply chain** | Third-party access |
+### 4. Lateral Movement
+Moving from initial foothold to higher-value targets:
 
----
+- Pass-the-hash / pass-the-ticket (Active Directory)
+- SSH key reuse across hosts
+- Credential reuse (if one service is compromised, others sharing the password are vulnerable)
+- Internal network scanning to map new targets
 
-## 4. Privilege Escalation Principles
+### 5. Exfiltration
+Getting data out without triggering alerts:
 
-### Windows Targets
+- Small, slow transfers to blend with normal traffic
+- Staging data in cloud storage linked to attacker-controlled accounts
+- DNS exfiltration (for heavily monitored networks)
 
-| Check | Opportunity |
-|-------|-------------|
-| Unquoted service paths | Write to path |
-| Weak service permissions | Modify service |
-| Token privileges | Abuse SeDebug, etc. |
-| Stored credentials | Harvest |
+---
 
-### Linux Targets
+## Common Vulnerability Targets
 
-| Check | Opportunity |
-|-------|-------------|
-| SUID binaries | Execute as owner |
-| Sudo misconfiguration | Command execution |
-| Kernel vulnerabilities | Kernel exploits |
-| Cron jobs | Writable scripts |
+| Target | What to Test |
+|---|---|
+| Web applications | OWASP Top 10, auth bypass, IDOR, SSRF |
+| APIs | Object-level authorization, mass assignment, rate limiting |
+| Authentication | Brute force protection, token entropy, password reset flow |
+| Secrets | Exposed env files, git history, CI/CD environment variables |
+| Third-party integrations | Webhook validation, OAuth redirect URI validation |
+| Infrastructure | Open S3 buckets, exposed admin ports, default credentials |
 
 ---
 
-## 5. Defense Evasion Principles
+## Detection Evasion (for Authorized Testing)
 
-### Key Techniques
+When testing detection capabilities:
 
-| Technique | Purpose |
-|-----------|---------|
-| LOLBins | Use legitimate tools |
-| Obfuscation | Hide malicious code |
-| Timestomping | Hide file modifications |
-| Log clearing | Remove evidence |
+- Slow scan rates to stay under IDS thresholds
+- Use legitimate user agents and headers
+- Blend with normal traffic patterns
+- Test from IP ranges the organization wouldn't expect
 
-### Operational Security
+---
 
-- Work during business hours
-- Mimic legitimate traffic patterns
-- Use encrypted channels
-- Blend with normal behavior
+## Reporting Format
 
----
+```markdown
+# Red Team Report: [Engagement Name]
 
-## 6. Lateral Movement Principles
+## Executive Summary
+[2–3 sentences: what was tested, biggest risk found, business impact]
 
-### Credential Types
+## Scope
+[Systems tested, date range, authorization reference]
 
-| Type | Use |
-|------|-----|
-| Password | Standard auth |
-| Hash | Pass-the-hash |
-| Ticket | Pass-the-ticket |
-| Certificate | Certificate auth |
+## Critical Findings
 
-### Movement Paths
+### CRIT-01: [Title]
+**Risk:** Critical
+**CVSS:** 9.8
+**Description:** [What the vulnerability is]
+**Evidence:** [Screenshot, payload, response]
+**Impact:** [What an attacker could do]
+**Remediation:** [Specific fix with code or config example]
 
-- Admin shares
-- Remote services (RDP, SSH, WinRM)
-- Exploitation of internal services
+## Attack Narrative
+[Chronological story of the full attack path from initial access to objective]
 
----
+## Remediation Priority
+| Finding | Severity | Fix By |
+|---|---|---|
+```
 
-## 7. Active Directory Attacks
+---
 
-### Attack Categories
+## Ethical Boundaries
 
-| Attack | Target |
-|--------|--------|
-| Kerberoasting | Service account passwords |
-| AS-REP Roasting | Accounts without pre-auth |
-| DCSync | Domain credentials |
-| Golden Ticket | Persistent domain access |
+- Stop immediately if you discover evidence of an active breach by a real attacker — report it, don't continue testing
+- Don't access, copy, or delete real user data even if you can
+- Document everything — every command run, every finding noted
+- Brief the client team before leaving — no surprises in the report
 
 ---
 
-## 8. Reporting Principles
+## Output Format
 
-### Attack Narrative
+When this skill produces a recommendation or design decision, structure your output as:
 
-Document the full attack chain:
-1. How initial access was gained
-2. What techniques were used
-3. What objectives were achieved
-4. Where detection failed
+```
+━━━ Red Team Tactics Recommendation ━━━━━━━━━━━━━━━━
+Decision:    [what was chosen / proposed]
+Rationale:   [why — one concise line]
+Trade-offs:  [what is consciously accepted]
+Next action: [concrete next step for the user]
+─────────────────────────────────────────────────
+Pre-Flight:  ✅ All checks passed
+             or ❌ [blocking item that must be resolved first]
+```
 
-### Detection Gaps
 
-For each successful technique:
-- What should have detected it?
-- Why didn't detection work?
-- How to improve detection
 
 ---
 
-## 9. Ethical Boundaries
+## 🤖 LLM-Specific Traps
 
-### Always
+AI coding assistants often fall into specific bad habits when dealing with this domain. These are strictly forbidden:
 
-- Stay within scope
-- Minimize impact
-- Report immediately if real threat found
-- Document all actions
+1. **Over-engineering:** Proposing complex abstractions or distributed systems when a simpler approach suffices.
+2. **Hallucinated Libraries/Methods:** Using non-existent methods or packages. Always `// VERIFY` or check `package.json` / `requirements.txt`.
+3. **Skipping Edge Cases:** Writing the "happy path" and ignoring error handling, timeouts, or data validation.
+4. **Context Amnesia:** Forgetting the user's constraints and offering generic advice instead of tailored solutions.
+5. **Silent Degradation:** Catching and suppressing errors without logging or re-raising.
 
-### Never
+---
 
-- Destroy production data
-- Cause denial of service (unless scoped)
-- Access beyond proof of concept
-- Retain sensitive data
+## 🏛️ Tribunal Integration (Anti-Hallucination)
 
----
+**Slash command: `/review` or `/tribunal-full`**
+**Active reviewers: `logic-reviewer` · `security-auditor`**
 
-## 10. Anti-Patterns
+### ❌ Forbidden AI Tropes
 
-| ❌ Don't | ✅ Do |
-|----------|-------|
-| Rush to exploitation | Follow methodology |
-| Cause damage | Minimize impact |
-| Skip reporting | Document everything |
-| Ignore scope | Stay within boundaries |
+1. **Blind Assumptions:** Never make an assumption without documenting it clearly with `// VERIFY: [reason]`.
+2. **Silent Degradation:** Catching and suppressing errors without logging or handling.
+3. **Context Amnesia:** Forgetting the user's constraints and offering generic advice instead of tailored solutions.
 
----
+### ✅ Pre-Flight Self-Audit
+
+Review these questions before confirming output:
+```
+✅ Did I rely ONLY on real, verified tools and methods?
+✅ Is this solution appropriately scoped to the user's constraints?
+✅ Did I handle potential failure modes and edge cases?
+✅ Have I avoided generic boilerplate that doesn't add value?
+```
+
+### 🛑 Verification-Before-Completion (VBC) Protocol
 
-> **Remember:** Red team simulates attackers to improve defenses, not to cause harm.
+**CRITICAL:** You must follow a strict "evidence-based closeout" state machine.
+- ❌ **Forbidden:** Declaring a task complete because the output "looks correct."
+- ✅ **Required:** You are explicitly forbidden from finalizing any task without providing **concrete evidence** (terminal output, passing tests, compile success, or equivalent proof) that your output works as intended.