Cpq Builder

CPQ Builder Skill

What This Skill Does

This skill defines patterns for building Configure-Price-Quote-shaped tools — systems where users configure inputs, the system applies rules to calculate results, and the output is a formatted deliverable that may require review/approval.

CPQ is NOT limited to product pricing. The same structural pattern covers:

The builder reads this skill, reads the DOMAIN.md for the specific domain terminology and rules, and generates a working prototype. The DOMAIN.md determines whether the tool is about crane quotes or divorce calculations; this skill provides the structural pattern that fits.

The patterns in this skill are defaults, not mandates. When the actual workflow deviates from the canonical CPQ shape — has fewer stages, has a different layout, produces a different output — adapt the patterns. Each major section names the deviations explicitly.

Customer Context

Customware's CPQ customers span many domains: industrial equipment dealers, custom apparel and signage shops, food/beverage wholesalers, professional services firms (legal, consulting, design), IT and managed service providers, construction and trades businesses, manufacturers, distributors. The CPQ pattern fits all of them.

Examples in this skill rotate across multiple domains — industrial equipment, services, consumer goods, software, custom goods. This is deliberate. The patterns are domain-agnostic; the examples illustrate by analogy. When applying this skill, ignore the specific domain in any given example and pull out the structural pattern. Your DOMAIN.md determines the specific vocabulary, products, rules, and roles for the build.

A "single girder crane requires a motor" rule has the same shape as "custom hoodie requires a printing method" or "managed service contract requires a tier" or "dog treat order requires a packaging size." The rule is "parent product requires child component selection." Build that pattern; let DOMAIN.md fill in the words.

The customer profile

Customware's CPQ customers are typically SMB businesses (5-50 employees) going through growing pains. They are NOT migrating from another CPQ system. They are migrating from:

• Excel spreadsheets that have grown unwieldy (multiple tabs, copy-paste errors, broken formulas)
• Word document quote templates that get manually edited per customer
• Email-based approval workflows where the boss approves a quote in a reply-all thread
• Tribal knowledge about which products require which accessories, which lives in the senior rep's head
• Hand-keyed pricing where margin gets eroded through inconsistent discounting

The prototype's job is to feel dramatically better than spreadsheets without feeling enterprise-overcomplicated. A small team that's been quoting in Excel for 5 years should look at the prototype and immediately think "this is so much faster" — not "this looks complicated."

This positioning shapes every design decision in this skill:

• Inline line editing IS the comparison point. Excel users expect a grid they can edit directly.
• Live totals matter. Customers have been doing math in formulas; they expect to see numbers update as they change inputs.
• Role gating is impressive. Customers have never had "only the owner can approve over $50K" enforced by software — it was a verbal rule that got broken.
• Branded PDF output is impressive. Customers have been hand-formatting Word docs.
• Customer-facing portals, AI suggestions, e-signature integrations are NOT impressive at this stage. They're enterprise complexity that solves problems the customer doesn't have yet.

Build for the customer who's tired of broken Excel formulas, not the customer migrating from Salesforce.

Is This Even CPQ?

Before applying any pattern in this skill, confirm the workflow is actually CPQ-shaped. The CPQ pattern fits when ALL FOUR of these hold:

1. The user collects structured inputs that determine the outcome (configuration choices, customer details, requirements, financial data, case details).
2. Business rules or calculation logic transforms those inputs into a deliverable (markup formulas, guideline calculations, rate tables, eligibility rules).
3. A review or approval gate exists between input and finalization, OR the deliverable goes through some kind of stakeholder review (preparer/reviewer pattern).
4. The work product feels like it gets handed off — to a customer, an internal stakeholder, a regulatory body, a downstream system.

If criterion 1 is missing → it's a dashboard or display tool, not CPQ. Bail. If criterion 2 is missing → it's a data entry form, not CPQ. Bail. If criterion 3 is missing → it's "intake-and-deliver" — apply CPQ patterns but skip the Approve section. If criterion 4 is missing → it's a personal calculator/utility, not CPQ. Bail.

Common false positives:

