switchboard/core
Archived
1
0
Fork 0
Code Issues Pull Requests Actions Releases 9 Wiki Activity

Roadmap restructure v038 v039 (#231)

Browse Source 
Co-authored-by: gobha <jasafpro@gmail.com>
Co-committed-by: gobha <jasafpro@gmail.com>
This commit is contained in:
gobha
2026-03-24 20:35:13 +00:00
committed by xcaliber
parent 3a4afea7f2
commit 54ceeb4299
2 changed files with 269 additions and 108 deletions
Download Patch File Download Diff File Expand all files Collapse all files

139
docs/ROADMAP.md
View File

@@ -15,10 +15,12 @@ No compatibility guarantees before 1.0.
## Dependency Graph ## Dependency Graph
Two parallel implementation tracks converge at v0.50.0 (MVP). The Three parallel implementation tracks converge at v0.50.0 (MVP). The
extension track builds the package ecosystem and workflow capabilities. extension track (v0.38.x) builds the package ecosystem that dynamic
The operations track builds production readiness for multi-team workflows depend on. The workflow track (v0.39.x) builds both simple
deployment. Neither blocks the other until the MVP gate. and dynamic workflow capabilities on that foundation. The operations
track builds production readiness. A polish series (v0.40.x) follows
to stabilize for MVP.
``` ```
v0.9.x–v0.28.7 Foundation through Platform Polish ✅ v0.9.x–v0.28.7 Foundation through Platform Polish ✅
@@ -52,17 +54,23 @@ v0.9.x–v0.28.7 Foundation through Platform Polish ✅
│ v0.37.17–18 Surfaces ✅ │ │ v0.37.17–18 Surfaces ✅ │
│ v0.37.19 Tag │ │ v0.37.19 Tag │
│ │ │ │ │ │
│ v0.38.x Workflow │ v0.38.0–.4 │ │
│ Product Maturity │ Extension │ │
Continuation │ │
│ │ │ │ │ │
v0.39.0 │ │ ├────────────┤ │
v0.39.1 │ │ │ │ │
v0.39.2 │ │ │ v0.39.x Workflow │
v0.39.3 │ │ │ Product Maturity │
│ (simple + dynamic) │
│ │ │
│ v0.40.x Polish │
│ (bug hunt, dead │
│ code, stabilize) │
│ │ │ │ │ │
══════╪════════════╪═════════════════╪══════ ══════╪════════════╪═════════════════╪══════
│ MVP v0.50.0 │ │ MVP v0.50.0 │
│ (all three tracks complete │ │ (all tracks complete │
│ + mobile + deploy docs) │ │ + mobile + deploy docs) │
══════╪════════════╪═════════════════╪══════ ══════╪════════════╪═════════════════╪══════
│ │
@@ -254,36 +262,81 @@ light mode CSS audit, dead code hunt. Every capability has a UI.
--- ---
## v0.38.x — Workflow Product Maturity ## v0.38.x — Extension Track Continuation
See [ROADMAP-0.38](Workflow/ROADMAP-0.38.md) for full version plan.
Visual workflow builder series. Bridges .37 plumbing to MVP gate
("team admins build workflows visually").
| Version | Summary | MVP Role |
|---------|---------|----------|
| v0.38.0 | Form Builder | **Blocker** — visual field editor replaces JSON textarea |
| v0.38.1 | Stage Reorder + Bulk Ops | DnD reorder, multi-select operations |
| v0.38.2 | SLA Alerting | Scheduled scanner, breach notifications |
| v0.38.3 | Visitor Experience | Branding, progress indicator, email notifications |
| v0.38.4 | Workflow Templates + Clone | 5 built-in templates, deep copy |
| v0.38.5 | Analytics Dashboard | Throughput, cycle time, SLA compliance |
---
## v0.39.x — Extension Track Continuation
Resumes the extension track (v0.29–v0.31 ✅) with three new platform Resumes the extension track (v0.29–v0.31 ✅) with three new platform
primitives: multi-file Starlark packages, extension connections, and library primitives: multi-file Starlark packages, extension connections, and
packages. See design docs for full specifications. library packages. Culminates in a git-board rewrite that validates the
entire stack. **Must ship before v0.39.x** — dynamic workflows depend
on `load()`, connections, and libraries.
See design docs for full specifications.
| Version | Summary | Design Doc | | Version | Summary | Design Doc |
|---------|---------|------------| |---------|---------|------------|
| v0.39.0 | Multi-file Starlark | [DESIGN-MULTI-FILE-STARLARK.md](DESIGN-MULTI-FILE-STARLARK.md) — `load()` support, disk-based scripts, package-scoped loader. Prerequisite for libraries. 5 backend changesets. | | v0.38.0 | Multi-file Starlark | [DESIGN-MULTI-FILE-STARLARK.md](DESIGN-MULTI-FILE-STARLARK.md) — `load()` support, disk-based scripts, package-scoped loader. Prerequisite for libraries. 5 backend changesets. |
| v0.39.1 | Extension Connections | [DESIGN-EXT-CONNECTIONS-LIBRARIES.md](DESIGN-EXT-CONNECTIONS-LIBRARIES.md) Part 1 — `ext_connections` table, scoped CRUD (personal → team → global resolution), `connections` Starlark module, 3 management UIs. | | v0.38.1 | Extension Connections | [DESIGN-EXT-CONNECTIONS-LIBRARIES.md](DESIGN-EXT-CONNECTIONS-LIBRARIES.md) Part 1 — `ext_connections` table, scoped CRUD (personal → team → global resolution), `connections` Starlark module, 3 management UIs. |
| v0.39.2 | Library Packages | Part 2 — `library` package type, `ext_dependencies` table, `lib.load()` with per-library permission context, dependency resolution, uninstall protection. | | v0.38.2 | Library Packages | Part 2 — `library` package type, `ext_dependencies` table, `lib.load()` with per-library permission context, dependency resolution, uninstall protection. |
| v0.39.3 | Full Composition | Part 3 — Libraries declare connection types for consumers, reference `gitea-client` library, migrate `git-board` to library-backed surface. | | v0.38.3 | Full Composition | Part 3 — Libraries declare connection types for consumers, reference `gitea-client` library. |
| v0.38.4 | Git-board Rewrite | Capstone validation — rewrite git-board as multi-package, multi-platform extension (Gitea/GitLab/GitHub). Proves the entire extension architecture works end-to-end. Reference implementation for future extension authors. |
---
## v0.39.x — Workflow Product Maturity
See [ROADMAP-0.39](Workflow/ROADMAP-0.39.md) for full version plan.
Dual workflow architecture: **simple** (static stages, fixed forms,
declarative rules) and **dynamic** (Starlark-driven branching, API-backed
pre-screening, tailored data collection). A single workflow graph can
mix both types.
Depends on: v0.38.x (dynamic stages require `load()`, connections,
and libraries for external API calls and reusable logic).
### Stage Graph Architecture
Three node types in the workflow graph:
- **Simple stage** — declarative form, fixed fields, built-in renderer.
Team admins author these visually (form builder).
- **Dynamic stage** — Starlark hook runs at entry, returns form
config/routing based on customer data. Developers author these.
- **Automated stage** — no UI, Starlark execution only (API calls,
data transforms, pre-screening). Invisible to visitors.
**Branching:** layered approach — declarative rules (`if customer.type
== enterprise → stage A`) for simple cases, optional Starlark hook for
complex branching logic. Progressive complexity.
**Visitor surface:** standalone portal (branded URL, no chat chrome).
The portal renders whatever the current stage dictates — it doesn't
care whether the stage config came from static definition or Starlark.
### Version Plan
| Version | Summary | MVP Role |
|---------|---------|----------|
| v0.39.0 | Stage Graph Engine + Form Builder | **Blocker** — graph execution engine with simple/dynamic/automated node types; visual field editor replaces JSON textarea |
| v0.39.1 | Stage Reorder + Bulk Ops | DnD reorder, multi-select operations |
| v0.39.2 | SLA Alerting | Scheduled scanner, breach notifications |
| v0.39.3 | Visitor Portal | Standalone branded portal, progress indicator, email notifications, session resume |
| v0.39.4 | Workflow Templates + Clone | Built-in templates, deep copy |
| v0.39.5 | Analytics Dashboard | Throughput, cycle time, SLA compliance |
---
## v0.40.x — Polish
Bug hunt, dead code hunt, stabilization. As many sub-versions as
needed to reach a polished MVP-ready product. May pull in features
from ongoing stakeholder meetings.
- [ ] UI bug fixes
- [ ] Dead code removal
- [ ] Performance audit
- [ ] Accessibility pass
- [ ] Additional features TBD from stakeholder input
--- ---
@@ -294,13 +347,19 @@ on a 3-node cluster. An IT team can operate the platform without
reading Go source code. Team admins build workflows visually. reading Go source code. Team admins build workflows visually.
**Requires all of:** **Requires all of:**
- Extension track through v0.31.2 (full package ecosystem, visual - Extension track through v0.31.2 (package ecosystem, SDK-based
workflow builder, SDK-based surfaces, team workflow self-service) surfaces, team workflow self-service) ✅
- Operations track through v0.34.0 (multi-replica HA, observability, - Operations track through v0.34.0 (multi-replica HA, observability,
data portability) ✅ data portability) ✅
- Workflow product v0.35.0 (form rendering, data pipeline, conditional - Workflow product v0.35.0 (form rendering, data pipeline, conditional
routing, structured review, monitoring dashboard) routing, structured review, monitoring dashboard) ✅
- Full OpenAPI spec v0.36.0 (complete API documentation for all domains) - Full OpenAPI spec v0.36.0 (complete API documentation) ✅
- UI rewrite v0.37.x (Preact+htm migration, all surfaces) ✅
- Extension continuation v0.38.x (multi-file Starlark, connections,
libraries, git-board rewrite)
- Workflow maturity v0.39.x (stage graph engine, simple + dynamic
workflows, visitor portal, analytics)
- Polish v0.40.x (bug hunt, dead code, stabilization)
**Additionally requires:** **Additionally requires:**
- [ ] Deployment guide: step-by-step for IT team (PG cluster, - [ ] Deployment guide: step-by-step for IT team (PG cluster,

238
docs/Workflow/ROADMAP-0.38.md → docs/Workflow/ROADMAP-0.39.md
View File

@@ -1,11 +1,56 @@
# ROADMAP-0.38 — Workflow Product Maturity # ROADMAP-0.39 — Workflow Product Maturity
Everything deferred from v0.37.15 plus what the MVP gate actually Everything deferred from v0.37.15 plus what the MVP gate actually
requires: "Team admins build workflows **visually**." requires: "Team admins build workflows **visually**."
v0.37.15 delivers the plumbing — cancel, unclaim, reassign, stage CRUD v0.37.15 delivers the plumbing — cancel, unclaim, reassign, stage CRUD
in the FE, queue views. This series builds the product on top of that in the FE, queue views. v0.38.x delivers the extension infrastructure
plumbing. (multi-file Starlark, connections, libraries) that dynamic workflows
depend on. This series builds the product on top of both foundations.
**Two workflow camps:**
- **Simple workflows** — static stages, fixed forms, declarative rules.
Team admins author these visually.
- **Dynamic workflows** — Starlark-driven branching, API-backed
pre-screening, tailored data collection based on customer context.
Developers author these for team admins to deploy.
A single workflow graph can mix simple, dynamic, and automated stages.
---
## Stage Graph Architecture
Three node types in the workflow graph:
| Node Type | UI | Author | Example |
|-----------|-----|--------|---------|
| **Simple** | Declarative form, fixed fields, built-in renderer | Team admin (form builder) | "Collect name, email, issue type" |
| **Dynamic** | Starlark hook returns form config/routing at runtime | Developer | "Check CRM, skip fields we already know, route by customer tier" |
| **Automated** | No UI — Starlark execution only | Developer | "Call external API, transform data, pre-screen eligibility" |
**Branching:** Layered approach — declarative rules for simple cases
(`if customer.type == enterprise → stage A`), optional Starlark hook
for complex branching. Progressive complexity: team admins use rules,
developers add hooks when needed.
**Visitor surface:** Standalone portal (branded URL, no chat chrome).
The portal renders whatever the current stage dictates — it doesn't
care whether the stage config came from static definition or Starlark.
### Example Mixed Workflow
```
[Pre-screen (automated: CRM lookup via Starlark)]
│
[Branch: known customer?]
yes → [Verify Info (simple: pre-filled form)]
no → [Full Intake (dynamic: Starlark picks fields)]
│
[Review (simple stage)]
│
[Provision (automated: external API call)]
```
--- ---
@@ -13,17 +58,21 @@ plumbing.
``` ```
v0.37.15 Workflow Ownership & Lifecycle (plumbing) v0.37.15 Workflow Ownership & Lifecycle (plumbing)
v0.37.16 Projects Surface v0.37.16–18 Projects, Workspaces, Debug surfaces
v0.37.17 Debug / Model Surface v0.37.19 Tag ("UI Complete")
│ │
── 0.37 tag ── v0.38.0–.4 Extension Continuation (Starlark, connections, libraries, git-board)
│ │
v0.38.0 Form Builder ← team admins stop writing JSON ── 0.38 tag ──
v0.38.1 Stage Reorder + Bulk Ops ← queue management at scale │
v0.38.2 SLA Alerting ← stale queues self-report v0.39.0 Stage Graph Engine + Form Builder ← graph execution + visual editing
v0.38.3 Visitor Experience ← the public face v0.39.1 Stage Reorder + Bulk Ops ← queue management at scale
v0.38.4 Workflow Templates + Clone ← reuse across teams v0.39.2 SLA Alerting ← stale queues self-report
v0.38.5 Analytics Dashboard ← throughput, bottlenecks, SLA compliance v0.39.3 Visitor Portal ← standalone branded experience
v0.39.4 Workflow Templates + Clone ← reuse across teams
v0.39.5 Analytics Dashboard ← throughput, bottlenecks, SLA compliance
│
v0.40.x Polish (bug hunt, dead code, stabilize)
│ │
─ ─ ─ MVP v0.50.0 gate ─ ─ ─ ─ ─ ─ MVP v0.50.0 gate ─ ─ ─
``` ```
@@ -33,23 +82,65 @@ v0.38.5 Analytics Dashboard ← throughput, bottlenecks, SLA compl
| Milestone | Gate | Meaning | | Milestone | Gate | Meaning |
|-----------|------|---------| |-----------|------|---------|
| v0.37 tag | **UI Complete** | Every platform capability has a surface; no features require raw API calls | | v0.37 tag | **UI Complete** | Every platform capability has a surface; no features require raw API calls |
| v0.38.0 | **Self-service** | A team admin can build a complete workflow without touching JSON or asking a global admin | | v0.38 tag | **Extensible** | Extensions can load modules, manage connections, and compose libraries; git-board proves it |
| v0.38.2 | **Operational** | Stale work surfaces automatically; team admins can manage queues without monitoring dashboards | | v0.39.0 | **Self-service** | Team admins build simple workflows visually; developers can add dynamic stages |
| v0.38.5 | **Measurable** | Team leads can answer "how long does stage X take" and "where are we bottlenecked" | | v0.39.2 | **Operational** | Stale work surfaces automatically; team admins can manage queues without monitoring dashboards |
| v0.39.5 | **Measurable** | Team leads can answer "how long does stage X take" and "where are we bottlenecked" |
--- ---
## v0.38.0 — Form Builder ## v0.39.0 — Stage Graph Engine + Form Builder
**The foundational version.** Two deliverables:
### 1. Stage Graph Engine
The workflow execution engine gains awareness of node types. Each stage
in the workflow definition includes a `stage_type` field:
```go
// Stage model additions:
type StageType string
const (
StageSimple StageType = "simple" // declarative form, built-in renderer
StageDynamic StageType = "dynamic" // Starlark hook returns form/routing
StageAutomated StageType = "automated" // no UI, Starlark only
)
// Branching rule (declarative):
type BranchRule struct {
Field string `json:"field"` // form field key or context var
Op string `json:"op"` // eq, neq, gt, lt, contains, exists
Value any `json:"value"` // comparison value
NextStage string `json:"next_stage"` // stage ID to route to
}
// Stage additions:
type Stage struct {
// ... existing fields ...
StageType StageType `json:"stage_type"`
BranchRules []BranchRule `json:"branch_rules,omitempty"` // declarative
StarlarkHook string `json:"starlark_hook,omitempty"` // package:function
}
```
The engine evaluates branch rules first; if no rule matches and a
Starlark hook is configured, it calls the hook. Default fallback is
next ordinal (existing behavior).
For automated stages, the engine calls the Starlark hook immediately
on entry and auto-advances when it returns.
### 2. Form Builder
**The single biggest gap.** `form_template` is currently raw JSON in a **The single biggest gap.** `form_template` is currently raw JSON in a
textarea. The MVP gate says "build workflows visually" — this is the textarea. The MVP gate says "build workflows visually" — this is the
make-or-break. make-or-break.
### Scope
A visual form builder embedded in the stage editor (E2 from the .15 A visual form builder embedded in the stage editor (E2 from the .15
design). Not a standalone surface — it's a panel that opens when you design). Not a standalone surface — it's a panel that opens when you
click "Edit Form" on a `form_only` or `form_chat` stage. click "Edit Form" on a `simple` or `form_chat` stage.
### Fields supported (matching existing TypedFormTemplate) ### Fields supported (matching existing TypedFormTemplate)
@@ -87,7 +178,6 @@ function FormBuilder({ initial, onSave, onCancel }) {
required: false, required: false,
}; };
if (useFieldsets && targetFieldset !== undefined) { if (useFieldsets && targetFieldset !== undefined) {
// Add to specific fieldset
setFieldsets(fs => fs.map((f, i) => setFieldsets(fs => fs.map((f, i) =>
i === targetFieldset ? { ...f, fields: [...f.fields, field] } : f i === targetFieldset ? { ...f, fields: [...f.fields, field] } : f
)); ));
@@ -209,27 +299,24 @@ function FieldEditor({ field, onChange, onRemove, allFields }) {
} }
``` ```
### BE changes
None. The form builder is pure FE — it produces the same
`TypedFormTemplate` JSON that already exists. The BE validation
in `models/workflow.go` is unchanged.
### Deliverables ### Deliverables
| File | What | | File | What |
|------|------| |------|------|
| `server/models/workflow.go` | `StageType`, `BranchRule` types; stage model additions |
| `server/engine/graph.go` | Graph execution: branch rules → Starlark hook → ordinal fallback |
| `server/engine/automated.go` | Automated stage runner (call hook, auto-advance) |
| `src/js/sw/components/form-builder/index.js` | FormBuilder root | | `src/js/sw/components/form-builder/index.js` | FormBuilder root |
| `src/js/sw/components/form-builder/field-editor.js` | FieldEditor, type-specific validators | | `src/js/sw/components/form-builder/field-editor.js` | FieldEditor, type-specific validators |
| `src/js/sw/components/form-builder/fieldset-editor.js` | Fieldset grouping | | `src/js/sw/components/form-builder/fieldset-editor.js` | Fieldset grouping |
| `src/js/sw/components/form-builder/condition-editor.js` | Conditional visibility | | `src/js/sw/components/form-builder/condition-editor.js` | Conditional visibility |
| `src/js/sw/components/form-builder/preview.js` | Live form preview | | `src/js/sw/components/form-builder/preview.js` | Live form preview |
| `src/css/form-builder.css` | Styles | | `src/css/form-builder.css` | Styles |
| Integration into StageEditor (E2 from .15) | "Edit Form" button opens builder | | Integration into StageEditor (E2 from .15) | "Edit Form" button opens builder; stage type picker |
--- ---
## v0.38.1 — Stage Reorder + Bulk Ops ## v0.39.1 — Stage Reorder + Bulk Ops
### Stage drag-and-drop ### Stage drag-and-drop
@@ -297,7 +384,7 @@ patch. YAGNI for now.
--- ---
## v0.38.2 — SLA Alerting ## v0.39.2 — SLA Alerting
The monitor already computes `sla_breached`. This version makes it The monitor already computes `sla_breached`. This version makes it
proactive instead of requiring someone to check the dashboard. proactive instead of requiring someone to check the dashboard.
@@ -340,31 +427,37 @@ The queue items (E1, E4) already render `sla_breached` badges. Add:
--- ---
## v0.38.3 — Visitor Experience ## v0.39.3 — Visitor Portal
The visitor currently gets a raw workflow surface. After .15 they get The visitor currently gets a raw workflow surface embedded in the
a terminal screen (E5) when their stages are done. This version makes app shell. This version delivers a **standalone branded portal** —
the visitor experience feel like a product. a dedicated URL with no chat chrome, optimized for the visitor
experience.
### Scope ### Scope
1. **Branded entry page** — the workflow landing page already supports 1. **Standalone portal surface** — `/w/:id/:slug` renders a
full-page portal outside the app shell. No sidebar, no user menu,
no chat chrome. The portal renders the current stage's form
(simple or dynamic) and handles stage transitions.
2. **Branded entry page** — the workflow landing page already supports
branding (`accent_color`, `logo_url`, `tagline`). Extend with: branding (`accent_color`, `logo_url`, `tagline`). Extend with:
- Custom welcome text (markdown) - Custom welcome text (markdown)
- Background image/gradient - Background image/gradient
- "Powered by" toggle (hide/show Switchboard branding) - "Powered by" toggle (hide/show Switchboard branding)
2. **Progress indicator** — visitor sees "Step 1 of N" for their 3. **Progress indicator** — visitor sees "Step 1 of N" for their
visible stages only. Internal team stages are invisible. The visible stages only. Internal team stages are invisible. The
progress bar counts only stages where the visitor is the audience. progress bar counts only stages where the visitor is the audience.
3. **Email notifications** — optional. When configured on the workflow: 4. **Email notifications** — optional. When configured on the workflow:
- Collect email at stage 0 (or extract from form data) - Collect email at stage 0 (or extract from form data)
- Send "request received" confirmation - Send "request received" confirmation
- Send "your request is complete" when workflow completes - Send "your request is complete" when workflow completes
- No notifications for internal stage transitions - No notifications for internal stage transitions
4. **Session resume** — visitor who closes the browser can return to 5. **Session resume** — visitor who closes the browser can return to
`/w/:id/:slug` and resume where they left off. Already partially `/w/:id/:slug` and resume where they left off. Already partially
implemented via `sb_session` cookie. Polish the UX: show "Welcome implemented via `sb_session` cookie. Polish the UX: show "Welcome
back, pick up where you left off" instead of starting fresh. back, pick up where you left off" instead of starting fresh.
@@ -401,16 +494,15 @@ the workflow editor with a hint.
/** /**
* VisitorProgress — step indicator for visitor-facing stages * VisitorProgress — step indicator for visitor-facing stages
* *
* Mount: workflow surface, above the stage content * Mount: workflow portal, above the stage content
* Only counts stages where audience = visitor. * Only counts stages where audience = visitor.
*/ */
function VisitorProgress({ stages, currentStage }) { function VisitorProgress({ stages, currentStage }) {
// Filter to visitor-facing stages only
const visitorStages = stages.filter(s => !s.assignment_team_id); const visitorStages = stages.filter(s => !s.assignment_team_id);
const visitorIndex = visitorStages.findIndex(s => s.ordinal === currentStage); const visitorIndex = visitorStages.findIndex(s => s.ordinal === currentStage);
const total = visitorStages.length; const total = visitorStages.length;
if (total <= 1) return null; // Single stage = no progress bar if (total <= 1) return null;
return ( return (
<div className="visitor-progress"> <div className="visitor-progress">
@@ -431,7 +523,7 @@ function VisitorProgress({ stages, currentStage }) {
--- ---
## v0.38.4 — Workflow Templates + Clone ## v0.39.4 — Workflow Templates + Clone
Team admins shouldn't rebuild common patterns from scratch. Two Team admins shouldn't rebuild common patterns from scratch. Two
features: features:
@@ -439,8 +531,9 @@ features:
### Clone workflow ### Clone workflow
"Duplicate" button on the workflow editor. Creates a new workflow with "Duplicate" button on the workflow editor. Creates a new workflow with
the same stages, form templates, and routing rules. New slug, new name the same stages, form templates, branch rules, and Starlark hooks.
(appended "- Copy"). No versions carried over (must re-publish). New slug, new name (appended "- Copy"). No versions carried over
(must re-publish).
``` ```
POST /api/v1/teams/:teamId/workflows/:id/clone POST /api/v1/teams/:teamId/workflows/:id/clone
@@ -451,15 +544,16 @@ Pure BE operation — deep-copies workflow + stages, generates new IDs.
### Built-in templates ### Built-in templates
Seed a `workflow_templates` table with 3-5 common patterns: Seed a `workflow_templates` table with common patterns covering both
simple and mixed workflows:
| Template | Stages | Description | | Template | Stages | Type |
|----------|--------|-------------| |----------|--------|------|
| Customer Intake | form → review | Public form, team reviews | | Customer Intake | form → review | Simple |
| IT Help Desk | LLM chat → triage → resolution | AI-assisted intake | | IT Help Desk | LLM chat → triage → resolution | Simple |
| Approval Chain | form → approve → approve → notify | Multi-level approval | | Approval Chain | form → approve → approve → notify | Simple |
| Feedback Survey | form (multi-step) → analytics | Data collection | | Smart Intake | automated (CRM lookup) → dynamic (tailored form) → review | Mixed |
| Onboarding | form → team A → team B → team A | Multi-team handoff | | Onboarding | form → team A → team B → automated (provision) | Mixed |
"New from template" in the team-admin workflow creation flow. "New from template" in the team-admin workflow creation flow.
Templates are read-only platform data, not user-editable. They Templates are read-only platform data, not user-editable. They
@@ -469,11 +563,11 @@ serve as starting points — clone and customize.
- "Duplicate" button in workflow editor header - "Duplicate" button in workflow editor header
- "New from Template" option in workflow creation flow - "New from Template" option in workflow creation flow
- Template picker modal with descriptions - Template picker modal with descriptions and type badges
--- ---
## v0.38.5 — Analytics Dashboard ## v0.39.5 — Analytics Dashboard
Team leads need to answer: how long does each stage take, where are Team leads need to answer: how long does each stage take, where are
we bottlenecked, what's our SLA compliance rate. we bottlenecked, what's our SLA compliance rate.
@@ -555,30 +649,38 @@ too high on large datasets (unlikely at 50-user scale).
| Version | Estimated CS | Heaviest piece | | Version | Estimated CS | Heaviest piece |
|---------|-------------|----------------| |---------|-------------|----------------|
| v0.38.0 | 4 | Form builder component tree (5+ files) | | v0.39.0 | 5 | Graph engine + form builder (10+ files) |
| v0.38.1 | 2 | Drag-and-drop is fiddly but small | | v0.39.1 | 2 | Drag-and-drop is fiddly but small |
| v0.38.2 | 3 | SLA scanner + notification plumbing | | v0.39.2 | 3 | SLA scanner + notification plumbing |
| v0.38.3 | 4 | Visitor branding + email + progress | | v0.39.3 | 4 | Standalone portal + branding + email + progress |
| v0.38.4 | 2 | Clone is one BE endpoint + FE button | | v0.39.4 | 2 | Clone is one BE endpoint + FE button |
| v0.38.5 | 3 | Analytics query + chart components | | v0.39.5 | 3 | Analytics query + chart components |
| **Total** | **~18** | | | **Total** | **~19** | |
--- ---
## Risk Notes ## Risk Notes
**v0.38.0 (Form Builder) is the long pole.** If this slips, the MVP **v0.39.0 (Graph Engine + Form Builder) is the long pole.** Two
gate phrase "build workflows visually" fails. Prioritize this over major deliverables in one version. If this slips, the MVP gate phrase
everything else in the series. If time is tight, ship a simplified "build workflows visually" fails. Prioritize this over everything
version (no fieldsets, no conditional visibility) and add those in a else in the series. If time is tight, ship the graph engine with
patch. simple stages only (dynamic/automated as stubs) and a simplified
form builder (no fieldsets, no conditional visibility), then add
dynamic/automated execution and form builder polish in a patch.
**v0.38.3 (Email) depends on platform SMTP.** If SMTP isn't **v0.39.3 (Email) depends on platform SMTP.** If SMTP isn't
configured, the feature is invisible. Consider making the email configured, the feature is invisible. Consider making the email
config a prerequisite admin step with a setup wizard, or defer email config a prerequisite admin step with a setup wizard, or defer email
to v0.38.5 and keep .3 focused on branding + progress. to v0.39.5 and keep .3 focused on the standalone portal + branding
+ progress.
**v0.38.5 (Analytics) can be cut.** If the series is running long, **v0.39.5 (Analytics) can be cut.** If the series is running long,
analytics is the most deferrable item — it's nice-to-have, not analytics is the most deferrable item — it's nice-to-have, not
gate-blocking. The existing monitor + funnel endpoints cover the gate-blocking. The existing monitor + funnel endpoints cover the
critical "is anything stuck" question. critical "is anything stuck" question.
**Dynamic stage authoring DX.** Developers need clear docs and
examples for writing Starlark hooks. The git-board rewrite (v0.38.4)
should establish patterns, but workflow-specific examples are needed.
Consider a "dynamic stage cookbook" as part of v0.39.0.