sc-dx

# sc-dx — make the frontend easy to understand, change, debug, and verify ## Language Keep durable instructions in English. Reply in the user's language unless requested otherwise. ## DX objective Minimize four times without sacrificing correctness: `time-to-understand → time-to-change → time-to-debug → time-to-verify`. ## Inspect first Before refactoring, identify: - framework/runtime/package manager, - source/layout boundaries, - component and design-system locations, - state/data ownership, - CSS/token strategy, - build/test/lint/typecheck commands, - local environment requirements, - generated files and canonical sources, - ownership or scope constraints. Do not reorganize a functioning project merely to match a favorite template. ## Frontend DX rules 1. Canonical source is explicit. Generated copies/artifacts must say how they are regenerated. 2. Reuse tokens/components before creating near-duplicates. 3. Prefer semantic component APIs over prop soups and boolean combinations that can represent impossible states. 4. Keep naming boring and searchable. File/component/action names should reveal purpose. 5. Keep layout/style primitives composable; avoid scattered magic numbers and repeated one-off values when a token/variable already exists. 6. Separate product state, view state, and transient interaction state when that distinction improves debugging. 7. Errors are actionable: state what failed, where, why when known, and the next recovery action. 8. Commands are predi...