• A "stock quote viewer" — has the word "quote" but is a display tool (criterion 1 missing)
• A "tax calculator" with no review step — utility, not CPQ (criterion 3 + 4 missing)
• A "product catalog" with prices — display, not CPQ (criterion 2 + 3 missing)
• A "feedback form" — data entry, not CPQ (criterion 2 missing)

If the four criteria don't hold, do not force-fit the patterns below. Build from the task description and DOMAIN.md using frontend-design's principles instead.

Domain Type

Most CPQ-shaped workflows fall into one of two domain types. Identify which type the build is before applying patterns:

Product domain. The user configures sellable products/services. Pricing is the central calculation. Output is a quote document with line items, totals, tax, and terms. Examples: equipment sales, custom apparel orders, food/CPG wholesale, service proposals (consulting bids, managed services), software licensing, custom packaging.

Calculator/intake domain. The user enters case/applicant details. Calculation applies guidelines/rules/rate tables. Output is a summary report with inputs, calculated values, and disclaimers. Examples: spousal support calculators (Clarity Legal), insurance estimators, loan qualification, benefits eligibility.

The skill's patterns adapt to both. When a section or rule is domain-specific, this skill says so explicitly.

Minimum Standards

Every CPQ build MUST meet Tier 1 standards. Tier 2 standards are built when DOMAIN.md signals the need. Tier 3 capabilities are mentioned in the completion summary as future work but not built in the prototype.

Tier 1 — Non-negotiable (every CPQ build)

These are the capabilities that make the prototype feel dramatically better than Excel + Word. If any are missing, the build is incomplete regardless of how clean the UI looks.

1. Direct inline line-item editing. A spreadsheet-style table where users add rows, edit any cell, and see totals update live. NOT a "Configure form → Add to Quote → Build Quote table → Edit" round trip. The line items table IS the workspace. See "Section Pattern" below for the canonical implementation.

2. Bundle / required-child products with appropriate configurator pattern. When a parent product requires a child component (e.g., "industrial unit requires a motor selection," "custom hoodie requires a printing method," "managed service contract requires a tier," "dog treat order requires a packaging size"), the child selection is part of configuring the parent. The line item shows the parent + the chosen child as one cohesive entry. Never two separate line items where the user might forget the child. For products with 4+ configuration attributes or cascading dependencies (typical industrial equipment, custom goods, and tiered services often go 3-4 levels deep), use the appropriate configurator pattern — see "Product Configurator Pattern" below for inline-expand vs side-drawer vs full-page decisions.

3. Constraint rules surfaced visibly. Requires / excludes / recommends rules from DOMAIN.md must be visible to the user — not just enforced silently. When the user adds a crane, the UI shows "Motor selection required (BR-001)" before they can save. When they try to add an excluded combination, the UI shows the rule and rationale. Customers used to Excel have NEVER had rules enforced — making the rules visible is half the value.

4. Discount stack with visible math. When discounts apply, show the layered calculation:

List Price:                  $15,000.00
Volume Discount (5%):           -$750.00
Promotional Discount (3%):      -$427.50
─────────────────────────────────────
Net Price:                   $13,822.50

Each discount is a row; the math is transparent. Customers used to negotiating discounts in email threads with no audit trail need to see exactly how the price was reached.

5. Live quote summary. Running totals (subtotal, tax, grand total) update in real-time as the user edits line items. No "click Calculate" button. This is the single biggest "wow" moment for Excel-coming customers — the totals just update.

6. Branded quote document. Generated PDF/print view with the customer's logo, line items table, totals, terms, and any required disclaimers. This replaces the hand-formatted Word document. Quality bar: it should look like a quote a real business would send.

7. Multi-tier approval routing. Most SMB workflows have 2+ levels of approval (rep configures → manager reviews → owner approves). Even simple cases have at least one approver and one final-signoff role. The prototype must show role-based routing that respects DOMAIN.md's stakeholder map. Routing often branches by request type — e.g., one company might route "custom configurations through a senior reviewer, inspections through the service manager, and maintenance through the operations manager, with the owner as final approver on all paths." That kind of conditional multi-tier routing is table stakes.

