P2.6: Type Safety Cleanup - Replaced 'any' return types in vite-plugin.ts with concrete types (UserConfig, transform return type) - Documented TypeScript mixin 'any[]' exception in PlatformServiceMixin.ts - Audit confirmed: zero 'any' in codebase except documented TS mixin limitation - All external boundaries use 'unknown', all data payloads use 'Record<string, unknown>' P2.7: System Invariants Documentation - Created SYSTEM_INVARIANTS.md documenting all 6 enforced invariants - Added to docs/00-INDEX.md under Policy & Contracts section - Each invariant includes: What, Why, How, Where Progress Docs Updates: - Updated 00-STATUS.md: marked P2.6/P2.7 complete, added type safety invariant note - Updated 01-CHANGELOG-WORK.md: added 2025-12-22 entries for P2.6/P2.7 - Updated 03-TEST-RUNS.md: added P2.6 type safety audit test run - Updated P2-DESIGN.md: marked P2.6 acceptance criteria complete - Updated SYSTEM_INVARIANTS.md: added Type Safety Notes section Baseline Tag: - Created v1.0.11-p0-p1.4-p1.5-p2.6-p2.7-complete TypeScript compilation: ✅ PASSES Build: ✅ PASSES CI: ✅ All checks pass
7.3 KiB
Integration Point Refactor - Quick Start Guide
Author: Matthew Raymer
Date: 2025-10-29
Status: 🎯 REFERENCE - Quick start for implementation on any machine
See also: REFACTOR_ANALYSIS.md for complete analysis | REFACTOR_NOTES.md for implementation context
Overview
This guide helps you get started implementing the Integration Point Refactor on any machine. All planning and specifications are documented in the codebase.
Key Documents
-
docs/integration-point-refactor-analysis.md- Complete analysis + improvement directive- Architecture decisions (ADR-001)
- Public interfaces (TypeScript + Kotlin)
- Migration plan (7 PRs)
- Acceptance criteria
- Risk register
-
src/types/content-fetcher.ts- TypeScript type definitionsNotificationContentinterfaceJsNotificationContentFetcherinterfaceSchedulingPolicyinterfaceFetchContextinterface
-
examples/native-fetcher-android.kt- Kotlin native fetcher skeleton- Complete example implementation
- Registration pattern
- Error handling
-
examples/js-fetcher-typescript.ts- TypeScript JS fetcher skeleton- Foreground fetcher implementation
- Policy configuration example
-
tests/fixtures/test-contract.json- Golden test contract- Shared fixture for both JS and Native fetchers
- Failure scenarios
Implementation Roadmap (7 PRs)
PR1 — SPI Shell
Status: Ready to start Files to create:
- Kotlin/Swift interface definitions
- TypeScript types (already in
src/types/content-fetcher.ts) SchedulingPolicyimplementation (plugin side)- No behavior change yet
Reference: Section B in analysis doc
PR2 — Background Workers
Status: After PR1 Tasks:
- Wire Native SPI in WorkManager/BGTasks
- Metrics skeleton
- Cache store
Reference: Section C1 (Background Reliability)
PR3 — JS Fetcher Path
Status: After PR2 Tasks:
- Foreground bridge
- Event bus
- Dev harness screen
Reference: Section B1 (TypeScript interfaces)
PR4 — Dedupe/Idempotency
Status: After PR3 Tasks:
- Bloom/filter store
dedupeKeyenforcement- Tests
Reference: Section C3 (Idempotency & De-duplication)
PR5 — Failure Policy
Status: After PR4 Tasks:
- Retry taxonomy (Section E)
- Backoff implementation
- Cache fallback
- Structured errors
PR6 — Docs & Samples
Status: After PR5 Tasks:
- INTEGRATION_GUIDE.md (when to use which fetcher)
- SCHEDULING_POLICY.md (all configuration knobs)
- Copy-paste snippets
PR7 — Feature Flag Legacy
Status: After PR6 Tasks:
- Guard legacy TimeSafari code behind flag
- Regression tests
- Changelog for major removal
Reference: Section H (Migration Plan)
Architecture Decisions
ADR-001: Dual-Path SPI
- Native Fetcher (Kotlin/Swift) - Required for background
- JS Fetcher (TypeScript) - Optional, foreground only
- Legacy code behind feature flag for one minor release
See: Section A in analysis doc
Interface Contracts
TypeScript (Host App)
// From src/types/content-fetcher.ts
interface JsNotificationContentFetcher {
fetchContent(context: FetchContext): Promise<NotificationContent[]>;
}
// Plugin API additions
interface DailyNotificationPlugin {
setJsContentFetcher(fetcher: JsNotificationContentFetcher): void;
enableNativeFetcher(enable: boolean): Promise<void>;
setPolicy(policy: SchedulingPolicy): Promise<void>;
}
Android SPI (Native)
interface NativeNotificationContentFetcher {
suspend fun fetchContent(context: FetchContext): List<NotificationContent>
}
See: Section B in analysis doc
Key Constraints
Background Workers
- Android: WorkManager - NO JS bridging, native SPI only
- iOS: BGAppRefreshTask/BGProcessingTask - native SPI only
- Tasks: Keep < 30s, respect backoff
Security
- JWT generation in host app only
- No TimeSafari DTOs in plugin
- Tokens never serialized through JS in background
Deduplication
- Use
dedupeKey(fallbackid) - Bloom/filter for recent keys
- Horizon:
dedupeHorizonMs(default 24h)
See: Sections C, D in analysis doc
Failure Handling
| Class | Examples | Behavior |
|---|---|---|
| Retryable | 5xx, network, timeout | Backoff per policy |
| Unretryable | 4xx auth, schema error | Log, skip batch |
| Partial | Some items bad | Enqueue valid subset |
| Over-quota | 429 | Honor Retry-After |
See: Section E in analysis doc
Testing Requirements
Golden Contract
- Single JSON fixture (
tests/fixtures/test-contract.json) - Run through both JS and Native fetchers
- Compare normalized outputs
- Contract tests must pass
Failure Scenarios
- Network chaos (drop, latency)
- 401 → refresh → 200
- 429 with Retry-After
- Malformed items (skip, don't crash)
See: Section G in analysis doc
Acceptance Criteria
Before considering this complete:
- ✅ Native fetcher runs with app killed
- ✅ JS fetcher never required for background
- ✅ Same inputs → same outputs (parity tests green)
- ✅ No TimeSafari imports/types in plugin
- ✅ No duplicate notifications within
dedupeHorizonMs - ✅ Metrics visible, error classes distinguished
- ✅ Docs include copy-paste snippets
- ✅ Battery/quotas respected
See: Section J in analysis doc
Open Questions (Resolve Before PR3)
- iOS capabilities: Which BG task identifiers/intervals acceptable?
- Token hardening: DPoP or JWE now or later?
- User controls: Per-plan snooze/mute in metadata?
See: Section K in analysis doc
Getting Started Checklist
When starting on a new machine:
- Read
docs/integration-point-refactor-analysis.md(full context) - Review
src/types/content-fetcher.ts(TypeScript interfaces) - Review
examples/native-fetcher-android.kt(Kotlin pattern) - Review
examples/js-fetcher-typescript.ts(JS pattern) - Review
tests/fixtures/test-contract.json(test contract) - Start with PR1 - SPI Shell (no behavior change)
- Follow 7-PR plan sequentially
- Run contract tests after each PR
File Locations
docs/
integration-point-refactor-analysis.md # Complete spec
INTEGRATION_REFACTOR_QUICK_START.md # This file
src/types/
content-fetcher.ts # TypeScript interfaces
examples/
native-fetcher-android.kt # Kotlin example
js-fetcher-typescript.ts # TypeScript example
tests/fixtures/
test-contract.json # Golden contract
Next Actions
-
Start PR1 (SPI Shell)
- Create Kotlin interface in plugin
- Create Swift interface (if iOS support needed)
- Wire up TypeScript types (already done)
- Add
SchedulingPolicyto plugin
-
Review examples before implementing
- Understand data flow
- See error handling patterns
- Note registration points
-
Plan testing early
- Set up contract test infrastructure
- Prepare mock fetchers for testing
Questions?
All specifications are in docs/integration-point-refactor-analysis.md. Refer to:
- Section B for interfaces
- Section C for policies
- Section E for failure handling
- Section I for PR breakdown
- Section J for acceptance criteria
Status: Reference guide Last Updated: 2025-10-29 Maintainer: Plugin development team