@martinffx/atelier 1.2.1 → 1.3.0

package/skills/oracle-security/references/threat-modeling-guide.md

@@ -1,137 +0,0 @@
-# Threat Modeling Guide
-
-Extended approaches for analyzing security threats during system design.
-
-## Data Flow Analysis
-
-Map how data moves through your system to identify trust boundaries:
-
-```
-External Request → [Trust Boundary] → API Gateway → [Trust Boundary] → Service → [Trust Boundary] → Database
-                        ↑                                              ↑
-                   Authenticate                                    Authorize
-                   Validate input                                 Validate output
-                   Rate limit                                     Audit log
-```
-
-**Process**:
-1. Draw the data flow for a specific use case
-2. Identify every trust boundary crossing
-3. Ask: "What's the worst thing that could enter here?"
-4. Ask: "What validation or enforcement should happen at this boundary?"
-5. Look for paths that bypass expected controls
-
-## STRIDE in Depth
-
-### Spoofing
-- **Threat**: Attacker pretends to be a legitimate user or system
-- **Questions**: How are identities verified? Can tokens be stolen or forged? Can sessions be hijacked?
-- **Controls**: Strong authentication, token binding, session validation, mutual TLS
-
-### Tampering
-- **Threat**: Data is modified in transit or at rest
-- **Questions**: Is integrity checked? Can parameters be altered? Can files be modified?
-- **Controls**: Input validation, checksums, signatures, immutable audit logs
-
-### Repudiation
-- **Threat**: Actions can't be traced back to an actor
-- **Questions**: Are all sensitive operations logged? Are logs tamper-evident? Can users deny their actions?
-- **Controls**: Comprehensive audit logging, signed logs, non-repudiation mechanisms
-
-### Information Disclosure
-- **Threat**: Sensitive data leaks to unauthorized parties
-- **Questions**: What data is exposed in errors? In logs? In API responses? Can users access other users' data?
-- **Controls**: Output filtering, log redaction, access controls, encryption at rest/transit
-
-### Denial of Service
-- **Threat**: System becomes unavailable or unusable
-- **Questions**: Can endpoints be overwhelmed? Are there expensive operations? Can resources be exhausted?
-- **Controls**: Rate limiting, resource quotas, circuit breakers, caching, input size limits
-
-### Elevation of Privilege
-- **Threat**: User gains more access than authorized
-- **Questions**: Is authorization checked on every operation? Can parameters be manipulated to access other resources? Are roles properly enforced?
-- **Controls**: Resource-level authorization, parameter validation, role enforcement, privilege separation
-
-## Attack Trees
-
-### Building an Attack Tree
-
-```
-Goal: Access User Data
-├── Path A: Steal Session Token
-│   ├── Phishing (requires social engineering)
-│   ├── XSS (requires input injection) ← Mitigated by output encoding
-│   └── Network interception (requires unencrypted traffic) ← Mitigated by HTTPS
-├── Path B: Direct Database Access
-│   ├── SQL Injection (requires unparameterized query) ← Mitigated by parameterized queries
-│   └── Direct connection (requires network access) ← Mitigated by network segmentation
-└── Path C: Abuse API
-    ├── IDOR (requires missing authorization) ← Mitigated by resource checks
-    └── Parameter tampering (requires missing validation) ← Mitigated by input validation
-```
-
-**Usage**: Focus on the unmitigated paths. If you find a path with no controls, that's your priority.
-
-### Risk Scoring
-
-For each identified threat, assess:
-
-- **Impact** (1-5): How bad would exploitation be?
-- **Likelihood** (1-5): How easy is it to exploit?
-- **Risk** = Impact × Likelihood
-
-| Score | Action |
-|-------|--------|
-| 20-25 | Must mitigate before release |
-| 12-16 | Should mitigate in next release cycle |
-| 6-10 | Track and mitigate when convenient |
-| 1-5 | Accept risk, document reasoning |
-
-## Trust Boundary Patterns
-
-### External → Internal
-- Every external request is hostile until authenticated and validated
-- Validation must happen before any processing
-- Never use external data to make internal decisions without verification
-
-### Internal → External
-- Assume external systems are compromised or malicious
-- Validate all responses from third parties
-- Don't expose internal state or identifiers
-
-### User → User
-- Users should never directly access each other's data
-- All cross-user access must go through authorization checks
-- Consider temporal access (can user A access user B's data at time T?)
-
-### Process → Process
-- Inter-service communication should be authenticated
-- Don't trust internal network traffic by default
-- Validate messages between components as if they came from outside
-
-## Threat Modeling Checklist
-
-For each feature or component:
-
-- [ ] All entry points identified
-- [ ] All trust boundaries mapped
-- [ ] STRIDE threats considered
-- [ ] Attack paths identified for high-value targets
-- [ ] Existing controls mapped
-- [ ] Gaps identified and prioritized
-- [ ] Risk scores assigned
-- [ ] Mitigations planned and scheduled
-- [ ] Assumptions documented (what are we trusting?)
-
-## Lightweight Threat Modeling
-
-When you don't have time for full analysis:
-
-1. **Write the user story**: "As an attacker, I want to..."
-2. **Identify one critical asset**: What would hurt most to lose?
-3. **Find the shortest path**: What's the easiest way to access it?
-4. **Add one control**: What's the simplest mitigation?
-5. **Repeat**: Do this for 3-5 attack stories
-
-This takes 15 minutes and catches the most obvious issues.

package/skills/oracle-testing/SKILL.md

@@ -1,237 +0,0 @@
----
-name: oracle-testing
-description: Stub-Driven TDD and layer boundary testing. Use when writing tests, deciding what to test, or testing at component boundaries.
-user-invocable: false
----
-
-# Testing Skill
-
-Stub-Driven Test-Driven Development and layer boundary testing for functional core and effectful edge architecture.
-
-## Core Principle: Stub-Driven TDD
-
-Test-Driven Development workflow for the functional core / effectful edge pattern:
-
-```
-1. Stub   → Create minimal interface/function signatures
-2. Test   → Write tests against stubs
-3. Implement → Make tests pass with real implementation
-4. Refactor  → Improve code while keeping tests green
-```
-
-**Key insight:** Write interface signatures first, test against those, then implement—not the other way around.
-
-See [references/stub-driven-tdd.md] for complete workflow examples.
-
-## Layer Boundary Testing
-
-Test at the boundaries between functional core and effectful edge, not internal implementation.
-
-```
-Test here ──────▼──────────────────▼────── Test here
-          Effectful Edge    │    Functional Core
-              (stub)        │       (unit test)
-```
-
-### Where to Test Each Layer
-
-| Layer | Test Type | What to Stub | What to Assert |
-|-------|-----------|--------------|-----------------|
-| **Entity** | Unit | Nothing (pure) | Validation, rules, transforms |
-| **Service** | Unit | Repositories | Orchestration logic, error handling |
-| **Router** | Integration | Service | Status codes, response format |
-| **Repository** | Integration | DB connection | CRUD operations, queries |
-| **Consumer** | Integration | Service | Event parsing, service calls |
-
-See [references/boundaries.md] for detailed testing patterns by layer.
-
-## Functional Core Testing
-
-### Entity Tests (Pure Functions)
-
-Focus: Validation, business rules, data transformations
-
-```typescript
-describe('Order entity', () => {
-  describe('validation', () => {
-    it('rejects empty items', () => {
-      const order = new Order('1', 'C1', [], 'pending', 0);
-      expect(order.validate().ok).toBe(false);
-    });
-  });
-
-  describe('business rules', () => {
-    it('prevents cancelling shipped order', () => {
-      const order = new Order('1', 'C1', [], 'shipped', 0);
-      expect(order.canCancel()).toBe(false);
-    });
-  });
-
-  describe('transformations', () => {
-    it('converts request to entity with calculated total', () => {
-      const order = Order.fromRequest({
-        customerId: 'C1',
-        items: [
-          { productId: 'P1', quantity: 2, price: 10 },
-          { productId: 'P2', quantity: 1, price: 15 }
-        ]
-      });
-      expect(order.total).toBe(35);
-    });
-  });
-});
-```
-
-### Service Tests (Stubbed Dependencies)
-
-Focus: Orchestration logic with stubbed repositories
-
-```typescript
-describe('OrderService.createOrder', () => {
-  let service: OrderService;
-  let mockRepo: OrderRepository;
-
-  beforeEach(() => {
-    mockRepo = {
-      save: vi.fn().mockResolvedValue({ id: '123' }),
-      findById: vi.fn()
-    };
-    service = new OrderService(mockRepo);
-  });
-
-  it('creates order with valid data', async () => {
-    const result = await service.createOrder({
-      customerId: 'C1',
-      items: [{ productId: 'P1', quantity: 2 }]
-    });
-
-    expect(result.ok).toBe(true);
-    expect(mockRepo.save).toHaveBeenCalled();
-  });
-
-  it('does not save when validation fails', async () => {
-    const result = await service.createOrder({
-      customerId: 'C1',
-      items: [] // Invalid
-    });
-
-    expect(result.ok).toBe(false);
-    expect(mockRepo.save).not.toHaveBeenCalled();
-  });
-});
-```
-
-See [references/core-testing.md] for comprehensive Entity and Service examples.
-
-## Effectful Edge Testing
-
-### Router, Repository, Consumer Integration Tests
-
-Focus: Real HTTP/database/events with stubbed core
-
-```typescript
-// Router: real HTTP, stub service
-describe('POST /orders', () => {
-  it('returns 201 for valid request', async () => {
-    const mockService = {
-      createOrder: vi.fn().mockResolvedValue(Ok({ id: '123' }))
-    };
-    const app = createApp(mockService);
-
-    const response = await request(app)
-      .post('/orders')
-      .send({ customerId: 'C1', items: [{ productId: 'P1', quantity: 2 }] });
-
-    expect(response.status).toBe(201);
-  });
-});
-
-// Repository: real test database
-describe('OrderRepository.save', () => {
-  it('persists order to database', async () => {
-    const repo = new OrderRepository(testDb);
-    const saved = await repo.save({
-      id: '123',
-      customer_id: 'C1',
-      items: '[]',
-      status: 'pending',
-      total: 0
-    });
-
-    const found = await testDb.orders.findOne({ id: '123' });
-    expect(found).toBeDefined();
-  });
-});
-
-// Consumer: real events, stub service
-describe('OrderConsumer', () => {
-  it('handles OrderPlaced event', async () => {
-    const mockService = {
-      processOrder: vi.fn().mockResolvedValue(Ok({}))
-    };
-    const consumer = new OrderConsumer(mockService);
-
-    await consumer.handle({
-      type: 'OrderPlaced',
-      data: { orderId: '123' }
-    });
-
-    expect(mockService.processOrder).toHaveBeenCalledWith('123');
-  });
-});
-```
-
-See [references/edge-testing.md] for Router, Repository, Consumer, Producer, and Client patterns.
-
-## Test Coverage Guidelines
-
-Aim for strategic coverage, not 100%:
-
-**High Coverage (Critical):**
-- Entity validation and business rules
-- Service orchestration logic
-- Critical user journeys (integration tests)
-- Data transformations with logic
-
-**Medium Coverage (Important):**
-- Error handling paths
-- Edge cases in business logic
-- API contract validation
-
-**Low Coverage (Optional):**
-- Simple getters/setters
-- Framework boilerplate
-- Trivial mappings
-- Internal utilities
-
-## What NOT to Test
-
-Avoid testing implementation details, framework behavior, and trivial code:
-
-- Don't test private methods (test through public API)
-- Don't test simple getters/setters (no logic = no test value)
-- Don't test framework behavior (Express, database driver already tested)
-- Don't test third-party library behavior (lodash, validation libraries)
-- Don't test trivial mappings without logic
-
-See [references/anti-patterns.md] for anti-patterns with examples and fixes.
-
-## Testing → Implementation Flow
-
-Follow this dependency order:
-
-```
-1. Entity tests    (pure functions, fast)
-2. Service tests   (stubbed dependencies, fast)
-3. Integration tests (real IO, slower)
-```
-
-This enables TDD: write tests first at lower layers, then implement, then build upward.
-
-## Quick Reference
-
-**For Entity Testing:** See [references/core-testing.md]
-**For Service Testing:** See [references/core-testing.md]
-**For Router/Repo/Consumer:** See [references/edge-testing.md]
-**For Workflow Examples:** See [references/stub-driven-tdd.md]
-**For What NOT to Do:** See [references/anti-patterns.md]