@maccesar/titools 4.3.0 → 4.4.0

package/README.md

@@ -333,6 +333,10 @@ When it activates:
 - Choosing data strategies (Models vs Collections)
 - Writing clean ES6+ code
 - Memory management and cleanup patterns
+- Choosing a feedback surface (Snackbar, Dialog, Bottom Sheet) and deciding what stays native
+- Designing reusable Alloy Widgets and their lifecycle contracts
+- Adaptive layouts for tablets, foldables, and large screens
+- Theming and dark mode
 - Performance optimization
 - Security patterns
 - Migrating legacy apps
@@ -343,13 +347,15 @@ Example prompts:
 "Create a user service that fetches data from an API."
 "What's the best pattern for navigation between screens?"
 "Prevent memory leaks in my controllers."
+"Every confirmation in my app is an alertDialog — what should each one actually be?"
+"Should this be a Widget or just a <Require>?"
 "Migrate classic Titanium code to modern Alloy patterns."
 "What's a clean way to organize services in an Alloy app?"
 ```
 
 Key features:
 - Quick decision matrix for common questions
-- 21 reference guides for deep dives
+- 24 reference guides for deep dives
 - Delegates to specialized skills when needed
 
 ---
@@ -718,7 +724,7 @@ This pattern is documented across three TiTools skills: `ti-ui`, `ti-expert`, an
 
 | Skill     | SKILL.md                      | References                                            |
 | --------- | ----------------------------- | ----------------------------------------------------- |
-| ti-expert | Architecture + Implementation | 21 files (patterns, testing, security, etc.)          |
+| ti-expert | Architecture + Implementation | 24 files (patterns, feedback surfaces, testing, security, etc.) |
 | purgetss  | Setup + Critical Rules        | 33 files (grid, animations, icons, class-index, SVG pipeline, etc.) |
 | ti-ui     | UI Rules + Platform Diffs     | 14 files (layouts, lists, gestures, etc.)             |
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@maccesar/titools",
-  "version": "4.3.0",
+  "version": "4.4.0",
   "description": "Titanium SDK skills and agents for AI coding assistants (Claude Code, Gemini CLI, Codex CLI)",
   "main": "lib/index.js",
   "type": "module",

package/skills/ti-expert/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: ti-expert
-description: "Use when designing, reviewing, analyzing, or examining Titanium SDK architecture and implementation (Alloy or Classic) — creating controllers/views/services, choosing models vs collections, implementing communication patterns, handling memory cleanup, testing, auditing code, migrating legacy apps, or building adaptive/responsive layouts for tablets, foldables, and large screens. AUTO-DETECT: If tiapp.xml exists, invoke BEFORE making architectural decisions, creating new controllers/views, or restructuring code. Titanium has its own patterns for navigation (NavigationWindow, TabGroup), memory management, and event handling that differ from web frameworks."
+description: "Use when designing, reviewing, auditing, analyzing, or examining Titanium SDK architecture and implementation (Alloy or Classic) — creating controllers/views/services, choosing models vs collections, deciding between app-owned and system UI, designing reusable Widgets or feedback/modality patterns, hunting memory leaks and cleanup gaps, testing, migrating legacy apps, or building adaptive layouts for tablets, foldables, and large screens. AUTO-DETECT: If tiapp.xml exists, invoke BEFORE architectural decisions, new controllers/views, feedback components, or restructuring. Titanium navigation, memory, event, and modal patterns differ from web frameworks."
 argument-hint: "[architecture-topic]"
 allowed-tools: Read, Grep, Glob, Edit, Write, Bash(git *), Bash(node *)
 ---
@@ -9,6 +9,26 @@ allowed-tools: Read, Grep, Glob, Edit, Write, Bash(git *), Bash(node *)
 
 Practical architecture and implementation guidance for Titanium SDK apps (Alloy and Classic). Focus on maintainability, clear boundaries, and low-friction testing.
 
+## Required workflow
+
+This file is an index. Read the references that govern the task before making a
+recommendation or changing code.
+
+| Task | Required reading |
+| --- | --- |
+| Architecture tier, folders, or boundaries | [Architecture tiers](references/architecture-tiers.md), [Alloy structure](references/alloy-structure.md) |
+| Feedback, alerts, choices, or app-owned versus system UI | [Feedback surfaces](references/feedback-surfaces.md) |
+| Reusable Snackbar, Dialog, Bottom Sheet, Widget, or `<Require>` | [Feedback Widget contracts](references/feedback-widget-contracts.md), [Alloy structure](references/alloy-structure.md) |
+| Migrating native dialogs, Toasts, or local overlays | [Feedback migration](references/feedback-migration.md), [Migration patterns](references/migration-patterns.md) |
+| Theme or dark mode | [Theming](references/theming.md); if PurgeTSS is detected, invoke the `purgetss` skill before styling |
+| Tablet, foldable, large screen, or responsive behavior | [Adaptive layouts](references/adaptive-layouts.md) |
+| Security architecture | [Security fundamentals](references/security-fundamentals.md), [Device security](references/security-device.md) |
+| Testing or performance | Load the matching guide under Quality & Performance below |
+
+Support recommendations with `[source: references/<file>.md]`. If a claim cannot
+be verified from the loaded references or inspected project, prefix it with
+`FROM_MEMORY (unverified):` and do not present it as a settled project fact.
+
 ## Project detection
 
 > **️ℹ️ Auto-detects Alloy vs Classic projects**
@@ -33,9 +53,10 @@ Practical architecture and implementation guidance for Titanium SDK apps (Alloy
 1. Architecture: define structure by technical type with flat folders (`lib/api`, `lib/services`, `lib/actions`, `lib/repositories`, `lib/helpers`)
 2. Data strategy: choose Models (SQLite) or Collections (API)
 3. Contracts: define I/O specs between layers
-4. Implementation: write XML views and ES6+ controllers
-5. Quality: testing, error handling, logging, performance
-6. Cleanup: implement a `cleanup()` pattern for memory management
+4. UI ownership: classify app-owned feedback, screen state, and system-owned flows
+5. Implementation: write XML views and ES6+ controllers
+6. Quality: testing, error handling, logging, performance
+7. Cleanup: implement a `cleanup()` pattern for memory management
 
 ## Architectural Maturity Tiers
 
@@ -84,6 +105,12 @@ Detailed examples and full implementation samples are available in: [Architectur
 
 ## Titanium style sheets rules (low freedom)
 
+Before styling, detect `purgetss/` or `purgetss/config.cjs`. If present, invoke
+the `purgetss` skill, verify every utility, and never edit the generated
+`app/styles/app.tss`. Without PurgeTSS, use standard Alloy TSS files. In either
+case, keep behavior in XML/controllers and use semantic colors for app-owned
+surfaces when the project supports them.
+
 > **🚨 Critical: platform-specific properties require modifiers**
 > Using `Ti.UI.iOS.*` or `Ti.UI.Android.*` properties without platform modifiers breaks cross-platform builds.
 >
@@ -138,7 +165,10 @@ For the complete reference with examples, see [Alloy builtins and globals](refer
 | Models or Collections?             | Collections for API data, Models for SQLite persistence        |
 | Ti.App.fireEvent or EventBus?      | Always EventBus (Backbone.Events)                              |
 | Direct navigation or service?      | Always Navigation service (auto cleanup)                       |
-| Inline styles or TSS files?        | Always TSS files (per-controller + `app.tss` for global)       |
+| Snackbar, Dialog, or Bottom Sheet? | Classify urgency, persistence, reversibility, and choice first |
+| Widget or `<Require>`?             | Widget for a self-contained API/lifecycle; `<Require>` for app composition |
+| App-owned or native UI?            | Keep OS trust/protected flows native; style app-owned feedback |
+| Inline styles or style system?     | PurgeTSS utilities when detected; otherwise Alloy TSS          |
 
 ## Reference guides (progressive disclosure)
 
@@ -155,6 +185,9 @@ For the complete reference with examples, see [Alloy builtins and globals](refer
 - [Alloy Builtins & Globals](references/alloy-builtins.md)
 - [Code Conventions](references/code-conventions.md)
 - [Controller Patterns](references/controller-patterns.md)
+- [Feedback Surfaces & App-Owned UI](references/feedback-surfaces.md)
+- [Feedback Widget Contracts](references/feedback-widget-contracts.md)
+- [Feedback Migration](references/feedback-migration.md)
 - [Theming & Dark Mode](references/theming.md)
 - [Migration Patterns](references/migration-patterns.md)
 - [Examples Collection](references/examples.md)

package/skills/ti-expert/references/alloy-builtins.md

@@ -75,13 +75,6 @@ Shared state and utilities accessible from any controller or lib file. Set in `a
 // alloy.js
 const Backbone = require('alloy/backbone')
 
