Implemented OpenSpec and created and updated its artifacts

openspec/changes/archive/2026-10-31-document-project-baseline/specs/preferences-cache/spec.md

@@ -0,0 +1,44 @@
+## Purpose
+
+Preserve user preferences and reuse eligible data without allowing expired or invalidated results to silently replace fresh information.
+
+## ADDED Requirements
+
+### Requirement: Preferences survive reopening
+The extension SHALL persist supported filter preferences, theme, opportunity type selections and cache duration in the browser profile. Invalid or unavailable stored values SHALL fall back to usable defaults or in-memory state.
+
+#### Scenario: Stored preference cannot be read
+- **WHEN** browser storage is unavailable or a saved preference is invalid
+- **THEN** the extension remains usable with its fallback rather than failing to open
+
+### Requirement: Sort preferences belong to individual tables
+Supported sortable tables SHALL retain their own last sort key and direction without changing other tables' preferences. Product detail tables SHALL remain excluded from this sorting behavior.
+
+#### Scenario: Two tables use different sorts
+- **WHEN** the user sorts Installed Base by amount and contact opportunities by close date
+- **THEN** reopening each table restores its own saved ordering
+
+### Requirement: Cache reuse respects validity and identity boundaries
+Product, workload and activity caches SHALL apply their configured lifetimes and existing identity/account/product-update scopes. A missing or expired activity cache SHALL not be represented as a confirmed empty result.
+
+#### Scenario: Workload token rotates
+- **WHEN** the same user's account workload data is still valid but the authorization token changes
+- **THEN** the account data can be reused without treating the token string as a different customer identity
+
+### Requirement: Only eligible reads are reused
+Form request caching SHALL reuse only known read operations, share concurrent reads and invalidate applicable entries after successful writes. Create, update and delete operations SHALL not be served from a response cache.
+
+#### Scenario: Repeated write
+- **WHEN** the user explicitly submits a new valid write operation
+- **THEN** the operation goes through the write transport rather than returning a cached success
+
+### Requirement: Refresh all invalidates reusable data safely
+Refresh all SHALL invalidate product/activity and related cached data before reloading the active Reference, preserve user preferences and authentication, and prevent pre-invalidation responses from repopulating invalidated cache entries. Cache invalidation errors SHALL be reported.
+
+#### Scenario: Old product request finishes after refresh
+- **WHEN** an old request completes after its cache has been invalidated
+- **THEN** its result does not restore the invalidated cache snapshot
+
+#### Scenario: Activity updates arrive
+- **WHEN** only background activity lookup results change
+- **THEN** those lookups do not independently advance the product Last update timestamp