Skip to Content

← All archived runs

Run: sla-configuration-alignment

run.md

Run: sla-configuration-alignment

  • branch: claude/sla-configuration-alignment-9wuci0
  • pr: #616

00_intake/stub.md

Stub: Align the SLA section to the full SLA configuration

  • feature-slug: sla-configuration-alignment
  • epic: onboarding-blueprint-alignment
  • personas: Admin, Vendor
  • initiative: Build the Bridge / objective: Q2-2026 O1 — Establish Product-Market Fit with Vendor Partners
  • depends-on: remove-categories-section
  • sequence: 3 of 6

Problem

The SLA section drafts "tiers to choose from", but the platform has exactly one SLA configuration per tenant: one live sla_definition per service stage (Request, BRD, Bidding, Delivery, Billing, CSAT), each with an owner role, Response/Resolution timers (target / warning / breach business days), an impact level, and an escalation toggle. The tier-picker model is wrong and produces meaningless options.

Proposed change

Reshape the SLA blueprint to draft the single full SLA configuration: one item per the six SLA_STAGES, each carrying the real timer fields (ownerRole, slaType, targetDays, warningDays, breachDays, impact, escalationEnabled). Seed from the platform SLA defaults (tenant-defaults) and let the AI adjust values from the source where sensible; the operator confirms/tunes each stage in the chat. Contract, prompt, review-panel editable fields, and commit all reflect the 6-stage config (commit already targets sla_definitions).

Acceptance criteria (rough)

  • The SLA section drafts exactly the six service-stage definitions (no arbitrary tiers).
  • Each SLA item's data matches the real sla_definition fields and validates against SLA_STAGES and the timer/impact/role enums.
  • SLA items seed from platform defaults and are AI-adjustable, then operator-confirmable.
  • Committing writes/updates the tenant's sla_definitions (one live per stage) without violating the unique per-stage index.
  • The review panel exposes the correct SLA timer fields per stage.

Out of scope (this feature)

  • Changes to the sla-definition model or the /admin/settings/sla CRUD itself.
  • SLA computation / business-day logic.

Notes for Define

  • Real shape confirmed: 6 stages × {ownerRole, slaType (Response|Resolution), targetDays, warningDays, breachDays, impact, escalationEnabled}. Defaults in packages/services/src/db/seed/tenant-defaults.ts (SLA_DEFAULTS). The commit path's toSlaInput already reads these fields.
  • touches: packages/services/src/ai/onboarding/{contract.ts,prompt.ts,analyse-source.ts}, packages/services/src/db/services/onboarding-blueprint/commit.ts (the sla branch), apps/web/components/onboarding/types.ts (sla SECTION_META); reference packages/services/src/db/models/sla-definition.ts + db/seed/tenant-defaults.ts.

01_define/output/spec.md

Spec: Align the SLA section to the full SLA configuration

  • slug: sla-configuration-alignment
  • personas: Admin, Vendor
  • touches: packages/services/src/ai/onboarding (contract.ts, prompt.ts, analyse-source.ts), packages/services/src/db/services/onboarding-blueprint/commit.ts, apps/web/components/onboarding/types.ts
  • complexity: standard

Problem

The onboarding concierge drafts the SLA blueprint section as "support/service-level tiers or commitments" — an open-ended tier-picker. But the platform has exactly one SLA configuration per tenant: one live sla_definition per service stage across the six SLA_STAGES (Request, BRD, Bidding, Delivery, Billing, CSAT), each with an owner role, a Response/Resolution timer set (target / warning / breach business days), an impact level, and an escalation toggle. The tier model produces meaningless options that don't map onto anything the tenant can actually run, so the blueprint the operator confirms doesn't match the SLA config the platform commits. This is part of the onboarding-blueprint-alignment epic (Build the Bridge / Q2-2026 O1 — establish product-market fit with vendor partners by onboarding them onto a workspace that reflects the real platform), which aligns each blueprint section to its real model so a freshly onboarded tenant lands with valid config.

Proposed change

Reshape the SLA blueprint section — end to end on the drafting side — to draft the single full 6-stage SLA configuration instead of arbitrary tiers:

  • Deterministic pre-seed. When the blueprint's SLA section is first drafted, pre-seed exactly the six SLA_STAGES from the platform SLA defaults (SLA_DEFAULTS in db/seed/tenant-defaults.ts), one item per stage keyed by stage, each carrying the real fields (stage, ownerRole, slaType, targetDays, warningDays, breachDays, impact, escalationEnabled).
  • AI adjusts, doesn't invent. The concierge/analyse_source may tune the seeded timer values from the source where the business material warrants it, but works within the fixed six stages and the real field shape — it never adds tiers, drops a stage, or invents fields.
  • Operator confirms in chat, stage by stage, as with other sections.
  • Prompt, source-analysis system prompt, and the extraction contract's SLA description all describe the 6-stage configuration (real fields) rather than tiers.
  • Review panel relabels the SLA section away from "tiers" and shows each stage's real fields; the three business-day timers (targetDays, warningDays, breachDays) stay inline-editable per stage (as today) while stage/ownerRole/slaType/impact/escalationEnabled come from the seed + AI and are shown but not operator-editable this round.
  • Commit already targets sla_definitions (one upsert per stage via toSlaInput); confirm it consumes the seeded shape unchanged and update only the stale "tiers" labelling around it.

