@carecard/validate 3.1.23 → 3.1.25

package/.agents/skills/github-pr-merge-cleanup/SKILL.md

@@ -0,0 +1,175 @@
+---
+name: github-pr-merge-cleanup
+description: 'Use only when the user explicitly asks for remote Git or GitHub PR work: reviewing remote mergeability, validating, merging, closing, deleting, or cleaning up a pull request branch.'
+---
+
+# Pull Request Merge Close
+
+## Purpose
+
+After the user explicitly asks for remote Git or GitHub PR work, review, validate, merge, close, delete branch, and clean local state for a GitHub pull request targeting origin/development.
+
+## When To Use
+
+- Use only when the user explicitly asks to review mergeability, validate, merge, close, or clean up a GitHub pull request branch.
+
+## When Not To Use
+
+- Do not use for creating a new pull request; use the PR create/update skill.
+- Do not use when the user only asks for local code changes without PR merge work.
+
+## Remote Git Operations Guardrail
+
+Do not run remote Git or GitHub operations unless the current user request explicitly asks for them. This includes `git fetch`, `git pull`, `git push`, `git push --delete`, remote branch cleanup, GitHub API calls, and any `gh pr` command that creates, updates, readies, merges, closes, or cleans up a pull request. Do not infer permission from branch names, validation needs, prior workflow habits, or convenience; ask first when remote state would help but was not requested.
+
+## Relevant Files And Directories
+
+- Git branch state in this repository
+- GitHub pull requests viewed with `gh`
+- repository validation commands and `.husky` scripts
+
+## Coding Principles
+
+- Preserve the repository structure, naming style, module system, and local helper patterns.
+- Prefer readable, maintainable code with meaningful function, variable, file, and test names.
+- Avoid new dependencies unless the existing stack cannot reasonably solve the task and the user confirms the tradeoff.
+
+## Testing Expectations
+
+- Run repository validation before PR creation or merge when code behavior changed.
+- Confirm the branch is clean except intended changes before finishing.
+
+## Safety Constraints
+
+- Do not edit generated output, dependency folders, logs, coverage, dist, or build artifacts unless the task requires it.
+- Do not revert or overwrite user changes; stage only requested skill or instruction files.
+- Never suppress errors, lint failures, type failures, security failures, or failing tests; fix the underlying issue or report the blocker.
+
+## Commit Continuation Rule
+
+Do not amend commits unless the user explicitly asks. If
+hook, formatter, documentation, skill, validation, or review follow-up changes
+appear after a commit, stage only the intended files and make a new commit with
+a clear message.
+
+## Scope
+
+Use this skill from the root of the repository that owns the pull request. The
+repository must use GitHub CLI, have a remote base branch, and have the target
+branch available locally or on `origin`.
+
+Default terms:
+
+- Base branch: `development` when `origin/development` exists, otherwise the
+  repository default branch.
+- Target branch: the current branch unless the user names another branch.
+- Pull request: the open PR whose head is the target branch and whose base is
+  the base branch.
+
+Do not continue automatically when:
+
+- `gh auth status` fails.
+- The target branch is detached or is the base branch.
+- The working tree has uncommitted changes that are not part of the requested
+  PR cleanup.
+- No open PR exists for the target branch.
+- A rebase or validation fix would require behavior changes instead of coding
+  criteria cleanup.
+
+## Workflow
+
+1. Capture the base branch, target branch, PR number, and protection state:
+
+    ```sh
+    gh auth status
+    base="development"
+    git ls-remote --exit-code --heads origin development >/dev/null 2>&1 || \
+      base="$(gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name')"
+    target_branch="$(git branch --show-current)"
+    test -n "$target_branch"
+    test "$target_branch" != "$base"
+    git status --short
+    git fetch origin "$base" --prune
+    pr_number="$(gh pr list --head "$target_branch" --base "$base" --state open --json number --jq '.[0].number // empty')"
+    test -n "$pr_number"
+    protected="$(gh api "repos/{owner}/{repo}/branches/$target_branch" --jq '.protected' 2>/dev/null || echo false)"
+    ```
+
+    If the PR head branch is not local, create a local branch from the remote
+    head before continuing.
+
+2. Check mergeability before changing history:
+
+    ```sh
+    gh pr view "$pr_number" --json mergeStateStatus,mergeable,headRefName,baseRefName
+    if git merge-tree --write-tree HEAD "origin/$base" >/tmp/pull-request-merge-close-merge-tree.out
+    then
+      merge_conflict_detected=false
+    else
+      merge_conflict_detected=true
+    fi
+    ```
+
+3. If a merge conflict is detected, rebase the target branch on the fresh base
+   branch. Abort and stop if the rebase conflicts:
+
+    ```sh
+    if [ "$merge_conflict_detected" = true ]; then
+      if git rebase "origin/$base"; then
+        git push --force-with-lease -u origin "$target_branch"
+      else
+        git rebase --abort
+        echo "Rebase conflicted; aborted without merging."
+        exit 1
+      fi
+    fi
+    ```
+
+    Do not resolve rebase conflicts unless the user explicitly asks.
+
+4. Load and apply all relevant repository skills before merging:
+    - Read the repository's `.agents/skills/**/SKILL.md` files that apply to the
+      changed code, plus shared workspace standards when present.
+    - Compare the target branch against the base with
+      `git diff --stat "origin/$base...HEAD"` and inspect changed files.
+    - Check whether the target branch satisfies the applicable coding,
+      architecture, validation, security, and style criteria from those skills.
+    - Run the validation commands required by the skills and repository hooks.
+    - If criteria are not met and the fix does not change functionality, make the
+      minimal cleanup, stage only intended files, commit to the target branch,
+      and push the target branch.
+    - If meeting the criteria would change behavior, stop and report the gap.
+
+5. Confirm the PR is still mergeable after validation changes:
+
+    ```sh
+    git fetch origin "$base" --prune
+    git merge-tree --write-tree HEAD "origin/$base" >/tmp/pull-request-merge-close-final-merge-tree.out
+    gh pr checks "$pr_number"
+    ```
+
+6. Merge the PR with GitHub CLI. Delete the remote target branch only when it is
+   not protected:
+
+    ```sh
+    if [ "$protected" = true ]; then
+      gh pr merge "$pr_number" --squash --admin
+    else
+      gh pr merge "$pr_number" --squash --admin --delete-branch
+    fi
+    ```
+
+7. Clean up the local repository after merge:
+
+    ```sh
+    git fetch origin "$base" --prune
+    git switch "$base"
+    git pull --ff-only origin "$base"
+    git branch -d "$target_branch" || git branch -D "$target_branch"
+    git ls-remote --heads origin "$target_branch"
+    ```
+
+8. Final response should include the PR URL, whether a rebase was performed,
+   what validation and skill checks ran, whether any cleanup commit was added,
+   whether the remote target branch was deleted or protected, and whether local
+   development is up to date.

