diff --git a/CLAUDE.md b/CLAUDE.md
index 51c3535..809f083 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -53,9 +53,12 @@ The `docs/` folder is organized by document type and purpose:
- **`docs/deployment/`** - Deployment guides, infrastructure setup, operations documentation
- **`docs/design/`** - Detailed design documents, feature specifications, phase plans
- **`docs/examples/`** - Example implementations, code samples, usage patterns
+- **`docs/migration/`** - Migration guides for upgrading between versions and configuration changes
- **`docs/projectplan/`** - Project roadmaps, implementation plans, feature scope definitions
+- **`docs/releases/`** - Release-specific documentation, release notes, version information
- **`docs/reports/`** - Implementation reports from developers (dated: YYYY-MM-DD-description.md)
- **`docs/reviews/`** - Architectural reviews, design critiques, retrospectives
+- **`docs/security/`** - Security-related documentation, vulnerability analyses, best practices
- **`docs/standards/`** - Coding standards, conventions, processes, workflows
### Where to Find Documentation
diff --git a/README.md b/README.md
index 34c39ef..6ff8b78 100644
--- a/README.md
+++ b/README.md
@@ -2,16 +2,13 @@
A minimal, self-hosted IndieWeb CMS for publishing notes with RSS syndication.
-**Current Version**: 1.0.0
+**Current Version**: 1.1.0
## Versioning
StarPunk follows [Semantic Versioning 2.0.0](https://semver.org/):
- Version format: `MAJOR.MINOR.PATCH`
-- Current: `1.0.0` (stable release)
-
-**Version Information**:
-- Current: `1.0.0` (stable release)
+- Current: `1.1.0` (stable release)
- Check version: `python -c "from starpunk import __version__; print(__version__)"`
- See changes: [CHANGELOG.md](CHANGELOG.md)
- Versioning strategy: [docs/standards/versioning-strategy.md](docs/standards/versioning-strategy.md)
diff --git a/docs/architecture/INDEX.md b/docs/architecture/INDEX.md
new file mode 100644
index 0000000..7049f41
--- /dev/null
+++ b/docs/architecture/INDEX.md
@@ -0,0 +1,82 @@
+# Architecture Documentation Index
+
+This directory contains architectural documentation, system design overviews, component diagrams, and architectural patterns for StarPunk CMS.
+
+## Core Architecture
+
+### System Overview
+- **[overview.md](overview.md)** - Complete system architecture and design principles
+- **[technology-stack.md](technology-stack.md)** - Current technology stack and dependencies
+- **[technology-stack-legacy.md](technology-stack-legacy.md)** - Historical technology decisions
+
+### Feature-Specific Architecture
+
+#### IndieAuth & Authentication
+- **[indieauth-assessment.md](indieauth-assessment.md)** - Assessment of IndieAuth implementation
+- **[indieauth-client-diagnosis.md](indieauth-client-diagnosis.md)** - IndieAuth client diagnostic analysis
+- **[indieauth-endpoint-discovery.md](indieauth-endpoint-discovery.md)** - Endpoint discovery architecture
+- **[indieauth-identity-page.md](indieauth-identity-page.md)** - Identity page architecture
+- **[indieauth-questions-answered.md](indieauth-questions-answered.md)** - Architectural Q&A for IndieAuth
+- **[indieauth-removal-architectural-review.md](indieauth-removal-architectural-review.md)** - Review of custom IndieAuth removal
+- **[indieauth-removal-implementation-guide.md](indieauth-removal-implementation-guide.md)** - Implementation guide for removal
+- **[indieauth-removal-phases.md](indieauth-removal-phases.md)** - Phased removal approach
+- **[indieauth-removal-plan.md](indieauth-removal-plan.md)** - Overall removal plan
+- **[indieauth-token-verification-diagnosis.md](indieauth-token-verification-diagnosis.md)** - Token verification diagnostic analysis
+- **[simplified-auth-architecture.md](simplified-auth-architecture.md)** - Simplified authentication architecture
+- **[endpoint-discovery-answers.md](endpoint-discovery-answers.md)** - Endpoint discovery implementation Q&A
+
+#### Database & Migrations
+- **[database-migration-architecture.md](database-migration-architecture.md)** - Database migration system architecture
+- **[migration-fix-quick-reference.md](migration-fix-quick-reference.md)** - Quick reference for migration fixes
+- **[migration-race-condition-answers.md](migration-race-condition-answers.md)** - Race condition resolution Q&A
+
+#### Syndication
+- **[syndication-architecture.md](syndication-architecture.md)** - RSS feed and syndication architecture
+
+## Version-Specific Architecture
+
+### v1.0.0
+- **[v1.0.0-release-validation.md](v1.0.0-release-validation.md)** - Release validation architecture
+
+### v1.1.0
+- **[v1.1.0-feature-architecture.md](v1.1.0-feature-architecture.md)** - Feature architecture for v1.1.0
+- **[v1.1.0-implementation-decisions.md](v1.1.0-implementation-decisions.md)** - Implementation decisions
+- **[v1.1.0-search-ui-validation.md](v1.1.0-search-ui-validation.md)** - Search UI validation
+- **[v1.1.0-validation-report.md](v1.1.0-validation-report.md)** - Overall validation report
+
+### v1.1.1
+- **[v1.1.1-architecture-overview.md](v1.1.1-architecture-overview.md)** - Architecture overview for v1.1.1
+
+## Phase Documentation
+- **[phase1-completion-guide.md](phase1-completion-guide.md)** - Phase 1 completion guide
+- **[phase-5-validation-report.md](phase-5-validation-report.md)** - Phase 5 validation report
+
+## Review Documentation
+- **[review-v1.0.0-rc.5.md](review-v1.0.0-rc.5.md)** - Architectural review of v1.0.0-rc.5
+
+## How to Use This Documentation
+
+### For New Developers
+1. Start with **overview.md** to understand the system
+2. Review **technology-stack.md** for current technologies
+3. Read feature-specific architecture docs relevant to your work
+
+### For Architects
+1. Review version-specific architecture for historical context
+2. Consult feature-specific docs when making changes
+3. Update relevant docs when architecture changes
+
+### For Contributors
+1. Read **overview.md** for system understanding
+2. Consult specific architecture docs for areas you're working on
+3. Follow patterns documented in architecture files
+
+## Related Documentation
+- **[../decisions/](../decisions/)** - Architectural Decision Records (ADRs)
+- **[../design/](../design/)** - Detailed design documents
+- **[../standards/](../standards/)** - Coding standards and conventions
+
+---
+
+**Last Updated**: 2025-11-25
+**Maintained By**: Documentation Manager Agent
diff --git a/docs/architecture/syndication-architecture.md b/docs/architecture/syndication-architecture.md
new file mode 100644
index 0000000..cb61ca4
--- /dev/null
+++ b/docs/architecture/syndication-architecture.md
@@ -0,0 +1,233 @@
+# Syndication Architecture
+
+## Overview
+StarPunk's syndication architecture provides multiple feed formats for content distribution, ensuring broad compatibility with feed readers and IndieWeb tools while maintaining simplicity.
+
+## Current State (v1.1.0)
+```
+┌─────────────┐
+│ Database │
+│ (Notes) │
+└──────┬──────┘
+ │
+┌──────▼──────┐
+│ feed.py │
+│ (RSS 2.0) │
+└──────┬──────┘
+ │
+┌──────▼──────┐
+│ /feed.xml │
+│ endpoint │
+└─────────────┘
+```
+
+## Target Architecture (v1.1.2+)
+```
+┌─────────────┐
+│ Database │
+│ (Notes) │
+└──────┬──────┘
+ │
+┌──────▼──────────────────┐
+│ Feed Generation Layer │
+├──────────┬───────────────┤
+│ feed.py │ json_feed.py │
+│ RSS/ATOM│ JSON │
+└──────────┴───────────────┘
+ │
+┌──────▼──────────────────┐
+│ Feed Endpoints │
+├─────────┬───────────────┤
+│/feed.xml│ /feed.atom │
+│ (RSS) │ (ATOM) │
+├─────────┼───────────────┤
+│ /feed.json │
+│ (JSON Feed) │
+└─────────────────────────┘
+```
+
+## Design Principles
+
+### 1. Format Independence
+Each syndication format operates independently:
+- No shared state between formats
+- Failures in one don't affect others
+- Can be enabled/disabled individually
+
+### 2. Shared Data Access
+All formats read from the same data source:
+- Single query pattern for notes
+- Consistent ordering (newest first)
+- Same publication status filtering
+
+### 3. Library Leverage
+Maximize use of existing libraries:
+- `feedgen` for RSS and ATOM
+- Native Python `json` for JSON Feed
+- No custom XML generation
+
+## Component Design
+
+### Feed Generation Module (`feed.py`)
+**Current Responsibility**: RSS 2.0 generation
+**Future Enhancement**: Add ATOM generation function
+
+```python
+# Pseudocode structure
+def generate_rss_feed(notes, config) -> str
+def generate_atom_feed(notes, config) -> str # New
+```
+
+### JSON Feed Module (`json_feed.py`)
+**New Component**: Dedicated JSON Feed generation
+
+```python
+# Pseudocode structure
+def generate_json_feed(notes, config) -> str
+def format_json_item(note) -> dict
+```
+
+### Route Handlers
+Simple pass-through to generation functions:
+```python
+@app.route('/feed.xml') # Existing
+@app.route('/feed.atom') # New
+@app.route('/feed.json') # New
+```
+
+## Data Flow
+
+1. **Request**: Client requests feed at endpoint
+2. **Query**: Fetch published notes from database
+3. **Transform**: Convert notes to format-specific structure
+4. **Serialize**: Generate final output (XML/JSON)
+5. **Response**: Return with appropriate Content-Type
+
+## Microformats2 Architecture
+
+### Template Layer Enhancement
+Microformats2 operates at the HTML template layer:
+
+```
+┌──────────────┐
+│ Data Model │
+│ (Notes) │
+└──────┬───────┘
+ │
+┌──────▼───────┐
+│ Templates │
+│ + mf2 markup│
+└──────┬───────┘
+ │
+┌──────▼───────┐
+│ HTML Output │
+│ (Semantic) │
+└──────────────┘
+```
+
+### Markup Strategy
+- **Progressive Enhancement**: Add classes without changing structure
+- **CSS Independence**: Use mf2-specific classes, not styling classes
+- **Validation First**: Test with parsers during development
+
+## Configuration Requirements
+
+### New Configuration Variables
+```ini
+# Author information for h-card
+AUTHOR_NAME = "Site Author"
+AUTHOR_URL = "https://example.com"
+AUTHOR_PHOTO = "/static/avatar.jpg" # Optional
+
+# Feed settings
+FEED_LIMIT = 50
+FEED_FORMATS = "rss,atom,json" # Comma-separated
+```
+
+## Performance Considerations
+
+### Caching Strategy
+- Feed generation is read-heavy, write-light
+- Consider caching generated feeds (5-minute TTL)
+- Invalidate cache on note creation/update
+
+### Resource Usage
+- RSS/ATOM: ~O(n) memory for n notes
+- JSON Feed: Similar memory profile
+- Microformats2: No additional server resources
+
+## Security Considerations
+
+### Content Sanitization
+- HTML in feeds must be properly escaped
+- CDATA wrapping for RSS/ATOM
+- JSON string encoding for JSON Feed
+- No script injection vectors
+
+### Rate Limiting
+- Apply same limits as HTML endpoints
+- Consider aggressive caching for feeds
+- Monitor for feed polling abuse
+
+## Testing Architecture
+
+### Unit Tests
+```
+tests/
+├── test_feed.py # Enhanced for ATOM
+├── test_json_feed.py # New test module
+└── test_microformats.py # Template parsing tests
+```
+
+### Integration Tests
+- Validate against external validators
+- Test feed reader compatibility
+- Verify IndieWeb tool parsing
+
+## Backwards Compatibility
+
+### URL Structure
+- `/feed.xml` remains RSS 2.0 (no breaking change)
+- New endpoints are additive only
+- Auto-discovery links updated in templates
+
+### Database
+- No schema changes required
+- All features use existing Note model
+- No migration needed
+
+## Future Extensibility
+
+### Potential Enhancements
+1. Content negotiation on `/feed`
+2. WebSub (PubSubHubbub) support
+3. Custom feed filtering (by tag, date)
+4. Feed pagination for large sites
+
+### Format Support Matrix
+| Format | v1.1.0 | v1.1.2 | v1.2.0 |
+|--------|--------|--------|--------|
+| RSS 2.0 | ✅ | ✅ | ✅ |
+| ATOM | ❌ | ✅ | ✅ |
+| JSON Feed | ❌ | ✅ | ✅ |
+| Microformats2 | Partial | Partial | ✅ |
+
+## Decision Rationale
+
+### Why Multiple Formats?
+1. **No Universal Standard**: Different ecosystems prefer different formats
+2. **Low Maintenance**: Feed formats are stable, rarely change
+3. **User Choice**: Let users pick their preferred format
+4. **IndieWeb Philosophy**: Embrace plurality and interoperability
+
+### Why This Architecture?
+1. **Simplicity**: Each component has single responsibility
+2. **Testability**: Isolated components are easier to test
+3. **Maintainability**: Changes to one format don't affect others
+4. **Performance**: Can optimize each format independently
+
+## References
+- [RSS 2.0 Specification](https://www.rssboard.org/rss-specification)
+- [ATOM RFC 4287](https://tools.ietf.org/html/rfc4287)
+- [JSON Feed Specification](https://www.jsonfeed.org/)
+- [Microformats2](https://microformats.org/wiki/microformats2)
\ No newline at end of file
diff --git a/docs/architecture/v1.1.1-architecture-overview.md b/docs/architecture/v1.1.1-architecture-overview.md
new file mode 100644
index 0000000..03befda
--- /dev/null
+++ b/docs/architecture/v1.1.1-architecture-overview.md
@@ -0,0 +1,379 @@
+# v1.1.1 "Polish" Architecture Overview
+
+## Executive Summary
+
+StarPunk v1.1.1 introduces production-focused improvements without changing the core architecture. The release adds configurability, observability, and robustness while maintaining full backward compatibility.
+
+## Architectural Principles
+
+### Core Principles (Unchanged)
+1. **Simplicity First**: Every feature must justify its complexity
+2. **Standards Compliance**: Full IndieWeb specification adherence
+3. **No External Dependencies**: Use Python stdlib where possible
+4. **Progressive Enhancement**: Core functionality without JavaScript
+5. **Data Portability**: User data remains exportable
+
+### v1.1.1 Additions
+6. **Observable by Default**: Production visibility built-in
+7. **Graceful Degradation**: Features degrade rather than fail
+8. **Configuration over Code**: Behavior adjustable without changes
+9. **Zero Breaking Changes**: Perfect backward compatibility
+
+## System Architecture
+
+### High-Level Component View
+
+```
+┌─────────────────────────────────────────────────────────┐
+│ StarPunk v1.1.1 │
+├─────────────────────────────────────────────────────────┤
+│ Configuration Layer │
+│ (Environment Variables) │
+├─────────────────────────────────────────────────────────┤
+│ Application Layer │
+│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐│
+│ │ Auth │ │ Micropub │ │ Search │ │ Web ││
+│ └──────────┘ └──────────┘ └──────────┘ └──────────┘│
+├─────────────────────────────────────────────────────────┤
+│ Monitoring & Logging Layer │
+│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
+│ │ Performance │ │ Structured │ │ Error │ │
+│ │ Monitoring │ │ Logging │ │ Handling │ │
+│ └──────────────┘ └──────────────┘ └──────────────┘ │
+├─────────────────────────────────────────────────────────┤
+│ Data Access Layer │
+│ ┌──────────────────────┐ ┌──────────────────────┐ │
+│ │ Connection Pool │ │ Search Engine │ │
+│ │ ┌────┐...┌────┐ │ │ ┌──────┐┌────────┐ │ │
+│ │ │Conn│ │Conn│ │ │ │ FTS5 ││Fallback│ │ │
+│ │ └────┘ └────┘ │ │ └──────┘└────────┘ │ │
+│ └──────────────────────┘ └──────────────────────┘ │
+├─────────────────────────────────────────────────────────┤
+│ SQLite Database │
+│ (WAL mode, FTS5) │
+└─────────────────────────────────────────────────────────┘
+```
+
+### Request Flow
+
+```
+HTTP Request
+ ↓
+[Logging Middleware: Start Request ID]
+ ↓
+[Performance Middleware: Start Timer]
+ ↓
+[Session Middleware: Validate/Extend]
+ ↓
+[Error Handling Wrapper]
+ ↓
+Route Handler
+ ├→ [Database: Connection Pool]
+ ├→ [Search: FTS5 or Fallback]
+ ├→ [Monitoring: Record Metrics]
+ └→ [Logging: Structured Output]
+ ↓
+Response Generation
+ ↓
+[Performance Middleware: Stop Timer, Record]
+ ↓
+[Logging Middleware: Log Request]
+ ↓
+HTTP Response
+```
+
+## New Components
+
+### 1. Configuration System
+
+**Location**: `starpunk/config.py`
+
+**Responsibilities**:
+- Load environment variables
+- Provide type-safe access
+- Define defaults
+- Validate configuration
+
+**Design Pattern**: Singleton with lazy loading
+
+```python
+Configuration
+├── get_bool(key, default)
+├── get_int(key, default)
+├── get_float(key, default)
+└── get_str(key, default)
+```
+
+### 2. Performance Monitoring
+
+**Location**: `starpunk/monitoring/`
+
+**Components**:
+- `collector.py`: Metrics collection and storage
+- `db_monitor.py`: Database performance tracking
+- `memory.py`: Memory usage monitoring
+- `http.py`: HTTP request tracking
+
+**Design Pattern**: Observer with circular buffer
+
+```python
+MetricsCollector
+├── CircularBuffer (1000 metrics)
+├── SlowQueryLog (100 queries)
+├── MemoryTracker (background thread)
+└── Dashboard (read-only view)
+```
+
+### 3. Structured Logging
+
+**Location**: `starpunk/logging.py`
+
+**Features**:
+- JSON formatting in production
+- Human-readable in development
+- Request correlation IDs
+- Log levels (DEBUG, INFO, WARNING, ERROR, CRITICAL)
+
+**Design Pattern**: Decorator with context injection
+
+### 4. Error Handling
+
+**Location**: `starpunk/errors.py`
+
+**Hierarchy**:
+```
+StarPunkError (Base)
+├── ValidationError (400)
+├── AuthenticationError (401)
+├── NotFoundError (404)
+├── DatabaseError (500)
+├── ConfigurationError (500)
+└── TransientError (503)
+```
+
+**Design Pattern**: Exception hierarchy with middleware
+
+### 5. Connection Pool
+
+**Location**: `starpunk/database/pool.py`
+
+**Features**:
+- Thread-safe pool management
+- Configurable pool size
+- Connection health checks
+- Usage statistics
+
+**Design Pattern**: Object pool with semaphore
+
+## Data Flow Improvements
+
+### Search Data Flow
+
+```
+Search Request
+ ↓
+Check Config: SEARCH_ENABLED?
+ ├─No→ Return "Search Disabled"
+ └─Yes↓
+ Check FTS5 Available?
+ ├─Yes→ FTS5 Search Engine
+ │ ├→ Execute FTS5 Query
+ │ ├→ Calculate Relevance
+ │ └→ Highlight Terms
+ └─No→ Fallback Search Engine
+ ├→ Execute LIKE Query
+ ├→ No Relevance Score
+ └→ Basic Highlighting
+```
+
+### Error Flow
+
+```
+Exception Occurs
+ ↓
+Catch in Middleware
+ ↓
+Categorize Error
+ ├→ User Error: Log INFO, Return Helpful Message
+ ├→ System Error: Log ERROR, Return Generic Message
+ ├→ Transient Error: Retry with Backoff
+ └→ Config Error: Fail Fast at Startup
+```
+
+## Database Schema Changes
+
+### Sessions Table Enhancement
+```sql
+CREATE TABLE sessions (
+ id TEXT PRIMARY KEY,
+ user_id TEXT NOT NULL,
+ created_at TIMESTAMP NOT NULL,
+ expires_at TIMESTAMP NOT NULL,
+ last_activity TIMESTAMP,
+ remember BOOLEAN DEFAULT FALSE,
+ INDEX idx_sessions_expires (expires_at),
+ INDEX idx_sessions_user (user_id)
+);
+```
+
+## Performance Characteristics
+
+### Metrics
+| Operation | v1.1.0 | v1.1.1 Target | v1.1.1 Actual |
+|-----------|---------|---------------|---------------|
+| Request Latency | ~50ms | <50ms | TBD |
+| Search Response | ~100ms | <100ms (FTS5) <500ms (fallback) | TBD |
+| RSS Generation | ~200ms | <100ms | TBD |
+| Memory per Request | ~2MB | <1MB | TBD |
+| Monitoring Overhead | N/A | <1% | TBD |
+
+### Scalability
+- Connection pool: Handles 20+ concurrent requests
+- Metrics buffer: Fixed 1MB memory overhead
+- RSS streaming: O(1) memory complexity
+- Session cleanup: Automatic background process
+
+## Security Enhancements
+
+### Input Validation
+- Unicode normalization in slugs
+- XSS prevention in search highlighting
+- SQL injection prevention via parameterization
+
+### Session Security
+- Configurable timeout
+- HTTP-only cookies
+- Secure flag in production
+- CSRF protection maintained
+
+### Error Information
+- Sensitive data never in errors
+- Stack traces only in debug mode
+- Rate limiting on error endpoints
+
+## Deployment Architecture
+
+### Environment Variables
+```
+Production Server
+├── STARPUNK_* Configuration
+├── Process Manager (systemd/supervisor)
+├── Reverse Proxy (nginx/caddy)
+└── SQLite Database File
+```
+
+### Health Monitoring
+```
+Load Balancer
+├→ /health (liveness)
+└→ /health/ready (readiness)
+```
+
+## Testing Architecture
+
+### Test Isolation
+```
+Test Suite
+├── Isolated Database per Test
+├── Mocked Time/Random
+├── Controlled Configuration
+└── Deterministic Execution
+```
+
+### Performance Testing
+```
+Benchmarks
+├── Baseline Measurements
+├── With Monitoring Enabled
+├── Memory Profiling
+└── Load Testing
+```
+
+## Migration Path
+
+### From v1.1.0 to v1.1.1
+1. Install new version
+2. Run migrations (automatic)
+3. Configure as needed (optional)
+4. Restart service
+
+### Rollback Plan
+1. Restore previous version
+2. No database changes to revert
+3. Remove new config vars (optional)
+
+## Observability
+
+### Metrics Available
+- Request count and latency
+- Database query performance
+- Memory usage over time
+- Error rates by type
+- Session statistics
+
+### Logging Output
+```json
+{
+ "timestamp": "2025-11-25T10:00:00Z",
+ "level": "INFO",
+ "logger": "starpunk.micropub",
+ "message": "Note created",
+ "request_id": "abc123",
+ "user": "alice@example.com",
+ "duration_ms": 45
+}
+```
+
+## Future Considerations
+
+### Extensibility Points
+1. **Monitoring Plugins**: Hook for external monitoring
+2. **Search Providers**: Interface for alternative search
+3. **Cache Layer**: Ready for Redis/Memcached
+4. **Queue System**: Prepared for async operations
+
+### Technical Debt Addressed
+1. ✅ Test race conditions fixed
+2. ✅ Unicode handling improved
+3. ✅ Memory usage optimized
+4. ✅ Error handling standardized
+5. ✅ Configuration centralized
+
+## Design Decisions Summary
+
+| Decision | Rationale | Alternative Considered |
+|----------|-----------|----------------------|
+| Environment variables for config | 12-factor app, container-friendly | Config files |
+| Built-in monitoring | Zero dependencies, privacy | External APM |
+| Connection pooling | Reduce latency, handle concurrency | Single connection |
+| Structured logging | Production parsing, debugging | Plain text logs |
+| Graceful degradation | Reliability, user experience | Fail fast |
+
+## Risks and Mitigations
+
+| Risk | Impact | Mitigation |
+|------|--------|------------|
+| FTS5 not available | Slow search | Automatic fallback to LIKE |
+| Memory leak in monitoring | OOM | Circular buffer with fixed size |
+| Configuration complexity | User confusion | Sensible defaults, clear docs |
+| Performance regression | Slow responses | Comprehensive benchmarking |
+
+## Success Metrics
+
+1. **Reliability**: 99.9% uptime capability
+2. **Performance**: <1% overhead from monitoring
+3. **Usability**: Zero configuration required to upgrade
+4. **Observability**: Full visibility into production
+5. **Compatibility**: 100% backward compatible
+
+## Documentation References
+
+- [Configuration System](/home/phil/Projects/starpunk/docs/decisions/ADR-052-configuration-system-architecture.md)
+- [Performance Monitoring](/home/phil/Projects/starpunk/docs/decisions/ADR-053-performance-monitoring-strategy.md)
+- [Structured Logging](/home/phil/Projects/starpunk/docs/decisions/ADR-054-structured-logging-architecture.md)
+- [Error Handling](/home/phil/Projects/starpunk/docs/decisions/ADR-055-error-handling-philosophy.md)
+- [Implementation Guide](/home/phil/Projects/starpunk/docs/design/v1.1.1/implementation-guide.md)
+
+---
+
+This architecture maintains StarPunk's commitment to simplicity while adding production-grade capabilities. Every addition has been carefully considered to ensure it provides value without unnecessary complexity.
\ No newline at end of file
diff --git a/docs/decisions/ADR-022-migration-race-condition-fix.md b/docs/decisions/ADR-037-migration-race-condition-fix.md
similarity index 100%
rename from docs/decisions/ADR-022-migration-race-condition-fix.md
rename to docs/decisions/ADR-037-migration-race-condition-fix.md
diff --git a/docs/decisions/ADR-038-syndication-formats.md b/docs/decisions/ADR-038-syndication-formats.md
new file mode 100644
index 0000000..6809340
--- /dev/null
+++ b/docs/decisions/ADR-038-syndication-formats.md
@@ -0,0 +1,50 @@
+# ADR-022: Multiple Syndication Format Support
+
+## Status
+Proposed
+
+## Context
+StarPunk currently provides RSS 2.0 feed generation using the feedgen library. The IndieWeb community and modern feed readers increasingly support additional syndication formats:
+- ATOM feeds (RFC 4287) - W3C/IETF standard XML format
+- JSON Feed (v1.1) - Modern JSON-based format gaining adoption
+- Microformats2 - Already partially implemented for IndieWeb parsing
+
+Multiple syndication formats increase content reach and client compatibility.
+
+## Decision
+Implement ATOM and JSON Feed support alongside existing RSS 2.0, maintaining all three formats in parallel.
+
+## Rationale
+1. **Low Implementation Complexity**: The feedgen library already supports ATOM generation with minimal code changes
+2. **JSON Feed Simplicity**: JSON structure maps directly to our Note model, easier than XML
+3. **Standards Alignment**: Both formats are well-specified and stable
+4. **User Choice**: Different clients prefer different formats
+5. **Minimal Maintenance**: Once implemented, feed formats rarely change
+
+## Consequences
+### Positive
+- Broader client compatibility
+- Better IndieWeb ecosystem integration
+- Leverages existing feedgen dependency for ATOM
+- JSON Feed provides modern alternative to XML
+
+### Negative
+- Three feed endpoints to maintain
+- Slightly increased test surface
+- Additional routes in API
+
+## Alternatives Considered
+1. **Single Universal Format**: Rejected - different clients have different preferences
+2. **Content Negotiation**: Too complex for minimal benefit
+3. **Plugin System**: Over-engineering for 3 stable formats
+
+## Implementation Approach
+1. ATOM: Use feedgen's built-in ATOM support (5-10 lines different from RSS)
+2. JSON Feed: Direct serialization from Note models (~50 lines)
+3. Routes: `/feed.xml` (RSS), `/feed.atom` (ATOM), `/feed.json` (JSON)
+
+## Effort Estimate
+- ATOM Feed: 2-4 hours (mostly testing)
+- JSON Feed: 4-6 hours (new serialization logic)
+- Tests & Documentation: 2-3 hours
+- Total: 8-13 hours
\ No newline at end of file
diff --git a/docs/decisions/ADR-040-microformats2-compliance.md b/docs/decisions/ADR-040-microformats2-compliance.md
new file mode 100644
index 0000000..1664c9a
--- /dev/null
+++ b/docs/decisions/ADR-040-microformats2-compliance.md
@@ -0,0 +1,72 @@
+# ADR-023: Strict Microformats2 Compliance
+
+## Status
+Proposed
+
+## Context
+StarPunk currently implements basic microformats2 markup:
+- h-entry on note articles
+- e-content for note content
+- dt-published for timestamps
+- u-url for permalinks
+
+"Strict" microformats2 compliance would add comprehensive markup for full IndieWeb interoperability, enabling better parsing by readers, Webmention receivers, and IndieWeb tools.
+
+## Decision
+Enhance existing templates with complete microformats2 vocabulary, focusing on h-entry, h-card, and h-feed structures.
+
+## Rationale
+1. **Core IndieWeb Requirement**: Microformats2 is fundamental to IndieWeb data exchange
+2. **Template-Only Changes**: No backend modifications required
+3. **Progressive Enhancement**: Adds semantic value without breaking existing functionality
+4. **Standards Maturity**: Microformats2 spec is stable and well-documented
+5. **Testing Tools Available**: Validators exist for compliance verification
+
+## Consequences
+### Positive
+- Full IndieWeb parser compatibility
+- Better social reader integration
+- Improved SEO through semantic markup
+- Enables future Webmention support (v1.3.0)
+
+### Negative
+- More complex HTML templates
+- Careful CSS selector management needed
+- Testing requires microformats2 parser
+
+## Alternatives Considered
+1. **Minimal Compliance**: Current state - rejected as incomplete for IndieWeb tools
+2. **Microdata/RDFa**: Not IndieWeb standard, adds complexity
+3. **JSON-LD**: Additional complexity, not IndieWeb native
+
+## Implementation Scope
+### Required Markup
+1. **h-entry** (complete):
+ - p-name (title extraction)
+ - p-summary (excerpt)
+ - p-category (when tags added)
+ - p-author with embedded h-card
+
+2. **h-card** (author):
+ - p-name (author name)
+ - u-url (author URL)
+ - u-photo (avatar, optional)
+
+3. **h-feed** (index pages):
+ - p-name (feed title)
+ - p-author (feed author)
+ - Nested h-entry items
+
+### Template Updates Required
+- `/templates/base.html` - Add h-card in header
+- `/templates/index.html` - Add h-feed wrapper
+- `/templates/note.html` - Complete h-entry properties
+- `/templates/partials/note_summary.html` - Create for consistent h-entry
+
+## Effort Estimate
+- Template Analysis: 2-3 hours
+- Markup Implementation: 4-6 hours
+- CSS Compatibility Check: 1-2 hours
+- Testing with mf2 parser: 2-3 hours
+- Documentation: 1-2 hours
+- Total: 10-16 hours
\ No newline at end of file
diff --git a/docs/decisions/ADR-027-versioning-strategy-for-authorization-removal.md b/docs/decisions/ADR-042-versioning-strategy-for-authorization-removal.md
similarity index 100%
rename from docs/decisions/ADR-027-versioning-strategy-for-authorization-removal.md
rename to docs/decisions/ADR-042-versioning-strategy-for-authorization-removal.md
diff --git a/docs/decisions/ADR-030-CORRECTED-indieauth-endpoint-discovery.md b/docs/decisions/ADR-043-CORRECTED-indieauth-endpoint-discovery.md
similarity index 98%
rename from docs/decisions/ADR-030-CORRECTED-indieauth-endpoint-discovery.md
rename to docs/decisions/ADR-043-CORRECTED-indieauth-endpoint-discovery.md
index 273c150..b4dcd2c 100644
--- a/docs/decisions/ADR-030-CORRECTED-indieauth-endpoint-discovery.md
+++ b/docs/decisions/ADR-043-CORRECTED-indieauth-endpoint-discovery.md
@@ -1,7 +1,7 @@
-# ADR-030-CORRECTED: IndieAuth Endpoint Discovery Architecture
+# ADR-043-CORRECTED: IndieAuth Endpoint Discovery Architecture
## Status
-Accepted (Replaces incorrect understanding in ADR-030)
+Accepted (Replaces incorrect understanding in previous ADR-030)
## Context
diff --git a/docs/decisions/ADR-031-endpoint-discovery-implementation.md b/docs/decisions/ADR-044-endpoint-discovery-implementation.md
similarity index 98%
rename from docs/decisions/ADR-031-endpoint-discovery-implementation.md
rename to docs/decisions/ADR-044-endpoint-discovery-implementation.md
index fcc1dca..7e368c1 100644
--- a/docs/decisions/ADR-031-endpoint-discovery-implementation.md
+++ b/docs/decisions/ADR-044-endpoint-discovery-implementation.md
@@ -112,5 +112,5 @@ Security principle: when in doubt, deny access. We use cached endpoints as a gra
## References
- W3C IndieAuth Specification Section 4.2 (Discovery)
-- ADR-030-CORRECTED (Original design)
+- ADR-043-CORRECTED (Original design)
- Developer analysis report (2025-11-24)
\ No newline at end of file
diff --git a/docs/decisions/ADR-052-configuration-system-architecture.md b/docs/decisions/ADR-052-configuration-system-architecture.md
new file mode 100644
index 0000000..2e0ee77
--- /dev/null
+++ b/docs/decisions/ADR-052-configuration-system-architecture.md
@@ -0,0 +1,223 @@
+# ADR-052: Configuration System Architecture
+
+## Status
+Accepted
+
+## Context
+StarPunk v1.1.1 "Polish" introduces several configurable features to improve production readiness and user experience. Currently, configuration values are hardcoded throughout the application, making customization difficult. We need a consistent, simple approach to configuration management that:
+
+1. Maintains backward compatibility
+2. Provides sensible defaults
+3. Follows Python best practices
+4. Minimizes complexity
+5. Supports environment-based configuration
+
+## Decision
+We will implement a centralized configuration system using environment variables with fallback defaults, managed through a single configuration module.
+
+### Configuration Architecture
+
+```
+Environment Variables (highest priority)
+ ↓
+Configuration File (optional, .env)
+ ↓
+Default Values (in code)
+```
+
+### Configuration Module Structure
+
+Location: `starpunk/config.py`
+
+Categories:
+1. **Search Configuration**
+ - `SEARCH_ENABLED`: bool (default: True)
+ - `SEARCH_TITLE_LENGTH`: int (default: 100)
+ - `SEARCH_HIGHLIGHT_CLASS`: str (default: "highlight")
+ - `SEARCH_MIN_SCORE`: float (default: 0.0)
+
+2. **Performance Configuration**
+ - `PERF_MONITORING_ENABLED`: bool (default: False)
+ - `PERF_SLOW_QUERY_THRESHOLD`: float (default: 1.0 seconds)
+ - `PERF_LOG_QUERIES`: bool (default: False)
+ - `PERF_MEMORY_TRACKING`: bool (default: False)
+
+3. **Database Configuration**
+ - `DB_CONNECTION_POOL_SIZE`: int (default: 5)
+ - `DB_CONNECTION_TIMEOUT`: float (default: 10.0)
+ - `DB_WAL_MODE`: bool (default: True)
+ - `DB_BUSY_TIMEOUT`: int (default: 5000 ms)
+
+4. **Logging Configuration**
+ - `LOG_LEVEL`: str (default: "INFO")
+ - `LOG_FORMAT`: str (default: structured JSON)
+ - `LOG_FILE_PATH`: str (default: None)
+ - `LOG_ROTATION`: bool (default: False)
+
+5. **Production Configuration**
+ - `SESSION_TIMEOUT`: int (default: 86400 seconds)
+ - `HEALTH_CHECK_DETAILED`: bool (default: False)
+ - `ERROR_DETAILS_IN_RESPONSE`: bool (default: False)
+
+### Implementation Pattern
+
+```python
+# starpunk/config.py
+import os
+from typing import Any, Optional
+
+class Config:
+ """Centralized configuration management"""
+
+ @staticmethod
+ def get_bool(key: str, default: bool = False) -> bool:
+ """Get boolean configuration value"""
+ value = os.environ.get(key, "").lower()
+ if value in ("true", "1", "yes", "on"):
+ return True
+ elif value in ("false", "0", "no", "off"):
+ return False
+ return default
+
+ @staticmethod
+ def get_int(key: str, default: int) -> int:
+ """Get integer configuration value"""
+ try:
+ return int(os.environ.get(key, default))
+ except (ValueError, TypeError):
+ return default
+
+ @staticmethod
+ def get_float(key: str, default: float) -> float:
+ """Get float configuration value"""
+ try:
+ return float(os.environ.get(key, default))
+ except (ValueError, TypeError):
+ return default
+
+ @staticmethod
+ def get_str(key: str, default: str = "") -> str:
+ """Get string configuration value"""
+ return os.environ.get(key, default)
+
+# Configuration instances
+SEARCH_ENABLED = Config.get_bool("STARPUNK_SEARCH_ENABLED", True)
+SEARCH_TITLE_LENGTH = Config.get_int("STARPUNK_SEARCH_TITLE_LENGTH", 100)
+# ... etc
+```
+
+### Environment Variable Naming Convention
+
+All StarPunk environment variables are prefixed with `STARPUNK_` to avoid conflicts:
+- `STARPUNK_SEARCH_ENABLED`
+- `STARPUNK_PERF_MONITORING_ENABLED`
+- `STARPUNK_DB_CONNECTION_POOL_SIZE`
+- etc.
+
+## Rationale
+
+### Why Environment Variables?
+1. **Standard Practice**: Follows 12-factor app methodology
+2. **Container Friendly**: Works well with Docker/Kubernetes
+3. **No Dependencies**: Built into Python stdlib
+4. **Security**: Sensitive values not in code
+5. **Simple**: No complex configuration parsing
+
+### Why Not Alternative Approaches?
+
+**YAML/TOML/INI Files**:
+- Adds parsing complexity
+- Requires file management
+- Not as container-friendly
+- Additional dependency
+
+**Database Configuration**:
+- Circular dependency (need config to connect to DB)
+- Makes deployment more complex
+- Not suitable for bootstrap configuration
+
+**Python Config Files**:
+- Security risk if user-editable
+- Import complexity
+- Not standard practice
+
+### Why Centralized Module?
+1. **Single Source**: All configuration in one place
+2. **Type Safety**: Helper methods ensure correct types
+3. **Documentation**: Self-documenting defaults
+4. **Testing**: Easy to mock for tests
+5. **Validation**: Can add validation logic centrally
+
+## Consequences
+
+### Positive
+1. **Backward Compatible**: All existing deployments continue working with defaults
+2. **Production Ready**: Ops teams can configure without code changes
+3. **Simple Implementation**: ~100 lines of code
+4. **Testable**: Easy to test different configurations
+5. **Documented**: Configuration options clear in one file
+6. **Flexible**: Can override any setting via environment
+
+### Negative
+1. **Environment Pollution**: Many environment variables in production
+2. **No Validation**: Invalid values fall back to defaults silently
+3. **No Hot Reload**: Requires restart to apply changes
+4. **Limited Types**: Only primitive types supported
+
+### Mitigations
+1. Use `.env` files for local development
+2. Add startup configuration validation
+3. Log configuration values at startup (non-sensitive only)
+4. Document all configuration options clearly
+
+## Alternatives Considered
+
+### 1. Pydantic Settings
+**Pros**: Type validation, .env support, modern
+**Cons**: New dependency, overengineered for our needs
+**Decision**: Too complex for v1.1.1 patch release
+
+### 2. Click Configuration
+**Pros**: Already using Click, integrated CLI options
+**Cons**: CLI args not suitable for all config, complex precedence
+**Decision**: Keep CLI and config separate
+
+### 3. ConfigParser (INI files)
+**Pros**: Python stdlib, familiar format
+**Cons**: File management complexity, not container-native
+**Decision**: Environment variables are simpler
+
+### 4. No Configuration System
+**Pros**: Simplest possible
+**Cons**: No production flexibility, poor UX
+**Decision**: v1.1.1 specifically targets production readiness
+
+## Implementation Notes
+
+1. Configuration module loads at import time
+2. Values are immutable after startup
+3. Invalid values log warnings but use defaults
+4. Sensitive values (tokens, keys) never logged
+5. Configuration documented in deployment guide
+6. Example `.env.example` file provided
+
+## Testing Strategy
+
+1. Unit tests mock environment variables
+2. Integration tests verify default behavior
+3. Configuration validation tests
+4. Performance impact tests (configuration overhead)
+
+## Migration Path
+
+No migration required - all configuration has sensible defaults that match current behavior.
+
+## References
+
+- [The Twelve-Factor App - Config](https://12factor.net/config)
+- [Python os.environ](https://docs.python.org/3/library/os.html#os.environ)
+- [Docker Environment Variables](https://docs.docker.com/compose/environment-variables/)
+
+## Document History
+
+- 2025-11-25: Initial draft for v1.1.1 release planning
\ No newline at end of file
diff --git a/docs/decisions/ADR-053-performance-monitoring-strategy.md b/docs/decisions/ADR-053-performance-monitoring-strategy.md
new file mode 100644
index 0000000..a49a474
--- /dev/null
+++ b/docs/decisions/ADR-053-performance-monitoring-strategy.md
@@ -0,0 +1,304 @@
+# ADR-053: Performance Monitoring Strategy
+
+## Status
+Accepted
+
+## Context
+StarPunk v1.1.1 introduces performance monitoring to help operators understand system behavior in production. Currently, we have no visibility into:
+- Database query performance
+- Memory usage patterns
+- Request processing times
+- Bottlenecks and slow operations
+
+We need a lightweight, zero-dependency monitoring solution that provides actionable insights without impacting performance.
+
+## Decision
+Implement a built-in performance monitoring system using Python's standard library, with optional detailed tracking controlled by configuration.
+
+### Architecture Overview
+
+```
+Request → Middleware (timing) → Handler
+ ↓ ↓
+ Context Manager Decorators
+ ↓ ↓
+ Metrics Store ← Database Hooks
+ ↓
+ Admin Dashboard
+```
+
+### Core Components
+
+#### 1. Metrics Collector
+Location: `starpunk/monitoring/collector.py`
+
+Responsibilities:
+- Collect timing data
+- Track memory usage
+- Store recent metrics in memory
+- Provide aggregation functions
+
+Data Structure:
+```python
+@dataclass
+class Metric:
+ timestamp: float
+ category: str # "db", "http", "function"
+ operation: str # specific operation name
+ duration: float # in seconds
+ metadata: dict # additional context
+```
+
+#### 2. Database Performance Tracking
+Location: `starpunk/monitoring/db_monitor.py`
+
+Features:
+- Query execution timing
+- Slow query detection
+- Query pattern analysis
+- Connection pool monitoring
+
+Implementation via SQLite callbacks:
+```python
+# Wrap database operations
+with monitor.track_query("SELECT", "notes"):
+ cursor.execute(query)
+```
+
+#### 3. Memory Tracking
+Location: `starpunk/monitoring/memory.py`
+
+Track:
+- Process memory (RSS)
+- Memory growth over time
+- Per-request memory delta
+- Memory high water mark
+
+Uses `resource` module (stdlib).
+
+#### 4. Request Performance
+Location: `starpunk/monitoring/http.py`
+
+Track:
+- Request processing time
+- Response size
+- Status code distribution
+- Slowest endpoints
+
+#### 5. Admin Dashboard
+Location: `/admin/performance`
+
+Display:
+- Real-time metrics (last 15 minutes)
+- Slow query log
+- Memory usage graph
+- Endpoint performance table
+- Database statistics
+
+### Data Retention
+
+In-memory circular buffer approach:
+- Last 1000 metrics retained
+- Automatic old data eviction
+- No persistent storage (privacy/simplicity)
+- Reset on restart
+
+### Performance Overhead
+
+Target: <1% overhead when enabled
+
+Strategies:
+- Sampling for high-frequency operations
+- Lazy computation of aggregates
+- Minimal memory footprint (1MB max)
+- Conditional compilation via config
+
+## Rationale
+
+### Why Built-in Monitoring?
+1. **Zero Dependencies**: Uses only Python stdlib
+2. **Privacy**: No external services
+3. **Simplicity**: No complex setup
+4. **Integrated**: Direct access to internals
+5. **Lightweight**: Minimal overhead
+
+### Why Not External Tools?
+
+**Prometheus/Grafana**:
+- Requires external services
+- Complex setup
+- Overkill for single-user system
+
+**APM Services** (New Relic, DataDog):
+- Privacy concerns
+- Subscription costs
+- Network dependency
+- Too heavy for our needs
+
+**OpenTelemetry**:
+- Large dependency
+- Complex configuration
+- Designed for distributed systems
+
+### Design Principles
+
+1. **Opt-in**: Disabled by default
+2. **Lightweight**: Minimal resource usage
+3. **Actionable**: Focus on useful metrics
+4. **Temporary**: No permanent storage
+5. **Private**: No external data transmission
+
+## Consequences
+
+### Positive
+1. **Production Visibility**: Understand behavior under load
+2. **Performance Debugging**: Identify bottlenecks quickly
+3. **No Dependencies**: Pure Python solution
+4. **Privacy Preserving**: Data stays local
+5. **Simple Deployment**: No additional services
+
+### Negative
+1. **Limited History**: Only recent data available
+2. **Memory Usage**: ~1MB for metrics buffer
+3. **No Alerting**: Manual monitoring required
+4. **Single Node**: No distributed tracing
+
+### Mitigations
+1. Export capability for external tools
+2. Configurable buffer size
+3. Webhook support for alerts (future)
+4. Focus on most valuable metrics
+
+## Alternatives Considered
+
+### 1. Logging-based Monitoring
+**Approach**: Parse performance data from logs
+**Pros**: Simple, no new code
+**Cons**: Log parsing complexity, no real-time view
+**Decision**: Dedicated monitoring is cleaner
+
+### 2. External Monitoring Service
+**Approach**: Use service like Sentry
+**Pros**: Full-featured, alerting included
+**Cons**: Privacy, cost, complexity
+**Decision**: Violates self-hosted principle
+
+### 3. Prometheus Exporter
+**Approach**: Expose /metrics endpoint
+**Pros**: Standard, good tooling
+**Cons**: Requires Prometheus setup
+**Decision**: Too complex for target users
+
+### 4. No Monitoring
+**Approach**: Rely on logs and external tools
+**Pros**: Simplest
+**Cons**: Poor production visibility
+**Decision**: v1.1.1 specifically targets production readiness
+
+## Implementation Details
+
+### Instrumentation Points
+
+1. **Database Layer**
+ - All queries automatically timed
+ - Connection acquisition/release
+ - Transaction duration
+ - Migration execution
+
+2. **HTTP Layer**
+ - Middleware wraps all requests
+ - Per-endpoint timing
+ - Static file serving
+ - Error handling
+
+3. **Core Functions**
+ - Note creation/update
+ - Search operations
+ - RSS generation
+ - Authentication flow
+
+### Performance Dashboard Layout
+
+```
+Performance Dashboard
+═══════════════════
+
+Overview
+--------
+Uptime: 5d 3h 15m
+Requests: 10,234
+Avg Response: 45ms
+Memory: 128MB
+
+Slow Queries (>1s)
+------------------
+[timestamp] SELECT ... FROM notes (1.2s)
+[timestamp] UPDATE ... SET ... (1.1s)
+
+Endpoint Performance
+-------------------
+GET / : avg 23ms, p99 45ms
+GET /notes/:id : avg 35ms, p99 67ms
+POST /micropub : avg 125ms, p99 234ms
+
+Memory Usage
+-----------
+[ASCII graph showing last 15 minutes]
+
+Database Stats
+-------------
+Pool Size: 3/5
+Queries/sec: 4.2
+Cache Hit Rate: 87%
+```
+
+### Configuration Options
+
+```python
+# All under STARPUNK_PERF_* prefix
+MONITORING_ENABLED = False # Master switch
+SLOW_QUERY_THRESHOLD = 1.0 # seconds
+LOG_QUERIES = False # Log all queries
+MEMORY_TRACKING = False # Track memory usage
+SAMPLE_RATE = 1.0 # 1.0 = all, 0.1 = 10%
+BUFFER_SIZE = 1000 # Number of metrics
+DASHBOARD_ENABLED = True # Enable web UI
+```
+
+## Testing Strategy
+
+1. **Unit Tests**: Mock collectors, verify metrics
+2. **Integration Tests**: End-to-end monitoring flow
+3. **Performance Tests**: Verify low overhead
+4. **Load Tests**: Behavior under stress
+
+## Security Considerations
+
+1. Dashboard requires admin authentication
+2. No sensitive data in metrics
+3. No external data transmission
+4. Metrics cleared on logout
+5. Rate limiting on dashboard endpoint
+
+## Migration Path
+
+No migration required - monitoring is opt-in via configuration.
+
+## Future Enhancements
+
+v1.2.0 and beyond:
+- Metric export (CSV/JSON)
+- Alert thresholds
+- Historical trending
+- Custom metric points
+- Plugin architecture
+
+## References
+
+- [Python resource module](https://docs.python.org/3/library/resource.html)
+- [SQLite Query Performance](https://www.sqlite.org/queryplanner.html)
+- [Web Vitals](https://web.dev/vitals/)
+
+## Document History
+
+- 2025-11-25: Initial draft for v1.1.1 release planning
\ No newline at end of file
diff --git a/docs/decisions/ADR-054-structured-logging-architecture.md b/docs/decisions/ADR-054-structured-logging-architecture.md
new file mode 100644
index 0000000..af8ef82
--- /dev/null
+++ b/docs/decisions/ADR-054-structured-logging-architecture.md
@@ -0,0 +1,355 @@
+# ADR-054: Structured Logging Architecture
+
+## Status
+Accepted
+
+## Context
+StarPunk currently uses print statements and basic logging without structure. For production deployments, we need:
+- Consistent log formatting
+- Appropriate log levels
+- Structured data for parsing
+- Correlation IDs for request tracking
+- Performance-conscious logging
+
+We need a logging architecture that is simple, follows Python best practices, and provides production-grade observability.
+
+## Decision
+Implement structured logging using Python's built-in `logging` module with JSON formatting and contextual information.
+
+### Logging Architecture
+
+```
+Application Code
+ ↓
+Logger Interface → Filters → Formatters → Handlers → Output
+ ↑ ↓
+Context Injection (stdout/file)
+```
+
+### Log Levels
+
+Following standard Python/syslog levels:
+
+| Level | Value | Usage |
+|-------|-------|-------|
+| CRITICAL | 50 | System failures requiring immediate attention |
+| ERROR | 40 | Errors that need investigation |
+| WARNING | 30 | Unexpected conditions that might cause issues |
+| INFO | 20 | Normal operation events |
+| DEBUG | 10 | Detailed diagnostic information |
+
+### Log Structure
+
+JSON format for production, human-readable for development:
+
+```json
+{
+ "timestamp": "2025-11-25T10:30:45.123Z",
+ "level": "INFO",
+ "logger": "starpunk.micropub",
+ "message": "Note created",
+ "request_id": "a1b2c3d4",
+ "user": "alice@example.com",
+ "context": {
+ "note_id": 123,
+ "slug": "my-note",
+ "word_count": 42
+ },
+ "performance": {
+ "duration_ms": 45
+ }
+}
+```
+
+### Logger Hierarchy
+
+```
+starpunk (root logger)
+├── starpunk.auth # Authentication/authorization
+├── starpunk.micropub # Micropub endpoint
+├── starpunk.database # Database operations
+├── starpunk.search # Search functionality
+├── starpunk.web # Web interface
+├── starpunk.rss # RSS generation
+├── starpunk.monitoring # Performance monitoring
+└── starpunk.migration # Database migrations
+```
+
+### Implementation Pattern
+
+```python
+# starpunk/logging.py
+import logging
+import json
+import sys
+from datetime import datetime
+from contextvars import ContextVar
+
+# Request context for correlation
+request_id: ContextVar[str] = ContextVar('request_id', default='')
+
+class StructuredFormatter(logging.Formatter):
+ """JSON formatter for structured logging"""
+
+ def format(self, record):
+ log_obj = {
+ 'timestamp': datetime.utcnow().isoformat() + 'Z',
+ 'level': record.levelname,
+ 'logger': record.name,
+ 'message': record.getMessage(),
+ 'request_id': request_id.get()
+ }
+
+ # Add extra fields
+ if hasattr(record, 'context'):
+ log_obj['context'] = record.context
+
+ if hasattr(record, 'performance'):
+ log_obj['performance'] = record.performance
+
+ # Add exception info if present
+ if record.exc_info:
+ log_obj['exception'] = self.formatException(record.exc_info)
+
+ return json.dumps(log_obj)
+
+def setup_logging(level='INFO', format_type='json'):
+ """Configure logging for the application"""
+ root_logger = logging.getLogger('starpunk')
+ root_logger.setLevel(level)
+
+ handler = logging.StreamHandler(sys.stdout)
+
+ if format_type == 'json':
+ formatter = StructuredFormatter()
+ else:
+ # Human-readable for development
+ formatter = logging.Formatter(
+ '%(asctime)s - %(name)s - %(levelname)s - %(message)s'
+ )
+
+ handler.setFormatter(formatter)
+ root_logger.addHandler(handler)
+
+ return root_logger
+
+# Usage pattern
+logger = logging.getLogger('starpunk.micropub')
+
+def create_note(content, user):
+ logger.info(
+ "Creating note",
+ extra={
+ 'context': {
+ 'user': user,
+ 'content_length': len(content)
+ }
+ }
+ )
+ # ... implementation
+```
+
+### What to Log
+
+#### Always Log (INFO+)
+- Authentication attempts (success/failure)
+- Note CRUD operations
+- Configuration changes
+- Startup/shutdown
+- External API calls
+- Migration execution
+- Search queries
+
+#### Error Conditions (ERROR)
+- Database connection failures
+- Invalid Micropub requests
+- Authentication failures
+- File system errors
+- Configuration errors
+
+#### Warnings (WARNING)
+- Slow queries
+- High memory usage
+- Deprecated feature usage
+- Missing optional configuration
+- FTS5 unavailability
+
+#### Debug Information (DEBUG)
+- SQL queries executed
+- Request/response bodies
+- Template rendering details
+- Cache operations
+- Detailed timing data
+
+### What NOT to Log
+- Passwords or tokens
+- Full note content (unless debug)
+- Personal information (PII)
+- Request headers with auth
+- Database connection strings
+
+### Performance Considerations
+
+1. **Lazy Evaluation**: Use lazy % formatting
+ ```python
+ logger.debug("Processing note %s", note_id) # Good
+ logger.debug(f"Processing note {note_id}") # Bad
+ ```
+
+2. **Level Checking**: Check before expensive operations
+ ```python
+ if logger.isEnabledFor(logging.DEBUG):
+ logger.debug("Data: %s", expensive_serialization())
+ ```
+
+3. **Async Logging**: For high-volume scenarios (future)
+
+4. **Sampling**: For very frequent operations
+ ```python
+ if random.random() < 0.1: # Log 10%
+ logger.debug("High frequency operation")
+ ```
+
+## Rationale
+
+### Why Standard Logging Module?
+1. **No Dependencies**: Built into Python
+2. **Industry Standard**: Well understood
+3. **Flexible**: Handlers, formatters, filters
+4. **Battle-tested**: Proven in production
+5. **Integration**: Works with existing tools
+
+### Why JSON Format?
+1. **Parseable**: Easy for log aggregators
+2. **Structured**: Consistent field access
+3. **Flexible**: Can add fields without breaking
+4. **Standard**: Widely supported
+
+### Why Not Alternatives?
+
+**structlog**:
+- Additional dependency
+- More complex API
+- Overkill for our needs
+
+**loguru**:
+- Third-party dependency
+- Non-standard API
+- Not necessary for our scale
+
+**Print statements**:
+- No levels
+- No structure
+- No filtering
+- Not production-ready
+
+## Consequences
+
+### Positive
+1. **Production Ready**: Professional logging
+2. **Debuggable**: Rich context in logs
+3. **Parseable**: Integration with log tools
+4. **Performant**: Minimal overhead
+5. **Configurable**: Adjust without code changes
+6. **Correlatable**: Request tracking via IDs
+
+### Negative
+1. **Verbosity**: More code for logging
+2. **Learning**: Developers must understand levels
+3. **Size**: JSON logs are larger than plain text
+4. **Complexity**: More setup than prints
+
+### Mitigations
+1. Provide logging utilities/helpers
+2. Document logging guidelines
+3. Use log rotation for size management
+4. Create developer-friendly formatter option
+
+## Alternatives Considered
+
+### 1. Continue with Print Statements
+**Pros**: Simplest possible
+**Cons**: Not production-ready
+**Decision**: Inadequate for production
+
+### 2. Custom Logging Solution
+**Pros**: Exactly what we need
+**Cons**: Reinventing the wheel
+**Decision**: Standard library is sufficient
+
+### 3. External Logging Service
+**Pros**: No local storage needed
+**Cons**: Privacy, dependency, cost
+**Decision**: Conflicts with self-hosted philosophy
+
+### 4. Syslog Integration
+**Pros**: Standard Unix logging
+**Cons**: Platform-specific, complexity
+**Decision**: Can add as handler if needed
+
+## Implementation Notes
+
+### Bootstrap Logging
+```python
+# Application startup
+import logging
+from starpunk.logging import setup_logging
+
+# Configure based on environment
+if os.environ.get('STARPUNK_ENV') == 'production':
+ setup_logging(level='INFO', format_type='json')
+else:
+ setup_logging(level='DEBUG', format_type='human')
+```
+
+### Request Correlation
+```python
+# Middleware sets request ID
+from uuid import uuid4
+from contextvars import copy_context
+
+def middleware(request):
+ request_id.set(str(uuid4())[:8])
+ # Process request in context
+ return copy_context().run(handler, request)
+```
+
+### Migration Strategy
+1. Phase 1: Add logging module, keep prints
+2. Phase 2: Convert prints to logger calls
+3. Phase 3: Remove print statements
+4. Phase 4: Add structured context
+
+## Testing Strategy
+
+1. **Unit Tests**: Mock logger, verify calls
+2. **Integration Tests**: Verify log output format
+3. **Performance Tests**: Measure logging overhead
+4. **Configuration Tests**: Test different levels/formats
+
+## Configuration
+
+Environment variables:
+- `STARPUNK_LOG_LEVEL`: DEBUG|INFO|WARNING|ERROR|CRITICAL
+- `STARPUNK_LOG_FORMAT`: json|human
+- `STARPUNK_LOG_FILE`: Path to log file (optional)
+- `STARPUNK_LOG_ROTATION`: Enable rotation (optional)
+
+## Security Considerations
+
+1. Never log sensitive data
+2. Sanitize user input in logs
+3. Rate limit log output
+4. Monitor for log injection attacks
+5. Secure log file permissions
+
+## References
+
+- [Python Logging HOWTO](https://docs.python.org/3/howto/logging.html)
+- [The Twelve-Factor App - Logs](https://12factor.net/logs)
+- [OWASP Logging Guide](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html)
+- [JSON Logging Best Practices](https://www.loggly.com/use-cases/json-logging-best-practices/)
+
+## Document History
+
+- 2025-11-25: Initial draft for v1.1.1 release planning
\ No newline at end of file
diff --git a/docs/decisions/ADR-055-error-handling-philosophy.md b/docs/decisions/ADR-055-error-handling-philosophy.md
new file mode 100644
index 0000000..e3c64f9
--- /dev/null
+++ b/docs/decisions/ADR-055-error-handling-philosophy.md
@@ -0,0 +1,415 @@
+# ADR-055: Error Handling Philosophy
+
+## Status
+Accepted
+
+## Context
+StarPunk v1.1.1 focuses on production readiness, including graceful error handling. Currently, error handling is inconsistent:
+- Some errors crash the application
+- Error messages vary in helpfulness
+- No distinction between user and system errors
+- Insufficient context for debugging
+
+We need a consistent philosophy for handling errors that balances user experience, security, and debuggability.
+
+## Decision
+Adopt a layered error handling strategy that provides graceful degradation, helpful user messages, and detailed logging for operators.
+
+### Error Handling Principles
+
+1. **Fail Gracefully**: Never crash when recovery is possible
+2. **Be Helpful**: Provide actionable error messages
+3. **Log Everything**: Detailed context for debugging
+4. **Secure by Default**: Don't leak sensitive information
+5. **User vs System**: Different handling for different audiences
+
+### Error Categories
+
+#### 1. User Errors (4xx class)
+Errors caused by user action or client issues.
+
+Examples:
+- Invalid Micropub request
+- Authentication failure
+- Missing required fields
+- Invalid slug format
+
+Handling:
+- Return helpful error message
+- Suggest corrective action
+- Log at INFO level
+- Don't expose internals
+
+#### 2. System Errors (5xx class)
+Errors in system operation.
+
+Examples:
+- Database connection failure
+- File system errors
+- Memory exhaustion
+- Template rendering errors
+
+Handling:
+- Generic user message
+- Detailed logging at ERROR level
+- Attempt recovery if possible
+- Alert operators (future)
+
+#### 3. Configuration Errors
+Errors due to misconfiguration.
+
+Examples:
+- Missing required config
+- Invalid configuration values
+- Incompatible settings
+- Permission issues
+
+Handling:
+- Fail fast at startup
+- Clear error messages
+- Suggest fixes
+- Document requirements
+
+#### 4. Transient Errors
+Temporary errors that may succeed on retry.
+
+Examples:
+- Database lock
+- Network timeout
+- Resource temporarily unavailable
+
+Handling:
+- Automatic retry with backoff
+- Log at WARNING level
+- Fail gracefully after retries
+- Track frequency
+
+### Error Response Format
+
+#### Development Mode
+```json
+{
+ "error": {
+ "type": "ValidationError",
+ "message": "Invalid slug format",
+ "details": {
+ "field": "slug",
+ "value": "my/bad/slug",
+ "pattern": "^[a-z0-9-]+$"
+ },
+ "suggestion": "Slugs can only contain lowercase letters, numbers, and hyphens",
+ "documentation": "/docs/api/micropub#slugs",
+ "trace_id": "abc123"
+ }
+}
+```
+
+#### Production Mode
+```json
+{
+ "error": {
+ "message": "Invalid request format",
+ "suggestion": "Please check your request and try again",
+ "documentation": "/docs/api/micropub",
+ "trace_id": "abc123"
+ }
+}
+```
+
+### Implementation Pattern
+
+```python
+# starpunk/errors.py
+from enum import Enum
+from typing import Optional, Dict, Any
+import logging
+
+logger = logging.getLogger('starpunk.errors')
+
+class ErrorCategory(Enum):
+ USER = "user"
+ SYSTEM = "system"
+ CONFIG = "config"
+ TRANSIENT = "transient"
+
+class StarPunkError(Exception):
+ """Base exception for all StarPunk errors"""
+
+ def __init__(
+ self,
+ message: str,
+ category: ErrorCategory = ErrorCategory.SYSTEM,
+ suggestion: Optional[str] = None,
+ details: Optional[Dict[str, Any]] = None,
+ status_code: int = 500,
+ recoverable: bool = False
+ ):
+ self.message = message
+ self.category = category
+ self.suggestion = suggestion
+ self.details = details or {}
+ self.status_code = status_code
+ self.recoverable = recoverable
+ super().__init__(message)
+
+ def to_user_dict(self, debug: bool = False) -> dict:
+ """Format error for user response"""
+ result = {
+ 'error': {
+ 'message': self.message,
+ 'trace_id': self.trace_id
+ }
+ }
+
+ if self.suggestion:
+ result['error']['suggestion'] = self.suggestion
+
+ if debug and self.details:
+ result['error']['details'] = self.details
+ result['error']['type'] = self.__class__.__name__
+
+ return result
+
+ def log(self):
+ """Log error with appropriate level"""
+ if self.category == ErrorCategory.USER:
+ logger.info(
+ "User error: %s",
+ self.message,
+ extra={'context': self.details}
+ )
+ elif self.category == ErrorCategory.TRANSIENT:
+ logger.warning(
+ "Transient error: %s",
+ self.message,
+ extra={'context': self.details}
+ )
+ else:
+ logger.error(
+ "System error: %s",
+ self.message,
+ extra={'context': self.details},
+ exc_info=True
+ )
+
+# Specific error classes
+class ValidationError(StarPunkError):
+ """User input validation failed"""
+ def __init__(self, message: str, field: str = None, **kwargs):
+ super().__init__(
+ message,
+ category=ErrorCategory.USER,
+ status_code=400,
+ **kwargs
+ )
+ if field:
+ self.details['field'] = field
+
+class AuthenticationError(StarPunkError):
+ """Authentication failed"""
+ def __init__(self, message: str = "Authentication required", **kwargs):
+ super().__init__(
+ message,
+ category=ErrorCategory.USER,
+ status_code=401,
+ suggestion="Please authenticate and try again",
+ **kwargs
+ )
+
+class DatabaseError(StarPunkError):
+ """Database operation failed"""
+ def __init__(self, message: str, **kwargs):
+ super().__init__(
+ message,
+ category=ErrorCategory.SYSTEM,
+ status_code=500,
+ suggestion="Please try again later",
+ **kwargs
+ )
+
+class ConfigurationError(StarPunkError):
+ """Configuration is invalid"""
+ def __init__(self, message: str, setting: str = None, **kwargs):
+ super().__init__(
+ message,
+ category=ErrorCategory.CONFIG,
+ status_code=500,
+ **kwargs
+ )
+ if setting:
+ self.details['setting'] = setting
+```
+
+### Error Handling Middleware
+
+```python
+# starpunk/middleware/errors.py
+def error_handler(func):
+ """Decorator for consistent error handling"""
+ def wrapper(*args, **kwargs):
+ try:
+ return func(*args, **kwargs)
+ except StarPunkError as e:
+ e.log()
+ return e.to_user_dict(debug=is_debug_mode())
+ except Exception as e:
+ # Unexpected error
+ error = StarPunkError(
+ message="An unexpected error occurred",
+ category=ErrorCategory.SYSTEM,
+ details={'original': str(e)}
+ )
+ error.log()
+ return error.to_user_dict(debug=is_debug_mode())
+ return wrapper
+```
+
+### Graceful Degradation Examples
+
+#### FTS5 Unavailable
+```python
+try:
+ # Attempt FTS5 search
+ results = search_with_fts5(query)
+except FTS5UnavailableError:
+ logger.warning("FTS5 unavailable, falling back to LIKE")
+ results = search_with_like(query)
+ flash("Search is running in compatibility mode")
+```
+
+#### Database Lock
+```python
+@retry(
+ stop=stop_after_attempt(3),
+ wait=wait_exponential(multiplier=0.5, max=2),
+ retry=retry_if_exception_type(sqlite3.OperationalError)
+)
+def execute_query(query):
+ """Execute with retry for transient errors"""
+ return db.execute(query)
+```
+
+#### Missing Optional Feature
+```python
+if not config.SEARCH_ENABLED:
+ # Return empty results instead of error
+ return {
+ 'results': [],
+ 'message': 'Search is disabled on this instance'
+ }
+```
+
+## Rationale
+
+### Why Graceful Degradation?
+1. **User Experience**: Don't break the whole app
+2. **Reliability**: Partial functionality better than none
+3. **Operations**: Easier to diagnose in production
+4. **Recovery**: System can self-heal from transients
+
+### Why Different Error Categories?
+1. **Appropriate Response**: Different errors need different handling
+2. **Security**: Don't expose internals for system errors
+3. **Debugging**: Operators need full context
+4. **User Experience**: Users need actionable messages
+
+### Why Structured Errors?
+1. **Consistency**: Predictable error format
+2. **Parsing**: Tools can process errors
+3. **Correlation**: Trace IDs link logs to responses
+4. **Documentation**: Self-documenting error details
+
+## Consequences
+
+### Positive
+1. **Better UX**: Helpful error messages
+2. **Easier Debugging**: Rich context in logs
+3. **More Reliable**: Graceful degradation
+4. **Secure**: No information leakage
+5. **Consistent**: Predictable error handling
+
+### Negative
+1. **More Code**: Error handling adds complexity
+2. **Testing Burden**: Many error paths to test
+3. **Performance**: Error handling overhead
+4. **Maintenance**: Error messages need updates
+
+### Mitigations
+1. Use error hierarchy to reduce duplication
+2. Generate tests for error paths
+3. Cache error messages
+4. Document error codes clearly
+
+## Alternatives Considered
+
+### 1. Let Exceptions Bubble
+**Pros**: Simple, Python default
+**Cons**: Poor UX, crashes, no context
+**Decision**: Not production-ready
+
+### 2. Generic Error Pages
+**Pros**: Simple to implement
+**Cons**: Not helpful, poor API experience
+**Decision**: Insufficient for Micropub API
+
+### 3. Error Codes System
+**Pros**: Precise, machine-readable
+**Cons**: Complex, needs documentation
+**Decision**: Over-engineered for our scale
+
+### 4. Sentry/Error Tracking Service
+**Pros**: Rich features, alerting
+**Cons**: External dependency, privacy
+**Decision**: Conflicts with self-hosted philosophy
+
+## Implementation Notes
+
+### Critical Path Protection
+Always protect critical paths:
+```python
+# Never let note creation completely fail
+try:
+ create_search_index(note)
+except Exception as e:
+ logger.error("Search indexing failed: %s", e)
+ # Continue without search - note still created
+```
+
+### Error Budget
+Track error rates for SLO monitoring:
+- User errors: Unlimited (not our fault)
+- System errors: <0.1% of requests
+- Configuration errors: 0 after startup
+- Transient errors: <1% of requests
+
+### Testing Strategy
+1. Unit tests for each error class
+2. Integration tests for error paths
+3. Chaos testing for transient errors
+4. User journey tests with errors
+
+## Security Considerations
+
+1. Never expose stack traces to users
+2. Sanitize error messages
+3. Rate limit error endpoints
+4. Don't leak existence via errors
+5. Log security errors specially
+
+## Migration Path
+
+1. Phase 1: Add error classes
+2. Phase 2: Wrap existing code
+3. Phase 3: Add graceful degradation
+4. Phase 4: Improve error messages
+
+## References
+
+- [Error Handling Best Practices](https://www.python.org/dev/peps/pep-0008/#programming-recommendations)
+- [HTTP Status Codes](https://httpstatuses.com/)
+- [OWASP Error Handling](https://owasp.org/www-community/Improper_Error_Handling)
+- [Google SRE Book - Handling Overload](https://sre.google/sre-book/handling-overload/)
+
+## Document History
+
+- 2025-11-25: Initial draft for v1.1.1 release planning
\ No newline at end of file
diff --git a/docs/decisions/INDEX.md b/docs/decisions/INDEX.md
new file mode 100644
index 0000000..aaafaae
--- /dev/null
+++ b/docs/decisions/INDEX.md
@@ -0,0 +1,139 @@
+# Architectural Decision Records (ADRs) Index
+
+This directory contains all Architectural Decision Records for StarPunk CMS. ADRs document significant architectural decisions, their context, rationale, and consequences.
+
+## ADR Format
+
+Each ADR follows this structure:
+- **Title**: ADR-NNN-brief-descriptive-title.md
+- **Status**: Proposed, Accepted, Deprecated, Superseded
+- **Context**: Why we're making this decision
+- **Decision**: What we decided to do
+- **Consequences**: Impact of this decision
+
+## All ADRs (Chronological)
+
+### Foundation & Technology Stack (ADR-001 to ADR-009)
+- **[ADR-001](ADR-001-python-web-framework.md)** - Python Web Framework Selection
+- **[ADR-002](ADR-002-flask-extensions.md)** - Flask Extensions Strategy
+- **[ADR-003](ADR-003-frontend-technology.md)** - Frontend Technology Stack
+- **[ADR-004](ADR-004-file-based-note-storage.md)** - File-Based Note Storage
+- **[ADR-005](ADR-005-indielogin-authentication.md)** - IndieLogin Authentication
+- **[ADR-006](ADR-006-python-virtual-environment-uv.md)** - Python Virtual Environment with uv
+- **[ADR-007](ADR-007-slug-generation-algorithm.md)** - Slug Generation Algorithm
+- **[ADR-008](ADR-008-versioning-strategy.md)** - Versioning Strategy
+- **[ADR-009](ADR-009-git-branching-strategy.md)** - Git Branching Strategy
+
+### Authentication & Authorization (ADR-010 to ADR-027)
+- **[ADR-010](ADR-010-authentication-module-design.md)** - Authentication Module Design
+- **[ADR-011](ADR-011-development-authentication-mechanism.md)** - Development Authentication Mechanism
+- **[ADR-016](ADR-016-indieauth-client-discovery.md)** - IndieAuth Client Discovery
+- **[ADR-017](ADR-017-oauth-client-metadata-document.md)** - OAuth Client Metadata Document
+- **[ADR-018](ADR-018-indieauth-detailed-logging.md)** - IndieAuth Detailed Logging
+- **[ADR-019](ADR-019-indieauth-correct-implementation.md)** - IndieAuth Correct Implementation
+- **[ADR-021](ADR-021-indieauth-provider-strategy.md)** - IndieAuth Provider Strategy
+- **[ADR-022](ADR-022-auth-route-prefix-fix.md)** - Auth Route Prefix Fix
+- **[ADR-023](ADR-023-indieauth-client-identification.md)** - IndieAuth Client Identification
+- **[ADR-024](ADR-024-static-identity-page.md)** - Static Identity Page
+- **[ADR-025](ADR-025-indieauth-pkce-authentication.md)** - IndieAuth PKCE Authentication
+- **[ADR-026](ADR-026-indieauth-token-exchange-compliance.md)** - IndieAuth Token Exchange Compliance
+- **[ADR-027](ADR-027-indieauth-authentication-endpoint-correction.md)** - IndieAuth Authentication Endpoint Correction
+
+### Error Handling & Core Features (ADR-012 to ADR-015)
+- **[ADR-012](ADR-012-http-error-handling-policy.md)** - HTTP Error Handling Policy
+- **[ADR-013](ADR-013-expose-deleted-at-in-note-model.md)** - Expose Deleted-At in Note Model
+- **[ADR-014](ADR-014-rss-feed-implementation.md)** - RSS Feed Implementation
+- **[ADR-015](ADR-015-phase-5-implementation-approach.md)** - Phase 5 Implementation Approach
+
+### Micropub & API (ADR-028 to ADR-029)
+- **[ADR-028](ADR-028-micropub-implementation.md)** - Micropub Implementation
+- **[ADR-029](ADR-029-micropub-indieauth-integration.md)** - Micropub IndieAuth Integration
+
+### Database & Migrations (ADR-020, ADR-031 to ADR-037)
+- **[ADR-020](ADR-020-automatic-database-migrations.md)** - Automatic Database Migrations
+- **[ADR-031](ADR-031-database-migration-system-redesign.md)** - Database Migration System Redesign
+- **[ADR-032](ADR-032-initial-schema-sql-implementation.md)** - Initial Schema SQL Implementation
+- **[ADR-033](ADR-033-database-migration-redesign.md)** - Database Migration Redesign
+- **[ADR-037](ADR-037-migration-race-condition-fix.md)** - Migration Race Condition Fix
+- **[ADR-041](ADR-041-database-migration-conflict-resolution.md)** - Database Migration Conflict Resolution
+
+### Search & Advanced Features (ADR-034 to ADR-036, ADR-038 to ADR-040)
+- **[ADR-034](ADR-034-full-text-search.md)** - Full-Text Search
+- **[ADR-035](ADR-035-custom-slugs.md)** - Custom Slugs
+- **[ADR-036](ADR-036-indieauth-token-verification-method.md)** - IndieAuth Token Verification Method
+- **[ADR-038](ADR-038-syndication-formats.md)** - Syndication Formats (ATOM, JSON Feed)
+- **[ADR-039](ADR-039-micropub-url-construction-fix.md)** - Micropub URL Construction Fix
+- **[ADR-040](ADR-040-microformats2-compliance.md)** - Microformats2 Compliance
+
+### Architecture Refinements (ADR-042 to ADR-044)
+- **[ADR-042](ADR-042-versioning-strategy-for-authorization-removal.md)** - Versioning Strategy for Authorization Removal
+- **[ADR-043](ADR-043-CORRECTED-indieauth-endpoint-discovery.md)** - CORRECTED IndieAuth Endpoint Discovery
+- **[ADR-044](ADR-044-endpoint-discovery-implementation.md)** - Endpoint Discovery Implementation Details
+
+### Major Architectural Changes (ADR-050 to ADR-051)
+- **[ADR-050](ADR-050-remove-custom-indieauth-server.md)** - Remove Custom IndieAuth Server
+- **[ADR-051](ADR-051-phase1-test-strategy.md)** - Phase 1 Test Strategy
+
+### v1.1.1 Quality & Production Readiness (ADR-052 to ADR-055)
+- **[ADR-052](ADR-052-configuration-system-architecture.md)** - Configuration System Architecture
+- **[ADR-053](ADR-053-performance-monitoring-strategy.md)** - Performance Monitoring Strategy
+- **[ADR-054](ADR-054-structured-logging-architecture.md)** - Structured Logging Architecture
+- **[ADR-055](ADR-055-error-handling-philosophy.md)** - Error Handling Philosophy
+
+## ADRs by Topic
+
+### Authentication & IndieAuth
+ADR-005, ADR-010, ADR-011, ADR-016, ADR-017, ADR-018, ADR-019, ADR-021, ADR-022, ADR-023, ADR-024, ADR-025, ADR-026, ADR-027, ADR-036, ADR-043, ADR-044, ADR-050
+
+### Database & Migrations
+ADR-004, ADR-020, ADR-031, ADR-032, ADR-033, ADR-037, ADR-041
+
+### API & Micropub
+ADR-028, ADR-029, ADR-039
+
+### Content & Features
+ADR-007, ADR-013, ADR-014, ADR-034, ADR-035, ADR-038, ADR-040
+
+### Development & Operations
+ADR-001, ADR-002, ADR-003, ADR-006, ADR-008, ADR-009, ADR-012, ADR-015, ADR-042, ADR-051, ADR-052, ADR-053, ADR-054, ADR-055
+
+## Superseded ADRs
+
+These ADRs have been superseded by later decisions:
+- **ADR-030** (old) - Superseded by ADR-043 (CORRECTED IndieAuth Endpoint Discovery)
+
+## How to Create a New ADR
+
+1. **Find the next sequential number**: Check the highest existing ADR number
+2. **Use the naming format**: `ADR-NNN-brief-descriptive-title.md`
+3. **Follow the template**:
+ ```markdown
+ # ADR-NNN: Title
+
+ ## Status
+ Proposed | Accepted | Deprecated | Superseded
+
+ ## Context
+ Why are we making this decision?
+
+ ## Decision
+ What have we decided to do?
+
+ ## Consequences
+ What are the positive and negative consequences?
+
+ ## Alternatives Considered
+ What other options did we evaluate?
+ ```
+4. **Update this index** with the new ADR
+
+## Related Documentation
+- **[../architecture/](../architecture/)** - Architectural overviews and system design
+- **[../design/](../design/)** - Detailed design documents
+- **[../standards/](../standards/)** - Coding standards and conventions
+
+---
+
+**Last Updated**: 2025-11-25
+**Maintained By**: Documentation Manager Agent
+**Total ADRs**: 55
diff --git a/docs/deployment/INDEX.md b/docs/deployment/INDEX.md
new file mode 100644
index 0000000..080b4b4
--- /dev/null
+++ b/docs/deployment/INDEX.md
@@ -0,0 +1,41 @@
+# Deployment Documentation Index
+
+This directory contains deployment guides, infrastructure setup instructions, and operations documentation for StarPunk CMS.
+
+## Deployment Guides
+
+- **[container-deployment.md](container-deployment.md)** - Container-based deployment guide (Docker, Podman)
+
+## Deployment Options
+
+### Container Deployment (Recommended)
+Container deployment provides:
+- Consistent environment across platforms
+- Easy updates and rollbacks
+- Resource isolation
+- Simplified dependency management
+
+See: [container-deployment.md](container-deployment.md)
+
+### Manual Deployment
+For manual deployment without containers:
+- Follow [../standards/development-setup.md](../standards/development-setup.md)
+- Configure systemd service
+- Set up reverse proxy (nginx/Caddy)
+- Configure SSL/TLS certificates
+
+### Cloud Deployment
+StarPunk can be deployed to:
+- Any container platform (Kubernetes, Docker Swarm)
+- VPS providers (DigitalOcean, Linode, Vultr)
+- PaaS platforms supporting containers
+
+## Related Documentation
+- **[../standards/development-setup.md](../standards/development-setup.md)** - Development environment setup
+- **[../architecture/](../architecture/)** - System architecture
+- **[README.md](../../README.md)** - Quick start guide
+
+---
+
+**Last Updated**: 2025-11-25
+**Maintained By**: Documentation Manager Agent
diff --git a/docs/design/INDEX.md b/docs/design/INDEX.md
new file mode 100644
index 0000000..503ee63
--- /dev/null
+++ b/docs/design/INDEX.md
@@ -0,0 +1,128 @@
+# Design Documentation Index
+
+This directory contains detailed design documents, feature specifications, and phase implementation plans for StarPunk CMS.
+
+## Project Structure
+- **[project-structure.md](project-structure.md)** - Overall project structure and organization
+- **[initial-files.md](initial-files.md)** - Initial file structure for the project
+
+## Phase Implementation Plans
+
+### Phase 1: Foundation
+- **[phase-1.1-core-utilities.md](phase-1.1-core-utilities.md)** - Core utility functions and helpers
+- **[phase-1.1-quick-reference.md](phase-1.1-quick-reference.md)** - Quick reference for Phase 1.1
+- **[phase-1.2-data-models.md](phase-1.2-data-models.md)** - Data models and database schema
+- **[phase-1.2-quick-reference.md](phase-1.2-quick-reference.md)** - Quick reference for Phase 1.2
+
+### Phase 2: Core Features
+- **[phase-2.1-notes-management.md](phase-2.1-notes-management.md)** - Notes CRUD functionality
+- **[phase-2.1-quick-reference.md](phase-2.1-quick-reference.md)** - Quick reference for Phase 2.1
+
+### Phase 3: Authentication
+- **[phase-3-authentication.md](phase-3-authentication.md)** - Authentication system design
+- **[phase-3-authentication-implementation.md](phase-3-authentication-implementation.md)** - Implementation details
+- **[indieauth-pkce-authentication.md](indieauth-pkce-authentication.md)** - IndieAuth PKCE authentication design
+
+### Phase 4: Web Interface
+- **[phase-4-web-interface.md](phase-4-web-interface.md)** - Web interface design
+- **[phase-4-quick-reference.md](phase-4-quick-reference.md)** - Quick reference for Phase 4
+- **[phase-4-error-handling-fix.md](phase-4-error-handling-fix.md)** - Error handling improvements
+
+### Phase 5: RSS & Deployment
+- **[phase-5-rss-and-container.md](phase-5-rss-and-container.md)** - RSS feed and container deployment
+- **[phase-5-executive-summary.md](phase-5-executive-summary.md)** - Executive summary of Phase 5
+- **[phase-5-quick-reference.md](phase-5-quick-reference.md)** - Quick reference for Phase 5
+
+## Feature-Specific Design
+
+### Micropub API
+- **[micropub-endpoint-design.md](micropub-endpoint-design.md)** - Micropub endpoint detailed design
+
+### Authentication Fixes
+- **[auth-redirect-loop-diagnosis.md](auth-redirect-loop-diagnosis.md)** - Diagnosis of redirect loop issues
+- **[auth-redirect-loop-diagram.md](auth-redirect-loop-diagram.md)** - Visual diagrams of the problem
+- **[auth-redirect-loop-executive-summary.md](auth-redirect-loop-executive-summary.md)** - Executive summary
+- **[auth-redirect-loop-fix-implementation.md](auth-redirect-loop-fix-implementation.md)** - Implementation guide
+
+### Database Schema
+- **[initial-schema-implementation-guide.md](initial-schema-implementation-guide.md)** - Schema implementation guide
+- **[initial-schema-quick-reference.md](initial-schema-quick-reference.md)** - Quick reference
+
+### Security
+- **[token-security-migration.md](token-security-migration.md)** - Token security improvements
+
+## Version-Specific Design
+
+### v1.1.1
+- **[v1.1.1/](v1.1.1/)** - v1.1.1 specific design documents
+
+## Quick Reference Documents
+
+Quick reference documents provide condensed, actionable information for developers:
+- **phase-1.1-quick-reference.md** - Core utilities quick ref
+- **phase-1.2-quick-reference.md** - Data models quick ref
+- **phase-2.1-quick-reference.md** - Notes management quick ref
+- **phase-4-quick-reference.md** - Web interface quick ref
+- **phase-5-quick-reference.md** - RSS and deployment quick ref
+- **initial-schema-quick-reference.md** - Database schema quick ref
+
+## How to Use This Documentation
+
+### For Developers Implementing Features
+1. Start with the relevant **phase** document (e.g., phase-2.1-notes-management.md)
+2. Consult the **quick reference** for that phase
+3. Check **feature-specific design** docs for details
+4. Reference **ADRs** in ../decisions/ for architectural decisions
+
+### For Planning New Features
+1. Review similar **phase documents** for patterns
+2. Check **project-structure.md** for organization guidelines
+3. Create new design doc following existing format
+4. Update this index with the new document
+
+### For Understanding Existing Code
+1. Find the **phase** that implemented the feature
+2. Read the design document for context
+3. Check **ADRs** for decision rationale
+4. Review implementation reports in ../reports/
+
+## Document Types
+
+### Phase Documents
+Comprehensive plans for each development phase, including:
+- Goals and scope
+- Implementation tasks
+- Dependencies
+- Testing requirements
+
+### Quick Reference Documents
+Condensed information for rapid development:
+- Key decisions
+- Code patterns
+- Common operations
+- Gotchas and notes
+
+### Feature Design Documents
+Detailed specifications for specific features:
+- Requirements
+- API design
+- Data models
+- UI/UX considerations
+
+### Diagnostic Documents
+Problem analysis and solutions:
+- Issue description
+- Root cause analysis
+- Solution design
+- Implementation plan
+
+## Related Documentation
+- **[../architecture/](../architecture/)** - System architecture and overviews
+- **[../decisions/](../decisions/)** - Architectural Decision Records (ADRs)
+- **[../reports/](../reports/)** - Implementation reports
+- **[../standards/](../standards/)** - Coding standards and conventions
+
+---
+
+**Last Updated**: 2025-11-25
+**Maintained By**: Documentation Manager Agent
diff --git a/docs/design/v1.1.1/bug-fixes-spec.md b/docs/design/v1.1.1/bug-fixes-spec.md
new file mode 100644
index 0000000..5be29c8
--- /dev/null
+++ b/docs/design/v1.1.1/bug-fixes-spec.md
@@ -0,0 +1,665 @@
+# Bug Fixes and Edge Cases Specification
+
+## Overview
+This specification details the bug fixes and edge case handling improvements planned for v1.1.1, focusing on test stability, Unicode handling, memory optimization, and session management.
+
+## Bug Fixes
+
+### 1. Migration Race Condition in Tests
+
+#### Problem
+10 tests exhibit flaky behavior due to race conditions during database migration execution. Tests occasionally fail when migrations are executed concurrently or when the test database isn't properly initialized.
+
+#### Root Cause
+- Concurrent test execution without proper isolation
+- Shared database state between tests
+- Migration lock not properly acquired
+- Test fixtures not waiting for migration completion
+
+#### Solution
+```python
+# starpunk/testing/fixtures.py
+import threading
+import tempfile
+from contextlib import contextmanager
+
+# Global lock for test database operations
+_test_db_lock = threading.Lock()
+
+@contextmanager
+def isolated_test_database():
+ """Create isolated database for testing"""
+ with _test_db_lock:
+ # Create unique temp database
+ temp_db = tempfile.NamedTemporaryFile(
+ suffix='.db',
+ delete=False
+ )
+ db_path = temp_db.name
+ temp_db.close()
+
+ try:
+ # Initialize database with migrations
+ run_migrations_sync(db_path)
+
+ # Yield database for test
+ yield db_path
+ finally:
+ # Cleanup
+ try:
+ os.unlink(db_path)
+ except:
+ pass
+
+def run_migrations_sync(db_path: str):
+ """Run migrations synchronously with proper locking"""
+ conn = sqlite3.connect(db_path)
+
+ # Use exclusive lock during migrations
+ conn.execute("BEGIN EXCLUSIVE")
+
+ try:
+ migrator = DatabaseMigrator(conn)
+ migrator.run_all()
+ conn.commit()
+ except Exception:
+ conn.rollback()
+ raise
+ finally:
+ conn.close()
+
+# Test base class
+class StarPunkTestCase(unittest.TestCase):
+ """Base test case with proper database isolation"""
+
+ def setUp(self):
+ """Set up test with isolated database"""
+ self.db_context = isolated_test_database()
+ self.db_path = self.db_context.__enter__()
+ self.app = create_app(database=self.db_path)
+ self.client = self.app.test_client()
+
+ def tearDown(self):
+ """Clean up test database"""
+ self.db_context.__exit__(None, None, None)
+
+# Example test with proper isolation
+class TestMigrations(StarPunkTestCase):
+ def test_migration_idempotency(self):
+ """Test that migrations can be run multiple times"""
+ # First run happens in setUp
+
+ # Second run should be safe
+ run_migrations_sync(self.db_path)
+
+ # Verify database state
+ with sqlite3.connect(self.db_path) as conn:
+ tables = conn.execute(
+ "SELECT name FROM sqlite_master WHERE type='table'"
+ ).fetchall()
+ self.assertIn(('notes',), tables)
+```
+
+#### Test Timing Improvements
+```python
+# starpunk/testing/wait.py
+import time
+from typing import Callable
+
+def wait_for_condition(
+ condition: Callable[[], bool],
+ timeout: float = 5.0,
+ interval: float = 0.1
+) -> bool:
+ """Wait for condition to become true"""
+ start = time.time()
+
+ while time.time() - start < timeout:
+ if condition():
+ return True
+ time.sleep(interval)
+
+ return False
+
+# Usage in tests
+def test_async_operation(self):
+ """Test with proper waiting"""
+ self.client.post('/notes', data={'content': 'Test'})
+
+ # Wait for indexing to complete
+ success = wait_for_condition(
+ lambda: search_index_updated(),
+ timeout=2.0
+ )
+ self.assertTrue(success)
+```
+
+### 2. Unicode Edge Cases in Slug Generation
+
+#### Problem
+Slug generation fails or produces invalid slugs for certain Unicode inputs, including emoji, RTL text, and combining characters.
+
+#### Current Issues
+- Emoji in titles break slug generation
+- RTL languages produce confusing slugs
+- Combining characters aren't normalized
+- Zero-width characters remain in slugs
+
+#### Solution
+```python
+# starpunk/utils/slugify.py
+import unicodedata
+import re
+
+def generate_slug(text: str, max_length: int = 50) -> str:
+ """Generate URL-safe slug from text with Unicode handling"""
+
+ if not text:
+ return generate_random_slug()
+
+ # Normalize Unicode (NFKD = compatibility decomposition)
+ text = unicodedata.normalize('NFKD', text)
+
+ # Remove non-ASCII characters but keep numbers and letters
+ text = text.encode('ascii', 'ignore').decode('ascii')
+
+ # Convert to lowercase
+ text = text.lower()
+
+ # Replace spaces and punctuation with hyphens
+ text = re.sub(r'[^a-z0-9]+', '-', text)
+
+ # Remove leading/trailing hyphens
+ text = text.strip('-')
+
+ # Collapse multiple hyphens
+ text = re.sub(r'-+', '-', text)
+
+ # Truncate to max length (at word boundary if possible)
+ if len(text) > max_length:
+ text = text[:max_length].rsplit('-', 1)[0]
+
+ # If we end up with empty string, generate random
+ if not text:
+ return generate_random_slug()
+
+ return text
+
+def generate_random_slug() -> str:
+ """Generate random slug when text-based generation fails"""
+ import random
+ import string
+
+ return 'note-' + ''.join(
+ random.choices(string.ascii_lowercase + string.digits, k=8)
+ )
+
+# Extended test cases
+TEST_CASES = [
+ ("Hello World", "hello-world"),
+ ("Hello 👋 World", "hello-world"), # Emoji removed
+ ("مرحبا بالعالم", "note-a1b2c3d4"), # Arabic -> random
+ ("Ĥëłłö Ŵöŕłđ", "hello-world"), # Diacritics removed
+ ("Hello\u200bWorld", "helloworld"), # Zero-width space
+ ("---Hello---", "hello"), # Multiple hyphens
+ ("123", "123"), # Numbers only
+ ("!@#$%", "note-x1y2z3a4"), # Special chars -> random
+ ("a" * 100, "a" * 50), # Truncation
+ ("", "note-r4nd0m12"), # Empty -> random
+]
+
+def test_slug_generation():
+ """Test slug generation with Unicode edge cases"""
+ for input_text, expected in TEST_CASES:
+ result = generate_slug(input_text)
+ if expected.startswith("note-"):
+ # Random slug - just check format
+ assert result.startswith("note-")
+ assert len(result) == 13
+ else:
+ assert result == expected
+```
+
+### 3. RSS Feed Memory Optimization
+
+#### Problem
+RSS feed generation for sites with thousands of notes causes high memory usage and slow response times.
+
+#### Current Issues
+- Loading all notes into memory at once
+- No pagination or limits
+- Inefficient XML building
+- No caching of generated feeds
+
+#### Solution
+```python
+# starpunk/feeds/rss.py
+from typing import Iterator
+import sqlite3
+
+class OptimizedRSSGenerator:
+ """Memory-efficient RSS feed generator"""
+
+ def __init__(self, base_url: str, limit: int = 50):
+ self.base_url = base_url
+ self.limit = limit
+
+ def generate_feed(self) -> str:
+ """Generate RSS feed with streaming"""
+ # Use string builder for efficiency
+ parts = []
+ parts.append(self._generate_header())
+
+ # Stream notes from database
+ for note in self._stream_recent_notes():
+ parts.append(self._generate_item(note))
+
+ parts.append(self._generate_footer())
+
+ return ''.join(parts)
+
+ def _stream_recent_notes(self) -> Iterator[dict]:
+ """Stream notes without loading all into memory"""
+ with get_db() as conn:
+ # Use server-side cursor equivalent
+ conn.row_factory = sqlite3.Row
+
+ cursor = conn.execute(
+ """
+ SELECT
+ id,
+ content,
+ slug,
+ created_at,
+ updated_at
+ FROM notes
+ WHERE published = 1
+ ORDER BY created_at DESC
+ LIMIT ?
+ """,
+ (self.limit,)
+ )
+
+ # Yield one at a time
+ for row in cursor:
+ yield dict(row)
+
+ def _generate_item(self, note: dict) -> str:
+ """Generate single RSS item efficiently"""
+ # Pre-calculate values once
+ title = extract_title(note['content'])
+ url = f"{self.base_url}/notes/{note['id']}"
+
+ # Use string formatting for efficiency
+ return f"""
+
{{ uptime }}
+{{ summary.http.count }}
+{{ summary.http.avg_ms|round(2) }}ms
+{{ current_memory }}MB
+| Time | +Duration | +Query | +
|---|---|---|
| {{ query.timestamp|timeago }} | +{{ query.duration_ms|round(2) }}ms | +{{ query.metadata.query|truncate(100) }} |
+
| Endpoint | +Calls | +Avg (ms) | +P95 (ms) | +P99 (ms) | +
|---|---|---|---|---|
| {{ endpoint }} | +{{ stats.count }} | +{{ stats.avg_ms|round(2) }} | +{{ stats.p95_ms|round(2) }} | +{{ stats.p99_ms|round(2) }} | +
HTML content
", + "date_published": "2025-11-25T10:00:00Z", + "date_modified": "2025-11-25T10:00:00Z" + } + ] +} +``` + +#### Acceptance Criteria +- [ ] Valid JSON Feed v1.1 output +- [ ] Passes JSON Feed Validator +- [ ] Proper HTML encoding in content_html +- [ ] ISO 8601 date formatting +- [ ] Auto-discovery link in HTML head +- [ ] Unit tests with full coverage + +### 3. Strict Microformats2 Support (v1.2.0) +**Status**: Planned +**Effort**: 10-16 hours +**Priority**: High (IndieWeb core requirement) + +#### Requirements +- Complete h-entry markup +- Author h-card implementation +- h-feed on index pages +- Backward compatible with existing CSS + +#### Implementation Scope + +##### h-entry (Enhanced) +Current state: +- ✅ h-entry class +- ✅ e-content +- ✅ dt-published +- ✅ u-url + +To add: +- [ ] p-name (extracted title) +- [ ] p-summary (excerpt generation) +- [ ] p-author (embedded h-card) +- [ ] p-category (when tags implemented) +- [ ] u-uid (unique identifier) + +##### h-card (New) +- [ ] p-name (author name from config) +- [ ] u-url (author URL from config) +- [ ] u-photo (optional avatar) +- [ ] p-note (optional bio) + +##### h-feed (New) +- [ ] h-feed wrapper on index +- [ ] p-name (site title) +- [ ] p-author (site-level h-card) +- [ ] Nested h-entry items + +#### Template Changes Required +1. `base.html` - Add author h-card in header/footer +2. `index.html` - Wrap notes in h-feed +3. `note.html` - Complete h-entry properties +4. New partial: `note_summary.html` for consistent markup + +#### Acceptance Criteria +- [ ] Passes microformats2 validator +- [ ] Parseable by IndieWeb tools +- [ ] XRay parser compatibility +- [ ] CSS remains functional +- [ ] No visual regression +- [ ] Documentation of all mf2 classes used + +## Testing Strategy + +### Feed Validation +1. W3C Feed Validator for ATOM +2. JSON Feed Validator for JSON +3. Microformats2 parser for HTML + +### Automated Tests +- Unit tests for feed generation +- Integration tests for endpoints +- Validation tests using external validators +- Regression tests for existing RSS + +### Manual Testing +- Multiple feed readers compatibility +- IndieWeb tools parsing +- Social readers integration + +## Dependencies + +### External Libraries +- feedgen (existing) - ATOM support included +- No new dependencies for JSON Feed +- No new dependencies for microformats2 + +### Configuration +- New config options for author info (h-card) +- Feed URLs in auto-discovery links + +## Migration Impact +- None - all features are additive +- Existing RSS feed unchanged +- No database changes required + +## Documentation Requirements +1. Update user guide with feed URLs +2. Document microformats2 markup +3. Add feed discovery information +4. Include validation instructions + +## Risk Assessment + +### Low Risk +- ATOM feed (uses existing library) +- JSON Feed (simple serialization) + +### Medium Risk +- Microformats2 (template complexity) +- CSS selector conflicts + +### Mitigation +- Incremental template changes +- Thorough CSS testing +- Use mf2 validators throughout + +## Success Metrics +- All feeds validate successfully +- No performance degradation +- Feed readers consume without errors +- IndieWeb tools parse correctly +- Zero visual regression in UI + +## References +- [RFC 4287 - ATOM](https://www.rfc-editor.org/rfc/rfc4287) +- [JSON Feed v1.1](https://www.jsonfeed.org/version/1.1/) +- [Microformats2](https://microformats.org/wiki/microformats2) +- [IndieWeb h-entry](https://indieweb.org/h-entry) +- [IndieWeb h-card](https://indieweb.org/h-card) \ No newline at end of file diff --git a/docs/releases/INDEX.md b/docs/releases/INDEX.md new file mode 100644 index 0000000..8fa56d6 --- /dev/null +++ b/docs/releases/INDEX.md @@ -0,0 +1,45 @@ +# Release Documentation Index + +This directory contains release-specific documentation, release notes, and version information. + +## Release Documentation + +- **[v1.0.1-hotfix-plan.md](v1.0.1-hotfix-plan.md)** - v1.0.1 hotfix plan and details + +## Release Process + +1. **Prepare Release** + - Update version numbers + - Update CHANGELOG.md + - Run full test suite + - Build container + +2. **Tag Release** + - Create git tag matching version + - Push tag to repository + +3. **Deploy** + - Build and push container image + - Deploy to production + - Monitor for issues + +4. **Announce** + - Post release notes + - Update documentation + - Notify users + +## Version History + +See [CHANGELOG.md](../../CHANGELOG.md) for complete version history. + +See [docs/projectplan/ROADMAP.md](../projectplan/ROADMAP.md) for future releases. + +## Related Documentation +- **[../standards/versioning-strategy.md](../standards/versioning-strategy.md)** - Versioning guidelines +- **[../standards/version-implementation-guide.md](../standards/version-implementation-guide.md)** - How to implement versions +- **[CHANGELOG.md](../../CHANGELOG.md)** - Change log + +--- + +**Last Updated**: 2025-11-25 +**Maintained By**: Documentation Manager Agent diff --git a/docs/reports/2025-11-24-endpoint-discovery-analysis.md b/docs/reports/2025-11-24-endpoint-discovery-analysis.md index e490f8d..266a89f 100644 --- a/docs/reports/2025-11-24-endpoint-discovery-analysis.md +++ b/docs/reports/2025-11-24-endpoint-discovery-analysis.md @@ -9,7 +9,7 @@ ## Executive Summary -I have reviewed the architect's corrected IndieAuth endpoint discovery design and the W3C IndieAuth specification. The design is fundamentally sound and correctly implements the IndieAuth specification. However, I have **critical questions** about implementation details, particularly around the "chicken-and-egg" problem of determining which endpoint to verify a token with when we don't know the user's identity beforehand. +I have reviewed the architect's corrected IndieAuth endpoint discovery design (ADR-043) and the W3C IndieAuth specification. The design is fundamentally sound and correctly implements the IndieAuth specification. However, I have **critical questions** about implementation details, particularly around the "chicken-and-egg" problem of determining which endpoint to verify a token with when we don't know the user's identity beforehand. **Overall Assessment**: The design is architecturally correct, but needs clarification on practical implementation details before coding can begin. @@ -148,7 +148,7 @@ The token is an opaque string like `"abc123xyz"`. We have no idea: - Which provider issued it - Which endpoint to verify it with -**ADR-030-CORRECTED suggests (line 204-258)**: +**ADR-043-CORRECTED suggests (line 204-258)**: ``` 4. Option A: If we have cached token info, use cached 'me' URL 5. Option B: Try verification with last known endpoint for similar tokens @@ -204,7 +204,7 @@ Please confirm this is correct or provide the proper approach. ### Question 2: Caching Strategy Details -**ADR-030-CORRECTED suggests** (line 131-160): +**ADR-043-CORRECTED suggests** (line 131-160): - Endpoint cache TTL: 3600s (1 hour) - Token verification cache TTL: 300s (5 minutes) @@ -363,7 +363,7 @@ The W3C spec says "first HTTP Link header takes precedence", which suggests **Op ### Question 5: URL Resolution and Validation -**From ADR-030-CORRECTED** line 217: +**From ADR-043-CORRECTED** line 217: ```python from urllib.parse import urljoin diff --git a/docs/reports/INDEX.md b/docs/reports/INDEX.md new file mode 100644 index 0000000..f24a632 --- /dev/null +++ b/docs/reports/INDEX.md @@ -0,0 +1,140 @@ +# Implementation Reports Index + +This directory contains implementation reports created by developers for architect review. Reports document completed work, implementation details, test results, and decisions made during development. + +## Report Format + +Reports typically include: +- **Date**: YYYY-MM-DD-description.md format +- **Summary**: What was implemented +- **Technical Details**: How it was implemented +- **Test Results**: Coverage and test outcomes +- **Issues Encountered**: Problems and solutions +- **Next Steps**: Follow-up tasks + +## All Reports (Chronological) + +### November 2025 + +#### v1.1.0 Implementation +- **[2025-11-25-v1.0.1-micropub-url-fix.md](2025-11-25-v1.0.1-micropub-url-fix.md)** - Micropub URL double-slash fix + +#### v1.0.0 Implementation & Fixes +- **[2025-11-24-v1.0.0-rc.5-implementation.md](2025-11-24-v1.0.0-rc.5-implementation.md)** - RC.5 implementation +- **[2025-11-24-phase1-indieauth-server-removal.md](2025-11-24-phase1-indieauth-server-removal.md)** - Custom IndieAuth server removal +- **[2025-11-24-indieauth-removal-complete.md](2025-11-24-indieauth-removal-complete.md)** - IndieAuth removal completion +- **[2025-11-24-endpoint-discovery-analysis.md](2025-11-24-endpoint-discovery-analysis.md)** - Endpoint discovery analysis +- **[2025-11-24-migration-fix-v1.0.0-rc.2.md](2025-11-24-migration-fix-v1.0.0-rc.2.md)** - Migration fix for RC.2 +- **[2025-11-24-migration-detection-hotfix-rc3.md](2025-11-24-migration-detection-hotfix-rc3.md)** - Migration detection hotfix + +#### Phase 5 Implementation +- **[2025-11-19-container-implementation-summary.md](2025-11-19-container-implementation-summary.md)** - Container deployment +- **[2025-11-19-migration-system-implementation-report.md](2025-11-19-migration-system-implementation-report.md)** - Migration system +- **[2025-11-19-migration-system-implementation-guidance.md](2025-11-19-migration-system-implementation-guidance.md)** - Migration guidance +- **[2025-11-19-migration-implementation-quick-reference.md](2025-11-19-migration-implementation-quick-reference.md)** - Quick reference + +#### Phase 1-4 Implementation +- **[2025-11-18-auth-redirect-loop-fix.md](2025-11-18-auth-redirect-loop-fix.md)** - Auth redirect loop resolution +- **[2025-11-18-quickfix-auth-loop.md](2025-11-18-quickfix-auth-loop.md)** - Quick fix implementation + +### Specific Feature Reports + +#### Authentication & IndieAuth +- **[indieauth-client-discovery-analysis.md](indieauth-client-discovery-analysis.md)** - Client discovery analysis +- **[indieauth-client-discovery-fix-implementation.md](indieauth-client-discovery-fix-implementation.md)** - Fix implementation +- **[indieauth-client-discovery-root-cause-analysis.md](indieauth-client-discovery-root-cause-analysis.md)** - Root cause +- **[indieauth-detailed-logging-implementation.md](indieauth-detailed-logging-implementation.md)** - Logging implementation +- **[indieauth-fix-summary.md](indieauth-fix-summary.md)** - Fix summary +- **[indieauth-removal-analysis.md](indieauth-removal-analysis.md)** - Removal analysis +- **[indieauth-removal-questions.md](indieauth-removal-questions.md)** - Q&A +- **[indieauth-spec-url-standardization-2025-11-24.md](indieauth-spec-url-standardization-2025-11-24.md)** - URL standardization + +#### Database & Migrations +- **[database-migration-conflict-diagnosis.md](database-migration-conflict-diagnosis.md)** - Conflict diagnosis +- **[migration-failure-diagnosis-v1.0.0-rc.1.md](migration-failure-diagnosis-v1.0.0-rc.1.md)** - Failure diagnosis +- **[migration-race-condition-fix-implementation.md](migration-race-condition-fix-implementation.md)** - Race condition fix +- **[v1.0.0-rc.5-migration-race-condition-implementation.md](v1.0.0-rc.5-migration-race-condition-implementation.md)** - RC.5 migration fix + +#### Micropub +- **[micropub-401-diagnosis.md](micropub-401-diagnosis.md)** - 401 error diagnosis +- **[micropub-v1-implementation-progress.md](micropub-v1-implementation-progress.md)** - Implementation progress + +#### Bug Fixes +- **[custom-slug-bug-diagnosis.md](custom-slug-bug-diagnosis.md)** - Custom slug bug +- **[custom-slug-bug-implementation.md](custom-slug-bug-implementation.md)** - Bug fix +- **[delete-nonexistent-note-error-analysis.md](delete-nonexistent-note-error-analysis.md)** - Delete error +- **[delete-route-404-fix-implementation.md](delete-route-404-fix-implementation.md)** - 404 fix +- **[delete-route-fix-summary.md](delete-route-fix-summary.md)** - Fix summary +- **[delete-route-implementation-spec.md](delete-route-implementation-spec.md)** - Implementation spec + +#### Testing +- **[2025-11-19-todo-test-updates.md](2025-11-19-todo-test-updates.md)** - Test updates +- **[test-failure-analysis-deleted-at-attribute.md](test-failure-analysis-deleted-at-attribute.md)** - Test failure analysis +- **[phase-4-test-fixes.md](phase-4-test-fixes.md)** - Phase 4 test fixes + +### Version-Specific Reports + +#### ADR Implementation +- **[ADR-025-implementation-report.md](ADR-025-implementation-report.md)** - ADR-025 implementation +- **[ADR-025-implementation-summary.md](ADR-025-implementation-summary.md)** - Summary +- **[ADR-025-versioning-guidance.md](ADR-025-versioning-guidance.md)** - Versioning guidance + +#### Phase Implementation +- **[phase-2.1-implementation-20251118.md](phase-2.1-implementation-20251118.md)** - Phase 2.1 +- **[phase-2-implementation-report.md](phase-2-implementation-report.md)** - Phase 2 +- **[phase-3-authentication-20251118.md](phase-3-authentication-20251118.md)** - Phase 3 +- **[phase-4-architectural-assessment-20251118.md](phase-4-architectural-assessment-20251118.md)** - Phase 4 assessment +- **[phase-5-container-implementation-report.md](phase-5-container-implementation-report.md)** - Phase 5 +- **[phase-5-pre-implementation-review.md](phase-5-pre-implementation-review.md)** - Pre-implementation review +- **[phase-5-rss-implementation-20251119.md](phase-5-rss-implementation-20251119.md)** - RSS implementation + +#### Version Releases +- **[v0.9.1-implementation-report.md](v0.9.1-implementation-report.md)** - v0.9.1 release +- **[v1.0.0-rc.1-hotfix-instructions.md](v1.0.0-rc.1-hotfix-instructions.md)** - RC.1 hotfix +- **[v1.1.0-implementation-plan.md](v1.1.0-implementation-plan.md)** - v1.1.0 plan +- **[v1.1.0-implementation-report.md](v1.1.0-implementation-report.md)** - v1.1.0 report + +### Special Reports +- **[ARCHITECT-FINAL-ANALYSIS.md](ARCHITECT-FINAL-ANALYSIS.md)** - Comprehensive architectural analysis +- **[implementation-guide-expose-deleted-at.md](implementation-guide-expose-deleted-at.md)** - Implementation guide +- **[oauth-metadata-implementation-2025-11-19.md](oauth-metadata-implementation-2025-11-19.md)** - OAuth metadata +- **[identity-domain-validation-2025-11-19.md](identity-domain-validation-2025-11-19.md)** - Identity validation +- **[setup-complete-2025-11-18.md](setup-complete-2025-11-18.md)** - Setup completion + +## How to Use Reports + +### For Architects +- Review reports to verify implementation quality +- Check that decisions align with ADRs +- Identify patterns for future standards + +### For Developers +- Learn from past implementations +- Find solutions to similar problems +- Understand implementation context + +### For Project Management +- Track implementation progress +- Understand what was delivered +- Plan future work based on lessons learned + +## Creating New Reports + +When completing work, create a report with: +1. **Filename**: `YYYY-MM-DD-brief-description.md` +2. **Summary**: What was done +3. **Implementation**: Technical details +4. **Testing**: Test results and coverage +5. **Issues**: Problems encountered and solutions +6. **Next Steps**: Follow-up tasks + +## Related Documentation +- **[../architecture/](../architecture/)** - System architecture +- **[../decisions/](../decisions/)** - ADRs referenced in reports +- **[../design/](../design/)** - Design specs implemented + +--- + +**Last Updated**: 2025-11-25 +**Maintained By**: Documentation Manager Agent +**Total Reports**: 57 diff --git a/docs/reports/v1.0.0-rc.5-migration-race-condition-implementation.md b/docs/reports/v1.0.0-rc.5-migration-race-condition-implementation.md index 7f94c45..2def5d7 100644 --- a/docs/reports/v1.0.0-rc.5-migration-race-condition-implementation.md +++ b/docs/reports/v1.0.0-rc.5-migration-race-condition-implementation.md @@ -254,7 +254,7 @@ Total startup: ~280ms ## Architectural Decisions Followed All implementation decisions follow architect's specifications from: -- `docs/decisions/ADR-022-migration-race-condition-fix.md` +- `docs/decisions/ADR-037-migration-race-condition-fix.md` - `docs/architecture/migration-race-condition-answers.md` (23 questions answered) - `docs/architecture/migration-fix-quick-reference.md` @@ -422,7 +422,7 @@ After deployment, monitor for: ## References -- ADR-022: Database Migration Race Condition Resolution +- ADR-037: Database Migration Race Condition Resolution - migration-race-condition-answers.md: Complete Q&A (23 questions) - migration-fix-quick-reference.md: Implementation checklist - migration-race-condition-fix-implementation.md: Detailed guide diff --git a/docs/reviews/INDEX.md b/docs/reviews/INDEX.md new file mode 100644 index 0000000..b220562 --- /dev/null +++ b/docs/reviews/INDEX.md @@ -0,0 +1,38 @@ +# Architectural Reviews Index + +This directory contains architectural reviews, design critiques, and retrospectives conducted by the architect agent. + +## Phase Reviews + +- **[phase-2-architectural-review.md](phase-2-architectural-review.md)** - Phase 2 architecture review +- **[phase-3-authentication-architectural-review.md](phase-3-authentication-architectural-review.md)** - Phase 3 authentication review +- **[phase-5-container-architectural-review.md](phase-5-container-architectural-review.md)** - Phase 5 container deployment review +- **[phase-5-approval-summary.md](phase-5-approval-summary.md)** - Phase 5 approval summary + +## Feature Reviews + +### Micropub +- **[micropub-phase1-architecture-review.md](micropub-phase1-architecture-review.md)** - Phase 1 Micropub review +- **[micropub-phase3-architecture-review.md](micropub-phase3-architecture-review.md)** - Phase 3 Micropub review + +### Error Handling +- **[error-handling-rest-vs-web-patterns.md](error-handling-rest-vs-web-patterns.md)** - REST vs Web error handling patterns + +## Purpose of Reviews + +Architectural reviews ensure: +- Design quality and consistency +- Adherence to standards +- Alignment with project philosophy +- Technical soundness +- Maintainability + +## Related Documentation +- **[../decisions/](../decisions/)** - ADRs resulting from reviews +- **[../architecture/](../architecture/)** - Architectural documentation +- **[../reports/](../reports/)** - Implementation reports + +--- + +**Last Updated**: 2025-11-25 +**Maintained By**: Documentation Manager Agent diff --git a/docs/security/INDEX.md b/docs/security/INDEX.md new file mode 100644 index 0000000..0f0f1f0 --- /dev/null +++ b/docs/security/INDEX.md @@ -0,0 +1,51 @@ +# Security Documentation Index + +This directory contains security-related documentation, vulnerability analyses, and security best practices. + +## Security Guides + +- **[indieauth-endpoint-discovery-security.md](indieauth-endpoint-discovery-security.md)** - Security considerations for IndieAuth endpoint discovery + +## Security Topics + +### Authentication & Authorization +- IndieAuth security +- Token management +- Session security + +### Data Protection +- Secure storage +- Encryption +- Data privacy + +### Network Security +- HTTPS enforcement +- Endpoint validation +- CSRF protection + +## Security Principles + +StarPunk follows these security principles: +- **Secure by Default**: Security is enabled by default +- **Minimal Attack Surface**: Fewer features mean fewer vulnerabilities +- **Defense in Depth**: Multiple layers of security +- **Fail Closed**: Deny access when uncertain +- **Principle of Least Privilege**: Minimal permissions by default + +## Reporting Security Issues + +If you discover a security vulnerability: +1. **Do NOT** create a public issue +2. Email security details to project maintainer +3. Allow time for patch before disclosure +4. Coordinated disclosure benefits everyone + +## Related Documentation +- **[../decisions/](../decisions/)** - Security-related ADRs +- **[../standards/](../standards/)** - Security coding standards +- **[../architecture/](../architecture/)** - Security architecture + +--- + +**Last Updated**: 2025-11-25 +**Maintained By**: Documentation Manager Agent diff --git a/docs/standards/INDEX.md b/docs/standards/INDEX.md new file mode 100644 index 0000000..97fa888 --- /dev/null +++ b/docs/standards/INDEX.md @@ -0,0 +1,169 @@ +# Standards Documentation Index + +This directory contains coding standards, conventions, processes, workflows, and best practices for StarPunk CMS development. + +## Core Standards + +### Code Quality +- **[python-coding-standards.md](python-coding-standards.md)** - Python code style, patterns, and best practices +- **[utility-function-patterns.md](utility-function-patterns.md)** - Patterns for writing utility functions + +### Testing +- **[testing-checklist.md](testing-checklist.md)** - Comprehensive testing checklist and requirements + +### Development Workflow +- **[development-setup.md](development-setup.md)** - Development environment setup guide +- **[git-branching-strategy.md](git-branching-strategy.md)** - Git workflow and branching model +- **[versioning-strategy.md](versioning-strategy.md)** - Semantic versioning guidelines +- **[version-implementation-guide.md](version-implementation-guide.md)** - How to implement version changes + +### Conventions +- **[cookie-naming-convention.md](cookie-naming-convention.md)** - Cookie naming standards +- **[documentation-organization.md](documentation-organization.md)** - Documentation structure and organization + +## Standards by Category + +### Python Development +- **python-coding-standards.md** - Style guide, linting, formatting +- **utility-function-patterns.md** - Reusable code patterns + +### Version Control & Release Management +- **git-branching-strategy.md** - Branch naming, workflow, PRs +- **versioning-strategy.md** - SemVer guidelines, version bumping +- **version-implementation-guide.md** - Step-by-step version changes + +### Quality Assurance +- **testing-checklist.md** - Test coverage requirements, test types + +### Development Environment +- **development-setup.md** - Local setup, dependencies, tools + +### Project Organization +- **documentation-organization.md** - Where to put what docs +- **cookie-naming-convention.md** - Naming consistency + +## How to Use These Standards + +### For New Developers +1. **Start here**: [development-setup.md](development-setup.md) +2. **Read**: [python-coding-standards.md](python-coding-standards.md) +3. **Understand**: [git-branching-strategy.md](git-branching-strategy.md) +4. **Reference**: Other standards as needed + +### Before Writing Code +- [ ] Review [python-coding-standards.md](python-coding-standards.md) +- [ ] Check [utility-function-patterns.md](utility-function-patterns.md) for reusable patterns +- [ ] Create feature branch per [git-branching-strategy.md](git-branching-strategy.md) + +### Before Committing Code +- [ ] Run tests per [testing-checklist.md](testing-checklist.md) +- [ ] Verify code follows [python-coding-standards.md](python-coding-standards.md) +- [ ] Update version if needed per [versioning-strategy.md](versioning-strategy.md) +- [ ] Write clear commit message per [git-branching-strategy.md](git-branching-strategy.md) + +### Before Creating PR +- [ ] All tests pass ([testing-checklist.md](testing-checklist.md)) +- [ ] Documentation updated ([documentation-organization.md](documentation-organization.md)) +- [ ] Version bumped if needed ([version-implementation-guide.md](version-implementation-guide.md)) +- [ ] PR follows [git-branching-strategy.md](git-branching-strategy.md) + +### When Reviewing Code +- [ ] Check adherence to [python-coding-standards.md](python-coding-standards.md) +- [ ] Verify test coverage per [testing-checklist.md](testing-checklist.md) +- [ ] Confirm naming conventions ([cookie-naming-convention.md](cookie-naming-convention.md)) +- [ ] Validate documentation ([documentation-organization.md](documentation-organization.md)) + +## Key Principles + +### Code Quality +- **Simplicity First**: "Every line of code must justify its existence" +- **Explicit Over Implicit**: Clear, readable code over clever tricks +- **Type Hints Required**: All functions must have type hints +- **Docstrings Required**: All public functions must have docstrings + +### Testing +- **Test-Driven Development**: Write tests before implementation +- **Coverage Requirements**: Minimum 80% coverage, aim for 90%+ +- **Test Types**: Unit, integration, and end-to-end tests +- **No Skipped Tests**: All tests must pass + +### Version Control +- **Feature Branches**: All work happens in feature branches +- **Atomic Commits**: One logical change per commit +- **Clear Messages**: Commit messages follow conventional commits format +- **No Direct Commits to Main**: All changes via pull requests + +### Versioning +- **Semantic Versioning**: MAJOR.MINOR.PATCH format +- **Version Bumping**: Update version in multiple locations consistently +- **Changelog Maintenance**: Document all user-facing changes +- **Tag Releases**: Git tags match version numbers + +## Standards Compliance Checklist + +Use this checklist for all code contributions: + +### Code Standards +- [ ] Follows Python coding standards +- [ ] Uses approved utility patterns +- [ ] Has type hints on all functions +- [ ] Has docstrings on all public functions +- [ ] Passes linting (flake8, black) + +### Testing Standards +- [ ] Unit tests written +- [ ] Integration tests if needed +- [ ] All tests pass +- [ ] Coverage meets minimum (80%) + +### Git Standards +- [ ] Feature branch created +- [ ] Commits are atomic +- [ ] Commit messages are clear +- [ ] PR description is complete + +### Versioning Standards +- [ ] Version updated if needed +- [ ] Changelog updated +- [ ] Version consistent across files +- [ ] Git tag created for releases + +### Documentation Standards +- [ ] Code documented +- [ ] README updated if needed +- [ ] ADR created if architectural +- [ ] Implementation report written + +## Enforcing Standards + +### Automated Enforcement +- **Pre-commit hooks**: Run linting and formatting +- **CI/CD pipeline**: Run tests and checks +- **Code review**: Human verification of standards + +### Manual Verification +- **Checklist review**: Use standards compliance checklist +- **Peer review**: Other developers verify adherence +- **Architect review**: For architectural changes + +## Updating Standards + +Standards are living documents that evolve: + +1. **Propose Change**: Create ADR documenting why +2. **Discuss**: Get team consensus +3. **Update Standard**: Modify the relevant standard document +4. **Announce**: Communicate the change to team +5. **Enforce**: Update CI/CD and tooling + +## Related Documentation +- **[../architecture/](../architecture/)** - System architecture +- **[../decisions/](../decisions/)** - Architectural Decision Records +- **[../design/](../design/)** - Feature designs +- **[../reports/](../reports/)** - Implementation reports + +--- + +**Last Updated**: 2025-11-25 +**Maintained By**: Documentation Manager Agent +**Total Standards**: 9