Acceptance criteria

  • The SLA section is drafted as exactly the six SLA_STAGES service-stage definitions (one item per stage, keyed by stage) — never arbitrary/empty tiers.
  • The six SLA items are deterministically pre-seeded from SLA_DEFAULTS, so every stage is present with valid default field values before any AI adjustment.
  • The AI may adjust the seeded timer values from the source but stays within the six stages and the real sla_definition field shape; it does not add tiers or drop stages.
  • Each SLA item's data carries the real sla_definition fields (stage, ownerRole, slaType, targetDays, warningDays, breachDays, impact, escalationEnabled) and passes the commit's toSlaInput validation and the sla-definition schema enums.
  • Committing a verified blueprint writes/updates the tenant's sla_definitions — one live row per stage — without violating the unique-per-stage partial index.
  • The onboarding prompt, analyse-source system prompt, and the extraction contract describe the 6-stage SLA configuration (real fields), with no remaining "tiers to choose from" framing.
  • The review panel no longer labels the section "SLA tiers"; the three day-timer fields remain inline-editable per stage and the stage's ownerRole/slaType/impact are shown for context.

Out of scope

  • Changes to the sla-definition model or the /admin/settings/sla CRUD.
  • SLA computation / business-day resolution logic (the escalationEnabled flag records intent only).
  • Making ownerRole, slaType, impact, or escalationEnabled operator-editable in the inline review panel — enum/boolean editor support is deferred; only the day timers are editable this round.
  • The other blueprint sections (profile, products, services, skills, settings) — each is aligned by its own sibling feature in the epic.
  • Re-onboarding or migrating existing tenants — this refines the fresh-tenant flow only.

Open questions

  • none.

02_build/output/notes.md

Build notes: sla-configuration-alignment

  • commits: feat: sla-configuration-alignment — draft the real six-stage SLA config, not tiers

What changed

  • packages/services/src/db/seed/tenant-defaults.ts: exported SLA_DEFAULTS (and the SlaDefault type) so the onboarding blueprint seeds from the platform's single source of truth instead of a duplicate table.
  • packages/services/src/ai/onboarding/sla-seed.ts (new): buildSlaSeedItem(stage) and seedSlaSection(tenantId) — deterministically materialise exactly the six SLA_STAGES as stage-keyed blueprint items carrying the real sla_definition shape (stage, ownerRole, slaType, targetDays, warningDays, breachDays, impact, escalationEnabled). Existing stage items are preserved on re-seed; missing stages added; non-stage junk dropped.
  • packages/services/src/ai/onboarding/analyse-source.ts: seed the SLA section from platform defaults at the top of analyseSource (before any AI drafting, and regardless of whether the source resolves); skip the sla key in the extraction write-loop so the model's freeform output can't dilute the six-stage config; system prompt now tells the extractor to leave sla empty (seeded separately).
  • packages/services/src/ai/onboarding/prompt.ts: the concierge instructions describe sla as the six-stage configuration and add explicit guidance — the section is pre-seeded, never add/remove stages, only tune a stage's day timers via draft_section keyed by stage.
  • packages/services/src/ai/onboarding/contract.ts: dropped "tiers" from the payload description; documented that sla is seeded (not source-extracted) while keeping the key so the section vocabulary stays in lockstep.
  • packages/services/src/db/services/onboarding-blueprint/commit.ts: comment-only — "SLA tiers" → "SLA configuration" (the commit path already upserts one sla_definition per stage via toSlaInput, unchanged).
  • apps/web/components/onboarding/types.ts: section label and collection label "SLA tiers" → "SLA configuration"; editable fields stay the three business-day timers (per the numeric-only decision).
  • apps/web/components/onboarding/blueprint-item.tsx: the item summary surfaces an SLA stage's slaType / impact / ownerRole for context (read-only), since day timers are the editable fields.
  • packages/services/src/ai/onboarding/blueprint-tools.ts (review follow-up): draft_section now merges an item's data field-wise over the existing item instead of replacing it wholesale. Without this, the concierge tuning one SLA stage's day timers would wipe the seeded stage/ownerRole/slaType/impact fields and fail the whole blueprint commit (toSlaInput). Mirrors the inline editor's merge.

