fix(codemods): make the composite codemod runnable from a URL

[mfal]

What & why

flowAlphaAll (now flow1) has been broken for every consumer since it shipped in #2884:

Error: Cannot find module './flowAlphaActionPropToOnAction'
Require stack:
- /var/folders/.../T/jscodeshift-65239-mBfrbFIj29B6-.ts

Root cause. jscodeshift downloads a -t <url> transform into the OS temp
dir and requires it from there (Runner.js:182-193), so relative imports
resolve against that temp dir, where no sibling file exists. It was
the only transform importing its siblings, so it was the only broken one — the
individual codemods all work.

The fix

src/transforms is what consumers fetch and must stay self-contained.
src/composites holds transforms that compose others, and
pnpm nx build codemods inlines a composite into a standalone, committed
bundle.

• The composite is renamed to flow1 — named after where it takes you, the
  way flow020 already is. "All" is gone on purpose: of the 23 breaking-change
  entries in MIGRATION.md, 5 have a codemod, so the script is the mechanical
  part of the migration, not the whole of it. The guide and the transform's own
  doc now say so. The old URL never worked, so no functioning command changes.
• The bundler parses with jscodeshift itself and keeps types and JSDoc, so the
  generated file passes tsc, eslint and prettier like hand-written code
  (no ignore entries needed). It is strict on purpose: it knows the shape every
  transform has — one type-only jscodeshift import, one top-level
  declaration, one export default <identifier> — and throws on anything else
  instead of emitting a bundle that silently drops code.
• nx wiring: build declares outputs and excludes its own output from
  inputs; test:unit depends on build and folds its hash in via
  dependentTasksOutputFiles, so affected:test regenerates and CI's
  git diff --exit-code catches a stale bundle.

Tests

The package had none. It now has 20, all running the real jscodeshift CLI on
a temp copy of the transform — the consumer's path, not just the exported
function.

standalone.test.ts is the regression test: it copies each transform alone
into a temp directory and runs it, which is exactly how a URL-fetched transform
executes. Verified against the bug — 8 passed, flowAlphaAll failed.

One subtlety worth knowing when reading runTransform.ts: jscodeshift exits
0 even when its worker dies while loading the transform. A test asserting on
the exit code would have stayed green. The helper asserts on the run summary
instead (0 errors and exactly one file processed).

Two more defects, found by the idempotency test

All eight transforms are now asserted to be idempotent — a second run must be a
no-op, which matters because flow1 chains five of them over the same source.
Writing that test turned up two pre-existing defects in
flowAlphaAlignToCombine, both shipping broken code to the consumer:

• import { Align as Row } was never rewritten, although the transform
  documents that an alias is kept and only the imported name changes. The early
  return counted non-aliased renames only, so an alias-only file looked
  untouched and the mutation was discarded. Align no longer exists, so the
  consumer was left with a broken import.
• A file importing both Align and Combine ended up with
  import { Combine, Combine }, which does not parse — the first run produced a
  file no second run could read. Colliding specifiers now collapse onto one, and
  a value import wins over a type-only one so nothing loses its runtime binding.

Also in here

AccentBox codemod for alpha.786 (flowAlphaAccentBoxColorToBackgroundColor,
also part of flowAlphaAll). The entry existed without a transform.

This is not a rename — color changed meaning. It used to accept
"blue" | "green" | "gradient" | "neutral" and now accepts
"default" | "dark" | "light" | "dark-static" | "light-static", so a blanket
rename would break every element already on the new API. The transform decides
per value: a value from the new foreground union stays on color, every other
literal moves to backgroundColor.

Two cases are deliberately left for a human, because neither is decidable from
the source — both are documented in the migration entry:

• color={expression} — the same expression means background in old code and
  foreground in new code.
• An element that already carries backgroundColor — moving color there
  would overwrite the explicit value.

flow020.ts type error. Pre-existing, surfaced by the new test:compile
gate. Fixed with a String() cast; behaviour is unchanged.

Reviewer notes

• packages/codemods/src/transforms/flow1.ts is generated — review
  src/composites/flow1.ts instead. It is ~650 lines of the diff.
• New package docs in packages/codemods/AGENTS.md,
  plus a generated-artifact row and a common-failures row in the root
  AGENTS.md.
• The runtime fallback in AccentBox.tsx maps neutral/gradient/green onto
  the background but not blue. That is intended, so
  <AccentBox color="blue"> renders neutral today, and the codemod moving it to
  backgroundColor="blue" brings the blue background back. That is the one case
  where running the codemod changes what you see; the migration entry says so.

Base branch & title

fix(codemods): → base main. No feature and no breaking change: the fix
restores a documented command that never worked, and the new codemod is
additive tooling in a private package.

Checklist

• PR title is a Conventional Commit and matches the base branch above
• pnpm lint is clean and pnpm affected:test passes (browser tests if
  behavior changed)
• Generated code is committed (git diff is empty after the relevant
  build:* targets)
• User-facing strings added to both de-DE and en-US locale files —
  n/a, no UI text
• Docs updated if a public API changed; intentional visual changes get
  updated snapshots / the update-screenshots label — no visual change

[github-actions]

Coverage Report for ./packages/components/

Status	Category	Percentage	Covered / Total
🔵	Lines	76%	627 / 825
🔵	Statements	75.91%	643 / 847
🔵	Functions	77.95%	145 / 186
🔵	Branches	66.66%	298 / 447

File Coverage

No changed files found.

Generated in workflow #6325 for commit ac6a596 by the Vitest Coverage Report Action

[github-actions]

🚀 Preview Deployment

Preview environments are ready:

Type	URL
docs	pr-2942.docs.review.flow-components.de
storybook	pr-2942.storybook.review.flow-components.de

Images:

• docs: ghcr.io/mittwald/flow/docs:pr-2942
• storybook: ghcr.io/mittwald/flow/storybook:pr-2942

[mfal]

Closed in favour of #2978, which supersedes this.

What was adopted there: the four transforms this PR added, the test harness (runTransform, the fixture and idempotency suites), remoteScope.ts and its derived remote-package check, and the migration prose this PR added to MIGRATION.md — in particular the AccentBox entry explaining that color was re-meant rather than renamed. All of it reviewed and green here, so re-deriving it would have been waste.

What was not: the composite bundler and src/composites. #2978 publishes @mittwald/flow-codemods as a CLI, which runs the codemods individually and reports per codemod, so bundling them into one self-contained transform has no remaining caller. The raw-GitHub-URL delivery path that made the bundler necessary is retired there, and the transform files are renamed to dashed catalogue ids.

That rename is why this PR was closed rather than merged: merging it to main afterwards would conflict with every renamed file.

The bug this PR fixed is fixed there too — by construction rather than by bundling. The CLI hands jscodeshift a path inside the installed package, so a transform is never downloaded into a temp directory and can never fail to resolve a sibling import.