Created: 2026-01-28
Last Updated: 2026-06-30
Related Documents:Canonical standard: This guide is the single canonical source for the wizard conformance tiers (below).
specs/pf/specs/PF-135-wizard-conformance-and-enforcement.md- Conformance & enforcement program (defines the tier model below; supersedes the retiredWIZARD-CONSOLIDATION-PLAN.md)specs/_templates/SPEC_TEMPLATE.md(wizard flow; snippetsnippets/wizard-flow.md) - Specification templatespecs/pf/specs/PF-41-configurable-module-wizards.md- PF-41 infrastructure specsrc/platform/wizards/README.md- Platform wizard implementationdocs/development/WIZARD_WORKFLOW_RECOMMENDATIONS.md- Workflow recommendationsWIZARD_UX_STANDARD.md,specs/cross-cutting/WIZARD-PATTERN.md,WIZARD-RULES.md, and.cursor/rules/wizard-patterns.mdshould link to this section rather than restate it (PF-135 NFR-maint-1).
Quick Start
1. Create Wizard Specification
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": truein 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.jsoncarriescurrent_tier(L0/L1/L2),target_tier, andsanctioned_bespoke.npm run wizard:conformanceprints the coverage report (PF-135 SM-1). - Gate: the
wizard-governanceCI workflow runsregistry:audit(wizard scope), the spec↔registry link check,wizard:integrity,check:wizard-shell, andvalidate --type wizardas 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 viatrackWizardEvent. 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 theWIZARD_STEP_ICONS catalog:
resolveStepIcon():
Available Icon Keys
TheWIZARD_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
- Semantic relevance: Choose icons that represent the step’s purpose, not its position.
- Consistency: Use the same icon for the same concept across wizards (e.g.
userfor personal info,calendarfor scheduling). - Review/completion steps: Use
revieworcomplete— these are recognizable patterns. - No icon is acceptable: Steps without an icon fall back to step number display.
- Accessibility: Step icons are decorative (step circle has
aria-labelwith step title); no additionalaria-labelneeded on icons.
Icon Display Behavior
Phase 2: PF-41 Integration Decision
Decision Tree
Approach Comparison
Implementation Patterns
System Template (Recommended)
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-41ModuleWizardRenderer, 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 runvalidate-spec --file <path> --type wizard to catch gaps.
3. No Draft Persistence
Problem: Users lose progress when navigating away. Solution: Always implement draft persistence usinguseWizardDraft 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; snippetsnippets/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 insrc/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 bysrc/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.wizardsis wired into bootstrap for parity, butregisterRHWizardSteps()is an intentional no-op — RH admission ships as a hardcodedWizardShellflow and its PF-41StepComponentPropsadapters 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
TheWizardStep.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)
Theaudit-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 theWIZARD_STEP_ICONScatalog (src/platform/wizards/utils/stepIcons.ts); review/submit steps usereview/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, orreact-hook-form) and does not mix patterns within one wizard.
Deprecated template references
Flag legacy references for replacement:UX_WIZARD_TEMPLATE.md →
SPEC_TEMPLATE.md (wizard flow; snippet snippets/wizard-flow.md);
UX_WIZARD_PLAN_TEMPLATE.md → deprecated (merged).
Last Updated: 2026-06-03