@maccesar/titools 4.17.0 → 4.18.0

package/README.md

@@ -6,7 +6,7 @@
 
 </div>
 
-TiTools is a Titanium SDK toolkit for AI coding assistants. It ships 10 skills — 5 specialist skills (`ti-expert`, `purgetss`, `ti-ui`, `ti-game`, `ti-synthengine`) plus 5 documentation-mirror skills (`ti-api`, `ti-guides`, `ti-howtos`, `alloy-guides`, `alloy-howtos`) — a research agent, and reference files covering Titanium architecture, API reference, native how-tos, Alloy MVC, PurgeTSS styling, UI/UX patterns, 2D games, and native sound synthesis.
+TiTools is a Titanium SDK toolkit for AI coding assistants. It ships 10 skills — 5 specialist skills (`ti-expert`, `purgetss`, `ti-ui`, `ti-game`, `ti-synthengine`) plus 5 documentation-mirror skills (`ti-api`, `ti-guides`, `ti-howtos`, `alloy-guides`, `alloy-howtos`) — a research agent, and reference files covering Titanium architecture, API reference, native how-tos, Alloy MVC, PurgeTSS styling and resource automation, UI/UX patterns, 2D games, and native sound synthesis.
 
 The reference files are maintained against official documentation whenever an official source exists, so the assistant can retrieve current framework behavior instead of guessing from generic training data.
 
@@ -175,7 +175,7 @@ The knowledge index is based on the latest Titanium SDK documentation. If your p
 | Skill        | Purpose                             | Best For                                |
 | ------------ | ----------------------------------- | --------------------------------------- |
 | ti-expert    | Architecture and implementation     | Starting point for most tasks           |
-| purgetss     | Utility-first styling               | UI styling and animations               |
+| purgetss     | Alloy styling + asset automation    | Utility classes; Alloy/Classic branding, images, colors, fonts and modules |
 | ti-ui        | UI/UX patterns                      | Complex layouts, ListViews, platform UI |
 | ti-game      | 2D games with the `ti.game` module  | Sprites, physics, tile layers, wall jumps, pathfinding, text/performance HUDs, particles, camera |
 | ti-synthengine | Sound design with `ti.synthengine` | Tones, chords, retro/UI effects, alarms, sweeps, patterns, mixing and troubleshooting |
@@ -277,7 +277,7 @@ Skills are automatically activated based on your questions. Just ask naturally:
 
 The AI will automatically use:
 - `ti-expert` -> Architecture and controller structure
-- `purgetss` -> Styling classes and animations (if PurgeTSS detected)
+- `purgetss` -> Alloy styling, or supported asset/CommonJS commands in Alloy and Classic (if PurgeTSS is detected or requested)
 - `ti-howtos` -> Secure token storage and native integration guidance
 
 You do not need to call skills explicitly. The AI reads skill descriptions and loads the appropriate knowledge when needed.
@@ -288,14 +288,14 @@ All skills include automatic project detection to ensure compatibility:
 
 | Skill     | What It Detects       | How It Works                                                  |
 | --------- | --------------------- | ------------------------------------------------------------- |
-| purgetss  | PurgeTSS installation | Checks for `purgetss/` folder, `config.cjs`, `utilities.tss`  |
+| purgetss  | PurgeTSS mode and project type | Checks PurgeTSS markers, then separates Alloy utilities from Classic standalone commands |
 | ti-expert | Alloy vs Classic      | Checks for `app/` (Alloy) vs `Resources/` (Classic) structure |
 | ti-ui     | Titanium projects     | Checks for `tiapp.xml` (both Alloy and Classic)               |
 | ti-game   | ti.game module        | Checks for `<module>ti.game</module>` in `tiapp.xml` or `require('ti.game')` |
 | ti-synthengine | ti.synthengine module | Checks for `<module>ti.synthengine</module>` in `tiapp.xml` or `require('ti.synthengine')` |
 
 Why this matters:
-- PurgeTSS suggestions are only provided if PurgeTSS is installed
+- PurgeTSS suggestions are provided when its project markers are detected or the user explicitly requests a standalone command
 - Alloy-specific patterns are only suggested for Alloy projects
 - Classic Titanium projects will not receive inappropriate Alloy advice
 
@@ -359,7 +359,7 @@ Key features:
 
 ### purgetss
 
-Utility-first styling toolkit for Titanium/Alloy.
+Utility-first styling for Titanium Alloy plus standalone asset and CommonJS commands for Alloy and Classic.
 
 When it activates:
 - Setting up PurgeTSS in a project
@@ -369,6 +369,7 @@ When it activates:
 - Custom color palettes
 - Platform-specific styling
 - config.cjs configuration
+- Classic `Resources/` outputs for branding, density images, semantic colors, fonts, and modules
 
 Example prompts:
 ```
@@ -378,6 +379,8 @@ Example prompts:
 "How do I configure custom colors in config.cjs?"
 "How do I use Font Awesome 7 icons?"
 "Style this button differently on iOS vs Android."
+"Generate image densities for this Classic Titanium app without converting it to Alloy."
+"Install Font Awesome and its CommonJS module under Resources in my Classic app."
 ```
 
 Rules:
@@ -802,7 +805,7 @@ This pattern is documented across four bundled TiTools skills: `ti-ui`, `ti-expe
 | Skill     | SKILL.md                      | References                                            |
 | --------- | ----------------------------- | ----------------------------------------------------- |
 | ti-expert | Architecture + Implementation | 26 files (patterns, feedback surfaces, file type association, sharing, testing, security, etc.) |
-| purgetss  | Setup + Critical Rules        | 33 files (grid, animations, icons, class-index, SVG pipeline, etc.) |
+| purgetss  | Setup + Critical Rules        | 34 files (Classic compatibility, grid, animations, icons, class-index, SVG pipeline, etc.) |
 | ti-ui     | UI Rules + Platform Diffs     | 14 files (layouts, lists, gestures, etc.)             |
 | ti-game   | Native 2D Game Workflow       | 9 files (API, setup, patterns, recipes, tile maps, debugging, roadmap) |
 | ti-synthengine | Native Sound Synthesis   | 8 files (API, sound design, lifecycle, engine, official examples, curated recipes, recommendations, troubleshooting) |
@@ -831,7 +834,8 @@ If the AI suggests patterns you don't use (for example, PurgeTSS when you're not
 If the purgetss skill doesn't activate for your PurgeTSS project:
 1. Verify `purgetss/` folder exists in project root
 2. Check that `purgetss/config.cjs` exists
-3. Mention "PurgeTSS" explicitly in your prompt
+3. In Classic, check for generated `Resources/lib/purgetss.*.js` modules
+4. Mention "PurgeTSS" explicitly in your prompt
 
 ### Wrong advice?
 

package/commands/ti-audit.md

@@ -17,7 +17,7 @@ Project-type audit:
 
 6. If the project is Alloy (`app/views/`, `app/controllers/`, `app/styles/`), invoke `alloy-guides` — check controllers, XML/TSS, models, collections, widgets, sync adapters and cleanup patterns.
 7. If the Alloy project uses `alloy.jmk`, `config.json`, `widget.json`, conditional views, custom XML tags or Alloy CLI workflows, invoke `alloy-howtos` — check configuration precedence, build hooks, generated structures and compilation/debugging conventions.
-8. If the project uses PurgeTSS (`purgetss/` or `purgetss/config.cjs`), invoke `purgetss` before evaluating styling — check unsupported utility classes, padding on Views, unnecessary manual TSS, dynamic components, grids, icons and animations.
+8. If the project uses PurgeTSS (`purgetss/`, `purgetss/config.cjs`, a PurgeTSS-generated `app.tss`, or `purgetss.{ui,colors,fonts}.js`), invoke `purgetss` and detect Alloy vs. Classic before applying findings. In Alloy, audit unsupported utility classes, padding on Views, unnecessary manual TSS, dynamic components, grids, icons and animations. In Classic, audit only the supported standalone asset/CommonJS commands and their `Resources/` outputs; do not require or recommend `alloy.jmk`, generated TSS, utility classes, or `$.UI.create()`.
 
 Native-module audit:
 

package/lib/commands/doctor.js

@@ -100,7 +100,9 @@ export async function doctorCommand() {
     }
   }
   const expectedCommands = COMMANDS.length - pluginCommands.length;
-  if (pluginCommands.length === COMMANDS.length) {
+  if (COMMANDS.length === 0) {
+    console.log(`  ${CHECK} Slash commands: none (workflows ship as cross-agent skills)`);
+  } else if (pluginCommands.length === COMMANDS.length) {
     console.log(`  ${CHECK} Slash commands: all ${COMMANDS.length} served by the marketplace plugin`);
   } else if (missingCommands.length === 0) {
     console.log(`  ${CHECK} Slash commands: ${expectedCommands}/${expectedCommands} installed in ~/.claude/commands/`);
@@ -138,10 +140,13 @@ export async function doctorCommand() {
 
     for (const skill of SKILLS) {
       // A skill the marketplace plugin provides is *supposed* to have no mirror
-      // here — the CLI removes it on purpose to avoid a duplicate entry. Counting
-      // it as missing turns a healthy marketplace install into a wall of errors
-      // telling the user to run a command that will correctly do nothing.
-      if (platform.name === 'claude' && pluginProvidesSkill(skill, homeDir)) {
+      // here — the CLI removes it on purpose to avoid a duplicate entry. During
+      // command-to-skill migrations, a same-name command in an older enabled
+      // cache also suppresses the mirror until the marketplace refreshes.
+      if (
+        platform.name === 'claude' &&
+        (pluginProvidesSkill(skill, homeDir) || pluginProvidesCommand(skill, homeDir))
+      ) {
         servedByPlugin.push(skill);
         continue;
       }

package/lib/symlink.js

@@ -83,8 +83,8 @@ async function removePath(path) {
  * @returns {Promise<boolean>} True if the plugin provides this skill
  */
 export async function isClaudePluginSkillInstalled(skillName, baseDir) {
-  const { pluginProvidesSkill } = await import('./claude-plugin.js');
-  return pluginProvidesSkill(skillName, baseDir);
+  const { pluginProvidesSkill, pluginProvidesCommand } = await import('./claude-plugin.js');
+  return pluginProvidesSkill(skillName, baseDir) || pluginProvidesCommand(skillName, baseDir);
 }
 
 /**
@@ -118,8 +118,9 @@ export async function createSkillSymlinks(platformSkillsDir, skills, baseDir) {
   const useRelative = !!baseDir;
 
   for (const skill of skills) {
-    // Skip Claude when the marketplace plugin already provides this skill;
-    // clean up any stale symlink left from a previous CLI install.
+    // Skip Claude when the marketplace plugin already provides this skill or
+    // still provides a same-name legacy command during a command-to-skill
+    // migration; clean up any stale symlink left from a previous CLI install.
     if (isClaudePlatform && await isClaudePluginSkillInstalled(skill, baseDir)) {
       const stalePath = join(platformSkillsDir, skill);
       if (existsSync(stalePath)) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@maccesar/titools",
-  "version": "4.17.0",
+  "version": "4.18.0",
   "description": "Titanium SDK skills and agents for AI coding assistants, including native game and sound synthesis modules",
   "main": "lib/index.js",
   "type": "module",

package/skills/purgetss/SKILL.md

@@ -1,22 +1,29 @@
 ---
 name: purgetss
-description: "Use when working with PurgeTSS, Titanium's utility-first styling toolkit — styling, reviewing, analyzing, or examining Titanium UI with utility classes, configuring config.cjs, creating dynamic components with $.UI.create(), building animations, grid layouts, icon fonts, or TSS styles. AUTO-DETECT: If purgetss/ folder or purgetss/config.cjs exists, invoke BEFORE writing ANY styling code. PurgeTSS classes look like Tailwind but are NOT Tailwind — verify every class exists. Never use padding on Views (use margins on children), never use flexbox classes, never write manual TSS when a utility class exists."
-argument-hint: "[class-name]"
+description: "Use when a Titanium project uses PurgeTSS utility classes, purgetss/config.cjs, $.UI.create(), generated app.tss, or PurgeTSS asset, color, font, branding, and CommonJS commands. Detect Alloy vs. Classic first: the utility-class workflow is Alloy-only, while selected standalone commands write native Resources/ files in Classic. PurgeTSS resembles Tailwind but has a different class contract, so verify every suggested class."
 allowed-tools: Read, Grep, Glob, Edit, Write, Bash(purgetss *), Bash(node *)
 ---
 
 # PurgeTSS Expert
 
-Utility-first styling toolkit for Titanium/Alloy mobile apps.
+PurgeTSS is a utility-first styling toolkit for Titanium Alloy and a standalone asset/CommonJS generator for Alloy and Classic projects. The project layout determines which half of the toolkit is valid.
 
 ## Required workflow (read before responding)
 
 The SKILL.md alone is an **index** of references. The detail you need to give accurate answers lives in the reference files. **Reading this SKILL.md is not enough.**
 
-### Step 1 — Open the relevant reference files
+### Step 1 — Detect the project type
+
+Before recommending a command, class, output path, `$.UI.create()`, TSS file, or build hook, determine whether the project is Alloy (`app/views/`, `app/controllers/`, `app/styles/`) or Classic (`Resources/` without the Alloy tree).
+
+- **Alloy:** utility classes and every standalone command are available.
+- **Classic:** only the supported standalone commands are available. Do not introduce `app/`, `alloy.jmk`, generated TSS, utility classes, or `$.UI.create()`.
+
+### Step 2 — Open the relevant reference files
 
 | Task involves | Required reading |
 |---|---|
+| Alloy vs. Classic support or output paths | [references/classic-projects.md](references/classic-projects.md), [references/cli-commands.md](references/cli-commands.md) |
 | Choosing utility classes | [references/class-index.md](references/class-index.md) |
 | Layout (horizontal/vertical/composite, grid) | [references/grid-layout.md](references/grid-layout.md), [references/ui-ux-design.md](references/ui-ux-design.md) |
 | Dynamic components in controllers | [references/dynamic-component-creation.md](references/dynamic-component-creation.md) |
@@ -27,7 +34,7 @@ The SKILL.md alone is an **index** of references. The detail you need to give ac
 | Apply directive / class extraction | [references/apply-directive.md](references/apply-directive.md) |
 | Animations | [references/animation-system.md](references/animation-system.md) |
 
-### Step 2 — Output contract
+### Step 3 — Output contract
 
 Every utility class you suggest and every styling pattern you describe MUST be backed by a citation in the form:
 
@@ -35,7 +42,7 @@ Every utility class you suggest and every styling pattern you describe MUST be b
 
 Example: *"Use `wh-12` to set width and height to 48px [source: references/class-index.md]"*
 
-### Step 3 — If you must answer from memory
+### Step 4 — If you must answer from memory
 
 If you write a claim without having read the reference that backs it, prepend `FROM_MEMORY (unverified):` to that claim. Do not hide it.
 
@@ -45,31 +52,42 @@ If you write a claim without having read the reference that backs it, prepend `F
 - ❌ Confusing PurgeTSS classes with Tailwind — they share naming but differ
 - ❌ Marking the answer complete without listing which reference files you read
 - ❌ Suggesting a class without first verifying it exists in `class-index.md`
