When adding or redesigning a GUI page, CLI wizard, or user-facing flow in opencodex, follow the PABCD Catalog Discovery stage ordering (CATALOG-DESIGN-FIRST-01):
- Design/UX decisions first (Product-Personality-Selection): mood, density, lightness, shape, typography, motion. Decide visual direction before functional layout.
- Domain-specific config semantics second: what entities does this surface manage (providers, models, accounts, sidecars)?
- Backend wiring derived last: API endpoints, data structures, and state management are consequences of the above, not independent decisions.
This is the design-first invariant from the PABCD Initiative
(pabcd_initiative/skills/dev-pabcd/references/catalog-discovery.yaml). It ensures
design coherence across surfaces without requiring a runtime interview engine — opencodex
is infrastructure plumbing, not a product-creation tool, so this is process discipline
for contributors, not a runtime feature.
| Surface | Current design | Notes |
|---|---|---|
| Dashboard | Data-dense, light, rounded, sans-serif | Default Bun/React template aesthetic |
ocx init CLI |
Flat numbered menu, no personality | Could benefit from staged approach |
| Add Provider modal | Functional form | Minimal styling |
| Logs page | Dense table, monospace | Appropriate for log viewing |
When next touching these surfaces, apply the Stage 1 design dials (mood, lightness, density, shape, typography, motion) before restructuring functional layout. For new surfaces, run through all 3 stages in order.
- Canonical source:
pabcd_initiative/skills/dev-pabcd/references/catalog-discovery.yaml - Design methodology: Product-Personality-Selection (dev-uiux-design §1)
- 6 design dials: mood, lightness, density, shape, typography, motion
- 7 axes total: design → domain → feature/data/security/ops/cost (derived)