Implemented OpenSpec and created and updated its artifacts

openspec/specs/product-workloads/spec.md

@@ -0,0 +1,57 @@
+# product-workloads Specification
+
+## Purpose
+
+Enrich opportunities with products and workload information and support review and explicit updates of consumption projections.
+
+## Requirements
+
+### Requirement: Product enrichment runs in the background
+Product loading SHALL update opportunity product counts and progress without blocking the displayed opportunity list. Product detail tables SHALL retain their source order rather than applying the general table sorting preference.
+
+#### Scenario: Some products are still loading
+- **WHEN** opportunities are visible and their products have not all arrived
+- **THEN** completed product results update their related opportunities while remaining products continue loading
+
+### Requirement: Workload retrieval is shared by customer
+Workload retrieval SHALL consolidate all result pages for each distinct customer account, reuse eligible cached results and correlate workloads to products by revenue identifier. Concurrent consumers of the same account SHALL share loading.
+
+#### Scenario: Multiple opportunities share a customer
+- **WHEN** their products require workloads for the same account
+- **THEN** one shared account retrieval supplies the matching products and continues while the response indicates more pages
+
+### Requirement: Booking classification requires loaded products without Workload names
+An opportunity with a nonempty loaded product list SHALL display a distinct Booking badge when every product has a blank or `-` Workload name. If any product has a Workload name, the existing ramp badge behavior SHALL remain.
+
+#### Scenario: No products have an assigned Workload
+- **WHEN** all loaded products have blank or `-` Workload names
+- **THEN** Booking replaces Ramp Months and the opportunity matches the Booking filter
+
+#### Scenario: Mixed product assignments
+- **WHEN** at least one product has a Workload name
+- **THEN** the opportunity retains its ramp behavior and is not classified as Booking
+
+### Requirement: Projection access is independent of a difference alert
+Clicking a ramp badge SHALL open consumption projection even when forecast and calculated amounts match. Difference alerts SHALL be placed between ramp and SR badges; product alerts without a workload record SHALL indicate unavailability with disabled styling.
+
+#### Scenario: Forecast matches calculation
+- **WHEN** the user clicks a ramp badge for a product with no forecast difference
+- **THEN** Consumption projection still opens
+
+### Requirement: Projection comparison uses calculated monthly values
+Consumption projection SHALL calculate monthly amounts using adjusted ACR, ramp months and first-month proration, and compare forecast minus calculated amounts at cent precision.
+
+#### Scenario: Monthly discrepancy
+- **WHEN** a calculated monthly amount differs from its forecast after rounding to cents
+- **THEN** the comparison shows the difference and enables the corresponding alert
+
+### Requirement: Estimate updates require confirmation
+Update estimates SHALL ask for confirmation before writing calculated values to SPA, prevent duplicate submissions and report success or failure. Successful updates SHALL refresh the comparison and invalidate affected workload cache data.
+
+#### Scenario: Confirmation is cancelled
+- **WHEN** the user declines the update confirmation
+- **THEN** no forecast update is sent
+
+#### Scenario: Confirmed update succeeds
+- **WHEN** the user confirms and the update request succeeds
+- **THEN** the comparison reflects the new values and subsequent workload reads do not reuse the invalidated values