ai-project-bootstrap
Docs / Technology catalogue / Categories & selection rules

Categories & selection rules

Three relationships govern what a selection resolves to. They are different things and behave differently.

Field
Meaning
Effect on your selection
requires
Hard prerequisite
Pulled in transitively — selecting a module silently adds what it needs
conflicts
Mutual exclusion
Rejected at validation time before anything is generated
dependencies
Soft ordering edge
Changes nothing that is selected — only the order modules are processed in

What that looks like in practice

Selecting Supabase Auth pulls in Supabase, because it declares it in requires.
Selecting two conflicting database modules fails validation with a named reason rather than generating something broken.
dependencies exists so one module's output can assume another's already ran — it never changes the stack.

Validation order

validateSelection   every id exists, required categories answered,
                    single-select categories have one answer
resolveSelection    pull in requires transitively, reject conflicts,
                    detect cycles, produce a deterministic order

Gating questions

A question that declares fixed choices in config/categories.json shapes the wizard rather than selecting a technology — aiTools and target are the two. Their answers never reach the module resolver. Other questions opt into visibility with showWhen, and a question ruled out this way also removes any module it would have pulled in: a web-only project is never offered a mobile-only test runner.

On this page
What that looks like in practiceValidation orderGating questions
Source: ARCHITECTURE.md §Selection resolution