Skip to content

feat(workflow): show object state machines on record detail#65

Merged
xuyushun441-sys merged 1 commit into
mainfrom
feat/wire-state-machine
Jun 1, 2026
Merged

feat(workflow): show object state machines on record detail#65
xuyushun441-sys merged 1 commit into
mainfrom
feat/wire-state-machine

Conversation

@xuyushun441-sys
Copy link
Copy Markdown
Contributor

Summary

StateMachineViewer existed and was unit-tested but had no route into the app. This surfaces it as a Lifecycle diagram on the record detail page (completing the trio: actions ✅, flows ✅, state machines ✅).

  • useStateMachines / deriveStateMachines resolve each meta.stateMachines entry against the object's fields. State machines carry no explicit field link, so a machine is matched to the select field whose option values cover its state names; that field's value on the record becomes the current state. States are classified initial/normal/final and labelled from the matched field's (localized) option labels; transitions carry their event + description.
  • RecordStateMachines renders one titled card per machine.
  • StateMachineViewer gains a scrollable prop (default true, backward-compatible) so it lays out at natural height when embedded in the detail scroll view instead of collapsing a nested flex-1 ScrollView.
  • DetailViewRenderer gains a footer slot; the detail screen passes the lifecycle diagram through it, only when a machine is present.

Verification

  • ✅ In-browser against a local 7.5.0 server: the crm_opportunity Lifecycle diagram renders with the current stage (提案 / proposal) highlighted, initial (●) / final (◎) markers, transition event descriptions, and localized state labels.
  • ✅ New deriveStateMachines unit tests (field matching, initial/final classification, transitions, current-state, no-match + no-machine fallbacks) — 3 pass; existing StateMachineViewer test still green.
  • tsc --noEmit clean; full jest suite 1125 pass (20 pre-existing snapshot failures, unrelated).

Notes

Read-only diagram for now. Driving transitions (tap an outgoing edge to advance the stage) could build on the same derivation + the existing record-update path in a follow-up.

🤖 Generated with Claude Code

The StateMachineViewer existed and was unit-tested but had no route into the
app. Wire it onto record detail as a "Lifecycle" diagram:

- useStateMachines / deriveStateMachines resolve each `meta.stateMachines`
  entry against the object's fields. State machines carry no explicit field
  link, so match a machine to the select field whose option values cover its
  state names; that field's value on the record becomes the current state.
  States are classified initial/normal/final and labelled from the matched
  field's (localized) option labels; transitions carry their event +
  description.
- RecordStateMachines renders one titled card per machine.
- StateMachineViewer gains a `scrollable` prop (default true) so it lays out
  at natural height when embedded in the detail scroll view instead of
  collapsing a nested flex-1 ScrollView.
- DetailViewRenderer gains a `footer` slot; the detail screen passes the
  lifecycle diagram through it (only when a machine is present).

Verified in-browser against a local 7.5.0 server: the crm_opportunity
"Lifecycle" diagram renders with the current stage highlighted, initial/final
markers, and localized state labels. Adds deriveStateMachines unit tests;
typecheck clean; full jest suite green apart from the pre-existing snapshots.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@xuyushun441-sys xuyushun441-sys merged commit 02162fc into main Jun 1, 2026
1 of 4 checks passed
@xuyushun441-sys xuyushun441-sys deleted the feat/wire-state-machine branch June 1, 2026 19:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants