@maccesar/titools 4.4.0 → 4.5.0

package/skills/ti-expert/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: ti-expert
-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."
+description: "Use when designing, reviewing, auditing, or analyzing 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, building adaptive layouts for tablets, foldables and large screens, or moving documents in and out of the app: custom file types, UTIs, CFBundleDocumentTypes, Android intent filters, AirDrop/Quick Share, document icons, sharing a link or file via the iOS share sheet or Android intent chooser. 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 *)
 ---
@@ -11,8 +11,7 @@ Practical architecture and implementation guidance for Titanium SDK apps (Alloy
 
 ## Required workflow
 
-This file is an index. Read the references that govern the task before making a
-recommendation or changing code.
+This file is an index. Read the references that govern the task before making a recommendation or changing code.
 
 | Task | Required reading |
 | --- | --- |
@@ -22,12 +21,12 @@ recommendation or changing code.
 | 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) |
+| Opening or receiving files: custom extensions, UTIs, intent filters, AirDrop, Quick Share, document icons | [File type association](references/file-type-association.md) |
+| Sending content out: share sheet, intent chooser, sharing a link or a file, `dk.napp.social`, `com.alcoapps.socialshare` | [Sharing content out](references/sharing.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.
+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
 
@@ -105,11 +104,7 @@ 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.
+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.
@@ -185,6 +180,8 @@ 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)
+- [File Type Association](references/file-type-association.md) (custom extensions and UTIs, `CFBundleDocumentTypes`, Android intent filters, receiving files from AirDrop/Quick Share, document icons)
+- [Sharing Content Out](references/sharing.md) (share sheet and intent chooser, why iOS still needs `dk.napp.social` and Android does not, text versus file, iPad popovers)
 - [Feedback Surfaces & App-Owned UI](references/feedback-surfaces.md)
 - [Feedback Widget Contracts](references/feedback-widget-contracts.md)
 - [Feedback Migration](references/feedback-migration.md)

package/skills/ti-expert/references/adaptive-layouts.md

@@ -35,9 +35,7 @@ What this means: portrait-only apps will be forced into landscape/resized on lar
 
 ### It already started in Android 16 (API 36)
 
-This is usually described as an API 37 change, but it lands one release earlier: an app
-targeting **API 36** already has `android:screenOrientation` ignored on >= 600dp displays
-running Android 16. The difference is that API 36 still ships an opt-out:
+This is usually described as an API 37 change, but it lands one release earlier: an app targeting **API 36** already has `android:screenOrientation` ignored on >= 600dp displays running Android 16. The difference is that API 36 still ships an opt-out:
 
 ```xml
 <!-- inside <application>, or on an individual <activity> -->
@@ -46,12 +44,9 @@ running Android 16. The difference is that API 36 still ships an opt-out:
   android:value="true"/>
 ```
 