package/.agents/skills/github-pr-merge-cleanup/agents/openai.yaml

@@ -0,0 +1,5 @@
+interface:
+    display_name: 'GitHub PR Merge And Cleanup'
+    short_description: 'Review, validate, merge, close, delete branch, and clean local state for a GitHub pull request targeting origin/development'
+    brand_color: '#0F766E'
+    default_prompt: 'Use $github-pr-merge-cleanup when this task matches the skill scope.'

package/.agents/skills/logged-in-user-profile-page/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: logged-in-user-profile-page
+description: 'Use when changing shared validation behavior for app-dashboard logged-in profile/settings fields, especially phone number and country-code request aliases.'
+---
+
+# Logged-In User Profile Page
+
+## Scope
+
+Use this skill inside `pkg-validate` when dashboard profile/settings behavior
+depends on shared validation rules.
+
+Relevant profile/settings fields:
+
+- Phone number: `phone_number`, `phoneNumber`
+- Country code: `country_code`, `countryCode`
+
+## Requirements
+
+- Keep `validateProperties` aliases in sync with `validateWhitelistProperties`
+  consumers in services such as `ms-auth`.
+- Preserve both snake_case and camelCase aliases unless a task explicitly
+  removes one.
+- Add focused tests for every accepted and rejected profile/settings key alias.
+- Update `readme.md` whenever a key alias is added or removed.
+- Do not add dashboard-specific service behavior to this package; keep it to
+  deterministic validation helpers and key-based validation contracts.
+
+## Validation
+
+- Run focused Mocha tests for the changed validator keys.
+- Run `npm run test:types` when public exports or declarations are affected.
+- Run `npm run test:All` for validator contract changes before finalizing.

