@wipal/agent-team 1.0.0

package/.claude/skills/domain/architecture/security-architecture/references/compliance.md

@@ -0,0 +1,246 @@
+# Compliance Frameworks
+
+## Overview
+Compliance requirements vary by industry and region. This reference covers common frameworks and their key requirements.
+
+## Major Compliance Frameworks
+
+### GDPR (EU Data Protection)
+```
+Scope: Personal data of EU residents
+
+Key Requirements:
+- Lawful basis for processing
+- Data subject rights (access, deletion, portability)
+- Data protection by design
+- Privacy notices
+- Data breach notification (72 hours)
+- Data Protection Officer (for large-scale processing)
+
+Technical Measures:
+- Encryption at rest and in transit
+- Access controls
+- Audit logging
+- Data minimization
+- Pseudonymization
+
+Documentation:
+- Processing activities record
+- Privacy impact assessments
+- Data retention policies
+```
+
+### SOC 2 (Service Organization Control)
+```
+Scope: Service providers handling customer data
+
+Trust Service Criteria:
+1. Security (Common Criteria)
+2. Availability
+3. Processing Integrity
+4. Confidentiality
+5. Privacy
+
+Key Controls:
+- Access control
+- Encryption
+- Monitoring
+- Incident response
+- Change management
+- Risk assessment
+
+Types:
+- Type I: Point-in-time
+- Type II: Period (6-12 months)
+```
+
+### HIPAA (US Healthcare)
+```
+Scope: Protected Health Information (PHI)
+
+Rules:
+- Privacy Rule: Use and disclosure
+- Security Rule: Technical safeguards
+- Breach Notification Rule
+
+Technical Safeguards:
+- Access controls
+- Audit controls
+- Integrity controls
+- Transmission security (encryption)
+- Authentication
+
+Administrative Safeguards:
+- Security officer
+- Risk analysis
+- Training
+- Incident procedures
+```
+
+### PCI DSS (Payment Cards)
+```
+Scope: Credit card data
+
+Requirements (12 total):
+1. Firewall configuration
+2. Default passwords changed
+3. Stored data protection
+4. Encryption in transit
+5. Anti-virus software
+6. Secure systems
+7. Need-to-know access
+8. Unique user IDs
+9. Physical access control
+10. Access logging
+11. Security testing
+12. Information security policy
+
+Compliance Levels:
+- Level 1: >6M transactions/year (audit)
+- Level 2: 1-6M transactions (self-assessment)
+- Level 3: 20K-1M transactions (self-assessment)
+- Level 4: <20K transactions (self-assessment)
+```
+
+### ISO 27001 (Information Security)
+```
+Scope: Information Security Management System (ISMS)
+
+Structure:
+- 114 controls in Annex A
+- Organizational controls
+- People controls
+- Physical controls
+- Technological controls
+
+Implementation:
+1. Scope definition
+2. Risk assessment
+3. Control selection
+4. Policy documentation
+5. Implementation
+6. Internal audit
+7. Certification audit
+```
+
+## Compliance Checklist Template
+
+### Data Protection
+```
+- [ ] Data inventory completed
+- [ ] Data classification scheme
+- [ ] Retention policies defined
+- [ ] Deletion procedures documented
+- [ ] Encryption implemented
+- [ ] Access controls in place
+```
+
+### Access Control
+```
+- [ ] Role-based access implemented
+- [ ] Principle of least privilege
+- [ ] Multi-factor authentication
+- [ ] Access review process
+- [ ] Privileged access management
+```
+
+### Audit & Monitoring
+```
+- [ ] Audit logging enabled
+- [ ] Log retention defined
+- [ ] Monitoring alerts configured
+- [ ] Incident response procedures
+- [ ] Regular security reviews
+```
+
+### Documentation
+```
+- [ ] Security policies documented
+- [ ] Risk assessments completed
+- [ ] Processing activities recorded
+- [ ] Training records maintained
+- [ ] Vendor assessments completed
+```
+
+## Cross-Compliance Mapping
+
+```
+Control Area          | GDPR | SOC2 | HIPAA | PCI | ISO27001
+----------------------|------|------|-------|-----|----------
+Access Control        |  ✓   |  ✓   |   ✓   |  ✓  |    ✓
+Encryption            |  ✓   |  ✓   |   ✓   |  ✓  |    ✓
+Audit Logging         |  ✓   |  ✓   |   ✓   |  ✓  |    ✓
+Incident Response     |  ✓   |  ✓   |   ✓   |  ✓  |    ✓
+Risk Assessment       |  ✓   |  ✓   |   ✓   |  ✓  |    ✓
+Data Minimization     |  ✓   |  -   |   ✓   |  ✓  |    ✓
+Vendor Management     |  ✓   |  ✓   |   ✓   |  ✓  |    ✓
+Training              |  ✓   |  ✓   |   ✓   |  ✓  |    ✓
+```
+
+## Compliance in Architecture
+
+### Data Residency
+```
+GDPR: EU data in EU (or adequate protection)
+China: Data localization required
+Russia: Personal data in Russia
+
+Architecture Impact:
+- Region-specific deployments
+- Data replication controls
+- Cross-border transfer mechanisms
+```
+
+### Right to Deletion
+```
+GDPR Article 17: Right to erasure
+
+Implementation:
+- Soft delete with retention period
+- Hard delete capability
+- Backup handling
+- Cascade to related systems
+- Verification mechanism
+```
+
+### Audit Trail Requirements
+```
+What to log:
+- Who (user/service)
+- What (action)
+- When (timestamp)
+- Where (IP, system)
+- Result (success/failure)
+
+Retention:
+- HIPAA: 6 years
+- SOX: 7 years
+- PCI: 1 year
+- GDPR: As needed for purpose
+```
+
+## Compliance Tools
+
+### Assessment Tools
+```
+- Compliance frameworks (NIST CSF)
+- Gap analysis tools
+- Risk assessment templates
+- Vendor questionnaires (SIG, CAIQ)
+```
+
+### Monitoring Tools
+```
+- SIEM (Security Information & Event Management)
+- DLP (Data Loss Prevention)
+- Cloud security posture management
+- Compliance dashboards
+```
+
+### Documentation Tools
+```
+- GRC platforms (Governance, Risk, Compliance)
+- Policy management systems
+- Evidence collection tools
+- Audit management systems
+```

