# Developer Q&A for StarPunk v1.1.2 "Syndicate"

**Developer**: StarPunk Fullstack Developer
**Date**: 2025-11-25
**Purpose**: Pre-implementation questions for architect review

## Document Overview

This document contains questions identified during the design review of v1.1.2 "Syndicate" specifications. Questions are organized by priority to help the architect focus on blocking issues first.

---

## Critical Questions (Must be answered before implementation)

These questions address blocking issues, unclear requirements, integration points, and major technical decisions that prevent implementation from starting.

### CQ1: Database Instrumentation Integration

**Question**: How should the MonitoredConnection wrapper integrate with the existing database pool implementation?

**Context**:
- The spec shows a `MonitoredConnection` class that wraps SQLite connections (metrics-instrumentation-spec.md, lines 60-114)
- We currently have a connection pool in `starpunk/database/pool.py`
- The spec doesn't clarify whether we:
  1. Wrap the pool's `get_connection()` method to return wrapped connections
  2. Replace the pool's connection creation logic
  3. Modify the pool class itself to include monitoring

**Current Understanding**:
- I see we have `starpunk/database/pool.py` which manages connections
- The spec suggests wrapping individual connection's `execute()` method
- But unclear how this fits with the pool's lifecycle management

**Impact**:
- Affects database module architecture
- Determines whether pool needs refactoring
- May affect existing database queries throughout codebase

**Proposed Approach**:
Wrap connections at pool level by modifying `get_connection()` to return `MonitoredConnection(real_conn, metrics_collector)`. Is this correct?

---

### CQ2: Metrics Collector Lifecycle and Initialization

**Question**: When and where should the global MetricsCollector instance be initialized, and how should it be passed to all monitoring components?

**Context**:
- Multiple components need access to the same collector (metrics-instrumentation-spec.md):
  - MonitoredConnection (database)
  - HTTPMetricsMiddleware (Flask)
  - MemoryMonitor (background thread)
  - SyndicationMetrics (business metrics)
- No specification for initialization order or dependency injection strategy
- Flask app initialization happens in `app.py` but monitoring setup is unclear

**Current Understanding**:
- Need a single collector instance shared across all components
- Should probably initialize during Flask app setup
- But unclear if it should be:
  - App config attribute: `app.metrics_collector`
  - Global module variable: `from starpunk.monitoring import metrics_collector`
  - Passed via dependency injection to all modules

**Impact**:
- Affects application initialization sequence
- Determines module coupling and testability
- Affects how metrics are accessed in route handlers

**Proposed Approach**:
Create collector during Flask app factory, store as `app.metrics_collector`, and pass to monitoring components during setup. Is this the intended pattern?

---

### CQ3: Content Negotiation vs. Explicit Format Endpoints

**Question**: Should we support BOTH explicit format endpoints (`/feed.rss`, `/feed.atom`, `/feed.json`) AND content negotiation on `/feed`, or only content negotiation?

**Context**:
- ADR-054 section 3 chooses "Content Negotiation" as the preferred approach (lines 155-162)
- But the architecture diagram (v1.1.2-syndicate-architecture.md) shows "HTTP Request Layer" with "Content Negotiator"
- Implementation guide (lines 586-592) shows both explicit URLs AND a `/feed` endpoint
- feed-enhancements-spec.md (line 342) shows a `/feed.<format>` route pattern

**Current Understanding**:
- ADR-054 prefers content negotiation for standards compliance
- But examples show explicit `.atom`, `.json` extensions working
- Unclear if we should implement both for compatibility

**Impact**:
- Affects route definition strategy
- Changes URL structure for feeds
- Determines whether to maintain backward compatibility URLs

**Proposed Approach**:
Implement both: `/feed.xml` (existing), `/feed.atom`, `/feed.json` for explicit access, PLUS `/feed` with content negotiation as the primary endpoint. Keep `/feed.xml` working for backward compatibility. Is this correct?

---

### CQ4: Cache Checksum Calculation Strategy

**Question**: Should the cache checksum include ALL notes or only the notes that will appear in the feed (respecting the limit)?

**Context**:
- feed-enhancements-spec.md shows checksum based on "latest note timestamp and count" (lines 317-325)
- But feeds are limited (default 50 items)
- If someone publishes note #51, does that invalidate cache for format with limit=50?