-The opt-out stops working the moment you target API 37, so treat it as a bridge while the
-layout is made adaptive — not as a fix. Source: [Android 16 behavior changes](https://developer.android.com/about/versions/16/behavior-changes-16).
+The opt-out stops working the moment you target API 37, so treat it as a bridge while the layout is made adaptive — not as a fix. Source: [Android 16 behavior changes](https://developer.android.com/about/versions/16/behavior-changes-16).
 
-Worth knowing when debugging: this only kicks in at >= 600dp. If a **phone** is rotating
-despite a portrait lock, the cause is in the app, not in Android — see the orientation
-debugging recipe in section 7.
+Worth knowing when debugging: this only kicks in at >= 600dp. If a **phone** is rotating despite a portrait lock, the cause is in the app, not in Android — see the orientation debugging recipe in section 7.
 
 ### Related: edge-to-edge (API 36)
 
@@ -429,9 +424,7 @@ To verify the exact generated activity name, check `build/android/app/src/main/A
 
 ### Which activities a lock has to cover
 
-`android:screenOrientation` is per-activity — it is not inherited from `<application>`. Every
-window the app opens runs inside one of a small, fixed set of activities declared by the
-Titanium AAR, so read the canonical list from the SDK instead of memorising it:
+`android:screenOrientation` is per-activity — it is not inherited from `<application>`. Every window the app opens runs inside one of a small, fixed set of activities declared by the Titanium AAR, so read the canonical list from the SDK instead of memorising it:
 
 ```bash
 cat ~/.gradle/caches/*/transforms/*/transformed/jetified-titanium-*/AndroidManifest.xml
@@ -448,8 +441,7 @@ ti.modules.titanium.media.TiVideoActivity
 ti.modules.titanium.ui.android.TiPreferencesActivity
 ```
 
-The seventh is the app's own root activity, generated from the `<name>` in tiapp.xml (see the
-derivation rule above). Which one hosts what:
+The seventh is the app's own root activity, generated from the `<name>` in tiapp.xml (see the derivation rule above). Which one hosts what:
 
 | What the app does | Activity |
 |---|---|
@@ -461,23 +453,12 @@ derivation rule above). Which one hosts what:
 
 Two things are better left undeclared:
 
-- **`android:configChanges`.** The CLI strips it before the merge even happens — `_build.js`
-  keeps a list of the `TiBaseActivity`-derived activities and calls
-  `removeActivityAttribute(name, 'android:configChanges')` on each, with the reason spelled out
-  in the source: *"Most devs don't set this right, causing UI to disappear when a config change
-  occurs for a missing setting."* So a hand-written subset is not dangerous, just dead weight —
-  Titanium's full list always wins.
-- **A lock on `TiTranslucentActivity`.** Android 8–11 throws `IllegalStateException` ("Only
-  fullscreen opaque activities can request orientation") when a translucent activity requests a
-  fixed orientation. Declaring `orientationModes` on those windows is safer: the SDK applies it
-  inside a try/catch (`TiWindowProxy.setOrientationModes`), so the worst case is a modal that
-  rotates instead of an app that crashes.
+- **`android:configChanges`.** The CLI strips it before the merge even happens — `_build.js` keeps a list of the `TiBaseActivity`-derived activities and calls `removeActivityAttribute(name, 'android:configChanges')` on each, with the reason spelled out in the source: *"Most devs don't set this right, causing UI to disappear when a config change occurs for a missing setting."* So a hand-written subset is not dangerous, just dead weight — Titanium's full list always wins.
+- **A lock on `TiTranslucentActivity`.** Android 8–11 throws `IllegalStateException` ("Only fullscreen opaque activities can request orientation") when a translucent activity requests a fixed orientation. Declaring `orientationModes` on those windows is safer: the SDK applies it inside a try/catch (`TiWindowProxy.setOrientationModes`), so the worst case is a modal that rotates instead of an app that crashes.
 
 ### Prefer orientationModes over the manifest
 
-`orientationModes` is defined on `TiWindowProxy`, so the same declaration works on `Window`,
-`TabGroup` and `NavigationWindow`. Being per-window it also composes with form-factor queries,
-which is what you usually want:
+`orientationModes` is defined on `TiWindowProxy`, so the same declaration works on `Window`, `TabGroup` and `NavigationWindow`. Being per-window it also composes with form-factor queries, which is what you usually want:
 
 ```xml
 <!-- PurgeTSS -->
@@ -489,14 +470,11 @@ which is what you usually want:
 '#tabs[formFactor=handheld]': { orientationModes: [ Ti.UI.PORTRAIT ] }
 ```
 
-Alloy resolves `formFactor` from `Ti.Platform.Android.physicalSizeCategory`, which is why this
-is more reliable than any width comparison you could write yourself.
+Alloy resolves `formFactor` from `Ti.Platform.Android.physicalSizeCategory`, which is why this is more reliable than any width comparison you could write yourself.
 
-Keep the manifest for what Alloy cannot reach: the root activity, which shows the splash before
-any JS runs, and optionally `TiActivity` as a blanket fallback for windows that carry no class.
+Keep the manifest for what Alloy cannot reach: the root activity, which shows the splash before any JS runs, and optionally `TiActivity` as a blanket fallback for windows that carry no class.
 
-A single Ti Element rule covers every window in the app without touching a single view, which
-is usually all an Alloy app needs:
+A single Ti Element rule covers every window in the app without touching a single view, which is usually all an Alloy app needs:
 
 ```javascript
 // purgetss/config.cjs
@@ -511,8 +489,7 @@ module.exports = {
 'Window[formFactor=handheld]': { orientationModes: [ Ti.UI.PORTRAIT ] }
 ```
 
-Note it matches `Window` only, so a `TabGroup` still needs its own class. And because the
-declaration is per-window, it does nothing for the splash — that one stays in the manifest.
+Note it matches `Window` only, so a `TabGroup` still needs its own class. And because the declaration is per-window, it does nothing for the splash — that one stays in the manifest.
 
 ### Debugging a rotation that shouldn't happen
 
@@ -522,13 +499,9 @@ Ask the system for the effective value instead of re-reading the manifest:
 adb shell dumpsys activity activities | grep -E "topResumedActivity|requestedOrientation"
 ```
 
-If `requestedOrientation` disagrees with what tiapp.xml declares, something overrode it at
-runtime — grep the app for `requestedOrientation` and `orientationModes` before touching the
-manifest again. Note that an *existing* `orientationModes` can be the bug rather than the fix:
-an empty array unlocks rotation (see the anti-patterns above).
+If `requestedOrientation` disagrees with what tiapp.xml declares, something overrode it at runtime — grep the app for `requestedOrientation` and `orientationModes` before touching the manifest again. Note that an *existing* `orientationModes` can be the bug rather than the fix: an empty array unlocks rotation (see the anti-patterns above).
 
-Before blaming the OS, let the SDK tell you. Titanium logs a warning when Android drops the
-request on a large screen, so this either hits or rules that cause out immediately:
+Before blaming the OS, let the SDK tell you. Titanium logs a warning when Android drops the request on a large screen, so this either hits or rules that cause out immediately:
 
 ```bash
 adb logcat | grep "Orientation request will be ignored"
@@ -536,8 +509,7 @@ adb logcat | grep "Orientation request will be ignored"
 # Orientation request will be ignored on Android 16+.
 ```
 
-And to see the size bucket the device actually reports — `normal` means a phone, so the >= 600dp
-rule does not apply and the cause is in the app:
+And to see the size bucket the device actually reports — `normal` means a phone, so the >= 600dp rule does not apply and the cause is in the app:
 
 ```bash
 adb shell am get-config    # e.g. ...-sw360dp-w360dp-h802dp-normal-...

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

@@ -97,10 +97,7 @@ Alloy.Collections.notifications = new Backbone.Collection()
 // <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).
+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
 

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

@@ -188,8 +188,7 @@ api.getFrames()
 ## Controller rules
 
 **DO:**
-- Use verified PurgeTSS utilities when detected; otherwise define styles in
-  per-controller TSS and manually maintained global TSS.
+- 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).
@@ -246,10 +245,7 @@ See [ControllerAutoCleanup.js](../assets/ControllerAutoCleanup.js) for the compl
 
 ## Widget structure
 
-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.
+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/
@@ -280,8 +276,7 @@ app/widgets/
 }
 ```
 
-Register the Widget in the app's `app/config.json`; the dependency key must
-match the manifest `id`:
+Register the Widget in the app's `app/config.json`; the dependency key must match the manifest `id`:
 
 ```json
 {
@@ -491,10 +486,7 @@ render()
 | 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).
+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

@@ -1,46 +1,35 @@
 # Titanium Alloy anti-patterns
 
 ## 1. Inline styling instead of TSS
-**Symptom:** Using inline attributes like `backgroundColor="#fff"` directly in XML views.
-**Problem:** Inline attributes make theme changes impossible and scatter visual definitions across views.
-**Solution:** Define styles in TSS files using IDs or class selectors.
+**Symptom:** Using inline attributes like `backgroundColor="#fff"` directly in XML views. **Problem:** Inline attributes make theme changes impossible and scatter visual definitions across views. **Solution:** Define styles in TSS files using IDs or class selectors.
 
 ## 2. Fat controllers
-**Symptom:** Controllers with 100+ lines handling logic, API, and UI.
-**Solution:** Delegate business logic to `lib/services/` and API calls to `lib/api/`.
+**Symptom:** Controllers with 100+ lines handling logic, API, and UI. **Solution:** Delegate business logic to `lib/services/` and API calls to `lib/api/`.
 
 ## 3. Memory leaks (Missing Cleanup)
-**Symptom:** Adding `Ti.App` or `Alloy.Collections` listeners without a `cleanup()` function.
-**Solution:** Always implement `$.cleanup = cleanup` and remove listeners there.
+**Symptom:** Adding `Ti.App` or `Alloy.Collections` listeners without a `cleanup()` function. **Solution:** Always implement `$.cleanup = cleanup` and remove listeners there.
 
 ## 4. Direct native module calls
-**Symptom:** Calling `require('ti.module')` directly in a controller.
-**Solution:** Wrap it in a service in `lib/services/` (e.g., `audioService.js`).
+**Symptom:** Calling `require('ti.module')` directly in a controller. **Solution:** Wrap it in a service in `lib/services/` (e.g., `audioService.js`).
 
 ## 5. Direct controller navigation
-**Symptom:** `Alloy.createController('name').getView().open()`.
-**Solution:** Use a Navigation Service to centralize `open/close` and trigger the `cleanup()` function automatically.
+**Symptom:** `Alloy.createController('name').getView().open()`. **Solution:** Use a Navigation Service to centralize `open/close` and trigger the `cleanup()` function automatically.
 
 ## 6. Complex matrix animations
-**Symptom:** Manual use of `Ti.UI.create2DMatrix()` for simple animations.
-**Solution:** Use `Ti.UI.createAnimation()` for opacity, transform, and duration-based animations. Reserve 2D Matrix for complex multi-property transforms.
+**Symptom:** Manual use of `Ti.UI.create2DMatrix()` for simple animations. **Solution:** Use `Ti.UI.createAnimation()` for opacity, transform, and duration-based animations. Reserve 2D Matrix for complex multi-property transforms.
 
 ## 7. Hardcoded strings & missing a11y
-**Symptom:** `text="Login"` instead of `text="L('login')"`, or missing `accessibilityLabel`.
-**Solution:** Always use i18n and accessibility properties.
+**Symptom:** `text="Login"` instead of `text="L('login')"`, or missing `accessibilityLabel`. **Solution:** Always use i18n and accessibility properties.
 
 ## 8. Logic in TSS
-**Symptom:** Using conditionals or calculations inside TSS.
-**Solution:** Keep styling declarative in TSS files.
+**Symptom:** Using conditionals or calculations inside TSS. **Solution:** Keep styling declarative in TSS files.
 
 ---
 
 ## Titanium layout anti-patterns
 
 ## 9. Padding on container views
-**Symptom:** Setting `padding` on View, Window, ScrollView, or TableView.
-**Problem:** Base container elements don't support padding in Titanium.
-**Solution:** Use margins on children instead:
+**Symptom:** Setting `padding` on View, Window, ScrollView, or TableView. **Problem:** Base container elements don't support padding in Titanium. **Solution:** Use margins on children instead:
 ```tss
 /* WRONG */
 "#container": { padding: 16 }
@@ -50,39 +39,21 @@
 ```
 
 ## 10. Redundant composite layout
-**Symptom:** Adding `layout: 'composite'` to Views.
-**Problem:** Composite (absolute positioning) is the DEFAULT layout. Setting it is redundant.
-**Solution:** Omit `layout` for composite, only specify `layout: 'horizontal'` or `layout: 'vertical'` when needed.
+**Symptom:** Adding `layout: 'composite'` to Views. **Problem:** Composite (absolute positioning) is the DEFAULT layout. Setting it is redundant. **Solution:** Omit `layout` for composite, only specify `layout: 'horizontal'` or `layout: 'vertical'` when needed.
 
 ## 11. Using `lib/` prefix in require statements
-**Symptom:** `const service = require('lib/services/picsum')`
-**Problem:** Alloy flattens the `lib/` folder during build. Files in `app/lib/services/` become `Resources/iphone/services/`.
-**Solution:** Omit the `lib/` prefix: `const service = require('services/picsum')`
+**Symptom:** `const service = require('lib/services/picsum')` **Problem:** Alloy flattens the `lib/` folder during build. Files in `app/lib/services/` become `Resources/iphone/services/`. **Solution:** Omit the `lib/` prefix: `const service = require('services/picsum')`
 
 ## 12. Wrong window ID in controller
-**Symptom:** Using `$.index.open()` when the Window has `id="mainWindow"`.
-**Problem:** Alloy generates `$` references from XML IDs. If Window is `id="mainWindow"`, `$.index` doesn't exist.
-**Solution:** Match the ID: `$.mainWindow.open()`
+**Symptom:** Using `$.index.open()` when the Window has `id="mainWindow"`. **Problem:** Alloy generates `$` references from XML IDs. If Window is `id="mainWindow"`, `$.index` doesn't exist. **Solution:** Match the ID: `$.mainWindow.open()`
 
 ## 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:** 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).
+**Symptom:** `Ti.UI.createNotification({ message: 'Hi' }).show()` **Problem:** This API doesn't exist in Titanium. Causes "invalid method" error. **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:**
-- 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.
+**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:**
+- 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
 

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

@@ -54,15 +54,11 @@ 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.
+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. Standard Alloy also supports a
-manually maintained global `app.tss`.
+Every controller can have a matching TSS file. Standard Alloy also supports a manually maintained global `app.tss`.
 
 ```
 app/styles/

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

@@ -281,9 +281,7 @@ 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.
+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
 function attachFeedback(hostWindow) {

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

@@ -20,16 +20,9 @@
 
 ## 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).
+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.

package/skills/ti-expert/references/feedback-migration.md

@@ -1,7 +1,6 @@
 # Migrating feedback surfaces
 
-Migrate semantics, not proxy names. Replacing every native dialog with the same
-custom modal preserves the original design problem.
+Migrate semantics, not proxy names. Replacing every native dialog with the same custom modal preserves the original design problem.
 
 ## Contents
 
@@ -21,9 +20,7 @@ Search the application for:
 rg -n "createAlertDialog|createOptionDialog|createNotification|Toast|toast|snackbar|overlay" app/
 ```
 
-Also inspect helpers that wrap these calls, XML overlays, controller timers,
-global events, and callbacks that can present UI indirectly. Record for every
-occurrence:
+Also inspect helpers that wrap these calls, XML overlays, controller timers, global events, and callbacks that can present UI indirectly. Record for every occurrence:
 
 - trigger and current message;
 - success, information, warning, error, confirmation, or choice;
@@ -33,8 +30,7 @@ occurrence:
 - callback side effects and cancellation behavior;
 - owning window and cleanup path.
 
-Do not implement the replacement until every occurrence has a semantic target
-from `feedback-surfaces.md`.
+Do not implement the replacement until every occurrence has a semantic target from `feedback-surfaces.md`.
 
 ## Classify before replacing
 
@@ -47,13 +43,9 @@ Use these defaults:
 - uncommon irreversible decision → destructive Dialog;
 - several related actions or app-data choices → Bottom Sheet;
 - long structured content → scrollable sheet or dedicated screen;
-- OS permission, picker, share, date/time, biometric, or purchase flow → keep the
-  system surface.
+- OS permission, picker, share, date/time, biometric, or purchase flow → keep the system surface.
 
-Preserve domain behavior separately from presentation. Services return results
-or errors; the window/controller that owns visible context chooses the surface.
-Do not let a service create app-owned UI, especially before the root window
-exists.
+Preserve domain behavior separately from presentation. Services return results or errors; the window/controller that owns visible context chooses the surface. Do not let a service create app-owned UI, especially before the root window exists.
 
 ## Migrate one window at a time
 
@@ -62,19 +54,15 @@ exists.
 3. Attach modal Widgets after the window exists.
 4. Route each old result to its classified surface.
 5. Call Widget `destroy()` from the window close cleanup.
-6. Exercise success, failure, cancel, Back, backdrop, double tap, and consecutive
-   presentation paths.
-7. Remove the old dialog, local overlay, helper, timer, and listener after the
-   migrated window passes verification.
+6. Exercise success, failure, cancel, Back, backdrop, double tap, and consecutive presentation paths.
+7. Remove the old dialog, local overlay, helper, timer, and listener after the migrated window passes verification.
 8. Commit the completed vertical slice before moving to the next window.
 
-Do not keep commented legacy implementations. Version control is the rollback
-mechanism; commented duplicates hide incomplete migrations and stale callbacks.
+Do not keep commented legacy implementations. Version control is the rollback mechanism; commented duplicates hide incomplete migrations and stale callbacks.
 
 ## Deliberate silence
 
-Cancellation or an unknowable result can be a complete, intentional outcome.
-Model it explicitly and do not infer a message from falsy values.
+Cancellation or an unknowable result can be a complete, intentional outcome. Model it explicitly and do not infer a message from falsy values.
 
 Example contract for an exported file:
 
@@ -103,9 +91,7 @@ function handleSaveResult(error, result) {
 }
 ```
 
-Do not add "Cancelled" for `saved === false`. Do not claim success for
-`saved === null`. Cover both branches with tests so a future fallback does not
-erase the intended silence.
+Do not add "Cancelled" for `saved === false`. Do not claim success for `saved === null`. Cover both branches with tests so a future fallback does not erase the intended silence.
 
 ## Contract tests
 
@@ -114,8 +100,7 @@ Add repository-appropriate static or unit tests for:
 - all Widget folders, manifests, XML views, controllers, and dependency entries;
 - each public method documented in `feedback-widget-contracts.md`;
 - the expected Widget declared in every migrated window;
-- absence of app-owned `Ti.UI.createAlertDialog` and
-  `Ti.UI.createOptionDialog` defaults;
+- absence of app-owned `Ti.UI.createAlertDialog` and `Ti.UI.createOptionDialog` defaults;
 - removal of the previous local Snackbar/overlay and timer;
 - Snackbar replacement and timer reset;
 - Dialog and Bottom Sheet FIFO ordering;
@@ -124,18 +109,15 @@ Add repository-appropriate static or unit tests for:
 - cleanup of active and queued presentations;
 - explicit silence for cancel and indeterminate save results.
 
-Do not enforce blanket bans on native system surfaces. A remaining native call
-must be tied to an OS-owned interaction or documented fallback.
+Do not enforce blanket bans on native system surfaces. A remaining native call must be tied to an OS-owned interaction or documented fallback.
 
 ## Delivery verification
 
-Run the project's real commands rather than assuming names. A complete migration
-normally includes:
+Run the project's real commands rather than assuming names. A complete migration normally includes:
 
 1. lint with zero errors and no new warnings;
 2. unit and contract tests with no new failures;
-3. PurgeTSS generation when detected, followed by inspection of unused or
-   unsupported classes at the end of `app.tss`;
+3. PurgeTSS generation when detected, followed by inspection of unused or unsupported classes at the end of `app.tss`;
 4. Alloy compilation for Android and iOS;
 5. native builds for every supported platform;
 6. manual checks in light, dark, and system appearance;
@@ -144,9 +126,7 @@ normally includes:
 9. VoiceOver and TalkBack focus/traversal checks;
 10. consecutive presentation and window-close cleanup checks.
 
-Record pre-existing failures before migration and require the final run to add
-none. Build artifacts are not proof of usable modal behavior; perform the manual
-interaction checks on device or simulator.
+Record pre-existing failures before migration and require the final run to add none. Build artifacts are not proof of usable modal behavior; perform the manual interaction checks on device or simulator.
 
 ## When to share Widgets between apps
 
@@ -157,9 +137,7 @@ Extract or copy a Widget into another app only when:
 - appearance depends on a documented semantic-token contract;
 - platform and minimum Titanium/Alloy versions are declared;
 - lifecycle and accessibility tests travel with it;
-- at least two apps need the same behavior, or one app has a clear portability
-  requirement.
+- at least two apps need the same behavior, or one app has a clear portability requirement.
 
-Do not extract merely because a view appeared three times. Extract because the
-boundary is independently understandable, testable, and maintainable.
+Do not extract merely because a view appeared three times. Extract because the boundary is independently understandable, testable, and maintainable.