-// --- Theme / Design Tokens ---
-Alloy.Globals.theme = {
-  primary: '#2563eb',
-  bg: '#ffffff',
-  text: '#111827'
-}
-
 // --- Device Info (cached once) ---
 Alloy.Globals.isTablet = Alloy.isTablet
 Alloy.Globals.screenWidth = Ti.Platform.displayCaps.platformWidth
@@ -100,27 +93,23 @@ Alloy.Collections.notifications = new Backbone.Collection()
 ### Access from anywhere
 
 ```javascript
-// In any controller
-const theme = Alloy.Globals.theme
-$.label.color = theme.primary
-
-// In TSS (evaluated at compile time for controller creation)
-"#header": {
-  backgroundColor: Alloy.Globals.theme.primary
-}
-
 // In XML with conditional binding
 // <View if="Alloy.Globals.isLoggedIn">
 ```
 
+Do not use `Alloy.Globals` as the default dark-mode palette. Prefer Titanium
+semantic colors; when PurgeTSS is detected, use its semantic color and Appearance
+workflow. Reserve a global runtime palette for custom theme requirements that
+semantic light/dark/system roles cannot model. See [Theming](theming.md).
+
 ### Globals vs services
 
-| Use `Alloy.Globals` for            | Use a Service for             |
-| ---------------------------------- | ----------------------------- |
-| Static config (theme, device info) | Business logic                |
-| Simple flags (isLoggedIn)          | Complex state with listeners  |
-| Values set once in `alloy.js`      | Values that change frequently |
-| Read-only data                     | Data with side effects        |
+| Use `Alloy.Globals` for               | Use a Service for             |
+| ------------------------------------- | ----------------------------- |
+| Immutable device/build facts          | Business logic                |
+| Framework-level shared registries     | Complex state with listeners  |
+| Values initialized once in `alloy.js` | Values that change frequently |
+| Read-only interoperability data       | Data with side effects        |
 
 ---
 