package/.agents/skills/logged-in-user-profile-page/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+    display_name: 'Logged-In User Profile Page'
+    short_description: 'Guide shared validator support for profile/settings fields'
+    default_prompt: 'Use $logged-in-user-profile-page when changing shared validation for dashboard profile/settings request fields.'

package/.agents/skills/pkg-validate-validation-library/SKILL.md

@@ -0,0 +1,200 @@
+---
+name: pkg-validate-validation-library
+description: 'Use when changing pkg-validate validators, sanitizers, whitelist behavior, nested path rules, bad-input errors, package exports, or tests.'
+---
+
+# Package Validate
+
+## Purpose
+
+CareCard validation package for deterministic validators, sanitization, whitelist validation, nested paths, error mapping, exports, and tests.
+
+## When To Use
+
+- Use when changing pkg-validate validators, sanitizers, whitelist behavior, nested path rules, bad-input errors, package exports, or tests.
+- Pair with `carecard-workspace-standards` when the task affects shared CareCard conventions or cross-repository contracts.
+
+## When Not To Use
+
+- Do not use for service-local behavior that should remain inside one API or app.
+- Do not change package public APIs without updating consumers and compatibility tests.
+
+## Relevant Files And Directories
+
+- package entry files
+- `src` when present
+- `test`
+- `package.json`
+- `package-lock.json`
+- `.husky`
+
+## Coding Principles
+
+- Preserve the repository structure, naming style, module system, and local helper patterns.
+- Prefer readable, maintainable code with meaningful function, variable, file, and test names.
+- Avoid new dependencies unless the existing stack cannot reasonably solve the task and the user confirms the tradeoff.
+- Keep public exports stable and update CommonJS, ESM, TypeScript declaration, and compatibility surfaces together when present.
+
+## Testing Expectations
+
+- Write or update package tests before behavior or public API changes.
+- Include type/export compatibility tests where the package already has them.
+- Run package test, lint, type, and Husky validation commands required by the changed area.
+
+## Safety Constraints
+
+- Do not edit generated output, dependency folders, logs, coverage, dist, or build artifacts unless the task requires it.
+- Do not revert or overwrite user changes; stage only requested skill or instruction files.
+- Never suppress errors, lint failures, type failures, security failures, or failing tests; fix the underlying issue or report the blocker.
+- Do not log or expose secrets, JWTs, passwords, credentials, private keys, sensitive personal data, SQL internals, or stack traces.
+
+## Overview
+
+Use this skill when working inside `pkg-validate`, the `@carecard/validate`
+package. It provides deterministic validators, key-based property sanitization,
+and CareCard whitelist validation behavior used across services.
+
+Use `$carecard-workspace-standards` for shared workspace, dependency, package,
+testing, and security rules. Legacy `pkg-validate/.codex` and
+`pkg-validate/.junie` guidance has been migrated into these skills; do not
+depend on those folders being present.
+
+## Non-Negotiable Rules
+
+- Never use TypeScript type `any`. Use specific value, record, validator,
+  option, result, generic, or `unknown` types with narrowing.
+- Follow this repository's coding style, naming conventions, and CommonJS
+  project structure.
+- Use Test-Driven Development: add or update relevant Mocha or type tests before
+  changing behavior.
+- Never suppress errors, linter warnings, TypeScript errors, or failing tests.
+  Handle the underlying issue.
+- Do not add dependencies unless absolutely needed. Ask for confirmation first
+  with the reason and tradeoff.
+- Before finalizing work, run every direct script in `.husky` and fix anything
+  they report.
+
+## Package Shape
+
+- Keep `index.js` as the centralized public export surface.
+- Keep TypeScript declarations in `index.d.ts` aligned with every public export
+  in `index.js`.
+- Keep direct validators in `lib/validate.js`.
+- Keep key-based property sanitization in `lib/validateProperties.js`.
+- Keep whitelist, nested-path, casing, flattening, and CareCard bad-input
+  behavior in `lib/validateWhitelistProperties.js`.
+- Preserve the package's CommonJS module style unless the repository is
+  intentionally migrated.
+- Keep the deprecated `validate` namespace export backward-compatible while
+  preferring direct top-level exports in new code.
+
+## Validation Behavior
+
+- Low-level validators should be deterministic predicate functions that return
+  `true` or `false`.
+- Password failure-message helpers should return `null` for valid input and a
+  user-readable string for invalid input.
+- `validateProperties` should return a new sanitized object and omit unknown or
+  invalid fields without mutating the input.
+- `validateWhitelistProperties` should reject missing or invalid required fields
+  with CareCard `BAD_INPUT` errors through `@carecard/common-util`.
+- Optional whitelist fields should be ignored when absent and rejected when
+  present but invalid.
+- Preserve supported snake_case and camelCase field aliases unless a task
+  explicitly changes the API contract.
+- Preserve nested dot-path handling, maximum nesting depth, maximum path count,
+  optional snake_case conversion, and flattening behavior.
+- Avoid broad regular expressions or validation changes without focused tests
+  for accepted values, rejected values, length limits, and edge cases.
+
+## Types And API Contracts
+
+- Model input and output records, whitelist options, flattened output behavior,
+  validators, and failure-message helpers explicitly in `index.d.ts`.
+- When existing declarations are too loose, improve them with specific types as
+  part of the touched change instead of adding new loose types.
+- Update `test/types.test.ts` whenever public types, exports, options, return
+  values, or validators change.
+- Keep runtime exports, README examples, and type declarations in sync.
+- Preserve validation behavior for invalid, missing, extra, and valid fields.
+
+## Tests And Coverage
+
+- Use Mocha for runtime tests under `test`.
+- Use `test/types.test.ts` for TypeScript declaration coverage through
+  `npm run test:types`.
+- Add focused tests for valid input, invalid input, missing fields, optional
+  fields, array handling, nested paths, casing conversion, flattening, and error
+  messages when those areas change.
+- Keep tests deterministic and avoid real external services.
+- This package enforces 100% coverage for branches, functions, lines, and
+  statements through `nyc`; do not reduce thresholds.
+
+## Legacy Junie Source Notes
+
+The migrated `.junie` memory files contained no active task, feedback, or error
+entries. `language.json` was an empty array, `memory.version` was `3.0`, and no
+plan files were present.
+
+## Validation
+
+Useful commands:
+
+- `npm run lint`
+- `npm run lint:fix`
+- `npm run format`
+- `npm run format:check`
+- `npm run test`
+- `npm run test:types`
+- `npm run test:coverage`
+- `npm run test:All`
+
+Before pushing or finalizing, run every direct `.husky` script. The current
+`.husky/pre-commit` runs:
+
+```bash
+npm run lint:fix
+npm run format
+npm run test:All
+```
+
+If any validation command cannot run, report the exact command, failure reason,
+and remaining risk.
+
+## Remote Git Operations Guardrail
+
+Do not run remote Git or GitHub operations unless the current user request explicitly asks for them. This includes `git fetch`, `git pull`, `git push`, `git push --delete`, remote branch cleanup, GitHub API calls, and any `gh pr` command that creates, updates, readies, merges, closes, or cleans up a pull request. Do not infer permission from branch names, validation needs, prior workflow habits, or convenience; ask first when remote state would help but was not requested.
+
+## Agent Guidance Git Workflow
+
+When this skill or any repository-owned `.agents` guidance changes, use the
+repository's agents-only Git workflow:
+
+1. Work from the affected repository root and confirm only intended `.agents`
+   files changed.
+2. Use `development` as the base branch when `origin/development` exists;
+   otherwise use the repository's default base branch, usually `main`.
+3. Create or update `feature/codex` from the updated remote base branch and
+   commit all the changed `.agents` guidance files there.
+4. Push `feature/codex`, create or reuse a pull request into the base branch,
+   and mark the pull request ready for review with `gh pr ready <number>`.
+5. Squash-merge with administrator privileges and delete the remote branch:
+
+    ```sh
+    gh pr merge <number> --squash --admin --delete-branch
+    ```
+
+6. After merge, update the local base branch and remove the local feature
+   branch:
+
+    ```sh
+    git fetch origin <base> --prune
+    git switch <base>
+    git pull --ff-only origin <base>
+    git branch -d feature/codex
+    git ls-remote --heads origin feature/codex
+    ```
+
+Do not commit or push `.agents` guidance changes directly from `development`
+or `main`. Do not stage unrelated files, generated output, dependency folders,
+build artifacts, logs, or `.DS_Store`.