8. Multi-quote management. Users have multiple quotes in flight simultaneously. The prototype must show a list of quotes with status indicators, support filtering/sorting, and let the user click into any quote to edit. NOT just a single-quote workspace with a "saved quotes" sidebar list.

9. Save / load / clone quotes. localStorage-backed. The user can create a new quote, save it, load a saved quote, and clone an existing quote as a starting point for a similar one. Excel users do this by copying tabs; the prototype gives them a Clone button.

10. Role-based view and action gating. Different roles see different things. Approvers see Approve buttons; preparers don't. Sensitive numbers (margin, cost) hide from non-approver roles. This is the "only the boss can see margin" pattern that customers know intuitively but have never had enforced.

Tier 2 — Build when DOMAIN.md justifies it

These are valuable capabilities but only worth building when DOMAIN.md provides clear signals.

• Guided selling (step-through Q&A for complex configurations) — when DOMAIN.md describes a discovery flow with the customer
• Volume / tier pricing — when DOMAIN.md mentions volume breaks, quantity tiers, or bulk discounts
• Customer-facing read-only quote link — when DOMAIN.md mentions emailing/sharing quotes with customers
• Subscription / renewal handling — when the domain is SaaS-like with recurring revenue
• Multiple pricing models in one build (cost-plus + catalog + custom) — when DOMAIN.md describes mixed pricing strategies
• Quote document templates by customer type — when DOMAIN.md describes different output formats per audience

