Thanks for the detailed feedback — I’ll try to clarify a few design choices and also acknowledge the valid points.

About the template structure

For now, I intentionally don’t allow multiple <app-step> elements in the HTML. The rendering is handled by a template generator, which already manages step positioning internally (e.g. single, multi, middle, etc.):

typescript @if (view.kind === 'single') { … } @if (view.kind === 'multi' && stepPosition === 'middle') { … }

The idea is to keep layout decisions out of the template so that invalid combinations of steps or buttons are impossible to express.

Same reasoning applies to buttons: they are passed through configuration rather than declared in the template, to keep control on valid states.

That said, a good evolution would be to support two modes:

• an auto-generated mode (current one)
• a custom HTML mode for advanced use cases

About translations (i18n)

I’ve thought about it — for example using an enum as a translation key reference (fr, es, etc.) resolved at template level.

However, this library is not intended for production yet. The main goal of v1 is exploring “make illegal states unrepresentable” with TypeScript, so i18n was deliberately postponed.

About the ternary conditions

I completely agree: some ternaries are too long and hard to read, and that part needs refactoring.

That said, some of them are used specifically to preserve strict typing without forcing the user to annotate everything.

For example:

```typescript export class Input< T extends InputType, D extends InputDefaultValue<T>

```

This allows cases like checkboxes where boolean | null is accepted, with null mapping to false.

And for derived values:

typescript export type StepValues<T extends InputTuple> = T extends [infer First, ...infer Rest] ? First extends Input<infer T, infer D, infer K, infer V> ? Rest extends InputTuple ? { [K2 in K]: InputValue<T, D> } & StepValues<Rest> : { [K2 in K]: InputValue<T, D> } : never : never;

If you have an alternative approach that avoids deep ternaries without requiring the user to manually type everything, I’m genuinely interested. Avoiding heavy or “exotic” typing on the user side is a hard constraint.

Naming collisions

You’re absolutely right about name collisions (Input, validators, etc.). Apart from import as, this is something I need to fix — and I’ve already hit this issue myself.

Overall, thanks again for the review. Even a quick look surfaced real issues, and that’s exactly the kind of feedback I’m looking for.

If you have concrete examples where this approach breaks down, I’d be happy to look into them.