+- ❌ Applying Alloy utility classes, generated TSS, `alloy.jmk`, or `$.UI.create()` to a Classic project
 
-## Project Detection
+## Project Detection and Mode Selection
 
 > **️ℹ️ AUTO-DETECTS PURGETSS PROJECTS**
 > This skill automatically detects PurgeTSS usage when invoked and provides utility-first styling guidance.
 >
 > **Detection occurs automatically** - no manual command needed.
 >
-> **PurgeTSS project indicators:**
+> **PurgeTSS indicators:**
 > - `purgetss/` folder
 > - `purgetss/config.cjs` configuration file
 > - `purgetss/styles/utilities.tss` utility classes
-> - `app/styles/app.tss` (auto-generated)
+> - A generated `app/styles/app.tss` whose header names PurgeTSS
+> - `app/lib/purgetss.{ui,colors,fonts}.js` or `Resources/lib/purgetss.{ui,colors,fonts}.js`
+>
+> `app/styles/app.tss` by itself is not proof: ordinary Alloy projects can have that file.
 >
-> **Behavior based on detection:**
-> - **PurgeTSS detected** → Provides PurgeTSS-specific guidance, recommends utility classes, suggests `$.UI.create()` for dynamic components
+> **Behavior based on detection and layout:**
+> - **Alloy + PurgeTSS utility lifecycle detected** → Provides utility-class guidance and may suggest `$.UI.create()` for dynamic components
+> - **Classic + PurgeTSS standalone command detected/requested** → Provides only asset, color, font, branding, or CommonJS command guidance with `Resources/` destinations
 > - **Not detected** → Does NOT suggest PurgeTSS utility classes, does NOT recommend `$.UI.create()`, does NOT reference PurgeTSS-specific patterns
 
-## Core Workflow
+## Core Workflows
+
+### Alloy utility-class workflow
+
+1. **Setup**: `purgetss create 'name'` or `purgetss init` for an existing Alloy project.
+2. **Build**: Write Alloy XML/controller classes; PurgeTSS generates `app/styles/app.tss`.
+3. **Configure**: Customize utilities through `purgetss/config.cjs`.
+
+### Classic standalone workflow
 
-1. **Setup**: `purgetss create 'name'` or `purgetss init` for existing projects
-2. **Build**: Write XML with utility classes → PurgeTSS auto-generates `app.tss`
-3. **Configure**: Customize via `purgetss/config.cjs`
+Run only a command marked Classic-compatible in [Classic Project Support](references/classic-projects.md). Generated files are ordinary Titanium resources under `Resources/`; the app does not need a PurgeTSS hook or runtime dependency.
 
-## Project Structure
+## Alloy Utility Project Structure
 
 ```bash
 ./purgetss/
@@ -141,7 +159,7 @@ If you write a claim without having read the reference that backs it, prepend `F
 >
 > If a class appears in "Unused or unsupported classes" in `app.tss`, it means it's truly not defined anywhere - not even in your `config.cjs` customizations.
 
-## Quick Start
+## Alloy Quick Start
 
 ```bash
 purgetss create 'MyApp' -d -v fa
@@ -158,7 +176,7 @@ purgetss create 'MyApp' -d -v fa
 
 ## Critical Rules (Low Freedom)
 
-### ⭐ PREFER `$.UI.create()` for Dynamic Components
+### ⭐ ALLOY ONLY: Prefer `$.UI.create()` for Dynamic Components
 
 > **💡 RECOMMENDED FOR DYNAMIC COMPONENTS**
 > When creating components dynamically in Controllers, **use `$.UI.create()` instead of `Ti.UI.create()`** to get full PurgeTSS utility class support:

package/skills/purgetss/references/app-branding.md

@@ -1,8 +1,8 @@
 # App Icons & Branding
 
-The `purgetss brand` command (introduced in v7.6.0, grouped config in v7.7.0, restructured into per-piece blocks in v7.13.0) regenerates **every image the Titanium template ships**, from one main SVG or PNG logo: launcher icons, adaptive icons, iOS 18+ Dark/Tinted variants, marketplace artwork, and both the iOS and Android splash sets. Per-piece overrides are there when you need them. Alloy and Classic layouts are auto-detected.
+The `purgetss brand` command generates the complete Titanium branding set from one main SVG or PNG logo: launcher icons, adaptive icons, iOS 18+ Dark/Tinted variants, marketplace artwork, and both splash sets. Per-piece overrides are available when needed. Alloy and Classic layouts are auto-detected, and since v7.14.0 a normal run follows the platforms enabled in `tiapp.xml`.
 
-The rule is simple: **if the template ships the file, `brand` updates it.** You should never have to know which API still reads which file to avoid shipping an app with the grey Alloy logo somewhere in it.
+The command also creates Titanium-consumed Classic paths that a fresh Classic template does not seed, including the 11 Android `Resources/android/images/res-*` splash variants. An explicit `--only` is an intentional override that can prepare assets for a disabled deployment target.
 
 For the terse flag reference, see the [`brand` command reference](./cli-commands.md#brand-command). For sibling UI assets, see [Multi-Density Images](./multi-density-images.md).
 
@@ -51,9 +51,10 @@ purgetss brand
 
 On a first run the command:
 
-1. Creates the `brand:` section in `purgetss/config.cjs` with sensible defaults (if missing).
-2. Generates every branding file directly into the project (in-place).
-3. Prints a compact summary of what was written.
+1. Creates `purgetss/config.cjs` from the canonical template if the file is missing, including in standalone Classic projects.
+2. Creates or updates the `brand:` section with current defaults.
+3. Generates branding files for the enabled deployment targets directly into the project.
+4. Prints a compact summary of what was written.
 
 Pass `--dry-run` to preview without writing any files:
 
@@ -61,6 +62,8 @@ Pass `--dry-run` to preview without writing any files:
 purgetss brand --dry-run
 ```
 
