docs(migration-script): dlt-3303 master migration script to next

[Ignacio Ropolo (iropolo)]

master migration script to next

Obligatory GIF (super important!)

🛠️ Type Of Change

These types will not increment the version number, but will still deploy to documentation site on release:

• Documentation

https://dialpad.atlassian.net/browse/DLT-3303

📖 Description

This is the master migration script.
Should hold all the necessary scripts to make the migration accordingly.

It is an interactive script, the user can navigate it and execute it in order.
It also have the ability to get a first dry-run and a health check.

This will be on Draft till I migrate ui-kits. -- I will use it there and then update and release the stable one in this PR.

Fixes made:

Rewrote to use Node builtins only (no chalk/globby/inquirer import). Config-based migrations now work without installing extra packages.

-> 29a9c4f

size-to-layout config — one token per declaration limit
The regex (BORDER_PROPS\s*:[^;]*?)var(--dt-size-N) with g flag: the first match consumes the property prefix, so subsequent tokens in the same declaration have no prefix to match.

dialtone_migrate_props — dt-checkbox missing from EMIT_EVENT_RENAMES
The event rename map has dt-input, dt-radio, dt-toggle, etc. but dt-checkbox is not listed. So @input on DtCheckbox is never migrated.

-> 197cd57

Fixed false/positive issues on the health check detect patterns for component-props to scope title to Dialtone component tags only:

-> 5aaac6c

Added dt-list-item / DtListItem to the scoped #left→#start, #right→#end, #bottom→#blockEnd slot rename regexes

Added vue3-to-vue-imports migration entry (required, config-based) with detect patterns for @dialpad/dialtone-icons/vue3 and @dialpad/dialtone-vue/vue3

3df4d6b

---

---

AI. generated description, it will be useful to have for a final blog post.

Dialtone Master Migration Script

What is it?

The Dialtone Master Migration Script (dialtone-migrate) is a single CLI tool that orchestrates all 17 automated migration scripts for the upcoming Dialtone major release. Instead of hunting through docs and running each tool one by one, you run one command and it walks you through everything — in the right order, with full control over what runs.

Why use it?

• One entry point — No need to remember 10+ different npx commands or which config name to pick in dialtone-migration-helper.
• Correct ordering — Migrations run in dependency order (e.g., color stops before base-to-semantic).
• Health check — Scan your codebase to see exactly which migrations still need to run, how many matches remain, and in which files.
• Selective execution — Run everything, just the required (breaking) migrations, or cherry-pick specific ones by ID.
• Dry-run mode — Preview every change before committing to it.
• Consistent interface — All migrations (config-based and standalone scripts) share the same --cwd, --dry-run, and --yes flags.

Scope

The script covers 17 migrations across three categories:

Required (breaking changes) — 10 migrations:

• Color stop renames
• HSL → OKLCH color tokens
• --dt-space-* → --dt-spacing-*
• --dt-size-* → --dt-layout-* / --dt-spacing-* / --dt-size-border-* / --dt-size-radius-*
• Border-radius logical names (d-btr* → d-bbsr*, etc.)
• Pixel-based utility classes → token-stop names (d-h16 → d-h-25)
• setTheme() / data-dt-theme → layered theming API
• Component prop/event/slot renames
• DtChip interactive default change
• Scrollbar :never → :always

Opt-in (deprecation / best practices) — 7 migrations:

• Base → semantic color tokens
• success* → positive*
• DtStack/DtDescriptionList gap stop renames
• d-d-flex →
• Link/button navigation patterns
• T-shirt sizes → numeric (size="sm" → :size="200")
• Physical → logical naming (left/right → start/end)

Step-by-step guide

1. Check what needs migrating
   Run the health check to get a full report of your codebase:

npx dialtone-migrate --health-check --cwd ./src

This scans your files and prints a status for every migration — DONE or PENDING with match counts and sample file paths. No files are modified.

2. Run migrations interactively
   Launch the script and pick which migrations to run from an interactive menu:

npx dialtone-migrate --cwd ./src

You'll see all available migrations grouped by required and opt-in, select by number, and confirm before any files are changed.

