Skip to main content
Version: 1.2
Created: 2026-01-28
Last Updated: 2026-06-30
Related Documents:
  • specs/pf/specs/PF-135-wizard-conformance-and-enforcement.md - Conformance & enforcement program (defines the tier model below; supersedes the retired WIZARD-CONSOLIDATION-PLAN.md)
  • specs/_templates/SPEC_TEMPLATE.md (wizard flow; snippet snippets/wizard-flow.md) - Specification template
  • specs/pf/specs/PF-41-configurable-module-wizards.md - PF-41 infrastructure spec
  • src/platform/wizards/README.md - Platform wizard implementation
  • docs/development/WIZARD_WORKFLOW_RECOMMENDATIONS.md - Workflow recommendations
Canonical standard: This guide is the single canonical source for the wizard conformance tiers (below). WIZARD_UX_STANDARD.md, specs/cross-cutting/WIZARD-PATTERN.md, WIZARD-RULES.md, and .cursor/rules/wizard-patterns.md should link to this section rather than restate it (PF-135 NFR-maint-1).

Quick Start

1. Create Wizard Specification

Output: specs/hr/ux/HR-UX-##-leave-request-wizard.md

2. Validate Specification

3. Generate Implementation Tasks

4. Implement and Test

Follow the implementation plan in the spec, using PF-41 infrastructure.

Wizard Conformance Tiers (PF-135)

This is the canonical definition of “a consistent wizard.” Every production wizard has a current tier and a target tier recorded in the conformance ledger (specs/cross-cutting/WIZARD_REGISTRY.json), and the wizard governance gate (npm run wizard:conformance) enforces it. The tiers are cumulative: L1 includes all of L0; L2 includes all of L1.

The three tiers

Choosing a target tier

  • L2 when an organization should be able to customize the steps (e.g. HR onboarding, HR performance review, RH resident admission — the in-flight migrations) and the flow is not regulatory-fixed.
  • L0 (sanctioned bespoke) when the flow is regulatory-mandated or schema-coupled and must not vary by org (e.g. payroll run, kiosk check-in, the PM and RH bespoke wizards). These stay hand-rolled on the engine’s chrome but are exempt from L2; they carry "sanctioned_bespoke": true in the ledger, pinned by a test so the status cannot drift.
  • L1 is the default for everything in between.
L0 is the floor — there is no exemption from it. “Intentionally bespoke” means exempt from the L2 engine, not exempt from shared chrome, accessibility, or telemetry. A wizard that renders its own stepper is non-conformant at every tier.

Conformance ledger & enforcement

  • Ledger: each entry in specs/cross-cutting/WIZARD_REGISTRY.json carries current_tier (L0/L1/L2), target_tier, and sanctioned_bespoke. npm run wizard:conformance prints the coverage report (PF-135 SM-1).
  • Gate: the wizard-governance CI workflow runs registry:audit (wizard scope), the spec↔registry link check, wizard:integrity, check:wizard-shell, and validate --type wizard as a blocking, changed-scope, ratcheted pre-merge check — new drift fails; pre-existing debt is baselined and burned down via migration waves. See PF-135 for the rollout.

Telemetry for bespoke (non-L2) wizards (PF-135 Wave 2-0)

L0 requires PHI-sanitized telemetry via trackWizardEvent. Engine (L2) wizards get it automatically from ModuleWizardRenderer. A bespoke wizard (on WizardShell / DialogWizardShell, no PF-41 template) has no template UUID — so it passes a stable wizardKey slug instead:
trackWizardEvent writes wizard_key (with template_id NULL) to pf_wizard_analytics_events. Never put PHI in metadata/validationErrors — the sanitizer drops PHI-keyed fields and throws on detection. This is the mechanical L0-telemetry step for each below-L0 wizard in the Phase-2 burndown (npm run wizard:tiers).

Standard step names

The step naming/icon conventions that L0 requires live in the deprecated-but-carried-forward table in PF-135’s predecessor and are mirrored under ## Step Icons below. New wizards MUST use the standard titles (e.g. “Review & Submit”, “Personal Information”) and a known WIZARD_STEP_ICONS key.

Wizard Development Lifecycle


Phase 1: Specification

Using SPEC_TEMPLATE.md (wizard flow; snippet snippets/wizard-flow.md)

The wizard specification template includes these key sections:

Step Definition Requirements

Each wizard step must document:

Step Icons