Acceptance criteria status

  • SLA section drafted as exactly the six SLA_STAGES (one item per stage, keyed by stage) — seedSlaSection builds exactly six stage-keyed items and drops anything else.
  • Six SLA items deterministically pre-seeded from SLA_DEFAULTS before any AI adjustment — seeded at the top of analyseSource from the exported platform defaults.
  • AI may adjust seeded timers but stays within the six stages/real shape — prompt directs draft_section timer tweaks keyed by stage; analyse-source ignores freeform sla; re-seed preserves edits and drops non-stage items.
  • Each SLA item's data carries the real sla_definition fields and passes toSlaInput + schema enums — seed data mirrors the model's required fields plus stage/escalationEnabled.
  • Commit writes/updates sla_definitions (one live per stage), no unique-index violation — unchanged per-stage upsert path; six distinct stages.
  • Prompt, analyse-source system prompt and the extraction contract describe the six-stage config with no "tiers to choose from" framing — all updated; remaining "tier" mentions are negative ("never add tiers").
  • Review panel no longer labels the section "SLA tiers"; three day-timer fields stay inline-editable; owner/type/impact shown for context — label + summary updated.

Verify result

  • mechanical checks (format · lint · typecheck · build) run in CI + the Vercel preview, not here. Release reads them back from the PR's check runs. No check is expected to fail.

Notes for review

  • Seeding lives in analyseSource, which the concierge prompt guarantees is called at the start (URL or free-text description both route through it), and it seeds even when the source is unreachable/empty — so the SLA section is always the full six-stage config.
  • Per the Define decisions: the inline editor stays numeric-timers-only (owner/type/impact/ escalation come from defaults + AI, shown read-only); enum/boolean editing is deferred (Out of scope).

03_release/output/changelog.md

Changelog: sla-configuration-alignment

Published at apps/help/app/changelog/2026-07-08-sla-configuration-alignment/page.mdx.

When you set up a new workspace, the setup assistant now drafts your service-level agreements as the six service stages you actually run — Request, BRD, Bidding, Delivery, Billing and CSAT — instead of placeholder tiers. Each stage is pre-filled with sensible response/resolution targets to confirm or adjust, and whatever you approve commits straight into your live SLA settings.

03_release/output/investor-update.md

Onboarding now configures vendors' real SLA setup

Who it's for: Admins and vendors setting up a new workspace What shipped: The onboarding assistant drafts the platform's real six-stage SLA configuration, pre-filled from defaults, instead of placeholder tiers. Why it matters: Vendors land with a valid, ready-to-run SLA setup, cutting onboarding friction — advancing Build the Bridge: establish product-market fit with vendor partners.

Dig deeper: <merged-PR URL> · <changelog entry URL>

03_release/output/release.md

Release: sla-configuration-alignment

  • pr: #616 (https://github.com/sustentus/sustentus/pull/616) · merged: no — pending
  • CI: green (Quality Project success; preview + preview-DB migrate success; audit success; prod-DB migrate skipped — no migration this run)
  • technical docs: no technical docs impact — technical/packages/services describes the concierge as interviewing "the six blueprint sections"; that stays true (this refines the SLA section's internal shape, not the flow, app, package, route, or env).
  • business docs: no business docs impact — no apps/docs/app/business page documents the onboarding SLA section's shape; platform-overview's "SLA timers configured per tenant" line is unchanged.
  • release notes: both — changelog entry + investor draft authored in this PR.
  • deploy: pending (poll after merge)
  • sent: pending

Review summary

  • /code-review medium on the diff (origin/main...HEAD): no actionable findings. Correctness, removed-behavior, cross-file, reuse, simplification, efficiency, altitude and CONVENTIONS angles all clean.
  • The earlier VADE (Vercel Agent Review) finding — draft_section replacing item data wholesale, which would wipe seeded SLA fields on a partial timer update and fail the commit — was fixed in commit 00b1324 (field-wise merge, mirroring the inline editor). Verified in this review.
  • seedSlaSection runs on every analyse_source call and preserves existing stage items by key, so operator/AI timer edits survive a re-seed; non-stage entries are dropped, enforcing exactly six stages.

Acceptance check (vs spec)

  • SLA section drafted as exactly the six SLA_STAGES, keyed by stage — seedSlaSection builds exactly six stage-keyed items, drops non-stage entries.
  • Six items deterministically pre-seeded from SLA_DEFAULTS before AI adjustment — seeded at the top of analyseSource.
  • AI adjusts timers within the six stages/real shape — prompt directs stage-keyed draft_section timer tweaks; analyse-source ignores freeform sla; draft_section now merges data field-wise so partial updates preserve seeded fields.
  • Each item's data carries the real sla_definition fields; passes toSlaInput + schema enums.
  • Commit writes/updates sla_definitions (one live per stage) — unchanged per-stage upsert path.
  • Prompt, analyse-source system prompt, contract describe the six-stage config; no "tiers to choose from" framing remains.
  • Review panel relabelled "SLA configuration"; three day-timers editable; owner/type/impact shown for context.