package/.agents/skills/pkg-validate-validation-library/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+    display_name: 'Package Validate Validation Library'
+    short_description: 'CareCard validation package for deterministic validators, sanitization, whitelist validation, nested paths, error mapping, exports, and t...'
+    default_prompt: 'Use $pkg-validate-validation-library when this task matches the skill scope.'

package/.agents/skills/software-design-patterns-and-clean-code/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: software-design-patterns-and-clean-code
+description: 'Use every time before coding, refactoring, debugging, or reviewing in this repository, alongside all other applicable skills, to apply pragmatic software design patterns, SOLID, Clean Code, and testable architecture.'
+---
+
+# Software Design Patterns And Clean Code
+
+## Purpose
+
+Use this skill with every coding, refactoring, debugging, or review task in
+this repository. It supplements repository-specific skills; follow both, and
+let the more specific skill decide file locations, framework conventions,
+validation commands, and API contracts.
+
+## Core Principles
+
+- Prefer simple, maintainable, readable implementation over clever abstraction.
+- Use Gang of Four design patterns only when they reduce real complexity,
+  improve clarity, or make behavior easier to test.
+- Follow SOLID principles, especially Single Responsibility and Dependency
+  Inversion where they improve maintainability.
+- Keep clear separation of concerns between routing, orchestration, domain
+  logic, persistence, validation, formatting, and side effects.
+- Apply DRY, KISS, and YAGNI. Remove meaningful duplication, keep solutions
+  direct, and avoid speculative generalization.
+- Favor small, composable functions with meaningful names and explicit inputs.
+- Prefer pure functions for calculations, mapping, validation, and transforms
+  when practical.
+- Keep side effects minimal, localized, and easy to identify.
+- Use explicit error handling. Do not swallow failures or hide actionable
+  error context.
+- Design code so behavior can be tested through focused unit, integration, or
+  service tests without fragile setup.
+- Avoid unnecessary dependencies. Use existing language, framework, and local
+  helper capabilities before adding packages.
+
+## Function Comments
+
+For every new or modified function, method, or exported callback, add a short
+comment immediately above it explaining the main pattern or principle being
+applied. Keep the comment accurate and specific to the function.
+
+Use the host language's normal comment syntax. Examples:
+
+```ts
+// Pattern: Single Responsibility - validates user input only.
+function validateUserInput(...) { ... }
+
+// Pattern: Pure Function - deterministic output with no side effects.
+function calculateTotal(...) { ... }
+
+// Pattern: Dependency Inversion - depends on an injected repository contract.
+async function loadProfile(...) { ... }
+```
+
+## Working Rules
+
+- Do not violate these coding principles unless there is no reasonable
+  alternative.
+- If a principle must be violated, include a short explanation in the code
+  review or final summary.
+- Refactor touched existing code to follow these patterns and principles when
+  doing so is safe and related to the requested change.
+- Do not use this skill as a reason for broad unrelated rewrites.
+- Before introducing an abstraction or design pattern, confirm it removes real
+  complexity compared with a straightforward function or module.
+- Prefer dependency inversion at boundaries such as databases, external
+  services, clocks, file systems, queues, and network calls when it improves
+  testability or substitution.
+- Keep interfaces and abstractions narrow. Do not create generic layers that
+  only have one trivial implementation unless they clarify a boundary.
+- Preserve the repository's existing style, naming, module system, and testing
+  approach.

