Files

Phil Skentelbery bebd47955f feat(core): implement Phase 1 foundation infrastructure

Implements Phase 1 Foundation with all core services:

Core Components:
- Configuration management with GONDULF_ environment variables
- Database layer with SQLAlchemy and migration system
- In-memory code storage with TTL support
- Email service with SMTP and TLS support (STARTTLS + implicit TLS)
- DNS service with TXT record verification
- Structured logging with Python standard logging
- FastAPI application with health check endpoint

Database Schema:
- authorization_codes table for OAuth 2.0 authorization codes
- domains table for domain verification
- migrations table for tracking schema versions
- Simple sequential migration system (001_initial_schema.sql)

Configuration:
- Environment-based configuration with validation
- .env.example template with all GONDULF_ variables
- Fail-fast validation on startup
- Sensible defaults for optional settings

Testing:
- 96 comprehensive tests (77 unit, 5 integration)
- 94.16% code coverage (exceeds 80% requirement)
- All tests passing
- Test coverage includes:
  - Configuration loading and validation
  - Database migrations and health checks
  - In-memory storage with expiration
  - Email service (STARTTLS, implicit TLS, authentication)
  - DNS service (TXT records, domain verification)
  - Health check endpoint integration

Documentation:
- Implementation report with test results
- Phase 1 clarifications document
- ADRs for key decisions (config, database, email, logging)

Technical Details:
- Python 3.10+ with type hints
- SQLite with configurable database URL
- System DNS with public DNS fallback
- Port-based TLS detection (465=SSL, 587=STARTTLS)
- Lazy configuration loading for testability

Exit Criteria Met:
✓ All foundation services implemented
✓ Application starts without errors
✓ Health check endpoint operational
✓ Database migrations working
✓ Test coverage exceeds 80%
✓ All tests passing

Ready for Architect review and Phase 2 development.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

2025-11-20 12:21:42 -07:00

1.5 KiB

Raw Blame History

0007. Logging Strategy for v1.0.0

Date: 2024-11-20

Status

Accepted

Context

We need structured logging for debugging, security auditing, and operational monitoring. The choice is between JSON-structured logs (machine-parseable), Python's standard logging with structured fields, or simple string logging.

Decision

Use Python's standard logging module with structured string formatting for v1.0.0:

Format pattern:

%(asctime)s [%(levelname)s] %(name)s: %(message)s

Structured information in message strings:

logger.info("Domain verification requested", extra={
    "domain": domain,
    "email": email,
    "request_id": request_id
})

Log levels:

Development: DEBUG (default when GONDULF_DEBUG=true)
Production: INFO (default)

Configuration:

GONDULF_LOG_LEVEL=INFO
GONDULF_DEBUG=false

Output: stdout/stderr (let deployment environment handle log collection)

Consequences

Positive

Standard Python logging - no additional dependencies
Simple to implement and test
Human-readable for local development
Structured extras can be extracted if needed later
Easy to redirect to files or syslog via deployment config

Negative

Not as machine-parseable as pure JSON logs
May need to migrate to structured JSON logging in future versions
Extra fields may not be captured by all log handlers

Future Consideration

If operational monitoring requires it, we can migrate to JSON-structured logging in a minor version update without breaking changes.

1.5 KiB Raw Blame History