refactor(specs): restructure into archive/active pattern

- Move completed specs to specs/archive/
  - core-pipeline (v0.1.0 - initial implementation)
  - gcs-bigquery-storage (v0.1.0 - storage backend)
- Create specs/active/ for in-progress features
- Add READMEs explaining:
  - Workflow for new features
  - Archive contents and outcomes
  - Design decisions and learnings

This makes it clear what's done vs what's being designed, and
preserves design history for future reference.

Author: prosdev

specs/README.md

@@ -0,0 +1,96 @@
+# EventKit Specifications
+
+This directory contains design specifications for EventKit features.
+
+## Structure
+
+```
+specs/
+├── archive/     # Completed features (historical reference)
+├── active/      # Features currently being designed/implemented
+└── README.md    # This file
+```
+
+## Workflow
+
+### 1. Designing a New Feature
+
+Create a new spec in `active/`:
+
+```bash
+mkdir specs/active/feature-name
+```
+
+Typical structure:
+```
+specs/active/feature-name/
+├── spec.md       # What to build (user stories, requirements)
+├── plan.md       # How to build it (architecture, components)
+├── tasks.md      # Implementation checklist
+└── decisions.md  # Key design decisions (ADR-style)
+```
+
+### 2. During Implementation
+
+- Work from the spec
+- Update tasks.md as you complete work
+- Document any deviations or learnings
+
+### 3. After Completion
+
+Move to archive and reference in commit:
+
+```bash
+git mv specs/active/feature-name specs/archive/feature-name
+git commit -m "docs(specs): archive feature-name spec (closes #123)"
+```
+
+The spec becomes historical context for:
+- Understanding design decisions
+- Future refactoring
+- Learning how the system evolved
+
+## Archive Contents
+
+### core-pipeline (v0.1.0)
+Initial EventKit implementation covering:
+- Event schema models (RawEvent, TypedEvent)
+- Validation & adaptation (validators, adapters)
+- Stream-based routing (sequencer)
+- Storage abstraction (EventStore protocol)
+- Queue implementations (AsyncQueue, PubSubQueue)
+- Ring buffer with WAL (durability layer)
+- API endpoints (collection, convenience)
+
+**Status**: ✅ Complete
+**Timeline**: Q1 2025
+**Issues**: Core pipeline implementation
+
+### gcs-bigquery-storage (v0.1.0)
+GCS + BigQuery storage backend:
+- Parquet serialization
+- Hive-partitioned file structure
+- BigQuery loader (batch loading)
+- Warehouse integration
+
+**Status**: ✅ Complete
+**Timeline**: Q1 2025
+**Issues**: Storage implementation
+
+## Active Specs
+
+_No features currently in design phase._
+
+## Tips
+
+- **Keep specs lightweight** - Focus on decisions and design, not implementation details
+- **Reference issues** - Link specs to GitHub issues for tracking
+- **Archive when done** - Don't let specs rot in active/
+- **Living docs elsewhere** - Specs are design history; user docs live in README/ARCHITECTURE/Nextra
+
+## Related
+
+- [ARCHITECTURE.md](../ARCHITECTURE.md) - High-level system overview
+- [README.md](../README.md) - User-facing documentation
+- [CONTRIBUTING.md](../CONTRIBUTING.md) - Development workflow
+- [WORKFLOW.md](../WORKFLOW.md) - Spec-driven development process

specs/active/README.md

@@ -0,0 +1,40 @@
+# Active Specifications
+
+_No features currently in design phase._
+
+When you start designing a new feature:
+
+1. Create a directory: `mkdir specs/active/feature-name`
+2. Add your spec documents (spec.md, plan.md, tasks.md)
+3. Work from the spec during implementation
+4. Move to archive when complete
+
+## Template Structure
+
+```
+specs/active/feature-name/
+├── spec.md       # What to build
+│   - User stories
+│   - Requirements
+│   - Acceptance criteria
+│
+├── plan.md       # How to build it
+│   - Architecture
+│   - Components
+│   - Design decisions
+│
+├── tasks.md      # Implementation checklist
+│   - Detailed task breakdown
+│   - Acceptance criteria per task
+│   - Files to create/modify
+│
+└── decisions.md  # ADR-style decision log (optional)
+    - Context
+    - Options considered
+    - Decision rationale
+```
+
+## See Also
+
+- [Archive](../archive/) - Completed specs for reference
+- [WORKFLOW.md](../../WORKFLOW.md) - Spec-driven development process

