Extract Constraints

extract-constraints

Skill Type: Actuator (Requirements Disambiguation) Purpose: Extract C-* constraints acknowledging ecosystem E(t) Prerequisites: REQ-* requirement exists

---

Agent Instructions

You are extracting constraints (C-*) from the ecosystem E(t).

Constraints are GIVEN (external reality), not CHOSEN (design decisions).

Examples:

• ✅ C-001: Stripe API timeout is 10 seconds (given by Stripe)
• ❌ C-002: We will use PostgreSQL (this is a design choice → ADR)

Goal: Acknowledge ecosystem constraints that code must work within.

---

C-* Categories

1. API/​Service Constraints

Timeouts:

C-001: Stripe API timeout
  - Value: 10 seconds (given by Stripe documentation)
  - Source: https://stripe.com/​docs/​api#timeouts
  - Fallback: Return error to user
  - Monitoring: Alert if approaching timeout (>8s)

Rate limits:

C-010: Stripe API rate limit
  - Limit: 100 requests per second
  - Source: Stripe API documentation
  - Behavior: Implement exponential backoff
  - Error: "Payment service temporarily unavailable"

---

2. Compliance Constraints

PCI-DSS:

C-020: PCI-DSS Level 1 compliance
  - Requirement: Never store full credit card numbers
  - Implementation: Tokenize via Stripe
  - Validation: No card numbers in logs or database
  - Audit: Regular PCI scans required

GDPR:

C-030: GDPR data portability
  - Requirement: Users can export their data
  - Format: JSON or CSV
  - Timeline: Within 30 days of request
  - Scope: All personal data

---

3. Platform Constraints

Language/​runtime:

C-040: Python version
  - Minimum: Python 3.8
  - Reason: Using dataclasses, type hints
  - Source: Project decision (E(t) = team knows Python)
  - Validation: Check at startup

Dependencies:

C-050: bcrypt library
  - Library: bcrypt
  - Version: >=4.0.0
  - Reason: Password hashing (security requirement)
  - Source: Security team standard

---

4. Performance Constraints

Response time SLAs:

C-060: Login response time
  - Max time: 500ms (p95)
  - Measurement: End-to-end from request to response
  - Monitoring: Datadog APM
  - Alerting: >400ms warning, >500ms critical

Resource limits:

C-070: Database connection pool
  - Max connections: 20
  - Source: RDS instance limit
  - Behavior: Queue requests if pool exhausted
  - Timeout: 5 seconds wait for connection

---

5. Security Constraints

Authentication:

C-080: HTTPS requirement
  - Protocol: All auth requests must be HTTPS
  - Source: Security policy
  - Enforcement: Reject HTTP requests
  - Exception: None (no HTTP fallback)

Session management:

C-090: Session timeout
  - Duration: 30 minutes of inactivity
  - Source: Security team policy
  - Token: JWT with exp claim
  - Storage: Redis with TTL

---

Constraint vs Design Decision

Constraint (C-*) - GIVEN by ecosystem:

✅ C-001: Stripe API timeout is 10 seconds
   Source: Stripe documentation (external reality)
   We MUST work within this constraint

✅ C-002: PCI-DSS prohibits storing card numbers
   Source: Payment Card Industry regulation
   We MUST comply

✅ C-003: Team knows Python, not Java
   Source: Team capabilities (E(t))
   We work within this reality

Design Decision - CHOSEN by us:

❌ "We will use PostgreSQL" → This is ADR, not C-*
❌ "We will implement REST API" → This is ADR, not C-*
❌ "We will use MVC pattern" → This is ADR, not C-*

Rule: If it's a choice between alternatives → ADR (Design stage) If it's a given reality we must work within → C-* (Constraint)

---

Extraction Process

Step 1: Identify Ecosystem Sources

Ask:

1. What external APIs/​services are we using? (Stripe, Auth0, AWS)
2. What compliance requirements apply? (PCI-DSS, GDPR, HIPAA)
3. What platform constraints exist? (language version, libraries)
4. What performance SLAs? (response time, uptime)
5. What security policies? (HTTPS, encryption, session timeout)
6. What team constraints? (skills, preferences, existing systems)

---

Step 2: Document Each Constraint

Template:

C-{ID}: {Constraint Name}
  - Value/​Requirement: {What is constrained}
  - Source: {Where this constraint comes from - API docs, regulation, policy}
  - Ecosystem E(t): {What ecosystem component imposes this}
  - Implementation: {How code must handle this}
  - Validation: {How to verify compliance}
  - Autogenerate: {Yes/​No}

---

Output Format

[EXTRACT CONSTRAINTS - <REQ-ID>]

Requirement: User login

Constraints Extracted:

API/​Service Constraints (2):
  ✓ C-001: Database query timeout (100ms, RDS limit)
  ✓ C-002: Session storage (Redis, existing infrastructure)

Compliance Constraints (2):
  ✓ C-003: HTTPS required (security policy)
  ✓ C-004: Password hashing (bcrypt, security standard)

Performance Constraints (1):
  ✓ C-005: Login response time (<500ms, SLA requirement)

Total: 5 constraints

Ecosystem E(t) Acknowledged:
  - External: RDS connection limits, Redis infrastructure
  - Compliance: Security policies (HTTPS, bcrypt)
  - Performance: SLA requirements

Updated: docs/​requirements/​authentication.md
  Added: Constraints section with 5 C-*

✅ Constraint Extraction Complete!

---

Notes

Why extract constraints?

• Acknowledge ecosystem E(t): Document external realities
• Design context: Constraints inform ADRs (architecture decisions)
• Code generation: Some constraints can be autogenerated (timeout checks)
• Compliance: Document regulatory requirements

Homeostasis Goal:

desired_state:
  all_ecosystem_constraints_documented: true
  constraints_vs_choices_clear: true

"Excellence or nothing" 🔥