Tier 3 — Future work (mention in completion summary, don't build)

These belong in production builds, not prototypes. The completion summary should name them so the customer knows what comes next.

• AI-suggested quotes from CRM/email/call context
• Quote versioning and amendment tracking
• Subscription billing logic and proration
• CRM/ERP integration (handled in full-stack phase)
• E-signature integration (DocuSign, HelloSign, etc.)
• Tax engine integration (Avalara, Vertex)
• Multi-currency with dynamic FX
• Self-serve customer configuration portal
• Deal Rooms / branded proposal microsites
• Native mobile app

Completion Summary Template

Every CPQ build's completion summary must include:

## What this prototype includes

**Tier 1 (always built):**
- [confirm each Tier 1 capability is present, or note why a specific one was omitted]

**Tier 2 (built for this domain):**
- [list any Tier 2 capabilities that were built and why]

## What this prototype does NOT include

This is a frontend prototype demonstrating the core CPQ workflow. The following capabilities
would come in production:

- [list relevant Tier 3 items based on the customer's likely future needs]

To move from prototype to production, add: real authentication, CRM/ERP integration,
e-signature, real PDF generation, and any Tier 3 capabilities listed above.

This sets honest expectations and shows the customer that more is coming, while being clear about what was delivered.

When to Use This Skill

When the four criteria in "Is This Even CPQ?" hold AND the customer's DOMAIN.md contains:

Classic CPQ signals:

• Products or services that are quoted/priced for customers
• Configuration options (sizes, models, variants, materials)
• Dependencies between products (requires, recommends, excludes)
• Markup or margin-based pricing (cost-plus, vendor list + percentage)
• A quoting or proposal workflow (draft → review → approve → send)

Broader "configure-calculate-output" signals:

• A calculator, estimator, or assessment tool with a review/handoff step
• Guided intake forms where inputs drive calculated outputs
• Multi-step data collection with rules applied to produce results
• Output documents (reports, summaries, estimates, proposals)
• A preparer/reviewer workflow (client fills in → professional reviews)

Do NOT use this skill when the domain is primarily about inventory tracking (use ERP skill), ongoing project execution with field tracking and payments (use trades-builder), online product sales (use e-commerce skill), or customer relationship management (use CRM skill).

Template Contract

Before you start building, understand what the template gives you and what this skill adds:

The template (app/layouts/MainLayout.tsx) ships with:

• SidebarProvider, Sidebar, SidebarContent, SidebarInset, SidebarTrigger — already wired
• SidebarContent is empty — this is your landing zone
• One brand slot in the header (logo placeholder + company name)
• ModeToggle and user menu in the header's right cluster

This skill fills:

• SidebarContent — with section navigation appropriate to the chosen layout
• The brand slot — with the client's logo and company name from DOMAIN.md
• The header's right cluster — adds a role switcher DropdownMenu before the existing user menu when the workflow has multiple roles
• The <Outlet /> in <main> — via route components for each section

This skill does NOT:

• Add a second Sidebar component. There is one sidebar.
• Put a brand tile inside SidebarContent. Brand lives in the header only.
• Mount MainLayout inside route components. Routes render in <Outlet />; the layout is the parent. Mounting MainLayout inside a route causes duplicate sidebars/headers.
• Rewire SidebarProvider or replace the collapsible behavior.

If the workflow doesn't fit a sidebar layout (see Layout Pattern alternatives below), the build may use a different shell. Document the deviation in the completion summary.

Section Pattern

The default CPQ workflow has three logical phases: configure inputs, review/approve, deliver document. The default UI maps these to three or four sections depending on whether the user benefits from a separate "review/edit lines" stage.

Default Section Structure (SMB direct-editing model)

For SMB CPQ where one role takes the quote from creation through approval (the most common case), the default is three sections:

1. Edit Quote — direct inline editing of all line items + customer details. This is the primary workspace where the user spends 90% of their time. Line items are added, edited, removed inline. Customer info, terms, and notes are inline. Live totals on the right or below.
2. Approve — review and approve action. Surfaces the final state, runs gating checks, and produces the approve action. May show change history if quote was previously approved/amended.
3. Quote Document — the deliverable. Read-only, printable, brand-formatted.

This collapses the v4.3 "Configure → Build Quote" round-trip into one direct-editing surface. Most SMB CPQ builds should use this three-section model.

Four-Section Structure (when handoff between roles exists)

When configuration and line-item assembly are done by different people (e.g., engineer configures → sales rep prices → manager approves), four sections are appropriate:

1. Configure — engineer or technical role specs the products
2. Build Quote — sales role adds pricing, terms, customer info
3. Approve — manager role approves
4. Quote Document — the deliverable

Use this only when DOMAIN.md describes genuine handoffs between roles at each stage. Most SMB CPQ does NOT need this — one person can configure, build, and approve. Use three sections.

Calculator Domain Section Structure

For calculator/intake domains (Clarity Legal pattern):

1. Submission Details — the intake form (client-facing)
2. Calculation — the computed result (auto-generated from inputs)
3. Lawyer Review — the reviewer-facing approval (lawyer-facing)
4. Final Report — the delivered output

The structural pattern is the same; the labels and components adapt to the domain.

Deviations

Skip "Approve" when the workflow has no review gate (self-service flow). Edit Quote → Document. Skip "Quote Document" when the deliverable isn't a document (push to system, inline result, confirmation page). Add Discover/Intake before Edit Quote when the workflow has a discovery phase before configuration. Pick the section count that matches the actual workflow. Don't pad to four. Don't truncate to fit.

Edit Quote Section — Direct Inline Editing (Tier 1 mandatory)

The Edit Quote section uses an Excel-like line items table as the primary workspace. This is non-negotiable for product CPQ.

Required behavior:

• Each line item is a row in a table
• Cells are editable inline — click a cell, edit value, totals update
• Add a new row via "+ Add Line" button below the table (or auto-add when user clicks into an empty placeholder row)
• Remove a row via row-action menu (trash icon, "Remove" option)
• Clone a row via row-action menu ("Duplicate" option)
• Total computes per row (qty × unit price - discount)
• Footer row computes subtotal across all line items
• Discount stack appears below subtotal (if applicable)
• Tax line appears below discount (if DOMAIN.md mentions tax)
• Grand total appears in bold at the bottom

Required columns (product domain):

The Description column shows the product name. The Configuration column shows the chosen options (e.g., "Premium tier — 50 users" or "Tri-blend, DTG print"). For products with required configurations (bundle/required-child pattern), clicking the row opens a configurator drawer/popover where the user picks options before the row is committed. The configuration shows inline once chosen, and is editable by clicking it again.

Required behavior for bundle / required-child products:

When DOMAIN.md describes a parent product that requires a child component — for example, "industrial unit requires a motor selection," "custom hoodie requires a printing method," "managed service contract requires a tier," or "dog treat order requires a packaging size":

• Adding the parent automatically prompts for the required child
• The line item displays as one cohesive entry: "[Parent Product] — [Required Child] — [Variant]"
• The price aggregates: parent base price + child upcharge
• The user cannot save the line until the required child is selected
• A visible rule indicator surfaces: "[Component name] selection required (BR-001)"

Required behavior for constraint rules:

When DOMAIN.md has requires / excludes / recommends rules:

• "Requires" rules block save until satisfied; show inline "Required: [explanation]"
• "Excludes" rules block invalid combinations; show inline "Cannot combine X with Y because [rationale]"
• "Recommends" rules surface as a soft suggestion; show "Customers often add Z with this. Add?"
• Each rule shows its rule ID (BR-001, BR-002) so the user can trace back to the source

This visible rule enforcement is one of the biggest "wow" moments for customers coming from Excel. Make it prominent.

Product Configurator Pattern

When a product has multiple configuration attributes (3+ decisions) or when configurations cascade (Level 1 selection determines Level 2 options, which determine Level 3, etc.), the inline dropdown-in-a-cell pattern isn't enough. The user needs a real configurator.

Real product configuration often goes 3-4 levels deep across many domains:

• Industrial equipment: type → capacity → motor → hoist → controls
• Custom apparel: garment style → fabric → size set → printing/embroidery method → finishing
• IT services: service tier → user count → modules → SLA level → integrations
• Food/CPG wholesale: product family → flavor or variant → packaging size → case quantity → shipping cold/ambient
• Professional services: engagement type → scope tier → team composition → duration → deliverable format
• Custom signage / packaging: substrate → dimensions → finish → printing method → mounting hardware

Each level constrains the next. Pick a 5-ton industrial unit → only certain motors fit → only certain controls match. Pick a tri-blend hoodie fabric → only certain printing methods compatible → only certain finishing options. Pick the Premium service tier → unlocks certain modules → requires the higher SLA. The shape is the same. DOMAIN.md tells the agent what's actually being configured.

For configurations of this depth, three patterns are appropriate, picked based on configuration complexity:

Pattern A — Inline expandable row (2-4 attributes, no cascading)

When a product has a small number of independent attributes (e.g., quantity, color, size, or one configuration choice), the line item row expands inline to reveal them. Click the row → expands to show attribute selectors → fill them out → row collapses with the configuration summarized in the Configuration column.

┌─────────────────────────────────────────────────────────────┐
│ 1  [Product Name]    [Variant ▾]    1   $X,XXX.XX  ...     │  ← collapsed
└─────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────┐
│ 1  [Product Name]    [Variant ▾]    1   $X,XXX.XX  ...     │
│    ┌───────────────────────────────────────────────────┐    │  ← expanded
│    │ Variant:      ( ) Option A    ( ) Option B        │    │
│    │ Quantity:     [  1  ]                             │    │
│    │ Description:  [                              ]    │    │
│    └───────────────────────────────────────────────────┘    │
└─────────────────────────────────────────────────────────────┘

Use when:

• 2-4 attributes total
• Attributes are independent (no cascading dependencies)
• All attributes fit visually within ~200px of vertical space when expanded

Examples of products that fit Pattern A: a t-shirt with size and color, a service add-on with hours and rate, a software license seat-count, a wholesale case quantity selection, a printed banner with one finishing option.

Pattern B — Side drawer with vertical stepper (4-7 attributes, cascading allowed)

When configuration has cascading dependencies or 4-7 attributes, click the row → a side drawer slides in from the right covering ~40% of the screen. The drawer has a vertical stepper down its left side showing each configuration level.

                           ┌────────────────────────────────┐
                           │ Configure [Product]            │
                           │                                │
                           │ ●━━━ Step 1: Foundation         │
                           │ │    [Selected value]           │
                           │ │                              │
                           │ ●━━━ Step 2: Sizing             │
                           │ │    [Selected value]           │
                           │ │                              │
                           │ ◉━━━ Step 3: Core Component     │
                           │ │    [ Option A ]  [ Option B ] │
                           │ │                              │
                           │ ○━━━ Step 4: Dependent Choice   │
                           │ │    (Complete Step 3 first)    │
                           │ │                              │
                           │ ○━━━ Step 5: Finishing           │
                           │                                │
                           │           [Cancel]  [Save]     │
                           └────────────────────────────────┘

Drawer behavior:

• Vertical stepper on the left within the drawer (NOT in the main app sidebar)
• Steps are clickable when their dependencies are satisfied; greyed out when not
• Each step's content appears to the right of the stepper inside the drawer
• Cascading dependencies: changing an upstream selection invalidates and clears downstream selections (with a confirmation toast: "Changing [upstream] will reset [downstream] selections")
• "Save" commits the configuration to the line item; "Cancel" discards
• The line item shows the assembled configuration summary in the Configuration column

This is the pattern for genuinely cascading configuration. Examples that fit Pattern B: industrial equipment with type/capacity/motor/controls, custom apparel with garment/fabric/printing-method/finishing, IT services with tier/users/modules/SLA, custom signage with substrate/dimensions/printing/mounting. The drawer gives the configurator room to breathe without taking the user out of the quote workspace context. The vertical stepper inside the drawer makes the cascade visible without consuming app-level navigation.

Why a drawer and not a modal:

• Drawers feel less interruptive than modals
• The user can still see the line items table on the left as context
• The drawer can be dismissed by clicking outside (modal-style "save before close" friction is avoided)
• Drawers compose well with React Router — open as a route, close returns to parent

Pattern C — Full-page configurator (8+ attributes, complex cascading)

When configuration is genuinely complex — 8+ attributes, multi-stage cascading, requires diagrams or visualizations — the configurator deserves its own page. Click "Configure" → navigate to /quotes/{id}/lines/{lineId}/configure → full page with horizontal step indicator at the top, configuration body in the middle, summary/preview rail on the right.

┌──────────────────────────────────────────────────────────────────┐
│ ← Back to Quote                                                  │
│                                                                  │
│ ●━━━━━━●━━━━━━●━━━━━━◉━━━━━━○━━━━━━○                            │
│ Step 1  Step 2  Step 3  Step 4  Step 5  Review                   │
│                                                                  │
│ ┌─────────────────────────────────────┬──────────────────────┐  │
│ │                                     │ Selected so far:     │  │
│ │  Configuration content for          │                      │  │
│ │  current step                       │ Step 1: [value]      │  │
│ │                                     │ Step 2: [value]      │  │
│ │                                     │ Step 3: [value]      │  │
│ │                                     │ Step 4: (selecting)  │  │
│ │                                     │                      │  │
│ │                                     │ Running price:       │  │
│ │                                     │ $X,XXX.XX            │  │
│ └─────────────────────────────────────┴──────────────────────┘  │
│                                                                  │
│                          [Back]  [Continue →]                    │
└──────────────────────────────────────────────────────────────────┘

Full-page is the only pattern that works for genuinely complex configuration. The horizontal step indicator at the top works HERE (in a dedicated wizard-like flow) where it would be wrong at the quote-detail level — because here the user genuinely IS doing one step at a time before moving to the next.

Use when:

• 8+ attributes
• Configuration involves visual elements (diagrams, dimensions, photos, color swatches, layout previews)
• Configuration takes more than 30 seconds — long enough to deserve a dedicated focus surface
• The configuration result is significant enough to warrant a "review before confirming" step

Examples that fit Pattern C: a custom kitchen with dozens of cabinet, surface, appliance, and finish decisions; a configurable bicycle with frame, drivetrain, wheels, brakes, accessories, color; an enterprise software contract with modules, user tiers, integrations, support levels, term length; a custom packaging order with substrate, dimensions, structural design, printing, finishing, quantity, shipping.

Picking the pattern

IF product has 2-4 independent attributes, no cascading:
  → Pattern A: Inline expandable row

IF product has 4-7 attributes, cascading dependencies, configuration takes <30s:
  → Pattern B: Side drawer with vertical stepper

IF product has 8+ attributes, visual/diagram component, takes >30s:
  → Pattern C: Full-page configurator with horizontal step indicator

WHEN IN DOUBT:
  → Pattern A for simple-looking products
  → Pattern B for industrial equipment, services with options
  → Pattern C reserved for genuinely complex configurators

Cascading dependency rules

For Patterns B and C, when configuration cascades:

1. Show downstream steps as disabled until upstream selections are made. Don't let the user click into Step 4 if Step 2 is empty.
2. When an upstream selection changes, clear downstream selections and show a confirmation: "Changing capacity from 5 ton to 10 ton will reset motor and hoist selections. Continue?"
3. Show the rule basis at each step: "Available motors are filtered based on your 5 ton capacity selection (BR-007)." Make the filtering rule visible.
4. Auto-select when only one option exists: if the cascade narrows to one valid choice, pre-select it and note "(only option available based on previous selections)."

This makes the cascade feel intelligent, not confusing. Customers used to Excel often have these rules in their head — "if it's the larger size, you can't use the basic component," "if it's the premium service tier, embedded support is included," "if it's the food-safe substrate, only water-based inks apply" — and surfacing the rule explicitly is more impressive than enforcing it silently.

Configuration summary in the line item

After the configurator commits (drawer saves, full-page confirms), the line item displays the assembled configuration in the Configuration column. For 3-4 deep configurations, this can get long:

[Industrial equipment example]
Industrial Lift — 5 ton, 40ft span
└─ Standard motor, Type 2 hoist, 480V controls, festoon system

[Custom apparel example]
Premium Hoodie — Tri-blend, M-XL run
└─ DTG print, 4-color front, sleeve embroidery, polybag

[IT services example]
Managed Services — Premium Tier, 50 users
└─ Security module, Backup module, 4-hr SLA, Slack integration

Show this as a compact summary text, with a "Edit configuration" link that re-opens the configurator. Don't try to fit every attribute as separate columns in the line items table — that doesn't scale beyond 2-3 attributes.

Reference implementation pattern:

<table>
  <thead>
    <tr>
      <th>#</th>
      <th>Description</th>
      <th>Configuration</th>
      <th>Qty</th>
      <th className="text-right">List Price</th>
      <th className="text-right">Discount</th>
      <th className="text-right">Net Price</th>
      <th className="text-right">Line Total</th>
      <th></th>
    </tr>
  </thead>
  <tbody>
    {lineItems.map((item, i) => (
      <tr key={item.id}>
        <td>{i + 1}</td>
        <td>
          <ProductPicker value={item.productId} => updateItem(item.id, { productId: p })} />
        </td>
        <td>
          <ConfigurationCell item={item} => updateItem(item.id, { configuration: config })} />
          {item.requiredRules.map(rule => (
            <RuleIndicator key={rule.id} rule={rule} satisfied={item.satisfiedRules.includes(rule.id)} />
          ))}
        </td>
        <td>
          <Input type="number" value={item.qty} => updateItem(item.id, { qty: e.target.value })} />
        </td>
        <td className="text-right">{formatCurrency(item.listPrice)}</td>
        <td className="text-right">
          <DiscountCell item={item} => updateItem(item.id, { discount: d })} />
        </td>
        <td className="text-right">{formatCurrency(item.netPrice)}</td>
        <td className="text-right font-medium">{formatCurrency(item.lineTotal)}</td>
        <td>
          <RowActions => cloneItem(item.id)} => removeItem(item.id)} />
        </td>
      </tr>
    ))}
  </tbody>
  <tfoot>
    <tr><td colSpan={7} className="text-right">Subtotal:</td><td className="text-right">{formatCurrency(subtotal)}</td><td /></tr>
    {discountRows.map(d => (
      <tr key={d.id}><td colSpan={7} className="text-right text-muted-foreground">{d.label}:</td><td className="text-right">-{formatCurrency(d.amount)}</td><td /></tr>
    ))}
    {taxRate > 0 && (
      <tr><td colSpan={7} className="text-right">{taxName} ({taxRate}%):</td><td className="text-right">{formatCurrency(taxAmount)}</td><td /></tr>
    )}
    <tr className="font-bold text-lg"><td colSpan={7} className="text-right">Total:</td><td className="text-right">{formatCurrency(grandTotal)} {currency}</td><td /></tr>
  </tfoot>