3. Run all required migrations at once
   If you want to tackle every breaking change in one go:

npx dialtone-migrate --all --cwd ./src

Add --yes to skip confirmation prompts:

npx dialtone-migrate --all --yes --cwd ./src

4. Preview changes with dry-run
   See what would change without touching any files:

npx dialtone-migrate --all --dry-run --cwd ./src

5. Run specific migrations only
   Cherry-pick by migration ID:

npx dialtone-migrate --only color-stops,border-radius,theme-to-mode --cwd ./src

Use --help to see all available IDs.

6. Verify the result
   Run the health check again to confirm everything is resolved:

npx dialtone-migrate --health-check --cwd ./src

7. Run ESLint auto-fix
   After all migrations, run an ESLint pass to catch anything the rule-based migrations flag:

npx eslint --fix "src/**/*.vue"

Individual scripts are still available

Every migration tool can still be run standalone if you prefer granular control:

# Config-based (via dialtone-migration-helper)
npx dialtone-migration-helper --cwd ./src
# Then select a config like "color stops", "hsl-to-oklch", etc.
 
# Standalone scripts
npx dialtone-migrate-border-radius --cwd ./src
npx dialtone-migrate-props --cwd ./src
npx dialtone-migrate-chip-interactive --cwd ./src
# ... and so on

The master script simply wraps all of these into a single, ordered workflow.

[coderabbitai]

Introduces a master migration script (dialtone-migrate) orchestrating 17 automated migrations for an upcoming major release. Adds interactive CLI with health checks, dry-run mode, and selective execution. Updates migration documentation and adds new migration configs (vue3-to-vue-imports, physical-to-logical slot updates). Expands package.json bin exports for new migration tools.

Overall Judgement: ⚠️ Needs minor changes

Rationale: Substantial well-structured addition with targeted fixes, but intentionally marked Draft pending ui-kits migration and final testing before stable release.

Walkthrough

This PR introduces a comprehensive migration orchestration system: a new dialtone-migrate CLI tool that coordinates next-major-version migrations with health checks, interactive selection, and both config-based and standalone execution. It adds three new migration configurations and registers two new CLI entry points.

Changes

Migration Orchestration System

Layer / File(s)	Summary
Migration configuration updates packages/dialtone-css/lib/build/js/dialtone_migrate_props/index.mjs, packages/dialtone-css/lib/build/js/dialtone_migration_helper/configs/physical-to-logical.mjs, packages/dialtone-css/lib/build/js/dialtone_migration_helper/configs/vue3-to-vue-imports.mjs	Props event renames extend to dt-checkbox (@input → @update:model-value). Slot migration rules expand component scoping for #left, #right, #bottom with PascalCase variants. New Vue import path migration config added (/vue3 → /vue).
Orchestrator registry and CLI interface packages/dialtone-css/lib/build/js/dialtone_migrate/index.mjs (setup, registry, parsing)	Migration registry defines metadata, required/opt-in status, execution type, detection regex, and file extensions per migration. CLI argument parsing handles --cwd, --dry-run, --yes, --health-check, --all, --only with dynamic help listing required and opt-in migration IDs.
Filesystem scanning and health checks packages/dialtone-css/lib/build/js/dialtone_migrate/index.mjs (utilities, health check, interactive selection)	Filesystem utilities scan directories recursively while skipping ignored paths. Health-check workflow counts pattern matches per migration and prints required/opt-in status with examples. Interactive selection creates a readline prompt to choose which migrations to run.
Migration execution packages/dialtone-css/lib/build/js/dialtone_migrate/index.mjs (config runner, standalone runner)	Config-based runner imports helper configs, derives scan extensions, queues matching files, applies regex replacements in a convergence loop, and writes modified files with dry-run support. Standalone runner spawns child processes forwarding --dry-run/--yes.
Orchestration and user reporting packages/dialtone-css/lib/build/js/dialtone_migrate/index.mjs (main orchestration)	Main orchestration parses options, runs health-check or selects migrations, executes sequentially with error handling and continuation prompts, records per-migration status, and prints final summary.
CLI registration and user documentation packages/dialtone-css/package.json, apps/dialtone-documentation/docs/guides/migration/index.md	New bin executables registered for dialtone-migrate, dialtone-migrate-tshirt-to-numeric, and dialtone-migrate-props. Migration guide updated with "Master migration script (recommended)" section documenting npx dialtone-migrate usage patterns and individual script behavior.