specs/archive/core-pipeline/README.md

@@ -0,0 +1,48 @@
+# Core Pipeline (Archived)
+
+**Status**: ✅ Completed in v0.1.0
+**Timeline**: Q1 2025 (8 weeks)
+**Issues**: Initial implementation
+
+## What Was Built
+
+The foundational EventKit architecture covering:
+
+1. **Event Schema** - RawEvent (flexible) → TypedEvent (strict)
+2. **Validation & Adaptation** - Composable validators, Segment adapter
+3. **Stream Routing** - Hash-based sequencer for consistent partitioning
+4. **Queue Layer** - AsyncQueue (single-server) + PubSubQueue (distributed)
+5. **Storage** - EventStore protocol, GCS implementation
+6. **Ring Buffer** - SQLite WAL for durability
+7. **API** - Collection endpoints + Segment-compatible convenience endpoints
+8. **Observability** - Prometheus metrics, structured logging
+
+## Spec Documents
+
+- [spec.md](./spec.md) - User stories and requirements
+- [plan.md](./plan.md) - Architecture and implementation approach
+- [tasks.md](./tasks.md) - 17 tasks with detailed checklists
+- [architecture.md](./architecture.md) - System design
+- [api.md](./api.md) - API specification
+- [data-models.md](./data-models.md) - Schema definitions
+
+## Key Decisions
+
+1. **Flexible ingestion, strict processing** - Accept any JSON at edge, validate downstream
+2. **Protocol-based design** - All components use Protocol, not ABC
+3. **Async-first** - Full async/await throughout
+4. **Pluggable storage** - EventStore protocol enables multiple backends
+5. **Ring buffer for durability** - SQLite WAL prevents data loss
+
+## Outcomes
+
+- **252 unit tests** with >80% coverage
+- **10k+ events/sec** validated throughput
+- **Sub-millisecond** p50 latency
+- **Zero data loss** with ring buffer
+- **Production-ready** v0.1.0 release
+
+## Related
+
+- [GCS + BigQuery Storage](../gcs-bigquery-storage/) - Storage backend implementation
+- See [ARCHITECTURE.md](../../../ARCHITECTURE.md) for current system design

specs/core-pipeline/api.md specs/archive/core-pipeline/api.mdspecs/core-pipeline/api.md renamed to specs/archive/core-pipeline/api.md

@@ -0,0 +1,43 @@
+# GCS + BigQuery Storage (Archived)
+
+**Status**: ✅ Completed in v0.1.0
+**Timeline**: Q1 2025
+**Issues**: Storage implementation
+
+## What Was Built
+
+Production-grade storage backend using Google Cloud Platform:
+
+1. **GCS Event Store** - Write events to Cloud Storage as Parquet files
+2. **Hive Partitioning** - Date-based organization (date=YYYY-MM-DD/)
+3. **BigQuery Loader** - Background service for batch loading
+4. **Warehouse Integration** - Idempotent loads, metadata tracking
+5. **EventLoader** - Batching with adaptive flushing (time + size based)
+
+## Spec Documents
+
+- [spec.md](./spec.md) - Requirements and user stories
+- [plan.md](./plan.md) - Implementation approach
+- [tasks.md](./tasks.md) - Task breakdown
+- [data-model.md](./data-model.md) - Schema and partitioning
+
+## Key Decisions
+
+1. **GCS as event store** - Parquet for compression + columnar format
+2. **Batch loading** - Write to GCS, load to BigQuery in batches (cost-optimized)
+3. **Hive partitioning** - Date-based folders for efficient queries
+4. **Metadata table** - Track loaded files for idempotency
+5. **Adaptive batching** - Flush on time OR size threshold
+
+## Outcomes
+
+- **Parquet compression** - ~10x smaller than JSON
+- **Cost-efficient** - GCS storage 50% cheaper than BigQuery
+- **Idempotent loads** - Safe to retry without duplicates
+- **Query performance** - Date partitioning enables fast filters
+- **Flexible warehouse** - Can swap BigQuery for Snowflake/Redshift
+
+## Related
+
+- [Core Pipeline](../core-pipeline/) - Foundation EventKit built on
+- See [ARCHITECTURE.md](../../../ARCHITECTURE.md) for storage design