package/skills/ti-expert/references/alloy-structure.md

@@ -30,7 +30,7 @@ app/
 │   ├── home.xml
 │   └── userProfile.xml
 ├── styles/               # TSS styles (one per view + global)
-│   ├── app.tss           # Global application styles
+│   ├── app.tss           # Standard Alloy global styles or PurgeTSS generated output
 │   ├── index.tss         # Styles for index view
 │   ├── home.tss
 │   └── userProfile.tss
@@ -59,7 +59,7 @@ app/
 │   └── providers/
 │       ├── containerProvider.js
 │       └── loggerProvider.js
-├── widgets/              # Truly reusable components (used in 3+ places)
+├── widgets/              # Self-contained components with an API/lifecycle boundary
 │   └── customButton/
 ├── config.json           # Alloy configuration
 └── alloy.js              # Collections & Global services
@@ -188,7 +188,8 @@ api.getFrames()
 ## Controller rules
 
 **DO:**
-- Define styles in TSS files (per-controller + `app.tss` for global).
+- Use verified PurgeTSS utilities when detected; otherwise define styles in
+  per-controller TSS and manually maintained global TSS.
 - Orchestrate view and model/collection interactions.
 - Handle UI events and delegate to services.
 - Format data for display (simple cases).
@@ -196,7 +197,7 @@ api.getFrames()
 - Keep `lib` modules flat and easy to locate.
 
 **DON'T:**
-- Use inline style attributes in XML (define in TSS files).
+- Scatter visual properties inline when the active style system can express them.
 - Make direct API calls (use lib/api/ or lib/services/).
 - Contain heavy business logic.
 - Call native modules directly (use a service wrapper).