**Current Understanding**:
- Checksum based on: latest timestamp + total count + config
- But this means cache invalidates even if new note wouldn't appear in limited feed
- Could be wasteful regeneration

**Impact**:
- Affects cache hit rates
- Determines when feeds actually need regeneration
- May impact performance goals (>80% cache hit rate)

**Proposed Approach**:
Use checksum based on the latest timestamp of notes that WOULD appear in feed (i.e., first N notes), not all notes. Is this the intent, or should we invalidate for ANY new note?

---

### CQ5: Memory Monitor Thread Lifecycle

**Question**: How should the MemoryMonitor thread be started, stopped, and managed during application lifecycle (startup, shutdown, restarts)?

**Context**:
- metrics-instrumentation-spec.md shows `MemoryMonitor(Thread)` with daemon flag (line 206)
- Background thread needs to be started during app initialization
- But Flask app lifecycle unclear:
  - When to start thread?
  - How to handle graceful shutdown?
  - What about development reloader (Flask debug mode)?

**Current Understanding**:
- Daemon thread will auto-terminate when main process exits
- But no specification for:
  - Starting thread after Flask app created
  - Preventing duplicate threads in debug mode
  - Cleanup on shutdown

**Impact**:
- Affects application stability
- Determines proper shutdown behavior
- May cause issues in development with auto-reload

**Proposed Approach**:
Start thread after Flask app initialized, set daemon=True, store reference in `app.memory_monitor`, implement `app.teardown_appcontext` cleanup. Should we prevent thread start in test mode?

---

### CQ6: Feed Generator Streaming Implementation

**Question**: For ATOM and JSON Feed generators, should we implement BOTH a complete generation method (`generate()`) and streaming method (`generate_streaming()`), or only streaming?

**Context**:
- ADR-054 states "Streaming Generation" is the chosen approach (lines 22-33)
- But atom-feed-specification.md shows `generate()` returning `Iterator[str]` (line 128)
- JSON Feed spec shows both `generate()` returning complete string AND `generate_streaming()` (lines 188-221)
- Existing RSS implementation has both methods (feed.py lines 32-126 and 129-227)

**Current Understanding**:
- ADR says streaming is the architecture decision
- But implementation may need both for:
  - Caching (need complete string to store)
  - Streaming response (memory efficient)
- Unclear if cache should store complete feeds or not cache at all