</table>

<Button Add Line</Button>

The customer info, payment terms, valid-until date, and notes appear as a section below the line items table — inline on the same page, NOT a separate route or step.

Discount Stack Pattern (Tier 1 mandatory when discounts apply)

When DOMAIN.md mentions any form of discount (volume, promotional, manual, negotiated), the build must show discounts as a layered, transparent calculation.

Required visible math:

List Price (5 × $15,000):       $75,000.00
─────────────────────────────────────────
Volume Discount (5%):              -$3,750.00
Promotional Discount (3%):         -$2,137.50
Manual Discount ($1,000):          -$1,000.00
─────────────────────────────────────────
Net Price:                       $68,112.50
HST (13%):                         $8,854.63
─────────────────────────────────────────
Total:                           $76,967.13 CAD

Required behavior:

• Each discount is a separate row in the totals stack
• Each row shows: discount type, percentage or amount, the dollar amount removed
• Discounts apply in stacked order (volume → promotional → manual)
• Manual discount triggers approval routing if it exceeds DOMAIN.md's threshold
• The user sees what was removed and why; nothing is hidden in formulas

Discount approval thresholds:

When DOMAIN.md describes discount approval rules ("discounts over 15% require manager approval"), the prototype enforces them:

• Discount under threshold → user can apply without approval
• Discount at/above threshold → user can apply but quote enters "Pending Approval" status
• The approval routing routes to the role authorized at that discount level