Sequence Diagram

sequenceDiagram
  participant User
  participant CLI as dialtone-migrate CLI
  participant Registry
  participant FileSystem
  participant HealthCheck
  participant Interactive
  participant ConfigRunner as Config Migration Runner
  participant StandaloneRunner as Standalone Runner
  participant Output

  User->>CLI: npx dialtone-migrate [options]
  CLI->>CLI: parseArgs()
  
  alt --health-check flag
    CLI->>Registry: getAll(MIGRATIONS)
    CLI->>FileSystem: findFiles(extensions)
    FileSystem-->>CLI: list of candidate files
    CLI->>HealthCheck: scanAndReport()
    HealthCheck->>FileSystem: read files, count patterns
    HealthCheck->>Output: print required/opt-in status
  else --all or --only
    CLI->>Registry: selectMigrations(--all|--only)
    Registry-->>CLI: migration list
  else interactive mode
    CLI->>Interactive: promptUserSelection()
    Interactive-->>CLI: selected migrations
  end
  
  loop for each selected migration
    alt execution type = config
      CLI->>ConfigRunner: runConfigMigration()
      ConfigRunner->>Registry: getConfig(migrationName)
      ConfigRunner->>FileSystem: findMatching(regex)
      ConfigRunner->>FileSystem: readFile(path)
      ConfigRunner->>ConfigRunner: applyRegexReplacements(convergence)
      ConfigRunner->>FileSystem: writeFile(path)
      ConfigRunner-->>CLI: status
    else execution type = standalone
      CLI->>StandaloneRunner: runStandaloneMigration()
      StandaloneRunner->>StandaloneRunner: spawn child process
      StandaloneRunner-->>CLI: status
    end
  end
  
  CLI->>Output: printMigrationSummary()
  CLI-->>User: exit(0)

Loading

Suggested reviewers

• francisrupert
• braddialpad
• ninarepetto

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch dlt-3303

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[Ignacio Ropolo (iropolo)]

Reverting fix tip-tap relative imports . This fix is possible not needed.

[Ignacio Ropolo (iropolo)]

• Added dt-list-item / DtListItem to the scoped #left→#start, #right→#end, #bottom→#blockEnd slot rename regexes

• Added vue3-to-vue-imports migration entry (required, config-based) with detect patterns for @dialpad/dialtone-icons/vue3 and @dialpad/dialtone-vue/vue3

3df4d6b

[github-actions]

✔️ Deploy previews ready!
😎 Dialtone documentation preview: https://dialtone.dialpad.com/deploy-previews/pr-1288/

[Ignacio Ropolo (iropolo)]

This should be already validated trough our migration of ui-kist.

Should be ok to go.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 57322d3a15

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "Codex (@codex) review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "Codex (@codex) address that feedback".

[chatgpt-codex-connector]

Avoid infinite reruns for preserving replacements

When a config intentionally preserves the matched text, this convergence loop never terminates. For example, the theme-to-mode config's dynamic setTheme(expr) replacement prepends a TODO but leaves setTheme(expr) in the file, so dialtone-migrate --only theme-to-mode on such input keeps matching the same call and repeatedly inserts comments instead of finishing. The original helper applies each expression once, so the master runner needs a narrower multi-pass strategy or a guard for preserving replacements.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Honor config-specific ignored paths

When users run the master script from a project root, config-based migrations now scan every file with the right extension and discard each config's globbyConfig.ignore. Several configs rely on those ignores to avoid rewriting fixtures, docs, generated output, and lint-rule sources (for example utility-class-to-token-stops excludes **/lib/dist/** and **/eslint-plugin-dialtone/**, while theme-to-mode excludes migration guide docs), but this call only passes extensions into the custom walker, so those protected files can be modified by --all or --only runs.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Fail the master run when child migrations fail

