feat(): add non-viable handling

[Karnaukhov-kh]

Adds an individual step to design system refactoring workflow that handles the cases of non-viable migrations.

2 approaches were weighted.

Exclusion Classes in Reporter

Pros:

• Clean solution - no HTML/CSS pollution
• Configuration-based - simple team management
• Performance - faster analysis by skipping excluded classes

Cons:

• Easy metric manipulation - teams can instantly hide violations by adding exclusions
• No accountability - violations disappear without evidence of work done
• Lost tracking - excluded classes become invisible and forgotten

Prefix with 'after-migration' Workflow

Pros:

• Requires demonstrable work - actual file changes and validation needed
• Future migration path - can later target after-migration-* classes for cleanup
• Immediate implementation - works with existing infrastructure

Cons:

• HTML pollution - adds after-migration- prefixes to templates
• CSS duplication - increases stylesheet size
• Manual process - requires AI-assisted execution

The Winner

Prefix with 'after-migration' Workflow

The exclusion approach has a flaw for large teams: it enables too easy manipulation of metrics without any work being done. Maintaining honest reporting and accountability is more valuable than clean code in the short term.

The workflow ensures teams actually engage with the problem rather than just hiding it. Plus, the future migration path means the CSS/HTML pollution isn't permanent - it's a documented stepping stone.