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

Feat v0.3.0 workflow schema (#14)
All checks were successful
CI/CD / detect-changes (push) Successful in 4s
Details
CI/CD / test-frontend (push) Successful in 5s
Details
CI/CD / test-go-pg (push) Successful in 2m23s
Details
CI/CD / test-sqlite (push) Successful in 2m42s
Details
CI/CD / build-and-deploy (push) Successful in 1m28s
Details

Browse Source 
Co-authored-by: Jeffrey Smith <jasafpro@gmail.com>
Co-committed-by: Jeffrey Smith <jasafpro@gmail.com>
This commit was merged in pull request #14.
This commit is contained in:
Jeffrey Smith
2026-03-27 17:52:29 +00:00
committed by xcaliber
parent 8580e1d93e
commit 965885a8f7
16 changed files with 414 additions and 161 deletions
Download Patch File Download Diff File Expand all files Collapse all files

56
ROADMAP.md
View File

@@ -123,15 +123,59 @@ Workflows are the core platform capability. This series implements the
full multi-step automation system with team role integration and
finalizes the extension lifecycle model.
### v0.3.0 — Workflow Design + Schema
### v0.3.0 — Schema Redesign + Stage CRUD Modernization (complete)
| Step | Status | Description |
|------|--------|-------------|
| Extension lifecycle | ⬚ | Define permanent vs PoC extensions. Package graduation criteria. Dependency policy. What ships with core vs what's installed separately. |
| Workflow design session | ⬚ | Define what "workflow" means in the extension-first model. Determine if the existing `workflows` table/handler survives, gets rebuilt, or gets removed. Document the Starlark contract for multi-step automation. See `docs/DESIGN-WORKFLOW-REDESIGN-0.2.6.md`. |
| Team roles | ⬚ | Different roles per team responsible for different workflow stages. Role-based stage assignment, multi-party validation (2-party sign-off at stage boundaries). |
| Trigger composition model | ⬚ | How do triggers, schedules, and workflows compose? Event chains, conditional branching, error handling. Design doc before code. |
| Settings audit pass 2 | ⬚ | Focused audit of team admin + user settings for workflow/team-role changes applied in this series. Validates new team role UI, stage assignment settings, workflow preferences. |
| Workflow schema redesign | ✅ | Dropped `persona_id`, `history_mode` from `workflow_stages`. Renamed `transition_rules` → `stage_config`. Updated `stage_mode` CHECK to `(form, review, delegated, automated)`. Added `audience`, `stage_type`, `starlark_hook`, `branch_rules`. Both PG + SQLite. |
| Model + store updates | ✅ | Go structs, constants, and PG/SQLite queries updated. New `ValidStageTypes`, `ValidAudiences` maps. Routing engine reads `branch_rules` directly. |
| Handler + Starlark updates | ✅ | Stage CRUD validation for new fields. Package export/import updated. Hook handler reads `stage_config`. Starlark module exposes `audience`, `stage_type`. |
| Frontend updates | ✅ | Team-admin and admin stage editors updated with new modes, audience selector, stage type selector, conditional Starlark hook input. Fixed admin `STAGE_MODES` bug. |
### v0.3.1 — Instance + Assignment Tables + Store
| Step | Status | Description |
|------|--------|-------------|
| Instance schema | ⬚ | Add `workflow_instances` table to 007_workflows.sql (PG + SQLite). Tracks execution state: workflow_version, current_stage, stage_data, status, entry_token. |
| Assignment schema | ⬚ | Add `workflow_assignments` table. Per-stage queue: instance_id, stage, team_id, assigned_to, status, review_data. Optimistic claim lock. |
| Models + store interface | ⬚ | `WorkflowInstance`, `WorkflowAssignment` structs. Store methods for instance lifecycle (Create, Get, Advance, Complete, Cancel, MarkStale) and assignments (Create, Claim, Unclaim, Complete). |
| Event types | ⬚ | Add `workflow.started`, `workflow.cancelled`, `workflow.sla.warning`, `workflow.sla.breached`, `workflow.error` to bus. |
### v0.3.2 — Workflow Engine + Handlers
| Step | Status | Description |
|------|--------|-------------|
| Stage execution engine | ⬚ | `server/workflow/engine.go` — advance lifecycle: validate → merge data → fire hooks → resolve next → create assignments → emit events. |
| Automated stages | ⬚ | `server/workflow/automated.go` — fire Starlark hook, auto-advance, cycle guard (max 10 consecutive). |
| Instance handlers | ⬚ | HTTP API: Start, GetInstance, Advance, Cancel, ListInstances. |
| Assignment handlers | ⬚ | HTTP API: Claim, Unclaim, Complete, Cancel, ListByTeam, ListMine. |
| Starlark module expansion | ⬚ | `workflow.get_instance()`, `workflow.advance()`, etc. |
### v0.3.3 — Public Entry + Background Jobs
| Step | Status | Description |
|------|--------|-------------|
| Public entry | ⬚ | StartPublic, ResumePublic, AdvancePublic — token-based anonymous workflow participation. |
| SLA scanner | ⬚ | Periodic goroutine checking active instances. Fire events + notifications on breach. |
| Staleness sweep | ⬚ | Mark idle instances as stale after configurable timeout. |
### v0.3.4 — Team Roles + Multi-party Validation
| Step | Status | Description |
|------|--------|-------------|
| Team roles | ⬚ | Expand `team_members.role` beyond admin/member. Role-based stage assignment rules. |
| Multi-party sign-off | ⬚ | 2-party validation at stage boundaries. |
| Extension lifecycle | ⬚ | Define permanent vs PoC packages. Graduation criteria. |
| Trigger composition | ⬚ | How triggers, schedules, and workflows compose. Design doc. |
### v0.3.5 — Settings Audit + ICD + Tests
| Step | Status | Description |
|------|--------|-------------|
| Settings audit pass 2 | ⬚ | Validate team admin + user settings for workflow/team-role changes. |
| Integration tests | ⬚ | Full instance lifecycle coverage. |
| ICD update | ⬚ | OpenAPI spec with all new endpoints. |
| Clone endpoint | ⬚ | `POST /api/v1/workflows/:id/clone` — deep copy workflow + stages. |
## v0.4.0 — Notes Surface