Every wizard step SHOULD have an icon to improve visual scanning and user orientation. Icons appear inside the step circle indicator in all three layout variants (horizontal, timeline, sidebar).

Two Layers of Icon Support

Using Icons with WizardShell (Presentational)

Pass Lucide icon components directly in the steps array:

Using Icons in PF-41 Templates (JSON Config)

For configurable wizard templates stored in the database, use string icon keys from the WIZARD_STEP_ICONS catalog:
Resolve string keys to components using resolveStepIcon():

Available Icon Keys

The WIZARD_STEP_ICONS catalog in @/platform/wizards provides ~50 curated icons organized by category: Adding new icons: Add to src/platform/wizards/utils/stepIcons.ts, update this table, and follow the Icon Guide. Healthcare examples: examples/wizard-templates/healthcare-icon-keys.json — copy-paste PF-41 snippets for stethoscope, pill, syringe. Unknown icon keys (fallback behavior): If a template references an icon key that isn’t in WIZARD_STEP_ICONS and doesn’t match a module code, resolveStepIcon() returns the FALLBACK_STEP_ICON (CircleHelp from Lucide) so the step indicator stays visible instead of silently collapsing to the step number. In development, a one-time console.warn per unknown key surfaces the typo to the author; the warning is stripped from production builds. Authors should still pick a real key from the catalog — the fallback is a safety net, not a sanctioned wildcard. An empty/missing icon field is treated as the intentional “show the step number” mode and does not trigger the fallback.

Icon Selection Rules

  1. Semantic relevance: Choose icons that represent the step’s purpose, not its position.
  2. Consistency: Use the same icon for the same concept across wizards (e.g. user for personal info, calendar for scheduling).
  3. Review/completion steps: Use review or complete — these are recognizable patterns.
  4. No icon is acceptable: Steps without an icon fall back to step number display.
  5. Accessibility: Step icons are decorative (step circle has aria-label with step title); no additional aria-label needed on icons.

Icon Display Behavior


Phase 2: PF-41 Integration Decision

Decision Tree

Approach Comparison

Implementation Patterns

Module-Specific

Hybrid


Phase 3: Implementation

File Structure

Custom Step Component Pattern

Step Registration (PF-41)

Draft Persistence


Phase 4: Testing

Required Tests

Unit Test Example

E2E Test Example


Phase 5: Analytics Integration

Standard Events

All wizards should track these events:

PF-41 Built-in Analytics

When using PF-41 ModuleWizardRenderer, analytics are tracked automatically:

Phase 6: Deployment

Feature Flags

Use feature flags for gradual rollout:

System Template Deployment

For PF-41 system templates, create a migration:

Common Pitfalls

1. Missing PF-41 Integration Documentation

Problem: Spec doesn’t document PF-41 approach. Solution: Always include the “PF-41 Wizard Architecture” section, even for module-specific wizards:

2. Incomplete Step Definitions

Problem: Steps missing validation rules, help content, or mobile considerations. Solution: Use the complete step template and run validate-spec --file <path> --type wizard to catch gaps.

3. No Draft Persistence

Problem: Users lose progress when navigating away. Solution: Always implement draft persistence using useWizardDraft or PF-41’s built-in draft management.

4. Missing Analytics

Problem: No tracking of wizard usage and drop-off points. Solution: Include the Analytics Events section in spec and implement tracking.

5. Poor Mobile Experience

Problem: Wizard unusable on mobile devices. Solution:
  • Use the mobile checklist per step
  • Test on actual mobile devices
  • Include mobile E2E tests

Commands Reference

Full workflow:

Resources

  • Specification Template: specs/_templates/SPEC_TEMPLATE.md (wizard flow; snippet snippets/wizard-flow.md)
  • PF-41 Spec: specs/pf/specs/PF-41-configurable-module-wizards.md
  • Platform Implementation: src/platform/wizards/README.md
  • Consolidation Plan: specs/cross-cutting/WIZARD-CONSOLIDATION-PLAN.md
  • Cross-Cutting Patterns: specs/cross-cutting/WIZARD-PATTERN.md
  • Cross-Cutting Rules: specs/cross-cutting/WIZARD-RULES.md
  • Selection Guide: docs/guides/use-cases/wizard-selection.md
  • UX Standard: docs/development/WIZARD_UX_STANDARD.md
  • Icon Guide: docs/development/ICON_GUIDE.md
  • Workflow Recommendations: docs/development/WIZARD_WORKFLOW_RECOMMENDATIONS.md
  • Analytics Guide: docs/pf/wizard-analytics-guide.md
  • Branching Guide: docs/pf/wizard-branching-guide.md
  • Marketplace Guide: docs/pf/wizard-marketplace-guide.md

