packages/react/src/components/presentation/auth/SignIn/v2/BaseSignIn.tsx (1)

64-70: 💤 Low value

JSDoc comment could clarify the server error lifecycle.

The inline documentation states that fieldErrors reflects both client-side and server-side errors, but it doesn't explain when server errors are cleared. Consider adding a note that server errors persist until the next submission or until the field is edited (depending on implementation).

🤖 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/react/src/components/presentation/auth/SignIn/v2/BaseSignIn.tsx`
around lines 64 - 70, Update the JSDoc for the fieldErrors block in BaseSignIn
to explicitly document the server error lifecycle: state that fieldErrors
combines client-side rule evaluation and server-side failures (from
data.fieldErrors), that full FieldError[] is on the raw response and mirrored to
the serverFieldErrors prop, and add a sentence stating when server-side errors
are cleared (e.g., they persist until the next form submission or until the user
edits the associated field depending on the existing implementation of
BaseSignIn's submit/field-change handlers). Reference the fieldErrors identifier
and the serverFieldErrors prop so readers can locate the related state/prop
handling.

packages/react/src/components/presentation/auth/InviteUser/v2/BaseInviteUser.tsx (1)

435-452: 💤 Low value

Complex nested validation logic can be simplified.

Lines 435-452 have nested conditionals: if required & empty → error, else → email validation, then rule validation (if no error yet). The if (value && !errors[comp.ref]) check at line 443 suggests defensive coding, but errors[comp.ref] won't be set yet in this context since we're building the errors object.

Consider restructuring for clarity:

♻️ Optional refactor for clarity

            const value: any = formValues[comp.ref];
            if (comp.required && (!value || value.trim() === '')) {
              errors[comp.ref] = `${comp.label || comp.ref} is required`;
+             return; // Skip further validation for empty required fields
            } else {
              // Email validation
              if (comp.type === 'EMAIL_INPUT' && value && !/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(value)) {
                errors[comp.ref] = 'Please enter a valid email address';
+               return; // Skip rule validation if email format is invalid
              }
              // Evaluate declarative validation rules from meta.components[].validation.
-             if (value && !errors[comp.ref]) {
+             if (value) {
                const ruleValidator = buildValidatorFromRules(comp.validation);
                if (ruleValidator) {
                  const message = ruleValidator(value);
                  if (message) {
                    errors[comp.ref] = message;
                  }
                }
              }
            }

This makes the validation precedence explicit: required → email format → rules.

🤖 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/react/src/components/presentation/auth/InviteUser/v2/BaseInviteUser.tsx`
around lines 435 - 452, The validation block in BaseInviteUser.tsx is overly
nested and uses a redundant guard (checking value && !errors[comp.ref]) which is
unnecessary because errors is being built here; refactor the logic in the loop
that inspects each comp so it enforces precedence explicitly: first check
required and set errors[comp.ref] if missing, then if comp.type ===
'EMAIL_INPUT' validate the email format and set errors[comp.ref] if invalid, and
finally if value exists and no error yet call
buildValidatorFromRules(comp.validation) and apply the returned ruleValidator to
set errors[comp.ref] if it returns a message; keep references to comp.ref,
comp.label, comp.type, buildValidatorFromRules and the errors object to locate
and update the code.

packages/react/src/components/presentation/auth/AcceptInvite/v2/BaseAcceptInvite.tsx (1)

491-502: 💤 Low value

Validation logic flow may allow both required and rule errors to be set.

Lines 491-502 check comp.required first, then evaluate rules. However, if comp.required && !value, the function returns early, but the else if (value) block at line 493 means rules are only evaluated when there's a value. The structure is correct, but the code would be clearer with an explicit early return after setting the required error.

♻️ Optional refactor for clarity

            const value: any = formValues[comp.ref];
            if (comp.required && (!value || value.trim() === '')) {
              errors[comp.ref] = t('validations.required.field.error');
-           } else if (value) {
+             return; // Skip rule evaluation for empty required fields
+           }
+           if (value) {
              // Evaluate declarative validation rules from meta.components[].validation.
              const ruleValidator = buildValidatorFromRules(comp.validation);
              if (ruleValidator) {
                const message = ruleValidator(value);
                if (message) {
                  errors[comp.ref] = t(message);
                }
              }
            }

This makes it explicit that we don't evaluate rules for empty required fields.

🤖 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/react/src/components/presentation/auth/AcceptInvite/v2/BaseAcceptInvite.tsx`
around lines 491 - 502, The required-field branch may be ambiguous; after
setting errors[comp.ref] when comp.required && (!value || value.trim() === ''),
short-circuit so we don't run buildValidatorFromRules/ ruleValidator for empty
values — add an explicit early exit (e.g., continue the loop or return from the
enclosing function) immediately after setting the required error so rules are
not evaluated for empty required fields and t(...) is only called once.

Fix all unresolved CodeRabbit comments on this PR:

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