If a standalone migration exits non-zero, the master runner still resolves normally and the caller records success: true, so the final summary can print DONE and the process can exit 0 even though a child script failed. This matters for --all --yes/CI-style usage because standalone scripts in this package do call process.exit(1) from their error handlers, but that failure is reduced to an unused exitCode field here instead of rejecting or marking the migration failed.

Useful? React with 👍 / 👎.

[coderabbitai]

Actionable comments posted: 7

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@apps/dialtone-documentation/docs/guides/migration/index.md`:
- Around line 60-61: The caption claiming "Run all required (breaking-change)
migrations interactively" is misleading because running `npx dialtone-migrate
--cwd ./src` only opens the selector; it won't execute all migrations unless the
user selects "a" or passes the `--all` flag. Update the documentation line to
either note the interactive prompt step (e.g., mention the selector and that you
must choose "a" to apply all) or change the example command to `npx
dialtone-migrate --cwd ./src --all` so it truly runs all required migrations
automatically.

In `@packages/dialtone-css/lib/build/js/dialtone_migrate_props/index.mjs`:
- Line 634: The help text showing the rewrite for "`@input` → `@update`:model-value"
is missing dt-select-menu despite EMIT_EVENT_RENAMES actually including it;
update the help line in dialtone_migrate_props/index.mjs to include
dt-select-menu in the component list (the line that lists dt-checkbox, dt-input,
dt-radio, dt-radio-group, dt-combobox-multi-select, dt-rich-text-editor,
dt-input-group) so the advertised coverage matches the EMIT_EVENT_RENAMES
mapping.

In `@packages/dialtone-css/lib/build/js/dialtone_migrate/index.mjs`:
- Around line 637-644: The loop currently skips files considered "minified"
using a newline-count heuristic (in the for-of over allFiles, reading into data)
before any regex-based migration checks, which causes short but valid modules to
be ignored; change the logic in the block where data is read so you do not
return early for files with <= 3 newlines — either remove that newline-length
check entirely or move it after the migration regex checks (so functions that
examine data for vue3-to-vue-imports run on short files), keeping the rest of
the flow intact (use the same data variable and preserve matchCount
initialization).
- Around line 153-167: The health-check for the migration "component-props" is
too narrow: update the migration config (object with id 'component-props' and
scriptDir 'dialtone_migrate_props') so its fileExtensions array includes .md,
.html, .js, .ts, .jsx, and .tsx (matching dialtone_migrate_props/index.mjs
rewrites) and extend detectPatterns to cover the additional cases you rewrite
(e.g., recipe-tag slot patterns); do the same reconciliation for the
'physical-to-logical' migration so its fileExtensions and detectPatterns match
the actual rewrite logic (including the new recipe-tag slot cases) to ensure
--health-check reflects real changes.
- Around line 828-833: The catch block handling migration failures (the code
that logs error using migration.name, pushes to results, then calls prompt) must
respect the CLI "--yes" non-interactive flag: replace the unconditional await
prompt call with a conditional that checks the existing boolean flag
representing --yes (e.g., yes / argv.yes / options.yes) and if that flag is true
skip the prompt and assume continuation (treat as 'y') so no stdin is read;
otherwise fall back to await prompt as before; keep the console.error and
results.push logic unchanged and ensure the code does not block when --yes is
set.
- Around line 719-728: The promise returned where you spawn a child process
(using spawn with process.execPath, scriptPath and args) currently always
resolves with { exitCode: code }; change this so non-zero exit codes propagate
as failures: when child.on('close', code => ...) detect if code === 0 then
resolve, otherwise reject (or resolve with an explicit success: false flag) so
main() can treat standalone migration failures as failures instead of marking
them done; update any callers that expect a resolved object if you choose the
reject path.

In `@packages/dialtone-css/package.json`:
- Around line 52-58: The new CLI `bin` entries (e.g., "dialtone-migrate",
"dialtone-health-check", "dialtone-migration-helper",
"dialtone-migrate-flex-to-stack", "dialtone-migrate-link-rendering",
"dialtone-migrate-tshirt-to-numeric", "dialtone-migrate-props" in package.json)
expand the package's public surface and must be released as a feature; update
the PR/commit title or release signal to use a feature-level type (e.g., prefix
the commit/PR title with "feat(dialtone-css):" or otherwise mark it as feat) so
the release tooling treats these new exports as a feature rather than a docs/fix
patch.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository YAML (base), Central YAML (inherited), Organization UI (inherited)

Review profile: ASSERTIVE

Plan: Enterprise

Run ID: d8f487ed-8318-421c-8994-5873ad4624cc

📥 Commits

Reviewing files that changed from the base of the PR and between 1dcf975 and 57322d3.

📒 Files selected for processing (6)

• apps/dialtone-documentation/docs/guides/migration/index.md
• packages/dialtone-css/lib/build/js/dialtone_migrate/index.mjs
• packages/dialtone-css/lib/build/js/dialtone_migrate_props/index.mjs
• packages/dialtone-css/lib/build/js/dialtone_migration_helper/configs/physical-to-logical.mjs
• packages/dialtone-css/lib/build/js/dialtone_migration_helper/configs/vue3-to-vue-imports.mjs
• packages/dialtone-css/package.json

[coderabbitai]

⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

The bare command does not "run all required migrations" by itself.

npx dialtone-migrate --cwd ./src opens the selector; it does not automatically execute all required migrations unless the user then chooses a. This caption should either mention that prompt step or use --all.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@apps/dialtone-documentation/docs/guides/migration/index.md` around lines 60 -
61, The caption claiming "Run all required (breaking-change) migrations
interactively" is misleading because running `npx dialtone-migrate --cwd ./src`
only opens the selector; it won't execute all migrations unless the user selects
"a" or passes the `--all` flag. Update the documentation line to either note the
interactive prompt step (e.g., mention the selector and that you must choose "a"
to apply all) or change the example command to `npx dialtone-migrate --cwd ./src
--all` so it truly runs all required migrations automatically.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Keep the help text aligned with the actual rewrite set.