package/.codex/AGENTS.md

@@ -92,6 +92,7 @@ The `pkg-*` directories are reusable CareCard packages. Shared API response, err
 
 - Write or update tests before implementation whenever changing behavior.
 - Testing is mandatory before finalizing code changes. Do not stop after implementation if tests, `.junie`, or `.husky` checks remain unrun.
+- Code coverage must never be lower than the previous commit. When coverage tooling exists, compare against the previous commit or recorded baseline before finalizing, add tests to maintain or improve coverage, and never reduce coverage thresholds to make checks pass.
 - Keep tests readable and domain-specific. Prefer explicit helper names over generic test utilities that hide important behavior.
 - Use existing test frameworks and layouts:
     - JavaScript `api-*`: usually Mocha, Supertest, `test/index.test.js`, and Docker-backed Postgres scripts.

package/.codex/config.toml

@@ -0,0 +1,2 @@
+approval_policy = "never"
+sandbox_mode = "danger-full-access"

package/.github/workflows/ci.yml

@@ -1,7 +1,6 @@
 name: CI
 
 on:
-    workflow_dispatch:
     push:
         branches:
             - main
@@ -21,7 +20,7 @@ on:
         paths-ignore:
             - '**.md'
     pull_request:
-        types: [opened, synchronize, reopened, ready_for_review]
+        types: [closed]
         branches:
             - main
             - develop