Architecture Recommendations

Wizard Infrastructure Audit Findings (2026-04-14)

The platform currently has three distinct wizard rendering paths. This section documents known gaps, recommended consolidations, and standards to enforce going forward.

1. Consolidate Step Registration at Bootstrap

Wizard step registration should happen centrally in src/bootstrap/registerModuleWizardSteps.ts so module entry points do not race dynamic step availability. Current baseline (recommended pattern): register all core step modules in registerAllModuleWizardSteps():
The live implementation also logs per-module failures with module id and registrar-function metadata (module, wizard_module_id, register_fn) and short-circuits retries during HMR. Coverage is enforced by src/bootstrap/registerModuleWizardSteps.test.ts, which asserts every registrar resolves to a callable function and that the expected step IDs land in the registry. RH parity no-op: rh.wizards is wired into bootstrap for parity, but registerRHWizardSteps() is an intentional no-op — RH admission ships as a hardcoded WizardShell flow and its PF-41 StepComponentProps adapters are deferred. The bootstrap test pins this empty registration so the deferred status cannot drift silently.

2. Deprecate Custom Stepper UIs

Custom stepper usage should be triaged as either (a) migration target or (b) documented exception: New wizard builds MUST NOT create custom steppers. Allowed exceptions are limited to non-wizard patterns (parallel tabs, schema-section progress) and should be explicitly documented in spec/guide artifacts.

3. Icon String Resolution for Template Wizards

The WizardStep.icon field (JSON config) accepts a string, while WizardShellStep.icon (presentational) accepts a React component. The resolveStepIcon() utility bridges this gap. ModuleWizardRenderer and any code converting template steps to shell steps SHOULD use resolveStepIcon() to map string keys to components.

4. Standardize Wizard Validation Patterns

Three validation patterns exist across wizard implementations: Avoid mixing patterns within the same wizard. Template-driven wizards should use PF-41 validation exclusively.

5. Wizard Selection Decision Tree

6. Standard Step Naming Conventions

Steps across all wizards SHOULD follow these naming patterns for consistency:

Wizard Spec Scoring Rubric (100 points)

The audit-wizard-specs command scores each wizard spec out of 100 using the allocation below. Passing is ≥80% (60–79% needs work, <60% critical). Header (10 pts): Feature ID format {CORE}-UX-## (2), Version present (1), Status present (1), Owner matches core (2), Dependencies include wizard infra (2), Created/Updated dates (2). Core sections (25 pts): Business Context & Problem Statement (5), Objectives & Success Criteria (5), Scope — In/Out (5), User Stories (5), Integration Points (5). Wizard-specific sections (25 pts): Wizard Step Definitions (10), Navigation & Flow (10), Wizard & Help UX Guidance (5). PF-41 integration (15 pts): PF-41 Architecture section present (10), Template Type Decision documented (5). Step definitions (15 pts), per step: Purpose (2), Type (2), Icon key from WIZARD_STEP_ICONS (2), Fields/Components (3), Validation Rules (3), Help Content (3). Testing Strategy (10 pts): Unit Tests section (3), Integration Tests section (3), E2E Tests section (4).

Step icon, naming, and validation-pattern checks

Beyond scoring, audit-wizard-specs flags per-step compliance:
  • Icon: each step declares a Step Icon: (or icon in the Step Type Summary table) whose key is from the WIZARD_STEP_ICONS catalog (src/platform/wizards/utils/stepIcons.ts); review/submit steps use review / complete.
  • Naming: step titles follow the Standard Step Naming Conventions above (e.g. “Review & Submit” not “Review”/“Summary”; “Personal Information” not “Employee Info”/“Basic Info”).
  • Validation pattern: the spec declares a pattern per step (pf-41-rules, step-component-props, or react-hook-form) and does not mix patterns within one wizard.

Deprecated template references

Flag legacy references for replacement: UX_WIZARD_TEMPLATE.mdSPEC_TEMPLATE.md (wizard flow; snippet snippets/wizard-flow.md); UX_WIZARD_PLAN_TEMPLATE.md → deprecated (merged).
Last Updated: 2026-06-03