@@ -245,7 +246,10 @@ See [ControllerAutoCleanup.js](../assets/ControllerAutoCleanup.js) for the compl
 
 ## Widget structure
 
-Widgets are self-contained, reusable components used in 3+ places across the app.
+Widgets are self-contained components with their own public API, state, assets,
+and lifecycle. Choose one for a portable boundary, not after an arbitrary number
+of usages. A first-use component with timers, modal state, and cleanup can merit
+a Widget; repeated static styling does not.
 
 ```
 app/widgets/
@@ -255,7 +259,7 @@ app/widgets/
     ├── views/
     │   └── widget.xml     # Main widget view
     ├── styles/
-    │   └── widget.tss     # Widget-specific styles
+    │   └── widget.tss     # Optional component-specific styles
     └── widget.json        # Widget manifest
 ```
 
@@ -276,6 +280,17 @@ app/widgets/
 }
 ```
 
+Register the Widget in the app's `app/config.json`; the dependency key must
+match the manifest `id`:
+
+```json
+{
+  "dependencies": {
+    "com.app.loadingOverlay": "1.0.0"
+  }
+}
+```
+
 ### Widget view (widget.xml)
 ```xml
 <Alloy>
@@ -290,10 +305,10 @@ app/widgets/
 
 ```tss
 /* styles/widget.tss */
-"#container": { width: Ti.UI.FILL, height: Ti.UI.FILL, visible: false, backgroundColor: 'rgba(0,0,0,0.5)' }
-"#box": { width: 128, height: 128, layout: 'vertical', borderRadius: 16, backgroundColor: '#fff' }
+"#container": { width: Ti.UI.FILL, height: Ti.UI.FILL, visible: false, backgroundColor: 'overlayColor' }
+"#box": { width: 128, height: 128, layout: 'vertical', borderRadius: 16, backgroundColor: 'surfaceColor' }
 "#spinner": { top: 24 }
-"#messageLabel": { left: 16, right: 16, top: 16, font: { fontSize: 14 }, color: '#4b5563' }
+"#messageLabel": { left: 16, right: 16, top: 16, font: { fontSize: 14 }, color: 'textColor' }
 ```
 
 ### Widget controller (widget.js)