EMIT_EVENT_RENAMES also rewrites @input on dt-select-menu, but this help line still omits it. The CLI now advertises narrower coverage than it actually has.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/dialtone-css/lib/build/js/dialtone_migrate_props/index.mjs` at line
634, The help text showing the rewrite for "`@input` → `@update`:model-value" is
missing dt-select-menu despite EMIT_EVENT_RENAMES actually including it; update
the help line in dialtone_migrate_props/index.mjs to include dt-select-menu in
the component list (the line that lists dt-checkbox, dt-input, dt-radio,
dt-radio-group, dt-combobox-multi-select, dt-rich-text-editor, dt-input-group)
so the advertised coverage matches the EMIT_EVENT_RENAMES mapping.

[coderabbitai]

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Keep health-check coverage in sync with the real migrations.

component-props only scans .vue here, but dialtone_migrate_props/index.mjs rewrites .md, .html, .js, .ts, .jsx, and .tsx too. physical-to-logical is similarly narrower here than its config, and this detect regex also misses the new recipe-tag slot cases added in physical-to-logical.mjs. --health-check can therefore report DONE while the actual migration would still change files.

Also applies to: 273-286

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/dialtone-css/lib/build/js/dialtone_migrate/index.mjs` around lines
153 - 167, The health-check for the migration "component-props" is too narrow:
update the migration config (object with id 'component-props' and scriptDir
'dialtone_migrate_props') so its fileExtensions array includes .md, .html, .js,
.ts, .jsx, and .tsx (matching dialtone_migrate_props/index.mjs rewrites) and
extend detectPatterns to cover the additional cases you rewrite (e.g.,
recipe-tag slot patterns); do the same reconciliation for the
'physical-to-logical' migration so its fileExtensions and detectPatterns match
the actual rewrite logic (including the new recipe-tag slot cases) to ensure
--health-check reflects real changes.

[coderabbitai]

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Don't treat short source files as minified by default.

