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