**Impact**:
- Affects generator interface design
- Determines cache strategy (can't cache generators)
- Memory efficiency trade-offs

**Proposed Approach**:
Implement both like existing RSS: `generate()` for complete feed (used with caching), `generate_streaming()` for memory-efficient streaming. Cache stores complete strings from `generate()`. Is this correct?

---

### CQ7: Content Negotiation Default Format

**Question**: What format should be returned if content negotiation fails or client provides no preference?

**Context**:
- feed-enhancements-spec.md shows default to 'rss' (line 106)
- But also shows checking `available_formats` (lines 88-106)
- What if RSS is disabled in config? Should we:
  1. Always default to RSS even if disabled
  2. Default to first enabled format
  3. Return 406 Not Acceptable

**Current Understanding**:
- RSS seems to be the universal default
- But config allows disabling formats (architecture doc lines 257-259)
- Edge case: all formats disabled or only one enabled

**Impact**:
- Affects error handling strategy
- Determines configuration validation requirements
- User experience for misconfigured systems

**Proposed Approach**:
Default to RSS if enabled, else first enabled format alphabetically. Validate at startup that at least one format is enabled. Return 406 if all disabled and no Accept match. Is this acceptable?

---

### CQ8: OPML Generator Endpoint Location

**Question**: Where should the OPML export endpoint be located, and should it require admin authentication?

**Context**:
- implementation-guide.md shows route as `/feeds.opml` (line 492)
- feed-enhancements-spec.md shows `export_opml()` function (line 492)
- But no specification whether it's:
  - Public endpoint (anyone can access)
  - Admin-only endpoint
  - Part of public routes or admin routes

**Current Understanding**:
- OPML is just a list of feed URLs
- Nothing sensitive in the data
- But unclear if it should be public or admin feature

**Impact**:
- Determines route registration location
- Affects security/access control decisions
- May influence feature discoverability

**Proposed Approach**:
Make `/feeds.opml` a public endpoint (no auth required) since it only exposes feed URLs which are already public. Place in `routes/public.py`. Is this correct?

---

## Important Questions (Should be answered for Phase 1)

These questions address implementation details, performance considerations, testing approaches, and error handling that are important but not blocking.

### IQ1: Database Query Pattern Detection Accuracy

**Question**: How robust should the table name extraction be in `MonitoredConnection._extract_table_name()`?

**Context**:
- metrics-instrumentation-spec.md shows regex patterns for common cases (lines 107-113)
- Comment says "Simple regex patterns" with "Implementation details..."
- Real SQL can be complex (JOINs, subqueries, CTEs)

**Current Understanding**:
- Basic regex for FROM, INTO, UPDATE patterns
- Won't handle complex queries perfectly
- Unclear if we should:
  1. Keep it simple (basic patterns only)
  2. Use SQL parser library (more accurate)
  3. Return "unknown" for complex queries

**Impact**:
- Affects metrics usefulness (how often is table "unknown"?)
- Determines dependencies (SQL parser adds complexity)
- Testing complexity

**Proposed Approach**:
Implement simple regex for 90% case, return "unknown" for complex queries. Document limitation. Consider SQL parser library as future enhancement if needed. Acceptable?

---

### IQ2: HTTP Metrics Request ID Generation

**Question**: Should request IDs be exposed in response headers for client debugging, and should they be logged?

**Context**:
- metrics-instrumentation-spec.md generates request_id (line 151)
- But doesn't specify if it should be:
  - Returned in response headers (X-Request-ID)
  - Logged for correlation
  - Only internal

**Current Understanding**:
- Request ID useful for debugging
- Common pattern to return in header
- Could help correlate client issues with server logs

**Impact**:
- Affects HTTP response headers
- Logging strategy decisions
- Debugging capabilities

**Proposed Approach**:
Generate UUID for each request, store in `g.request_id`, add `X-Request-ID` response header, include in error logs. Only in debug mode or always? What do you prefer?

---

### IQ3: Slow Query Threshold Configuration

**Question**: Should the slow query threshold (1 second) be configurable, and should it differ by query type?

**Context**:
- metrics-instrumentation-spec.md has hardcoded 1.0 second threshold (line 86)
- Configuration shows `STARPUNK_METRICS_SLOW_QUERY_THRESHOLD=1.0` (line 422)
- But some queries might reasonably be slower (full table scans for admin)

**Current Understanding**:
- 1 second is reasonable default
- But different operations have different expectations:
  - SELECT with full scan: maybe 2s is okay
  - INSERT: should be fast, 0.5s threshold?
- Unclear if one threshold fits all

**Impact**:
- Affects slow query alert noise
- Determines configuration complexity
- May need query-type-specific thresholds

**Proposed Approach**:
Start with single configurable threshold (1 second default). Add query-type-specific thresholds as v1.2 enhancement if needed. Sound reasonable?

---

### IQ4: Feed Cache Invalidation Timing

**Question**: Should cache invalidation happen synchronously when a note is published/updated, or should we rely solely on TTL expiration?

**Context**:
- feed-enhancements-spec.md shows `invalidate()` method (lines 273-288)
- But unclear WHEN to call it
- Options:
  1. Call on note create/update/delete (immediate invalidation)
  2. Rely only on TTL (simpler, 5-minute lag)
  3. Hybrid: invalidate on note changes, TTL as backup

**Current Understanding**:
- Checksum-based cache keys mean new notes create new cache entries naturally
- TTL handles expiration automatically
- Manual invalidation may be redundant

**Impact**:
- Affects feed freshness (how quickly new notes appear)
- Code complexity (invalidation hooks vs. simple TTL)
- Cache hit rates

**Proposed Approach**:
Rely on checksum + TTL without manual invalidation. New notes change checksum (new cache key), old entries expire via TTL. Simpler and sufficient. Agree?

---

### IQ5: Statistics Dashboard Chart Library

**Question**: Which JavaScript chart library should be used for the syndication dashboard graphs?

**Context**:
- implementation-guide.md shows Chart.js example (line 598-610)
- feed-enhancements-spec.md also shows Chart.js (lines 599-609)
- But we may already use a chart library elsewhere in the admin UI

**Current Understanding**:
- Chart.js is simple and popular
- But adds a dependency
- Need to check if admin UI already uses charts

**Impact**:
- Determines JavaScript dependencies
- Affects admin UI consistency
- Bundle size considerations

**Proposed Approach**:
Check current admin UI for existing chart library. If none, use Chart.js (lightweight, simple). If we already use something else, use that. Need to review admin templates first. Should I?

---

### IQ6: ATOM Content Type Selection Logic

**Question**: How should the ATOM generator decide between `type="text"`, `type="html"`, and `type="xhtml"` for content?

**Context**:
- atom-feed-specification.md shows three content types (lines 283-306)
- Implementation shows checking `note.html` existence (lines 205-214)
- But doesn't specify when to use XHTML (marked as "Future")

**Current Understanding**:
- If `note.html` exists: use `type="html"` with escaping
- If only plain text: use `type="text"`
- XHTML type is deferred to future

**Impact**:
- Affects content rendering in feed readers
- Determines XML structure
- XHTML support complexity

**Proposed Approach**:
For v1.1.2, only implement `type="text"` (escaped) and `type="html"` (escaped). Skip `type="xhtml"` for now. Document as future enhancement. Is this acceptable?

---

### IQ7: JSON Feed Custom Extensions Scope

**Question**: What should go in the `_starpunk` custom extension besides permalink_path and word_count?

**Context**:
- json-feed-specification.md shows custom extension (lines 290-293)
- Only includes `permalink_path` and `word_count`
- But we could include other StarPunk-specific data:
  - Note slug
  - Note UUID
  - Tags (though tags are in standard `tags` field)
  - Syndication targets

**Current Understanding**:
- Minimal extension with just basic metadata
- Unclear if we should add more StarPunk-specific fields
- JSON Feed spec allows any custom fields with underscore prefix

**Impact**:
- Affects feed schema evolution
- API stability considerations
- Client compatibility

**Proposed Approach**:
Keep it minimal for v1.1.2 (just permalink_path and word_count as shown). Add more fields in v1.2 if user feedback requests them. Document extension schema. Agree?

---

### IQ8: Memory Monitor Baseline Timing

**Question**: The memory monitor waits 5 seconds for baseline (metrics-instrumentation-spec.md line 217). Is this sufficient for Flask app initialization?

**Context**:
- App initialization involves:
  - Database connection pool creation
  - Template loading
  - Route registration
  - First request may trigger additional loading
- 5 seconds may not capture "steady state"

**Current Understanding**:
- Baseline needed to calculate growth rate
- 5 seconds is arbitrary
- First request often allocates more memory (template compilation, etc.)

**Impact**:
- Affects memory leak detection accuracy
- False positives if baseline too early
- Determines monitoring reliability

**Proposed Approach**:
Wait 5 seconds PLUS wait for first HTTP request completion before setting baseline. This ensures app is "warmed up". Does this make sense?

---

### IQ9: Feed Validation Integration

**Question**: Should feed validation be:
1. Automatic on every generation (validates output)
2. Manual via admin endpoint
3. Only in tests

**Context**:
- implementation-guide.md mentions validation framework (lines 332-365)
- Validators for each format (RSS, ATOM, JSON)
- But unclear if validation runs in production or just tests

**Current Understanding**:
- Validation adds overhead
- Useful for testing and development
- But may be too slow for production

**Impact**:
- Performance impact on feed generation
- Error handling strategy (what if validation fails?)
- Development/debugging workflow

**Proposed Approach**:
Implement validators for testing only. Optionally enable in debug mode. Add admin endpoint `/admin/validate-feeds` for manual validation. Skip in production for performance. Sound good?

---

### IQ10: Syndication Statistics Retention

**Question**: The architecture doc mentions 7-day retention (line 279), but how should old statistics be pruned?

**Context**:
- SyndicationStats collects metrics in memory (feed-enhancements-spec.md lines 387-478)
- Uses deque with maxlen for some data (errors)
- But counters and histograms grow unbounded
- 7-day retention mentioned but no pruning mechanism shown

**Current Understanding**:
- In-memory stats grow over time
- Need periodic cleanup or rotation
- But no specification for HOW to prune

**Impact**:
- Memory leak potential
- Data accuracy over time
- Dashboard performance with large datasets

**Proposed Approach**:
Add timestamp to all metrics, implement periodic cleanup (daily cron-like task) to remove data older than 7 days. Store in time-bucketed structure for efficient pruning. Is this the right approach?

---

## Nice-to-Have Clarifications (Can defer if needed)

These questions address optimizations, future enhancements, and documentation details that don't block implementation.

### NH1: Performance Benchmark Automation

**Question**: Should performance benchmarks be automated in CI/CD, or just manual developer tests?

**Context**:
- Multiple specs include benchmark examples
- atom-feed-specification.md has benchmark functions (lines 458-489)
- But unclear if these should run in CI

**Current Understanding**:
- Benchmarks help ensure performance targets met
- But may be flaky in CI environment
- Could add to test suite but not as gate

**Impact**:
- CI/CD pipeline complexity
- Performance regression detection
- Development workflow

**Proposed Approach**:
Create benchmark test suite, mark as `@pytest.mark.benchmark`, run manually or optionally in CI. Don't block merges on benchmark results. Make it opt-in. Acceptable?

---

### NH2: Feed Format Feature Parity

**Question**: Should all three formats (RSS, ATOM, JSON) expose exactly the same data, or can they differ based on format capabilities?

**Context**:
- RSS: Basic fields (title, description, link, date)
- ATOM: Richer (author objects, categories, updated vs published)
- JSON: Most flexible (attachments, custom extensions)

**Current Understanding**:
- Each format has different capabilities
- Should we limit to common denominator or leverage format strengths?

**Impact**:
- User experience varies by format choice
- Implementation complexity
- Testing matrix

**Proposed Approach**:
Leverage format strengths: include author in ATOM, custom extensions in JSON, keep RSS basic. Document differences in feed format comparison. Users can choose based on needs. Okay?

---

### NH3: Content Negotiation Quality Factor Scoring

**Question**: The negotiation algorithm (feed-enhancements-spec.md lines 141-166) shows wildcard scoring. Should we support more nuanced quality factor logic?

**Context**:
- Current logic: exact=1.0, wildcard=0.1, type/*=0.5
- Quality factors multiply these scores
- But clients might send complex preferences like:
  `application/atom+xml;q=0.9, application/rss+xml;q=0.8, application/json;q=0.7`

**Current Understanding**:
- Simple scoring algorithm shown
- May not handle all edge cases
- But probably good enough for feed readers

**Impact**:
- Content negotiation accuracy
- Complex client preference handling
- Testing complexity

**Proposed Approach**:
Keep simple algorithm as specified. If real-world edge cases emerge, enhance in v1.2. Log negotiation decisions in debug mode for troubleshooting. Sufficient?

---

### NH4: Cache Statistics Persistence

**Question**: Should cache statistics survive application restarts?

**Context**:
- feed-enhancements-spec.md shows in-memory stats (lines 213-220)
- Stats reset on restart
- Dashboard shows historical data

**Current Understanding**:
- All stats in memory (lost on restart)
- Simplest implementation
- But loses historical trends

**Impact**:
- Historical analysis capability
- Dashboard usefulness over time
- Storage complexity if we add persistence

**Proposed Approach**:
Keep stats in memory for v1.1.2. Document that stats reset on restart. Consider SQLite persistence in v1.2 if users request it. Defer for now?

---

### NH5: Feed Reader User Agent Detection Patterns

**Question**: The regex patterns for user agent normalization (feed-enhancements-spec.md lines 459-476) are basic. Should we use a user-agent parsing library?

**Context**:
- Simple regex patterns for common readers
- But user agents can be complex and varied
- Libraries like `user-agents` exist

**Current Understanding**:
- Regex covers major feed readers
- Library adds dependency
- Trade-off: accuracy vs. simplicity

**Impact**:
- Statistics accuracy
- Dependencies
- Maintenance burden (regex needs updates)

**Proposed Approach**:
Start with regex patterns, log unknown user agents, update patterns as needed. Add library later if regex becomes unmaintainable. Star with simple. Okay?

---

### NH6: OPML Multiple Feed Organization

**Question**: Should OPML export support grouping feeds by category or just flat list?

**Context**:
- Current spec shows flat outline list (feed-enhancements-spec.md lines 707-723)
- OPML supports nested outlines for categorization
- Could group by format: "RSS Feeds", "ATOM Feeds", "JSON Feeds"

**Current Understanding**:
- Flat list is simplest
- Three feeds (RSS, ATOM, JSON) probably don't need grouping
- But OPML spec supports it

**Impact**:
- OPML complexity
- User experience in feed readers
- Future extensibility (custom feeds)

**Proposed Approach**:
Keep flat list for v1.1.2 (just 3 feeds). Add optional grouping in v1.2 if we add custom feeds or filters. YAGNI for now. Agree?

---

### NH7: Streaming Chunk Size Optimization

**Question**: The architecture doc mentions 4KB chunk size (line 253). Should this be configurable or optimized per format?

**Context**:
- ADR-054 specifies 4KB streaming chunks (line 253)
- But different formats have different structure:
  - RSS/ATOM: XML entries vary in size
  - JSON: Object-based structure
- May want format-specific chunk strategies

**Current Understanding**:
- 4KB is reasonable default
- Generators yield semantic chunks (whole items), not byte chunks
- HTTP layer may buffer differently anyway

**Impact**:
- Memory efficiency trade-offs
- Network performance
- Implementation complexity

**Proposed Approach**:
Don't enforce strict 4KB chunks. Let generators yield semantic units (complete entries/items). Let Flask/HTTP layer handle buffering. Document approximate chunk sizes. Flexible approach okay?

---

### NH8: Error Handling for Feed Generation Failures

**Question**: What should happen if feed generation fails midway through streaming?

**Context**:
- Streaming sends response headers immediately
- If error occurs mid-stream, headers already sent
- Can't return 500 status code at that point

**Current Understanding**:
- Streaming commits to response early
- Errors mid-stream are problematic
- Need error handling strategy

**Impact**:
- Error recovery UX
- Client handling of partial feeds
- Logging and alerting

**Proposed Approach**:
1. Validate inputs before streaming starts
2. If error mid-stream, log error and truncate feed (may be invalid XML/JSON)
3. Monitor error logs for generation failures
4. Consider pre-generating to memory if errors are common (defeats streaming)

Is this acceptable, or should we always generate to memory first?

---

### NH9: Metrics Dashboard Auto-Refresh

**Question**: Should the syndication dashboard auto-refresh, and if so, at what interval?

**Context**:
- Dashboard shows live statistics (feed-enhancements-spec.md lines 483-611)
- Stats change as requests come in
- But no auto-refresh specified

**Current Understanding**:
- Manual refresh okay for admin UI
- Auto-refresh could be nice
- But adds JavaScript complexity

**Impact**:
- User experience for monitoring
- JavaScript dependencies
- Server load (polling)

**Proposed Approach**:
No auto-refresh for v1.1.2. Admin can manually refresh browser. Add auto-refresh in v1.2 if requested. Keep it simple. Fine?

---

### NH10: Configuration Validation for Feed Settings

**Question**: Should feed configuration be validated at startup (fail-fast), or allow invalid config with runtime errors?

**Context**:
- Many new config options (implementation-guide.md lines 549-563)
- Some interdependent (ENABLED flags, cache sizes, TTLs)
- Current `validate_config()` in config.py validates basics

**Current Understanding**:
- Config validation exists for core settings
- Need to extend for feed settings
- But unclear how strict to be

**Impact**:
- Error discovery timing (startup vs. runtime)
- Configuration flexibility
- Development experience

**Proposed Approach**:
Add feed config validation to `validate_config()`:
- At least one format enabled
- Positive integers for cache size, TTL, limits
- Warn if cache TTL very short (<60s) or very long (>3600s)
- Fail fast on startup

Is this the right level of validation?

---

## Summary and Next Steps

**Total Questions**: 30
- Critical (blocking): 8
- Important (Phase 1): 10
- Nice-to-Have (deferrable): 12

**Priority for Architect**:
1. Answer critical questions first (CQ1-CQ8) - these block implementation start
2. Review important questions (IQ1-IQ10) - needed for Phase 1 quality
3. Nice-to-have questions (NH1-NH10) - can defer or apply judgment

**Developer's Current Understanding**:
After thorough review of all specifications, I understand the overall architecture and design intent. The questions primarily focus on:
- Integration points with existing code
- Ambiguities in specifications
- Edge cases and error handling
- Configuration and lifecycle management
- Trade-offs between simplicity and features

**Ready to Implement**:
Once critical questions are answered, I can begin Phase 1 implementation (Metrics Instrumentation) with confidence. The important questions can be answered during Phase 1 development, and nice-to-have questions can be deferred.

**Request to Architect**:
Please prioritize answering CQ1-CQ8 first. For the others, feel free to provide brief guidance or "use your judgment" if the answer is obvious. I'll create follow-up questions document after Phase 1 if new issues emerge.

Thank you for the thorough design documentation - it makes implementation much clearer!