@@ -352,8 +367,12 @@ const loadData = () => {
 }
 ```
 
-> **💡 Widget Styles**
-> Widgets have their own `styles/widget.tss` file. Define all widget-specific styles there to keep them self-contained and portable.
+> **Widget styles**
+> In a standard Alloy project, keep component-specific properties in
+> `styles/widget.tss` and consume semantic colors. If PurgeTSS is detected, load
+> its skill first, enable Widget scanning, place verified utilities in XML, and
+> reserve `widget.tss` for properties with no utility. Never edit the generated
+> `app/styles/app.tss`.
 
 ### Widget ↔ controller communication
 
@@ -464,13 +483,18 @@ render()
 
 ### When to use widget vs require
 
-| Use `<Widget>` when                   | Use `<Require>` when            |
-| ------------------------------------- | ------------------------------- |
-| Component is used in 3+ places        | Component is used in 1-2 places |
-| Needs its own self-contained styles   | Shares styles with parent       |
-| Has public API (show/hide/setValue)   | Just renders, no API needed     |
-| Could be extracted to another project | Specific to this app            |
-| Needs its own `widget.json` manifest  | Lightweight, no manifest needed |
+| Use `<Widget>` when                   | Use `<Require>` when                 |
+| ------------------------------------- | ------------------------------------ |
+| Owns a stable public API              | Composes an app-specific controller  |
+| Owns state, timers, listeners, or cleanup | Shares the host's lifecycle       |
+| Has a portable design-system boundary | Shares the host's domain and styling |
+| Could be extracted to another project | Has no independent package contract  |
+| Needs its own `widget.json` manifest  | Remains lightweight and app-local    |
+
+Usage count is supporting evidence only. Also consider a screen-local XML state
+for loading/empty/error content, a style class for appearance without behavior,
+or native UI when the operating system owns the workflow. See
+[Feedback Widget Contracts](feedback-widget-contracts.md).
 
 ## config.json reference
 

package/skills/ti-expert/references/anti-patterns.md

@@ -67,14 +67,22 @@
 ## 13. Using `Ti.UI.createNotification`
 **Symptom:** `Ti.UI.createNotification({ message: 'Hi' }).show()`
 **Problem:** This API doesn't exist in Titanium. Causes "invalid method" error.
-**Solution:** Use `Ti.UI.createAlertDialog` for simple messages, or create custom toast views.
+**Solution:** Classify the feedback before choosing UI. Use the app's Snackbar
+Widget for transient foreground feedback, inline/Banner state for persistent
+conditions, and an app-owned Dialog only for blocking or critical information.
+Use the supported platform notification APIs only for actual OS notifications.
+See [Feedback Surfaces](feedback-surfaces.md).
 
 ## 14. Using nonexistent iOS share APIs
 **Symptom:** `Ti.UI.iOS.createActivityPopover` or `alloy/social` with wrong methods.
 **Problem:** These APIs either don't exist or have changed. Causes runtime errors.
 **Solution:**
-- iOS: Use `Ti.UI.iOS.createDocumentViewer` for files, or simple `Ti.UI.createOptionDialog` + `Ti.UI.Clipboard` for links
-- Android: Use `Ti.Android.createIntent` with ACTION_SEND
+- Keep sharing system-owned. Use the currently supported Titanium share/document
+  API or native module for the target platform and verify its current contract
+  with the `ti-api` skill.
+- Do not imitate a share sheet with an app-owned `OptionDialog`. A Bottom Sheet
+  may choose an app action such as an export format, but the OS share surface
+  owns the final destination.
 
 ## Community-Discovered Patterns
 
@@ -117,8 +125,8 @@ This applies to Windows inside both standalone NavigationWindow and TabGroup (wh
 | ----------------------- | ------------------------ | --------------------- |
 | `padding` on View       | No padding on containers | Margins on children   |
 | `layout: 'composite'`   | Already default          | Omit it               |
-| Inline style attributes | Scattered styling        | Define in TSS files   |
+| Inline style attributes | Scattered styling        | PurgeTSS utilities when detected; otherwise TSS |
 | `lib/` prefix           | lib/ is flattened        | Use path without lib/ |
 | `$.index.open()`        | Wrong ID reference       | Use actual Window ID  |
-| `createNotification`    | API doesn't exist        | `createAlertDialog`   |
+| `createNotification`    | API doesn't exist        | Classify feedback; Snackbar is the transient default |
 | `extendEdges` alone     | Content behind nav bar   | Add `autoAdjustScrollViewInsets: true` |

package/skills/ti-expert/references/code-conventions.md

@@ -54,9 +54,15 @@ const name = user.name
 
 ## Styling with TSS
 
+First detect `purgetss/` or `purgetss/config.cjs`. If present, invoke the
+`purgetss` skill, use verified utilities, and do not edit generated
+`app/styles/app.tss`. The manual TSS organization below applies when PurgeTSS is
+not present or to specific properties for which that skill confirms no utility.
+
 ### TSS file organization
 
-Every controller can have a matching TSS file. Alloy also supports a global `app.tss`.
+Every controller can have a matching TSS file. Standard Alloy also supports a
+manually maintained global `app.tss`.
 
 ```
 app/styles/
@@ -95,7 +101,7 @@ app/styles/
 | Selector            | Use for                     | Example                |
 | ------------------- | --------------------------- | ---------------------- |
 | Element (`"Label"`) | App-wide defaults           | Base font, color       |
-| Class (`".card"`)   | Reusable patterns (3+ uses) | Cards, buttons, inputs |
+| Class (`".card"`)   | Reusable visual pattern     | Cards, buttons, inputs |
 | ID (`"#name"`)      | Unique element positioning  | Specific layout needs  |
 
 ### Class selectors in XML
@@ -127,7 +133,7 @@ When an element has both an ID and classes, properties merge with ID taking prio
 <Button id="saveButton" class="btn-primary" title="L('save')" />
 ```
 
-### Building a design system in app.tss
+### Building a standard Alloy design system in app.tss
 
 Define reusable style classes for consistency:
 

package/skills/ti-expert/references/controller-patterns.md

@@ -281,43 +281,42 @@ async function loadData() {
 
 ## Modal and dialog patterns
 
+Declare the app-owned `dialog` and `bottomSheet` Widgets in the window XML.
+Attach them after the host exists and destroy them from the controller cleanup.
+Keep a modal Window for a distinct multi-step task, not for ordinary feedback.
+
 ```javascript