package/.claude/skills/domain/architecture/security-architecture/references/threat-modeling.md

@@ -0,0 +1,219 @@
+# Threat Modeling
+
+## What is Threat Modeling?
+A structured approach to identifying, assessing, and addressing security threats.
+
+## STRIDE Framework
+
+### Spoofing
+```
+Definition: Pretending to be something/someone else
+
+Examples:
+- Fake login page
+- Compromised credentials
+- Session hijacking
+- IP spoofing
+
+Mitigations:
+- Strong authentication (MFA)
+- Certificate validation
+- Session tokens with expiration
+- Anti-phishing measures
+```
+
+### Tampering
+```
+Definition: Unauthorized modification of data
+
+Examples:
+- SQL injection
+- Parameter tampering
+- File modification
+- Man-in-the-middle
+
+Mitigations:
+- Input validation
+- Parameterized queries
+- Digital signatures
+- Integrity checks (hashes)
+- TLS for transit
+```
+
+### Repudiation
+```
+Definition: Ability to deny actions
+
+Examples:
+- "I didn't make that transaction"
+- "Someone else used my account"
+- Log deletion
+
+Mitigations:
+- Comprehensive audit logging
+- Digital signatures
+- Non-repudiation services
+- Timestamped logs
+```
+
+### Information Disclosure
+```
+Definition: Unauthorized access to information
+
+Examples:
+- Data breach
+- Error message leakage
+- Side-channel attacks
+- Insecure storage
+
+Mitigations:
+- Encryption (at rest, in transit)
+- Access controls
+- Data masking
+- Secure error handling
+- Minimal data exposure
+```
+
+### Denial of Service
+```
+Definition: Preventing legitimate access
+
+Examples:
+- DDoS attacks
+- Resource exhaustion
+- Application crashes
+- Locking accounts
+
+Mitigations:
+- Rate limiting
+- Load balancing
+- Auto-scaling
+- Resource quotas
+- Circuit breakers
+```
+
+### Elevation of Privilege
+```
+Definition: Gaining unauthorized capabilities
+
+Examples:
+- SQL injection to admin
+- Exploiting vulnerabilities
+- Token manipulation
+- Horizontal/vertical escalation
+
+Mitigations:
+- Principle of least privilege
+- Role validation
+- Security patches
+- Input validation
+- API authorization
+```
+
+## Threat Modeling Process
+
+### Step 1: Identify Assets
+```
+What are we protecting?
+- User data
+- Financial data
+- Intellectual property
+- System availability
+- Reputation
+```
+
+### Step 2: Create Architecture Diagram
+```
+┌─────────┐     ┌─────────┐     ┌─────────┐
+│  Users  │────▶│   Web   │────▶│   API   │
+│         │     │   App   │     │ Server  │
+└─────────┘     └─────────┘     └────┬────┘
+                                     │
+                                     ▼
+                               ┌─────────┐
+                               │Database │
+                               └─────────┘
+
+Mark trust boundaries and data flows.
+```
+
+### Step 3: Identify Threats
+```
+For each component and data flow:
+1. Apply STRIDE
+2. Identify specific threats
+3. Assess likelihood and impact
+```
+
+### Step 4: Document Threats
+```
+| ID | Threat | STRIDE | Likelihood | Impact | Mitigation |
+|----|--------|--------|------------|--------|------------|
+| T1 | SQL injection | T | High | High | Parameterized queries |
+| T2 | Credential theft | S | Medium | High | MFA, monitoring |
+```
+
+### Step 5: Prioritize and Plan
+```
+Risk = Likelihood × Impact
+
+Priority 1: High likelihood, high impact
+Priority 2: Medium likelihood, high impact
+Priority 3: Low likelihood, high impact
+...
+```
+
+## DREAD Assessment
+
+```
+Score 1-10 for each:
+D - Damage potential
+R - Reproducibility
+E - Exploitability
+A - Affected users
+D - Discoverability
+
+Risk Score = (D+R+E+A+D) / 5
+
+High: 8-10
+Medium: 5-7
+Low: 1-4
+```
+
+## Common Threats by Architecture
+
+### Web Application
+```
+- XSS (Cross-Site Scripting)
+- CSRF (Cross-Site Request Forgery)
+- SQL Injection
+- Session hijacking
+- Brute force attacks
+```
+
+### API
+```
+- Broken authentication
+- Excessive data exposure
+- Rate limiting bypass
+- Injection attacks
+- Improper asset management
+```
+
+### Microservices
+```
+- Service-to-service auth
+- Secrets management
+- Network eavesdropping
+- Container vulnerabilities
+- API gateway bypass
+```
+
+### Cloud
+```
+- Misconfigured resources
+- Inadequate access controls
+- Data exfiltration
+- Insider threats
+- Supply chain attacks
+```

