Documentation Index
Fetch the complete documentation index at: https://grantmaster.dev/llms.txt
Use this file to discover all available pages before exploring further.
CRUD Interaction Matrix
Purpose: Decision rules for when to use modal-based vs page-based flows for Create/Read/Update/Delete operations.
Decision Matrix
| Criteria | → Modal | → Page / Wizard |
|---|
| Field count | ≤ 5 fields | > 5 fields |
| Sub-entities | None | Has nested items (budget lines, team members) |
| Workflow steps | Single step | Multi-step wizard |
| Context retention | User needs to see list behind | User focuses on creation |
| Data complexity | Simple flat record | Complex relationships or uploads |
Current Application
Modal-Based (correct usage)
| Feature | Action | Rationale |
|---|
| Expenses | Add/Edit expense | ≤ 5 fields, quick entry, list context needed |
| Contacts | Add/Edit contact | Small form, list visible behind |
| Journals | Quick time entry | Few fields, rapid data entry |
| Projects | Quick add project | Initial creation is simple |
| Compliance | Add policy | Small form |
Page-Based (correct usage)
| Feature | Action | Rationale |
|---|
| Grant Application | Full application | Multi-step wizard, complex sub-entities |
| Project Setup | Detailed setup | Nested budget lines, team members |
| Onboarding | Org setup wizard | Multi-step, focused flow |
| Grant Discovery | Detail view | Read-heavy, full-page context needed |
| Settings | All settings tabs | Multiple sections, focused editing |
Wizard-Based (correct usage)
| Feature | Action | Rationale |
|---|
| Organization Creation | Onboarding wizard | 4+ steps, progressive disclosure |
| Expense Wizard | Guided expense entry | Step-by-step with receipt upload |
| Classification | Org classification | Multi-step decision tree |
Rules for New Features
- Default to modal for simple CRUD (≤ 5 fields, no sub-entities)
- Use page when the form exceeds 5 fields or has nested collections
- Use wizard when there are 3+ sequential steps with validation between them
- Never mix — a single entity type should use one pattern consistently
- Confirmation modals are always modal (via
useConfirmDialog)
- Detail/read views are always page-based
Anti-Patterns
- Opening a full page for a 3-field form (use modal)
- Cramming 10+ fields into a modal (use page)
- Using different patterns for create vs edit of the same entity
- Skipping confirmation dialogs for destructive actions