-// AlertDialog
+function attachFeedback(hostWindow) {
+  $.dialog.attach(hostWindow)
+  $.bottomSheet.attach(hostWindow)
+}
+
+// Critical, irreversible confirmation
 function showConfirmDelete(itemName) {
-  const dialog = Ti.UI.createAlertDialog({
+  $.dialog.show({
     title: L('confirm_delete'),
     message: String.format(L('delete_message'), itemName),
-    buttonNames: [L('cancel'), L('delete')],
-    cancel: 0,
-    destructive: 1 // iOS: red button
-  })
-
-  dialog.addEventListener('click', (e) => {
-    if (e.index === 1) {
-      performDelete()
-    }
+    cancelTitle: L('cancel'),
+    confirmTitle: L('delete'),
+    destructive: true,
+    tone: 'warning',
+    onConfirm: performDelete
   })
-
-  dialog.show()
 }
 
-// OptionDialog (Action Sheet)
+// Contextual choices
 function showSortOptions() {
-  const options = [L('sort_name'), L('sort_date'), L('sort_price')]
+  const items = [
+    { id: 'name', title: L('sort_name') },
+    { id: 'date', title: L('sort_date') },
+    { id: 'price', title: L('sort_price') }
+  ]
 
-  const dialog = Ti.UI.createOptionDialog({
+  $.bottomSheet.show({
     title: L('sort_by'),
-    options: [...options, L('cancel')],
-    cancel: options.length
-  })
-
-  dialog.addEventListener('click', (e) => {
-    if (e.index < options.length) {
-      applySortOption(e.index)
-    }
+    items,
+    onSelect: item => applySortOption(item.id)
   })
-
-  dialog.show()
 }
 
 // Modal Window
@@ -341,6 +340,14 @@ function openModal(route, params) {
 
   return controller
 }
+
+function cleanup() {
+  $.dialog.destroy()
+  $.bottomSheet.destroy()
+  $.destroy()
+}
+
+$.cleanup = cleanup
 ```
 
 ## Tabgroup pattern

package/skills/ti-expert/references/examples.md

@@ -3,6 +3,7 @@
 <!-- TOC-START -->
 ## Contents
 
+- [Reading these examples](#reading-these-examples)
 - [API client service](#api-client-service)
 - [Native module wrapper service](#native-module-wrapper-service)
 - [i18n helper](#i18n-helper)
@@ -17,6 +18,19 @@
 
 <!-- TOC-END -->
 
+## Reading these examples
+
+Snippets that call `$.dialog`, `$.bottomSheet`, or `$.snackbar` expect the app to
+own those surfaces as Alloy Widgets under `app/widgets/`. Their public API,
+queueing, and cleanup rules live in [Feedback Widget Contracts](feedback-widget-contracts.md);
+[Feedback Surfaces](feedback-surfaces.md) covers which surface a given event
+deserves. The `<Widget>` declaration alone will not compile until those Widgets
+exist and are registered in `app/config.json`.
+
+Styles below carry literal hex values so each example reads on its own. Production
+code should name semantic color roles instead, so light and dark resolve without a
+second code path — see [Theming and dark mode](theming.md).
+
 ## API client service
 Standard logic for network requests.
 
@@ -350,6 +364,8 @@ $.cleanup = cleanup
       <ImageView id="emptyIcon" image="/images/search.png" />
       <Label id="emptyLabel" text="L('no_results')" />
     </View>
+
+    <Widget id="bottomSheet" src="com.example.ui.bottomsheet" />
   </Window>
 </Alloy>
 ```
@@ -375,6 +391,7 @@ let searchQuery = ''
 let debounceTimer = null
 
 function init() {
+  $.bottomSheet.attach($.contactsWindow)
   loadData()
 
   $.searchBar.addEventListener('cancel', clearSearch)
@@ -395,21 +412,23 @@ function clearSearch() {
 }
 
 function showFilters() {
-  const dialog = Ti.UI.createOptionDialog({
+  const items = [
+    { id: 'all', title: L('all') },
+    { id: 'work', title: L('work') },
+    { id: 'personal', title: L('personal') },
+    { id: 'family', title: L('family') }
+  ]
+
+  $.bottomSheet.show({
     title: L('filter_by_category'),
-    options: ['All', 'Work', 'Personal', 'Family', L('cancel')],
-    cancel: 4
-  })
-
-  dialog.addEventListener('click', (e) => {
-    if (e.index < 4) {
-      activeFilters.category = e.index === 0 ? null : ['work', 'personal', 'family'][e.index - 1]
+    items,
+    selectedId: activeFilters.category || 'all',
+    onSelect: item => {
+      activeFilters.category = item.id === 'all' ? null : item.id
       updateFilterTags()
       applyFilters()
     }
   })
-
-  dialog.show()
 }
 
 function applyFilters() {
@@ -465,6 +484,7 @@ function createFilterTag(label, onRemove) {
 
 function cleanup() {
   clearTimeout(debounceTimer)
+  $.bottomSheet.destroy()
   $.searchBar.removeEventListener('change', onSearchChange)
   $.destroy()
 }
@@ -530,6 +550,7 @@ $.cleanup = cleanup
           <Switch id="termsSwitch" />
           <Label id="termsLabel" text="L('accept_terms')" />
         </View>
+        <Label id="termsError" />
 
         <!-- Register Button -->
         <Button id="registerBtn"
@@ -544,6 +565,8 @@ $.cleanup = cleanup
         </View>
       </View>
     </ScrollView>
+
+    <Widget id="dialog" src="com.example.ui.dialog" />
   </Window>
 </Alloy>
 ```
@@ -570,6 +593,7 @@ $.cleanup = cleanup
 "#termsRow": { layout: 'horizontal', left: 16, right: 16, top: 24, width: Ti.UI.FILL }
 "#termsSwitch": { width: 48 }
 "#termsLabel": { left: 8 }
+"#termsError": { left: 16, right: 16, top: 4, font: { fontSize: 12 }, color: '#ef4444', visible: false }
 "#registerBtn": { left: 16, right: 16, top: 24, height: 56, borderRadius: 12, backgroundColor: '#2563eb', color: '#fff', font: { fontWeight: 'bold' } }
 "#loginRow": { layout: 'horizontal', top: 16 }
 "#haveAccountLabel": { font: { fontSize: 14 }, color: '#4b5563' }
@@ -611,6 +635,8 @@ const validators = {
 }
 
 function init() {
+  $.dialog.attach($.registerWindow)
+
   // Field navigation
   $.nameField.addEventListener('return', () => $.emailField.focus())
   $.emailField.addEventListener('return', () => $.passwordField.focus())
@@ -658,16 +684,14 @@ function validateAll() {
   const emailValid = validateField('email')
   const passwordValid = validateField('password')
   const confirmValid = validateField('confirm')
+  const termsValid = $.termsSwitch.value
 
-  if (!$.termsSwitch.value) {
-    Ti.UI.createAlertDialog({
-      title: L('error'),
-      message: L('error_accept_terms')
-    }).show()
-    return false
-  }
+  $.termsError.applyProperties({
+    text: termsValid ? '' : L('error_accept_terms'),
+    visible: !termsValid
+  })
 
-  return nameValid && emailValid && passwordValid && confirmValid
+  return nameValid && emailValid && passwordValid && confirmValid && termsValid
 }
 
 async function onRegister() {
@@ -686,10 +710,12 @@ async function onRegister() {
     Navigation.replace('main')
 
   } catch (error) {
-    Ti.UI.createAlertDialog({
+    $.dialog.show({
       title: L('error'),
-      message: error.message
-    }).show()
+      message: error.message,
+      tone: 'error',
+      confirmTitle: L('close')
+    })
   } finally {
     setLoading(false)
   }
@@ -707,6 +733,7 @@ function goToLogin() {
 }
 
 function cleanup() {
+  $.dialog.destroy()
   $.destroy()
 }