The <= 3 newline heuristic silently skips valid source modules before any regex check runs. That will miss exactly the kind of short JS/TS/MJS files the new vue3-to-vue-imports migration is supposed to rewrite.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/dialtone-css/lib/build/js/dialtone_migrate/index.mjs` around lines
637 - 644, The loop currently skips files considered "minified" using a
newline-count heuristic (in the for-of over allFiles, reading into data) before
any regex-based migration checks, which causes short but valid modules to be
ignored; change the logic in the block where data is read so you do not return
early for files with <= 3 newlines — either remove that newline-length check
entirely or move it after the migration regex checks (so functions that examine
data for vue3-to-vue-imports run on short files), keeping the rest of the flow
intact (use the same data variable and preserve matchCount initialization).

[coderabbitai]

⚠️ Potential issue | 🔴 Critical | ⚡ Quick win

Propagate standalone migration failures instead of marking them done.

A child process exiting with a non-zero code is still resolved here, and main() later records it as success: true. That means a failed standalone migration can appear as ✓ DONE in the final summary.

Suggested fix

-    child.on('close', code => {
-      // Exit code 0 means success (or nothing to do)
-      resolve({ exitCode: code });
-    });
+    child.on('close', code => {
+      if (code === 0) {
+        resolve({ exitCode: 0 });
+        return;
+      }
+      reject(new Error(`${migration.id} exited with code ${code}`));
+    });

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	return new Promise((resolve, reject) => {
	const child = spawn(process.execPath, [scriptPath, ...args], {
	stdio: 'inherit',
	cwd: process.cwd(),
	});
	child.on('close', code => {
	// Exit code 0 means success (or nothing to do)
	resolve({ exitCode: code });
	});
	return new Promise((resolve, reject) => {
	const child = spawn(process.execPath, [scriptPath, ...args], {
	stdio: 'inherit',
	cwd: process.cwd(),
	});
	child.on('close', code => {
	if (code === 0) {
	resolve({ exitCode: 0 });
	return;
	}
	reject(new Error(`${migration.id} exited with code ${code}`));
	});

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/dialtone-css/lib/build/js/dialtone_migrate/index.mjs` around lines
719 - 728, The promise returned where you spawn a child process (using spawn
with process.execPath, scriptPath and args) currently always resolves with {
exitCode: code }; change this so non-zero exit codes propagate as failures: when
child.on('close', code => ...) detect if code === 0 then resolve, otherwise
reject (or resolve with an explicit success: false flag) so main() can treat
standalone migration failures as failures instead of marking them done; update
any callers that expect a resolved object if you choose the reject path.

[coderabbitai]

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

--yes should stay non-interactive on failure.

If a migration throws, the tool still prompts for confirmation to continue. In scripted or CI usage, --yes should not block on stdin here; either continue automatically or fail fast.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/dialtone-css/lib/build/js/dialtone_migrate/index.mjs` around lines
828 - 833, The catch block handling migration failures (the code that logs error
using migration.name, pushes to results, then calls prompt) must respect the CLI
"--yes" non-interactive flag: replace the unconditional await prompt call with a
conditional that checks the existing boolean flag representing --yes (e.g., yes
/ argv.yes / options.yes) and if that flag is true skip the prompt and assume
continuation (treat as 'y') so no stdin is read; otherwise fall back to await
prompt as before; keep the console.error and results.push logic unchanged and
ensure the code does not block when --yes is set.

[coderabbitai]

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Use a feature-level release signal for these new CLI exports.

These bin entries expand the public surface of a published npm package. Shipping them under a docs(...) title/merge commit risks releasing them as a docs patch instead of a feature. As per coding guidelines, "This is a public npm library. Breaking changes without BREAKING CHANGE footer ship as patches and silently break consumers" and "new exports need feat, not fix."

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/dialtone-css/package.json` around lines 52 - 58, The new CLI `bin`
entries (e.g., "dialtone-migrate", "dialtone-health-check",
"dialtone-migration-helper", "dialtone-migrate-flex-to-stack",
"dialtone-migrate-link-rendering", "dialtone-migrate-tshirt-to-numeric",
"dialtone-migrate-props" in package.json) expand the package's public surface
and must be released as a feature; update the PR/commit title or release signal
to use a feature-level type (e.g., prefix the commit/PR title with
"feat(dialtone-css):" or otherwise mark it as feat) so the release tooling
treats these new exports as a feature rather than a docs/fix patch.