@@ -42,6 +41,7 @@ on:
 
 jobs:
     test:
+        if: github.event_name == 'push' || github.event.pull_request.merged == true
         runs-on: ubuntu-latest
 
         steps:

package/index.d.ts

@@ -58,6 +58,24 @@ export function validateWhitelistProperties(
     options?: ValidateWhitelistPropertiesOptions,
 ): Promise<Record<string, any>>;
 
+export const DEFAULT_USER_ROLE_REQUEST_ROLE: 'student';
+export const REQUIRE_SCOPE_WHEN_ROLE_OR_SCOPE_PRESENT: 'whenRoleOrScopePresent';
+
+export interface ValidateNewUserRoleRequestOptions {
+    defaultRole?: 'student' | undefined;
+    requireScope?: boolean | typeof REQUIRE_SCOPE_WHEN_ROLE_OR_SCOPE_PRESENT;
+}
+
+/**
+ * Normalizes and validates a carecard.new_user_role_request payload.
+ * Only student, intern, and volunteer are accepted. When scope is required,
+ * both institution_id and campus_id must be provided.
+ */
+export function validateNewUserRoleRequestObject(
+    roleRequest?: Record<string, any>,
+    options?: ValidateNewUserRoleRequestOptions,
+): Record<string, any>;
+
 /** Checks if the string is a valid image URL format. */
 export function isImageUrl(imageUrl: any): boolean;
 /** Checks if the value is an integer. */
@@ -112,6 +130,8 @@ export function isTextString(str: any): boolean;
 export function isInStringArray(StringArray: string[], inputString: any): boolean;
 /** Checks if the string is one of the supported user role request statuses. */
 export function isUserRoleRequestStatusString(inputString: any): boolean;
+/** Checks if the string is a supported new user role request role. */
+export function isUserRoleRequestRoleString(inputString: any): boolean;
 /** Checks if the string is a valid country code (e.g., +1). */
 export function isCountryCodeString(str: any): boolean;
 /** Checks if the string is a valid domain name. */
@@ -158,6 +178,7 @@ export const validate: {
     isTextString: typeof isTextString;
     isInStringArray: typeof isInStringArray;
     isUserRoleRequestStatusString: typeof isUserRoleRequestStatusString;
+    isUserRoleRequestRoleString: typeof isUserRoleRequestRoleString;
     isCountryCodeString: typeof isCountryCodeString;
     isValidDomainName: typeof isValidDomainName;
     isValidTimestampzString: typeof isValidTimestampzString;

package/index.js

@@ -1,11 +1,13 @@
 const validate = require('./lib/validate');
 const validateProperties = require('./lib/validateProperties');
 const validateWhitelistProperties = require('./lib/validateWhitelistProperties');
+const validateNewUserRoleRequest = require('./lib/validateNewUserRoleRequest');
 
 module.exports = {
     validate,
     validateProperties,
     validateWhitelistProperties,
+    ...validateNewUserRoleRequest,
     ...validate,
     ...validateProperties,
 };

package/lib/validate.js

@@ -173,6 +173,11 @@ const isUserRoleRequestStatusString = inputString => {
     return isInStringArray(statuses, inputString);
 };
 
+const isUserRoleRequestRoleString = inputString => {
+    const roles = ['student', 'intern', 'volunteer'];
+    return typeof inputString === 'string' && roles.includes(inputString.trim().toLowerCase());
+};
+
 const isCountryCodeString = str => {
     if (typeof str !== 'string' || str.length === 0 || str.length > 4) return false;
 
@@ -243,6 +248,7 @@ module.exports = {
     isTextString,
     isInStringArray,
     isUserRoleRequestStatusString,
+    isUserRoleRequestRoleString,
     isCountryCodeString,
     isValidDomainName,
     isValidTimestampzString,