package/.claude/skills/domain/architecture/system-design/SKILL.md

@@ -0,0 +1,227 @@
+---
+name: system-design
+description: |
+  Use when designing distributed systems, understanding scalability patterns,
+  or making architecture decisions that involve multiple components.
+  Covers CAP theorem, consistency patterns, scalability strategies, and resilience patterns.
+version: 1.0.0
+category: architecture
+tags:
+  - distributed-systems
+  - scalability
+  - resilience
+  - system-design
+depends_on: []
+recommends:
+  - architecture-patterns
+  - adr-writing
+used_by:
+  - tech-selection
+  - architecture-patterns
+  - performance-engineering
+  - security-architecture
+references:
+  - references/distributed-systems.md
+  - references/scalability.md
+  - references/resilience.md
+---
+
+# System Design
+
+## Core Principle
+**Design for failure, scale horizontally, and keep things simple until you need complexity.**
+
+## When to Use This Skill
+
+### Trigger Conditions
+- Designing a new system or service
+- Evaluating architecture for scalability
+- Planning for high availability
+- Reviewing system resilience
+- Making technology decisions for infrastructure
+
+### Keywords
+- "design a system"
+- "architecture for"
+- "scalability"
+- "high availability"
+- "distributed system"
+- "fault tolerance"
+- "disaster recovery"
+
+## Core Concepts
+
+### 1. CAP Theorem
+In distributed systems, you can only guarantee 2 of 3:
+- **Consistency** - All nodes see same data at same time
+- **Availability** - System always responds (may be stale data)
+- **Partition Tolerance** - System continues despite network failures
+
+```
+         CAP Theorem
+              │
+      ┌───────┴───────┐
+      │               │
+   ┌──┴──┐         ┌──┴──┐
+   │  C  │         │  A  │
+   └──┬──┘         └──┬──┘
+      │    ┌───┐      │
+      └────┤ P ├──────┘
+           └───┘
+
+C + P = CP Systems (MongoDB, Redis, HBase)
+A + P = AP Systems (Cassandra, DynamoDB, CouchDB)
+C + A = CA Systems (RDBMS - not truly distributed)
+```
+
+### 2. Scalability Patterns
+
+| Pattern | Description | Use Case |
+|---------|-------------|----------|
+| **Horizontal** | Add more machines | Web servers, stateless services |
+| **Vertical** | Bigger machines | Databases (until sharding) |
+| **Sharding** | Partition data | Large datasets, high write volume |
+| **Read Replicas** | Copy for reads | Read-heavy workloads |
+
+### 3. Consistency Patterns
+
+| Pattern | Description | Trade-off |
+|---------|-------------|-----------|
+| **Strong** | Immediate consistency | Higher latency |
+| **Eventual** | Converge over time | Stale reads possible |
+| **Causal** | Preserve causality | Complex implementation |
+
+### 4. Availability Patterns
+
+| Pattern | Description | Use Case |
+|---------|-------------|----------|
+| **Active-Active** | All nodes serve traffic | Maximum availability |
+| **Active-Passive** | Failover to standby | Simpler, lower cost |
+| **Multi-Region** | Geographic distribution | Disaster recovery |
+
+## Design Process
+
+### Step 1: Requirements Gathering
+```
+Functional Requirements:
+- What does the system do?
+- Who are the users?
+- What are the use cases?
+
+Non-Functional Requirements:
+- Scale: How many users/requests?
+- Performance: What latency?
+- Availability: What uptime SLA?
+- Consistency: Strong vs eventual?
+```
+
+### Step 2: Capacity Estimation
+```
+Traffic Estimation:
+- Daily Active Users (DAU)
+- Requests per second (RPS)
+- Read vs Write ratio
+
+Storage Estimation:
+- Data size per entity
+- Growth rate
+- Retention period
+
+Bandwidth Estimation:
+- Request/response sizes
+- Peak vs average traffic
+```
+
+### Step 3: High-Level Design
+```
+1. Define system interfaces (API)
+2. Create component diagram
+3. Identify data flow
+4. Choose data stores
+5. Define communication patterns
+```
+
+### Step 4: Deep Dive
+```
+For each component:
+- Algorithm choice
+- Data model
+- Scaling strategy
+- Failure handling
+- Monitoring needs
+```
+
+## Common System Design Templates
+
+### 1. Web Application
+```
+┌─────────┐    ┌─────────┐    ┌─────────┐    ┌─────────┐
+│ Client  │───▶│   LB    │───▶│  API    │───▶│   DB    │
+│ (Web)   │    │         │    │ Server  │    │         │
+└─────────┘    └─────────┘    └─────────┘    └─────────┘
+                    │
+                    ▼
+               ┌─────────┐
+               │ Cache   │
+               │ (Redis) │
+               └─────────┘
+```
+
+### 2. Real-time System
+```
+┌─────────┐    ┌─────────┐    ┌─────────┐    ┌─────────┐
+│ Client  │◀──▶│WebSocket│───▶│ Message │───▶│ Workers │
+│         │    │ Server  │    │  Queue  │    │         │
+└─────────┘    └─────────┘    └─────────┘    └─────────┘
+                                   │
+                                   ▼
+                              ┌─────────┐
+                              │   DB    │
+                              └─────────┘
+```
+
+### 3. Microservices
+```
+┌─────────┐    ┌─────────────────────────────────────┐
+│ Gateway │───▶│           Service Mesh              │
+└─────────┘    │  ┌───────┐ ┌───────┐ ┌───────┐    │
+               │  │ Svc A │ │ Svc B │ │ Svc C │    │
+               │  └───┬───┘ └───┬───┘ └───┬───┘    │
+               └──────┼─────────┼─────────┼────────┘
+                      │         │         │
+                      ▼         ▼         ▼
+                   ┌─────┐ ┌─────┐ ┌─────┐
+                   │ DB1 │ │ DB2 │ │ DB3 │
+                   └─────┘ └─────┘ └─────┘
+```
+
+## Rules
+
+### DO
+- ✅ Start simple, add complexity as needed
+- ✅ Design for failure (circuit breakers, retries)
+- ✅ Use caching strategically
+- ✅ Plan for horizontal scaling
+- ✅ Monitor everything
+- ✅ Document decisions
+
+### DON'T
+- ❌ Over-engineer for scale you don't have
+- ❌ Ignore operational concerns
+- ❌ Skip capacity planning
+- ❌ Forget about security
+- ❌ Make everything distributed
+
+## Output
+
+When using this skill, produce:
+1. **System Design Document** - High-level architecture
+2. **Component Diagram** - Visual representation
+3. **Data Flow Diagram** - How data moves
+4. **Capacity Estimates** - Resource requirements
+5. **ADR** - Key decisions documented
+
+## Related Skills
+- `architecture-patterns` - Specific architecture styles
+- `tech-selection` - Technology choices
+- `performance-engineering` - Optimization strategies