+You may also pass a source directly. When a standalone Classic project has no canonical `purgetss/brand/logo.{svg,png}`, the confirmed run moves that positional source into the convention and reports the destination. An existing canonical logo is never replaced silently.
+
 ## The `purgetss/brand/` convention
 
 `init` creates `purgetss/brand/` (alongside `fonts/` and `images/`) so the folder is already there the first time you look for it, even before you've dropped in a logo.
@@ -146,7 +149,7 @@ brand: {
 
   // One block per piece. Artwork comes from purgetss/brand/logo-<piece>.{svg,png};
   // these keys are for numbers, colors and activation. Padding is never inherited.
-  icon:             { padding: '4%' },    // DefaultIcon.png + DefaultIcon-ios.png
+  icon:             { padding: '0%' },    // DefaultIcon.png + DefaultIcon-ios.png
   dark:             { background: null }, // DefaultIcon-Dark.png
   tinted:           {},                   // DefaultIcon-Tinted.png
   iosSplash:        { padding: '26%' },   // assets/iphone/Default*.png × 16
@@ -234,12 +237,12 @@ And these live at the top level:
 
 | Piece | Config key | Generates | Default padding | On by default |
 | --- | --- | --- | --- | --- |
-| `icon` | `icon` | `DefaultIcon.png` + `DefaultIcon-ios.png` | `4%` | yes |
-| `dark` | `dark` | `DefaultIcon-Dark.png` | `4%` | yes |
-| `tinted` | `tinted` | `DefaultIcon-Tinted.png` | `4%` | yes |
+| `icon` | `icon` | `DefaultIcon.png` + `DefaultIcon-ios.png` | `0%` | yes |
+| `dark` | `dark` | `DefaultIcon-Dark.png` | `0%` | yes |
+| `tinted` | `tinted` | `DefaultIcon-Tinted.png` | `0%` | yes |
 | `ios-splash` | `iosSplash` | `assets/iphone/Default*.png` × 16 | `26%` | yes |
 | `launch-logo` | `launchLogo` | `LaunchLogo.png` (1024×1024) | `12%` | when `logo-launch.*` exists |
-| `marketplace` | `marketplace` | `iTunesConnect.png` + `MarketplaceArtwork.png` | `4%` | yes |
+| `marketplace` | `marketplace` | `iTunesConnect.png` + `MarketplaceArtwork.png` | `0%` | yes |
 | `feature-graphic` | `featureGraphic` | `MarketplaceArtworkFeature.png` (1024×500) | `12%` | yes |
 | `adaptive` | `adaptive` | `ic_launcher_{foreground,background,monochrome}.png` × 5 + `ic_launcher.xml` | `18%` | yes |
 | `legacy-icon` | `legacyIcon` | `ic_launcher.png` × 5 | `10%` | yes |
@@ -255,7 +258,7 @@ Only three pieces are opt-in, and for one reason: they produce nothing useful un
 
 ### `background` is inherited, `padding` is not
 
-Set `brand.background` once and every piece picks it up. Padding works the other way on purpose: the defaults answer to different constraints. The adaptive `18%` answers to the Android launcher mask, while the iOS `4%` is an aesthetic choice with no mask behind it. A single inherited number would let `8%` quietly break the launcher mask, so padding is set per piece or not at all.
+Set `brand.background` once and every piece picks it up. Padding works the other way on purpose: the adaptive `18%` answers to the Android launcher mask, while finished iOS/store artwork defaults to full-bleed `0%`. A single inherited number could quietly break the launcher mask or frame finished square artwork, so padding is set per piece or not at all.
 
 ## Overwrite confirmation
 
@@ -290,7 +293,7 @@ The output is automatically routed to the right directory for your project layou
 
 ```text
 <project>/
-├── DefaultIcon.png                 ← 1024×1024, universal fallback (Android-safe padding)
+├── DefaultIcon.png                 ← 1024×1024, universal fallback (brand.icon.padding)
 ├── DefaultIcon-ios.png             ← 1024×1024, iOS flattened on brand.background
 ├── DefaultIcon-Dark.png            ← 1024×1024, iOS 18+ dark (transparent per Apple HIG)
 ├── DefaultIcon-Tinted.png          ← 1024×1024, iOS 18+ tinted (grayscale on black)
@@ -326,7 +329,8 @@ The output is automatically routed to the right directory for your project layou
 │   ├── iphone/Default*.png         ← the launch images the template ships
 │   └── android/
 │       ├── appicon.png             ← 128×128
-│       └── default.png             ← Android <12 splash
+│       ├── default.png             ← Android <12 splash
+│       └── images/res-*/default.png ← 11 Titanium qualifier splashes
 └── platform/
     └── android/res/
         ├── mipmap-*/               ← same 5 densities as Alloy
@@ -334,7 +338,7 @@ The output is automatically routed to the right directory for your project layou
         └── mipmap-anydpi-v26/ic_launcher.xml
 ```
 
-A Classic project has no `images/res-*` folders, so the per-qualifier splashes are simply skipped there.
+A fresh Classic project may not contain `images/res-*`, but `brand` creates all 11 `Resources/android/images/res-*` variants because Titanium consumes those qualifier paths.
 
 The Android outputs are related, but they are not interchangeable:
 
@@ -475,7 +479,7 @@ Below Android 12 there is no system splash: the launch screen comes from the ima
 `brand` regenerates the whole set on every run. It is the `android-splash` piece, on by default:
 
 - `app/assets/android/default.png` (`Resources/android/default.png` in Classic)
-- `app/assets/android/images/res-*/default.png` — the 11 per-qualifier images the Alloy template ships
+- `app/assets/android/images/res-*/default.png` (`Resources/android/images/res-*/default.png` in Classic) — the 11 per-qualifier images Titanium consumes
 
 Earlier versions regenerated only the first file and hid the other 11 behind a `--legacy-splash` flag, which is why a freshly branded project could still flash the grey Alloy logo on an older phone. That flag is gone: its output is part of `android-splash` and always generated.
 
@@ -509,7 +513,7 @@ The output keeps its alpha, so the storyboard's `<default-background-color>` sho
 
 ## iPhone launch images
 
-The Alloy and Classic templates ship 16 `Default*.png` launch images under `assets/iphone/`, from the 320×480 original iPhone size up to 2688×1242. `brand` regenerates all of them, scaling the logo against the **shorter side** of each canvas so portrait and landscape carry the same visual weight.
+The Alloy and Classic templates ship 16 `Default*.png` launch images under `app/assets/iphone/` or `Resources/iphone/`, from the 320×480 original iPhone size up to 2688×1242. `brand` regenerates all of them, scaling the logo against the **shorter side** of each canvas so portrait and landscape carry the same visual weight.
 
 With `<enable-launch-screen-storyboard>` enabled (the default), iOS never reads these files. They are regenerated because they are in your project, they ship with the Alloy logo, and no one should have to audit their `tiapp.xml` to know whether that matters. If you are sure your project doesn't need them, [`--cleanup-legacy`](#cleanup-legacy-branding-artifacts) deletes them instead.
 
@@ -572,7 +576,7 @@ Padding belongs to the piece, not to the project. Each piece has its own key and
 | --- | --- | --- | --- |
 | `adaptive` | `brand.adaptive.padding` | `--android-adaptive-padding` | `18%` |
 | `legacy-icon` | `brand.legacyIcon.padding` | `--android-legacy-padding` | `10%` |
-| `icon` | `brand.icon.padding` | `--ios-padding` | `4%` |
+| `icon` | `brand.icon.padding` | `--ios-padding` | `0%` |
 | `feature-graphic` | `brand.featureGraphic.padding` | `--feature-graphic-padding` | `12%` |
 | `launch-logo` | `brand.launchLogo.padding` | `--launch-logo-padding` | `12%` |
 | `android-splash` | `brand.androidSplash.padding` | `--android-splash-padding` | `26%` |
@@ -580,7 +584,7 @@ Padding belongs to the piece, not to the project. Each piece has its own key and
 
 `--padding` is a shortcut for the two Android launcher paddings in a single run, and `--splash-padding` for the two splash paddings. `--ios-padding` moves the four square iOS/marketplace pieces together (`icon`, `dark`, `tinted`, `marketplace`); in config each of them has its own key.
 
-There is deliberately **no global padding value that cascades down**. The defaults answer to different constraints: `18%` answers to the Android launcher mask, while `4%` is an aesthetic choice for a canvas with no mask behind it. One inherited number would let a reasonable-looking `8%` silently break the launcher mask. `background`, which has no such trap, is inherited from `brand.background`.
+There is deliberately **no global padding value that cascades down**. The defaults answer to different constraints: `18%` answers to the Android launcher mask, while finished square iOS/store artwork stays full-bleed at `0%`. One inherited number could silently break the launcher mask or add an unwanted frame to finished artwork. `background`, which has no such trap, is inherited from `brand.background`.
 
 ### How the source is read, and how sharp the output is
 

package/skills/purgetss/references/classic-projects.md

@@ -0,0 +1,96 @@
+# Classic Project Support
+
+PurgeTSS 7.15 keeps its utility-class lifecycle Alloy-only while allowing independent asset and CommonJS commands to run in Titanium Classic projects. Detect the project layout before choosing a command or output path.
+
+Official source: <https://purgetss.com/docs/commands#alloy-and-classic-compatibility>
+
+## Compatibility Matrix
+
+| Command | Alloy | Classic | Classic behavior |
+| --- | :---: | :---: | --- |
+| `brand` | yes | yes | Writes branding assets to Classic paths and follows enabled `tiapp.xml` deployment targets; explicit `--only` overrides that filter. |
+| `images` | yes | yes | Writes density variants under `Resources/android/images/res-*/` and `Resources/iphone/images/`; follows deployment targets unless `--android` or `--ios` is explicit. |
+| `semantic` | yes | yes | Writes only `Resources/semantic.colors.json`; it does not create `purgetss/`, `config.cjs`, TSS, `app/`, or a hook. |
+| `shades` | yes | yes | Output-only modes work anywhere. Saving creates or updates `purgetss/config.cjs` as a development-time color source. |
+| `color-module` | yes | yes | Writes `app/lib/purgetss.colors.js` or `Resources/lib/purgetss.colors.js`. |
+| `module` | yes | yes | Writes `app/lib/purgetss.ui.js` or `Resources/lib/purgetss.ui.js`. |
+| `icon-library` | yes | yes | Copies fonts to `Resources/fonts/` and optional modules to `Resources/lib/`; `--styles` is skipped in Classic. |
+| `build-fonts` | yes | yes | Copies fonts to `Resources/fonts/` and optionally writes `Resources/lib/purgetss.fonts.js`; it does not generate TSS in Classic. |
+| Root `purgetss`, `--all`, `init`, `create`, `install-dependencies`, `build`, `watch` | yes | no | These commands own the Alloy utility-class lifecycle. |
+| `update`, `sudo-update` | yes | yes | Global CLI maintenance; no project layout is required. |
+
+## The Hard Boundary
+
+A Classic project does not receive or need:
+
+- `app/`
+- `app/styles/app.tss`
+- `purgetss/styles/utilities.tss`
+- `purgetss/styles/fonts.tss`
+- `alloy.jmk`
+- utility classes in views or controllers
+- `$.UI.create()`
+- PurgeTSS during application compilation or at runtime
+
+Files generated under `Resources/` are native Titanium resources. Compile the Classic app normally with `ti build`.
+
+Do not interpret the presence of `purgetss/config.cjs` in a Classic project as permission to use utilities. Commands such as `brand`, `images`, `shades`, and `color-module` may use that file as development-time input without installing the Alloy lifecycle.
+
+## Layout and Output Routing
+
+| Artifact | Alloy | Classic |
+| --- | --- | --- |
+| Semantic colors | `app/assets/semantic.colors.json` | `Resources/semantic.colors.json` |
+| Android UI densities | `app/assets/android/images/res-*/` | `Resources/android/images/res-*/` |
+| iPhone UI scales | `app/assets/iphone/images/` | `Resources/iphone/images/` |
+| Font files | `app/assets/fonts/` | `Resources/fonts/` |
+| Color module | `app/lib/purgetss.colors.js` | `Resources/lib/purgetss.colors.js` |
+| UI module | `app/lib/purgetss.ui.js` | `Resources/lib/purgetss.ui.js` |
+| Custom-font module | `app/lib/purgetss.fonts.js` | `Resources/lib/purgetss.fonts.js` |
+
+## Deployment Targets
+
+`brand` and `images` read `<deployment-targets>` from `tiapp.xml` independently of whether the layout is Alloy or Classic.
+
+- A normal run generates only enabled platform families.
+- `images --android` and `images --ios` are explicit overrides.
+- `brand --only <piece-or-group>` is an explicit override and may prepare assets for a platform before that target is enabled.
+
+Do not assume that Classic means Android-only or that an Alloy project targets both platforms.
+
+## Standalone First-Run Behavior
+
+### `brand`
+
+In a Classic project without `purgetss/config.cjs`, `brand` creates the canonical config before resolving settings. If a positional PNG/SVG is supplied and no canonical `purgetss/brand/logo.{png,svg}` exists, the command moves the source into that convention after overwrite confirmation and reports the destination. It never replaces an existing canonical logo silently.
+
+Classic Android receives the 11 `Resources/android/images/res-*` splash variants even when a fresh `ti create` template did not seed those folders. Titanium consumes those qualifier paths.
+
+### `images`
+
+Running `images` without a positional source establishes the `purgetss/images/` convention. Passing an existing external file or directory does not create an empty `purgetss/images/` folder or a config file merely to process that source.
+
+### `semantic`
+
+Classic `semantic` is deliberately output-only: it writes the native JSON and does not bootstrap any other PurgeTSS artifact. Classic code uses semantic keys directly in Titanium color properties rather than through utility classes.
+
+## Audit Checklist
+
+When auditing a Classic project that uses PurgeTSS:
+
+1. Confirm every invoked command is marked Classic-compatible in the matrix.
+2. Confirm outputs use `Resources/`, never Alloy's `app/assets/` or `app/lib/`.
+3. Reject any added `alloy.jmk`, generated TSS, utility classes, or `$.UI.create()`.
+4. For `brand` and `images`, compare generated platform families with `tiapp.xml` deployment targets and any explicit override flags.
+5. Confirm `semantic` did not create unrelated PurgeTSS setup files.
+6. For `icon-library --styles`, expect Classic to skip TSS output.
+7. For `build-fonts`, expect font files and optional CommonJS output only; no `fonts.tss`.
+
+## Related References
+
+- [CLI Commands](./cli-commands.md)
+- [App Icons & Branding](./app-branding.md)
+- [Multi-Density Images](./multi-density-images.md)
+- [Semantic Colors](./semantic-colors.md)
+- [Icon Font Libraries](./icon-fonts.md)
+- [Custom Fonts](./custom-fonts.md)

package/skills/purgetss/references/cli-commands.md

@@ -5,11 +5,7 @@ This page lists the commands available in PurgeTSS. For release-by-release featu
 <!-- TOC-START -->
 ## Contents
 
-- [Setup Commands](#setup-commands)
-- [Development Commands](#development-commands)
-- [Asset Commands](#asset-commands)
-- [Utility Commands](#utility-commands)
-- [Maintenance Commands](#maintenance-commands)
+- [Alloy and Classic Compatibility](#alloy-and-classic-compatibility)
 - [`init` Command](#init-command)
 - [`create` Command](#create-command)
 - [`brand` Command](#brand-command)
@@ -29,34 +25,21 @@ This page lists the commands available in PurgeTSS. For release-by-release featu
 
 <!-- TOC-END -->
 
-## Setup Commands
+## Alloy and Classic Compatibility
 
-- `init`: Initializes PurgeTSS on an existing Alloy project.
-- `create`: Creates a new Alloy project with PurgeTSS already set up.
-- `brand`: Generates the Titanium branding set from a single logo. See [`brand` Command](#brand-command).
-- `images`: Generates multi-density UI images from sources in `./purgetss/images/`. See [`images` Command](#images-command).
+The utility-class lifecycle remains Alloy-only. Classic projects can use independent asset and CommonJS commands without installing an `alloy.jmk` hook or adding PurgeTSS to their compilation flow.
 
-## Development Commands
+| Command | Alloy | Classic | Classic behavior |
+| --- | :---: | :---: | --- |
+| `brand` | yes | yes | Uses Classic asset paths and follows `tiapp.xml` deployment targets; `--only` is an explicit override. |
+| `images` | yes | yes | Writes under `Resources/` and follows deployment targets unless `--android` or `--ios` is explicit. |
+| `semantic` | yes | yes | Writes only `Resources/semantic.colors.json`; no utility setup is created. |
+| `shades` | yes | yes | Console modes work anywhere; saving creates or updates development-time `purgetss/config.cjs`. |
+| `color-module`, `module` | yes | yes | Writes CommonJS modules to `app/lib/` or `Resources/lib/`. |
+| `icon-library`, `build-fonts` | yes | yes | Writes fonts to `Resources/fonts/` and optional modules to `Resources/lib/`; Classic receives no TSS. |
+| Root `purgetss`, `--all`, `init`, `create`, `install-dependencies`, `build`, `watch` | yes | no | Alloy utility-class lifecycle only. |
 
-- `build`: Generates `utilities.tss` from `config.cjs`.
-- `watch`: Runs `purgetss` automatically on each project compile (defaults to `--on`).
-
-## Asset Commands
-
-- `icon-library`: Copies the official icon fonts into `./app/assets/fonts`.
-- `build-fonts`: Generates `./purgetss/styles/fonts.tss` with class definitions and `fontFamily` selectors for custom fonts.
-
-## Utility Commands
-
-- `shades`: Generates shades and tints for a color and writes the palette to `config.cjs`.
-- `semantic`: Generates Titanium semantic colors (Light/Dark) into `app/assets/semantic.colors.json`. See [`semantic` Command](#semantic-command).
-- `color-module`: Creates `./app/lib/purgetss.colors.js` with the colors defined in `config.cjs`.
-- `module`: Installs `purgetss.ui.js` in the `lib` folder.
-
-## Maintenance Commands
-
-- `update`: Updates PurgeTSS to the latest version.
-- `sudo-update`: Updates PurgeTSS using `sudo` to install npm modules if needed.
+See [Classic Project Support](./classic-projects.md) for the complete boundary and audit checklist.
 
 ## `init` Command
 
@@ -92,7 +75,7 @@ module.exports = {
     optimize: false,         // true = quantize the generated PNGs to a palette (lossy)
 
     // One block per piece — see the `brand` Command section for the full list.
-    icon: { padding: '4%' }, dark: { background: null }, tinted: {},
+    icon: { padding: '0%' }, dark: { background: null }, tinted: {},
     iosSplash: { padding: '26%' }, launchLogo: { padding: '12%' },
     marketplace: {}, featureGraphic: { padding: '12%' },
     adaptive: { padding: '18%' }, legacyIcon: { padding: '10%' },
@@ -191,7 +174,7 @@ Recommended VSCode extensions:
 
 ## `brand` Command
 
-Introduced in v7.6.0, grouped config in v7.7.0, restructured into per-piece blocks in v7.13.0. Regenerates **every image the Titanium template ships**, from one main logo: launcher icons, adaptive icons, iOS 18+ Dark/Tinted variants, marketplace artwork, and both the iOS and Android splash sets. The rule is *if the template ships the file, `brand` updates it*. Each piece can take its own artwork, and `--only` narrows a run to the pieces you name. Alloy and Classic projects are auto-detected.
+Introduced in v7.6.0 and fully standalone in Classic since v7.14.0. Generates the complete Titanium branding set from one main logo: launcher icons, adaptive icons, iOS 18+ Dark/Tinted variants, marketplace artwork, and both splash sets. Alloy and Classic projects are auto-detected. A normal run follows `<deployment-targets>` in `tiapp.xml`; explicit `--only` intentionally overrides that filter.
 
 > **Tip**
 > This is a quick reference. See [app-branding.md](./app-branding.md) for the complete guide — workflow, padding guidance, Android dark mode, iOS 18+ variants, the launch-background setup, and troubleshooting. It also carries the full `brand:` config reference.
@@ -228,7 +211,7 @@ The 14 pieces, their config keys and what each one writes are tabulated in [app-
 | `--padding <n>` | Shortcut: sets both Android launcher paddings to the same value for one run. |
 | `--android-adaptive-padding <n>` | Adaptive icon safe-zone % (default `18`). |
 | `--android-legacy-padding <n>` | Legacy `ic_launcher.png` padding % (default `10`). |
-| `--ios-padding <n>` | Padding % for the four square iOS/marketplace pieces — `icon`, `dark`, `tinted`, `marketplace` (range `2-8`, default `4`). |
+| `--ios-padding <n>` | Padding % for the four square iOS/marketplace pieces — `icon`, `dark`, `tinted`, `marketplace` (default `0`, full-bleed). |
 | `--feature-graphic-padding <n>` | Vertical padding % for `MarketplaceArtworkFeature.png` (range `0-40`, default `12`). |
 | `--launch-logo-padding <n>` | Padding % for `LaunchLogo.png` (default `12`). |
 | `--splash-padding <n>` | Shortcut: sets both splash paddings to the same value for one run. |
@@ -284,16 +267,14 @@ Every piece has a `--<piece>-logo <path>` flag — with no exceptions since v7.1
 
 > **Warning**
 > Breaking renames in v7.13.0: `--splash` → `--splash-icon`, `--notification` → `--notification-icon`, `--splash-logo` → `--splash-icon-logo`, `--feature-logo` → `--feature-graphic-logo`. `--icon-logo` now feeds the `icon` piece; the Android launcher source is `--adaptive-logo`. `--legacy-splash` is gone. **No aliases were kept.**
->
-> Also note `purgetss brand --help` still prints `default: 19` for `--android-adaptive-padding` and `default: 20` for the two splash paddings. Those help strings are stale — the pipeline applies `18`, `26` and `26`.
 
 ### Positional argument
 
-- `[logo-path]` (optional) — overrides auto-discovery of `purgetss/brand/logo.{svg,png}`. It is the main logo, source for every piece that has no override.
+- `[logo-path]` (optional) — main source for every piece without an override. In a standalone Classic first run, when no canonical logo exists, PurgeTSS moves this source to `purgetss/brand/logo.{svg,png}` after confirmation and reports the destination.
 
 ### Config block (v7.13.0 per-piece structure)
 
-Defaults live under `brand:` in `purgetss/config.cjs` and are injected automatically. The block has **one entry per piece**; each accepts the same four keys where they apply: `logo`, `padding` (never inherited), `background` (inherited from `brand.background`), `enabled`. Top-level: `background`, `confirmOverwrites`, `optimize`, `logo`, `monochromeLogo`.
+Defaults live under `brand:` in `purgetss/config.cjs`. Since v7.14.0, a standalone Classic run creates the canonical config when it is missing. The block has **one entry per piece**; each accepts the same four keys where they apply: `logo`, `padding` (never inherited), `background` (inherited from `brand.background`), `enabled`. Top-level: `background`, `confirmOverwrites`, `optimize`, `logo`, `monochromeLogo`.
 
 An unknown key aborts the run before a single file is written. A `brand:` block written for an older PurgeTSS is **rewritten on disk** on the next run, carrying over every customized value.
 
@@ -328,7 +309,7 @@ purgetss brand --cleanup-legacy --dry-run                 # preview legacy clean
 
 ## `images` Command
 
-Introduced in v7.6.0. Generates multi-density variants of your UI images (buttons, illustrations, logos, screen graphics) from a single high-resolution source per image. Alloy and Classic projects are auto-detected.
+Introduced in v7.6.0 and standalone in Classic since v7.15.0. Generates multi-density variants of UI images from one high-resolution source. Alloy and Classic projects are auto-detected. With neither platform flag, the command follows `<deployment-targets>` in `tiapp.xml`; `--android` and `--ios` are explicit overrides.
 
 > **Tip**
 > This is a quick reference. See [multi-density-images.md](./multi-density-images.md) for the complete guide — 4× source convention, re-processing single files, format conversion, subdirectory preservation, and troubleshooting.
@@ -360,6 +341,8 @@ purgetss images background/                           # re-process one subfolder
 
 - `[source]` (optional) — path to override auto-discovery. Resolves first against `purgetss/images/` (short paths like `buttons/btn.png`), then against cwd.
 
+Alloy outputs go under `app/assets/{android,iphone}/images/`; Classic outputs go under `Resources/{android,iphone}/images/`. Passing an existing external source in Classic does not bootstrap an empty `purgetss/images/` folder or config file.
+
 ### When to use `--width`
 
 Use `--width <n>` for SVG sources from vector editors with disproportionate viewBoxes — common in Affinity, Illustrator, and other design tools where the viewBox does not match the intended display size. Without the flag, every scale derives from the source's natural pixel size as a 4× master, which can produce unexpected output sizes.
@@ -409,14 +392,14 @@ purgetss images --dry-run                              # preview
 
 ## `semantic` Command
 
-Introduced in v7.6.0. Generates Titanium semantic colors (Light/Dark mode aware) into `app/assets/semantic.colors.json`. The command dispatches between two distinct modes based on whether `--single` is passed.
+Introduced in v7.6.0. Generates Titanium semantic colors with Light/Dark support. Alloy writes `app/assets/semantic.colors.json` and utility mappings; Classic writes only `Resources/semantic.colors.json` and does not create `purgetss/`, `config.cjs`, TSS, `app/`, or a hook. The command dispatches between two modes based on `--single`.
 
 > **Tip**
 > This is a quick reference. See [semantic-colors.md](./semantic-colors.md) for the complete guide — mirror inversion math, Titanium semantic color spec, class mapping conventions, and strategies for purpose-based design systems.
 
 ### Palette mode (no `--single`)
 
-One base hex, 11-shade tonal palette with mirror-by-index Light/Dark inversion anchored at shade `500`. Writes both files in one step: the JSON gets 11 entries, and `config.cjs` gets the family mapped to those semantic keys.
+One base hex, 11-shade tonal palette with mirror-by-index Light/Dark inversion anchored at shade `500`. Alloy writes the JSON plus the utility mapping in `config.cjs`; Classic writes only the native JSON entries.
 
 ```bash
 purgetss semantic <hex> <name>
@@ -427,7 +410,7 @@ Usage produces classes like `bg-amazon-50`, `text-amazon-500`, `border-amazon-95
 
 ### Single mode (`--single`)
 
-Explicit per-mode hex values for purpose-based semantic colors (`surfaceColor`, `textColor`, `borderColor`, `overlayColor`, etc.). Writes the JSON entry AND auto-maps it to a class in `config.cjs` by stripping the conventional `Color` suffix (e.g. `surfaceColor` → class `surface`).
+Explicit per-mode hex values for purpose-based semantic colors (`surfaceColor`, `textColor`, `borderColor`, `overlayColor`, etc.). Alloy writes the JSON entry and maps it to a utility class in `config.cjs`; Classic writes only the native JSON entry and uses its key directly in Titanium color properties.
 
 ```bash
 purgetss semantic --single <hex> <name> [--dark <hex>] [--alpha <0-100>]
@@ -479,13 +462,13 @@ Re-running on the same palette family fully replaces it: PurgeTSS strips prior k
 | `-a, --alpha <0-100>` | With `--single`, wraps both modes in `{ color, alpha }` per the Titanium spec. |
 | `-n, --name <name>` | Specify the name (alternative to the positional argument). |
 | `-r, --random` | Palette mode — use a random base color. |
-| `-o, --override` | Place the mapping in `theme.colors` instead of `theme.extend.colors`. |
-| `-q, --quotes` | Keep double quotes in `config.cjs`. |
+| `-o, --override` | Alloy only: place the mapping in `theme.colors` instead of `theme.extend.colors`. Ignored in Classic. |
+| `-q, --quotes` | Alloy only: keep double quotes in `config.cjs`. Ignored in Classic. |
 | `-l, --log` | Preview the JSON without writing any files. |
 
 ## `install-dependencies` Command
 
-This command installs dev dependencies and configuration files in existing PurgeTSS projects, and sets up Visual Studio Code support.
+This Alloy-only command installs dev dependencies and configuration files for the utility-class workflow and sets up Visual Studio Code support. Do not run it in Classic.
 
 ```bash
 purgetss install-dependencies
@@ -499,7 +482,7 @@ purgetss id
 
 ## `icon-library` Command
 
-Copies the bundled free font files (Font Awesome 7, Material Icons, Material Symbols, Framework7 Icons) into `./app/assets/fonts/`. Once the fonts are in place, every official icon class (`fa-home`, `ms-home`, `mi-home`, `f7-house`, etc.) works out of the box — PurgeTSS resolves them at compile time from its own bundled `dist/` files.
+Copies the bundled free font files (Font Awesome 7, Material Icons, Material Symbols, Framework7 Icons) to `app/assets/fonts/` in Alloy or `Resources/fonts/` in Classic. Alloy resolves the official utility classes at compile time; Classic uses the installed `fontFamily` plus Unicode directly or through the optional CommonJS module.
 
 ```bash
 purgetss icon-library [--vendor=fa,mi,ms,f7] [--module] [--styles]
@@ -513,17 +496,19 @@ purgetss il [-v=fa,mi,ms,f7] [-m] [-s]
 | Flag | Purpose |
 | --- | --- |
 | `-v, --vendor [fa,mi,ms,f7]` | Copy specific font vendors only (default copies all four). |
-| `-m, --module` | Copy the matching CommonJS module into `./app/lib/` so you can reference icons by name from controllers (`icons.fa.home`). |
-| `-s, --styles` | Copy the official `.tss` source files into `./purgetss/styles/` for reference only — not needed for the classes to work. |
+| `-m, --module` | Copy the matching CommonJS module into `app/lib/` (Alloy) or `Resources/lib/` (Classic). |
+| `-s, --styles` | Alloy only: copy official `.tss` sources into `purgetss/styles/` for reference. Classic skips this output. |
 
 Vendor aliases: `fa`/`fontawesome`, `mi`/`materialicons`, `ms`/`materialsymbol`, `f7`/`framework7`.
 
+Every installed module exposes `families.default`. Direct variant aliases are `solid`/`regular`/`brands` for Font Awesome; `regular`/`outlined`/`round`/`sharp`/`twoTone` for Material Icons; `outlined`/`rounded`/`sharp` for Material Symbols; and `fontFamily` for Framework7.
+
 > **Tip**
 > This is a quick reference. See [Icon Fonts](./icon-fonts.md) for the complete guide — variant tables (`.ms`/`.mso`/`.msr`/`.mss`, `.fa`/`.fas`/`.far`/`.fab`), XML usage patterns, the side-by-side four-family example, Font Awesome Pro / Beta workflow, and instructions for recreating removed libraries.
 
 ## `build-fonts` Command
 
-Generates `./purgetss/styles/fonts.tss` with class definitions and `fontFamily` selectors for any user-defined fonts dropped into `./purgetss/fonts/` (Google Fonts, brand typefaces, community icon libraries with `.ttf` + `.css` pairs).
+Installs user-defined fonts dropped into `purgetss/fonts/`. Alloy also generates `purgetss/styles/fonts.tss`; Classic copies only native fonts to `Resources/fonts/` and generates no TSS or utility definitions.
 
 ```bash
 purgetss build-fonts [-m] [-f]
@@ -536,13 +521,13 @@ purgetss bf [-m] [-f]
 
 | Flag | Purpose |
 | --- | --- |
-| `-m, --module` | Also generates a CommonJS module in `./app/lib/purgetss.fonts.js` exposing `exports.icons` and `exports.families` for use from controllers. |
+| `-m, --module` | Also generates `app/lib/purgetss.fonts.js` (Alloy) or `Resources/lib/purgetss.fonts.js` (Classic), exposing `exports.icons` and `exports.families`. |
 | `-f, --font-class-from-filename` | Uses the font filename as the class name and icon prefix instead of the font family. Replaces the old `-p` flag. |
 
 ### What it does
 
-1. Creates `./purgetss/styles/fonts.tss` with one `fontFamily` class per file.
-2. Copies the font files into `./app/assets/fonts/`, renamed to their PostScript names so they work on both iOS and Android.
+1. Copies font files to `app/assets/fonts/` (Alloy) or `Resources/fonts/` (Classic), renamed to their PostScript names.
+2. In Alloy only, creates `purgetss/styles/fonts.tss` with the TSS class definitions.
 
 > **Tip**
 > This is a quick reference. See [Custom Fonts](./custom-fonts.md) for the complete guide — folder organization, class renaming, adding icon libraries, the `--module` output structure, and `--font-class-from-filename` workflow.
@@ -554,6 +539,8 @@ purgetss bf [-m] [-f]
 
 The `shades` command generates shades and tints for a given color and writes the palette to `config.cjs`.
 
+Saving works in Alloy and Classic. In Classic, `config.cjs` is only a development-time color source for commands such as `color-module`; it does not install the PurgeTSS utility lifecycle. `--log`, `--json`, and `--tailwind` write nothing and work outside a project.
+
 ```bash
 purgetss shades [hexcode] [name]
 
@@ -654,7 +641,7 @@ purgetss s '#65e92c' -j
 
 ## `color-module` Command
 
-This command creates `purgetss.colors.js` in the `lib` folder with all colors defined in `config.cjs`.
+This command creates `purgetss.colors.js` with all colors defined in `config.cjs`: `app/lib/` in Alloy or `Resources/lib/` in Classic. A missing config is created as the color source, but Classic receives no Alloy hook or TSS.
 
 ```bash
 purgetss color-module
@@ -687,7 +674,7 @@ This is handy for using colors in code without hardcoding values in multiple pla
 
 ## `build` Command
 
-The `build` command generates `utilities.tss` from `config.cjs`. Run it after you change `config.cjs`.
+The Alloy-only `build` command generates `utilities.tss` from `config.cjs`. It is not part of a Classic standalone workflow.
 
 ```bash
 purgetss build
@@ -704,7 +691,7 @@ When `purgetss` runs (manually or via `watch`), it checks for changes in `config
 
 ## `watch` Command
 
-The `watch` command runs PurgeTSS on each project compile. You do not need to run `build` manually after each change.
+The Alloy-only `watch` command runs PurgeTSS on each Alloy project compile. Classic projects do not install this hook.
 
 ```bash
 purgetss watch
@@ -746,7 +733,7 @@ purgetss w -d
 
 ## `module` Command
 
-The `module` command installs `purgetss.ui.js` in the `lib` folder.
+The `module` command installs the self-contained `purgetss.ui.js` in `app/lib/` (Alloy) or `Resources/lib/` (Classic). A Classic app does not need PurgeTSS during compilation or at runtime.
 
 ```bash
 purgetss module
@@ -757,7 +744,7 @@ purgetss m
 
 The PurgeTSS module includes:
 
-- Animation: Methods for playing or applying basic animations and transformations to Alloy objects.
+- Animation: methods for playing or applying basic animations and transformations to Titanium views.
 
 See [Animation System](./animation-system.md) for details.
 

package/skills/purgetss/references/custom-fonts.md

@@ -1,9 +1,29 @@
 # Custom Fonts
 
-Use the `purgetss/fonts/` folder and the `build-fonts` command to register any font in your Titanium app: brand typefaces, custom icon fonts, or community icon libraries that PurgeTSS no longer bundles.
+Use the `purgetss/fonts/` folder and the `build-fonts` command to register any font in Alloy or Classic: brand typefaces, custom icon fonts, or community icon libraries that PurgeTSS no longer bundles.
+
+| Output | Alloy | Classic |
+| --- | --- | --- |
+| Font files | `app/assets/fonts/` | `Resources/fonts/` |
+| Generated TSS classes | `purgetss/styles/fonts.tss` | Not generated |
+| `--module` output | `app/lib/purgetss.fonts.js` | `Resources/lib/purgetss.fonts.js` |
+
+Classic receives only native Titanium resources and optional CommonJS output. It does not receive `app/`, TSS, or an Alloy build hook.
 
 For the 4 official icon families that ship with PurgeTSS (Font Awesome 7, Material Icons, Material Symbols, Framework7), see [Icon Fonts](./icon-fonts.md) — they use the `icon-library` command and do **not** require `build-fonts`.
 
+<!-- TOC-START -->
+## Contents
+
+- [The `fonts` folder](#the-fonts-folder)
+- [The `build-fonts` command](#the-build-fonts-command)
+- [Adding icon fonts](#adding-icon-fonts)
+- [Options](#options)
+- [Custom proprietary icon fonts](#custom-proprietary-icon-fonts)
+- [Community-Discovered Patterns](#community-discovered-patterns)
+
+<!-- TOC-END -->
+
 ## The `fonts` folder
 
 Place `.ttf` or `.otf` files in `./purgetss/fonts/`. For icon fonts, also include the `.css` file that ships with the library. PurgeTSS reads it to extract the Unicode characters for each icon class.
@@ -49,13 +69,15 @@ $ purgetss build-fonts [-m] [-f]
 $ purgetss bf [-m] [-f]
 ```
 
-What it does:
+In Alloy it:
 
 1. Creates `./purgetss/styles/fonts.tss` with one `fontFamily` class per file.
 2. Copies the font files into `./app/assets/fonts/`, renamed to their PostScript names so they work on both iOS and Android.
 
+In Classic it copies the renamed font files into `Resources/fonts/` and deliberately skips TSS and utility definitions. Use each PostScript name directly through Titanium's `fontFamily` property.
+
 > ℹ️ **INFO — How this differs from the official icon fonts**
-> Unlike the [official icon fonts](./icon-fonts.md), which PurgeTSS resolves automatically from its own bundled files and need no `.tss` in your project, custom fonts **do** generate `./purgetss/styles/fonts.tss`. That file is then folded into the generated `app/styles/app.tss` when you run `purgetss` (or compile your app) — that is where the final classes used by Alloy live.
+> In Alloy, unlike the [official icon fonts](./icon-fonts.md), custom fonts generate `purgetss/styles/fonts.tss`, which is folded into generated `app/styles/app.tss`. Classic skips this class-generation step.
 
 After running `purgetss build-fonts` with the Bevan and Dancing Script example above:
 
@@ -156,7 +178,7 @@ After `purgetss build-fonts`, the generated `fonts.tss` includes the family clas
 
 Two optional flags adjust what `build-fonts` generates:
 
-- `-m, --module`: generates a CommonJS module in `./app/lib/purgetss.fonts.js` that exposes each icon's Unicode string to JavaScript. Handy when you set `label.text` from a controller.
+- `-m, --module`: generates a CommonJS module in `app/lib/purgetss.fonts.js` (Alloy) or `Resources/lib/purgetss.fonts.js` (Classic) that exposes each icon's Unicode string to JavaScript.
 - `-f, --font-class-from-filename`: uses the font's filename as the font class name and icon prefix instead of the font family name. Useful when you want shorter prefixes. Replaces the old `-p` flag.
 
 ### Using `--module`
@@ -170,7 +192,7 @@ $ purgetss bf -m
 
 To avoid prefix conflicts between libraries, each icon keeps its prefix as a nested object. Both `icons` and `families` are exported:
 
-`./app/lib/purgetss.fonts.js`
+`app/lib/purgetss.fonts.js` (Alloy) or `Resources/lib/purgetss.fonts.js` (Classic)
 ```javascript
 const icons = {
   // map-icons/map-icons.css
@@ -240,7 +262,7 @@ purgetss
 /* ... */
 ```
 
-`./app/lib/purgetss.fonts.js`
+`app/lib/purgetss.fonts.js` (Alloy) or `Resources/lib/purgetss.fonts.js` (Classic)
 ```javascript
 const icons = {
   // map-icons/mp.css
@@ -283,7 +305,7 @@ If your design system ships its own icon font, treat it like any other icon libr
 The following notes reflect community experience with `build-fonts` against real-world Titanium projects.
 
 > **💡 PostScript renaming**
-> `build-fonts` copies `.ttf`/`.otf` files into `./app/assets/fonts/` renamed to their **PostScript names**. iOS reads PostScript names while Android tolerates filenames; by renaming both platforms work from the same `fontFamily` value.
+> `build-fonts` copies `.ttf`/`.otf` files into `app/assets/fonts/` (Alloy) or `Resources/fonts/` (Classic), renamed to their **PostScript names**. iOS reads PostScript names while Android tolerates filenames; by renaming both platforms work from the same `fontFamily` value.
 
 > **🛑 Font Awesome Duotone**
 > Titanium cannot render Font Awesome duotone icons because each icon uses two glyphs. If you work with Font Awesome Pro, avoid documenting duotone as supported.

package/skills/purgetss/references/customization-deep-dive.md

@@ -56,7 +56,7 @@ module.exports = {
 
     // One block per piece. Artwork comes from purgetss/brand/logo-<piece>.{svg,png};
     // these keys are for numbers, colors and activation. Padding is never inherited.
-    icon:             { padding: '4%' },    // DefaultIcon.png + DefaultIcon-ios.png
+    icon:             { padding: '0%' },    // DefaultIcon.png + DefaultIcon-ios.png
     dark:             { background: null }, // DefaultIcon-Dark.png
     tinted:           {},                   // DefaultIcon-Tinted.png
     iosSplash:        { padding: '26%' },   // assets/iphone/Default*.png × 16

package/skills/purgetss/references/icon-fonts.md

@@ -1,6 +1,6 @@
 # Icon Font Libraries
 
-PurgeTSS ships with four official icon font families, each preconfigured with the TSS classes and `fontFamily` mappings you need to drop icons into Buttons, Labels, and TextFields.
+PurgeTSS ships with four official icon font families. Alloy projects can use their preconfigured TSS classes; Classic projects can install the same fonts and use `fontFamily` plus Unicode directly or through the optional CommonJS modules.
 
 For user-defined fonts (Google Fonts, brand typefaces, community icon libraries like map-icons or microns), see [Custom Fonts](./custom-fonts.md) — those use `build-fonts`, not `icon-library`.
 
@@ -43,7 +43,7 @@ The complete class definitions live in the PurgeTSS `dist/` folder:
 
 ## Installing the icon fonts
 
-Run `icon-library` to copy the `.ttf` files into `./app/assets/fonts/`. That is the only step you need. Once the fonts are in place, the icon classes from the table above work out of the box.
+Run `icon-library` to copy the font files to `app/assets/fonts/` (Alloy) or `Resources/fonts/` (Classic). Alloy can then use the icon classes from the table; Classic does not run class resolution.
 
 ```bash
 # All four families
@@ -56,14 +56,14 @@ $ purgetss il -v=fa,mi,ms,f7
 > ℹ️ **INFO — You do not need the `.tss` files in `./purgetss/styles/`**
 > PurgeTSS already knows every official icon class and resolves them at compile time from its own bundled `dist/` files. You do not need `fontawesome.tss`, `materialsymbols.tss`, `materialicons.tss`, or `framework7icons.tss` inside `./purgetss/styles/` for `class="fas fa-home"` (or any other icon class) to work in your XML and controllers. Install the `.ttf` files with `icon-library` and the classes are ready.
 >
-> The resolved classes are written to the generated `app/styles/app.tss`, not to `purgetss/styles/utilities.tss`. If you go looking for a class like `.ms-home`, check `app.tss`.
+> The resolved Alloy classes are written to generated `app/styles/app.tss`, not `purgetss/styles/utilities.tss`. Classic receives only native fonts and any requested JavaScript module.
 
 ### Optional flags
 
 Two optional flags adjust what `icon-library` copies into your project:
 
-- `-s, --styles`: copies the official `.tss` source files into `./purgetss/styles/` for reference only. Useful if you want to grep the full class list, see how a class is defined, or override a specific class in your own project.
-- `-m, --module`: copies the matching CommonJS module into `./app/lib/`, which exposes each icon's Unicode string to JavaScript. Handy when you set `label.text` from a controller and prefer a friendly name like `icons.fa.home` over a raw ``.
+- `-s, --styles`: Alloy only. Copies the official `.tss` sources into `purgetss/styles/` for reference. Classic skips this output.
+- `-m, --module`: copies the matching CommonJS module into `app/lib/` (Alloy) or `Resources/lib/` (Classic), exposing Unicode strings and stable font-family aliases.
 
 ```bash
 # Add either flag when you want them
@@ -81,7 +81,32 @@ $ purgetss il -m -s
 - `ms`, `materialsymbol` = Material Symbols
 - `f7`, `framework7` = Framework7 Icons
 
-## Using icons in XML
+### CommonJS modules in Classic
+
+Each module exposes its existing icon lookup API plus a `families` object with `families.default`. Direct aliases are also available:
+
+| Module | Direct aliases |
+| --- | --- |
+| `fontawesome` | `solid`, `regular`, `brands` |
+| `materialicons` | `regular`, `outlined`, `round`, `sharp`, `twoTone` |
+| `materialsymbols` | `outlined`, `rounded`, `sharp` |
+| `framework7icons` | `fontFamily` |
+
+```javascript
+const fontAwesome = require('fontawesome')
+
+const home = Ti.UI.createLabel({
+  text: fontAwesome.icons.home,
+  font: {
+    fontFamily: fontAwesome.solid,
+    fontSize: 24
+  }
+})
+```
+
+The direct alias and `families` values agree, for example `fontAwesome.solid === fontAwesome.families.solid`; `families.default` provides the library's default variant.
+
+## Using icons in Alloy XML
 
 The variant class sets the `fontFamily`. The icon class sets the glyph (`text` / `title`). Apply both together:
 

package/skills/purgetss/references/installation-setup.md

@@ -12,6 +12,12 @@ Install PurgeTSS globally on your machine using [NPM](https://www.npmjs.com/).
 > Node.js 20+ required.
 > PurgeTSS requires Node 20.0.0 or higher.
 
+## Alloy vs. Classic Setup
+
+The root `purgetss` command, `init`, `create`, `install-dependencies`, `build`, and `watch` belong to the Alloy utility-class lifecycle described below. Do not run them to “set up PurgeTSS” in a Classic project.
+
+Classic projects can run compatible standalone commands directly: `brand`, `images`, `semantic`, `shades`, `color-module`, `module`, `icon-library`, and `build-fonts`. Their native outputs go under `Resources/`, and the application does not need an `alloy.jmk` hook or PurgeTSS at compile/runtime. See [Classic Project Support](./classic-projects.md).
+
 ## XML Validation
 
 Before purging, PurgeTSS pre-checks every XML file in your project. One case worth calling out: double dashes (`--`) are not allowed inside XML comments. That restriction comes from the XML spec itself, not from PurgeTSS, but many people only run into it once a tool actually parses the file.
@@ -44,7 +50,7 @@ Pick whichever of these reads best:
 
 Any of those approaches keeps the comment readable and produces a document that every XML parser will accept.
 
-## Run PurgeTSS the First Time
+## Run PurgeTSS the First Time (Alloy Only)
 
 > **INFO**
 > Run `purgetss` once in your project to generate the required files and folders.

package/skills/purgetss/references/multi-density-images.md

@@ -1,6 +1,6 @@
 # Multi-Density Images
 
-The `purgetss images` command (shipped in PurgeTSS v7.6.0) generates every Titanium density variant of your UI images — buttons, illustrations, screen graphics, inline icons, logos — from a single high-resolution source per image. Alloy and Classic layouts are auto-detected.
+The `purgetss images` command generates every Titanium density variant of your UI images from one high-resolution source. Alloy and Classic layouts are auto-detected. Since v7.15.0, a normal run follows the enabled platforms in `tiapp.xml`; `--android` and `--ios` are explicit overrides.
 
 - **Android**: `res-mdpi`, `res-hdpi`, `res-xhdpi`, `res-xxhdpi`, `res-xxxhdpi` (5 densities)
 - **iPhone**: `@1x`, `@2x`, `@3x` (3 scales via filename suffix)
@@ -10,7 +10,7 @@ For the terse flag reference, see the [`images` command reference](./cli-command
 > **INFO**
 >
 > The `images` command at a glance
-> One source per image in `purgetss/images/`, run `purgetss images`, and every density lands in the right place under `app/assets/android/images/res-*/` and `app/assets/iphone/images/`. Works on both Alloy and Classic projects.
+> One source per image in `purgetss/images/`, run `purgetss images`, and every density lands under `app/assets/` (Alloy) or `Resources/` (Classic).
 
 <!-- TOC-START -->
 ## Contents
@@ -80,11 +80,11 @@ app/assets/
         └── primary@3x.svg
 ```
 
-Classic projects output to `assets/android/images/res-*/` and `assets/iphone/images/` under the project root instead of under `app/assets/` — the command auto-detects the layout.
+Classic projects output to `Resources/android/images/res-*/` and `Resources/iphone/images/` — the command auto-detects the layout.
 
 ## The `purgetss/images/` convention
 
-`init` creates `purgetss/images/` (alongside `fonts/` and `brand/`), so the folder is already there the first time you look for it, even before you've dropped any sources.
+Alloy `init` creates `purgetss/images/` alongside `fonts/` and `brand/`. In standalone Classic, running `purgetss images` without a positional source establishes the convention folder. Passing an existing external source does not create an empty `purgetss/images/` folder or config file.
 
 ```text
 purgetss/images/
@@ -99,7 +99,7 @@ purgetss/images/
 
 Supported input formats: `.svg`, `.png`, `.jpg`, `.jpeg`, `.webp`, `.gif`.
 
-**Subdirectories are preserved in the output.** A file at `purgetss/images/buttons/primary.png` ends up at `app/assets/android/images/res-*/buttons/primary.png` and `app/assets/iphone/images/buttons/primary.png`. Organize however makes sense for your project.
+**Subdirectories are preserved in the output.** A file at `purgetss/images/buttons/primary.png` ends up under the matching `app/assets/` or `Resources/` platform roots. Organize however makes sense for your project.
 
 > **INFO**
 >
@@ -264,7 +264,7 @@ Raster entries you add by hand survive subsequent runs untouched. For SVGs detec
 
 ```text
 <project>/
-└── assets/
+└── Resources/
     ├── android/images/res-*/
     └── iphone/images/
 ```
@@ -329,11 +329,11 @@ purgetss images ./docs/screenshots/home-hero.png
 purgetss images /Users/cesar/Design/banner.svg
 ```
 
-When the source is outside `purgetss/images/`, subdirectory preservation uses the directory of the source file as the root instead.
+When the source is outside `purgetss/images/`, subdirectory preservation uses the directory of the source file as the root instead. Processing that external source in Classic does not bootstrap unrelated PurgeTSS folders or config.
 
 ## Platform filter
 
-By default, every run generates both Android densities and iPhone scales. Scope to one platform for targeted runs:
+By default, the command follows `<deployment-targets>` in `tiapp.xml`. Pass a platform flag to override that selection for a targeted run:
 
 ```bash
 purgetss images --android                # Android only (skip iPhone)
@@ -345,7 +345,7 @@ Useful when:
 - You're iterating on an iOS-only screen and don't need to regenerate Android assets every time.
 - You want to tune JPEG quality differently for the two platforms (run the command twice with different flags).
 
-The two flags are mutually exclusive. Pass neither to get both.
+The two flags are mutually exclusive. Passing neither means “use the project's enabled targets,” not “always generate both.”
 
 ## Format conversion
 
@@ -462,7 +462,7 @@ If you only tweaked CSS classes (no image changes), you don't need to re-run `pu
 
 ## Cleaning up
 
-`purgetss images` never deletes files. It only creates them. If you remove an image from `purgetss/images/`, the previously-generated copies in `app/assets/android/images/res-*/` and `app/assets/iphone/images/` stay in place. Remove them manually (or via git) when you clean up.
+`purgetss images` never deletes files. It only creates them. If you remove a source, generated copies under `app/assets/` (Alloy) or `Resources/` (Classic) stay in place. Remove them manually or with git when you clean up.
 
 ## Full flag reference
 

package/skills/purgetss/references/semantic-colors.md

@@ -8,7 +8,7 @@ For the mode-switching runtime that drives all of this (`Appearance.init()`, `Ap
 
 > **INFO**
 >
-> Semantic color resolution is a **Titanium** feature, not PurgeTSS magic. Titanium natively reads `semantic.colors.json` (at `app/assets/` on Alloy, `Resources/` on Classic) and resolves any color-accepting property whose value matches a key in that file. PurgeTSS only generates the utility classes that point *at* those keys — the switching behavior is 100% native.
+> Semantic color resolution is a **Titanium** feature, not PurgeTSS magic. Titanium natively reads `semantic.colors.json` (at `app/assets/` on Alloy, `Resources/` on Classic) and resolves any color-accepting property whose value matches a key in that file. In Alloy, PurgeTSS also generates utility mappings that point at those keys; Classic uses the keys directly. The switching behavior is native in both layouts.
 
 <!-- TOC-START -->
 ## Contents
@@ -17,7 +17,7 @@ For the mode-switching runtime that drives all of this (`Appearance.init()`, `Ap
 - [Registering in `config.cjs`](#registering-in-configcjs)
 - [Numeric 11-step tonal-inversion palette](#numeric-11-step-tonal-inversion-palette)
 - [The `semantic` CLI command](#the-semantic-cli-command)
-- [Using semantic classes in views](#using-semantic-classes-in-views)
+- [Using semantic classes in Alloy views](#using-semantic-classes-in-alloy-views)
 - [Using semantic colors in controllers](#using-semantic-colors-in-controllers)
 - [Recommended starter palette](#recommended-starter-palette)
 - [Related](#related)
@@ -235,13 +235,15 @@ One base hex plus a family name produces 11 JSON entries with mirror inversion,
 purgetss semantic '#15803d' amazon
 ```
 
-This:
+In Alloy, this:
 
 1. Generates `amazon50` through `amazon950` using the same algorithm as the `shades` command.
-2. Writes `semantic.colors.json` at the project's canonical location (`app/assets/` on Alloy, `Resources/` on Classic) with mirror-by-index values — 50 ↔ 950, 100 ↔ 900, …, 500 as the identical anchor.
+2. Writes `semantic.colors.json` under `app/assets/` with mirror-by-index values — 50 ↔ 950, 100 ↔ 900, …, 500 as the identical anchor.
 3. Writes the `{ 50: 'amazon50', 100: 'amazon100', ... }` mapping into `config.cjs`.
 4. Strips any prior keys for the `amazon` family before writing — re-runs cleanly replace, never duplicate.
 
+In Classic, the same command writes only the native `Resources/semantic.colors.json` entries. It does not create `purgetss/`, `config.cjs`, utility mappings, TSS, `app/`, or an Alloy hook. Use keys such as `amazon50` directly in Titanium color properties.
+
 Useful flags:
 
 - `--log` (`-l`) — preview the JSON on the console without writing anything.
@@ -270,7 +272,7 @@ purgetss semantic --single '#000000' overlayColor       --alpha 50
 
 The name is preserved verbatim as the JSON key (camelCase is respected). When `--dark` is omitted, it defaults to the light hex — useful for overlays where alpha is the only variation between modes.
 
-Single mode writes **both files** in one shot. The class name is auto-derived from the semantic key by stripping the conventional `Color` suffix and kebab-casing the rest, so `surfaceHighColor` becomes the `surface-high` class:
+In Alloy, single mode writes **both files** in one shot. The class name is auto-derived from the semantic key by stripping the conventional `Color` suffix and kebab-casing the rest, so `surfaceHighColor` becomes the `surface-high` class. In Classic, it writes only the native JSON entry and code uses the semantic key directly:
 
 `./purgetss/config.cjs` (auto-generated)
 ```js
@@ -301,7 +303,7 @@ After the batch above you can use `bg-surface`, `bg-surface-high`, `text-text`,
 
 Alpha follows the Titanium spec exactly: range `0.0-100.0`, stored as a **string**, wrapped per-mode as `{ color, alpha }`. Without `--alpha`, values stay as bare hex strings. Out-of-range values are rejected before any file is written.
 
-## Using semantic classes in views
+## Using semantic classes in Alloy views
 
 Once the JSON and the `config.cjs` mapping are in place, you use the semantic classes like any other PurgeTSS utility:
 
@@ -315,6 +317,14 @@ Once the JSON and the `config.cjs` mapping are in place, you use the semantic cl
 </Window>
 ```
 
+Classic has no utility mapping. Use the native semantic key directly:
+
+```javascript
+const window = Ti.UI.createWindow({
+  backgroundColor: 'surfaceColor'
+})
+```
+
 When the appearance changes — whether from `Appearance.set(...)` or a system-level toggle — Titanium resolves each semantic color name to its `light` or `dark` value automatically. No event listeners, no manual repaint.
 
 ### Opacity modifier auto-derivation
@@ -440,5 +450,5 @@ Start with these 6-7 colors and add more only when the design requires it. Fewer
 ## Community-Discovered Patterns
 
 - **The `[object Object]` crash is always a missing `DEFAULT`.** Any time a view renders with a mysterious fallback color and the class was something like `bg-surface`, check `config.cjs` first: if `surface` is a nested object without a `DEFAULT` key, PurgeTSS serializes the whole object and emits `[object Object]` as the color value. The fix is either to add `DEFAULT: 'surfaceColor'` inside the nested object or flatten the structure.
-- **Semantic resolution is Titanium-native, not PurgeTSS.** This matters when debugging: if a semantic name doesn't resolve, the problem is usually the `semantic.colors.json` file (wrong filename, wrong key, malformed JSON, or file in the wrong location — Alloy expects `app/assets/`, Classic expects `Resources/`), not PurgeTSS. PurgeTSS's job ends at generating the class that points at the name.
+- **Semantic resolution is Titanium-native, not PurgeTSS.** This matters when debugging: if a semantic name doesn't resolve, the problem is usually the `semantic.colors.json` file (wrong filename, wrong key, malformed JSON, or wrong location — Alloy expects `app/assets/`, Classic expects `Resources/`). PurgeTSS generates the file in both layouts and an additional utility mapping only in Alloy.
 - **Re-running `purgetss semantic` on the same family is safe.** The CLI strips prior keys for that family from both the JSON and `config.cjs` before writing, so switching between palette and single forms — or changing the base hex — does not leave orphans. Other palettes and manually-defined entries are untouched.

package/skills/purgetss/references/version-history.md

@@ -8,6 +8,22 @@ When in doubt about whether a class, flag, or config key exists in the user's in
 
 ---
 
+## v7.15.0
+- Standalone `images`, `semantic`, `shades`, `color-module`, `module`, `icon-library`, and `build-fonts` now support Classic without installing the Alloy hook or utility-class lifecycle. Outputs route to native `Resources/` paths where appropriate. See [classic-projects.md](classic-projects.md).
+- `images` follows `<deployment-targets>` from `tiapp.xml` by default; explicit `--android` / `--ios` override that selection.
+- Classic `semantic` writes only `Resources/semantic.colors.json`; external Classic `images` runs no longer create unrelated empty `purgetss/` or config artifacts.
+- Official icon-font CommonJS modules expose stable `families.default` plus variant aliases. Existing icon lookup APIs remain intact. See [icon-fonts.md](icon-fonts.md).
+
+## v7.14.0
+- `brand` became self-contained in standalone Classic projects: it creates the canonical config when missing and adopts a positional logo into `purgetss/brand/logo.{png,svg}` after confirmation when no canonical source exists.
+- Normal `brand` runs follow `tiapp.xml` deployment targets; explicit `--only` remains an intentional override.
+- Classic Android now receives the 11 `Resources/android/images/res-*` splash variants Titanium consumes, even when `ti create` did not seed the directories.
+- Square iOS/store artwork defaults to full-bleed `0%` padding. Android adaptive (`18%`), legacy (`10%`), and splash (`26%`) defaults remain platform-specific.
+- Fixes align `DefaultIcon.png` and `DefaultIcon-ios.png` with `brand.icon.padding` and make the documented legacy padding the actual per-side inset.
+
+## v7.13.2
+- `brand --help` padding defaults now come from the same piece table as the pipeline. The help output correctly reports adaptive `18%` and splash `26%`; do not preserve the older “stale help strings” warning.
+
 ## v7.13.1
 - Four vulnerable transitive dependencies patched (`postcss`, `nanoid`, `brace-expansion`, `uuid`). Lockfile only; no API or class changes.