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)

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

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

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

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

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

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

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

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

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

✅ 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

❌ "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-*

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}

[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!

desired_state:
  all_ecosystem_constraints_documented: true
  constraints_vs_choices_clear: true