This is the most common "we lose margin" complaint from SMB businesses. Surfacing the rule in the UI is high-value.

Multi-Tier Approval Chain Pattern (Tier 1 mandatory)

Most SMB CPQ workflows have 2+ approval levels. The prototype must reflect this.

Approval Chain Definition

DOMAIN.md describes approvers in the Stakeholder Map. The prototype derives the approval chain from this map:

• Single approver → simple gate ("Pending approval from [Owner]")
• Sequential approvers → chain ("Pending approval from [Sales Manager], then [Owner]")
• Conditional approvers → routing based on quote attributes ("Routes to [Reviewer A] for standard configurations, [Reviewer B] for service requests, [Reviewer C] for maintenance")

Approval Chain UI

Surface the chain visibly so users understand where the quote is and what's next:

Quote Status: Pending Approval
─────────────────────────────────────────
✓ Submitted by [Sales Rep]              (May 5, 2:30 PM)
✓ Approved by [Sales Manager]            (May 5, 3:15 PM)
○ Pending approval from [Finance Lead]
○ Pending final signoff from [Owner]

Each approver:

• Sees the quote in their queue (filtered list view: "Awaiting My Approval")
• Can approve, reject, or request changes
• Their action advances or halts the chain
• A rejected/changed quote returns to the previous approver with notes

Required for the build:

• The approval chain is derived from DOMAIN.md's Stakeholder Map automatically
• The role switcher lets the user view as any approver to see how the queue looks
• The "Awaiting My Approval" filter in the multi-quote list shows quotes pending the active role
• Approval actions update the chain state and trigger toast confirmations
• Rejection/changes capture a comment that's visible to the next/previous role

Approval Routing Rules

When DOMAIN.md describes routing rules — for example, "route maintenance requests to the service manager, inspection requests to the field supervisor" — the prototype implements the routing. Example logic (using placeholder names that DOMAIN.md replaces):

// Example routing logic derived from DOMAIN.md stakeholder map:
// - Standard quotes: route to [Sales Manager]
// - Inspection requests: route to [Field Supervisor]
// - Maintenance requests: route to [Service Manager]
// - All quotes finalized by [Owner]

function getApprovalChain(quote) {
  const chain = [];
  
  if (quote.requestType === 'inspection') {
    chain.push({ role: 'inspection-reviewer', name: '[Field Supervisor]' });
  } else if (quote.requestType === 'maintenance') {
    chain.push({ role: 'maintenance-reviewer', name: '[Service Manager]' });
  } else {
    chain.push({ role: 'sales-reviewer', name: '[Sales Manager]' });
  }
  
  chain.push({ role: 'final-approver', name: '[Owner]' }); // Always final-signoff at end
  return chain;
}

In the actual build, repla

…(truncated)