@carecard/validate 3.13.0 → 3.14.0

package/.agents/skills/carecard-workspace-standards/SKILL.md

@@ -7,6 +7,10 @@ Non-negotiable root-cause solution rule: Always identify and solve the verified
 
 # CareCard Workspace Standards
 
+Mandatory companion: load
+`$pkg-validate-coding-standards-and-best-practices` before this skill for every
+task in this repository.
+
 Non-negotiable test order invariance rule: Every test must pass independently of which tests run before or after it, and the suite must pass in every execution order. Each test must establish the state it needs, isolate mutable state, and clean up state it owns; it must never rely on another test's setup, mutations, or cleanup. Default test, CI, and Husky commands must use the test framework's ordinary ordering and must not force randomized ordering. Random-order execution is an explicit diagnostic only, and every failure it exposes must be fixed at the root cause.
 
 Non-negotiable parallel test execution rule: Run independent test files in parallel with repository-native worker support wherever resource isolation makes parallel execution safe. Tests that share a mutable database, application server, browser state, filesystem fixture, port, or cluster resource must remain in an explicitly isolated serial group until every worker owns a separate resource. Parallel execution must preserve ordinary test selection and must never use randomized ordering, retries, locks, or error suppression to conceal coupling.
@@ -406,7 +410,7 @@ the authenticated dashboard.
 - `ms-auth` follows the shared PostgreSQL/RLS pattern: auth tables live in the `carecard` schema, RLS is enabled and forced on every auth table, and application runtime queries use the unprivileged database role.
 - Auth table policies allow normal JWT users to access only self-owned rows. Do not add redundant `user_id = <jwt sub>` SQL predicates to duplicate self-row checks when RLS owns the authorization decision.
 - A JWT payload containing `roles: ["ad"]` is the auth-service super-admin signal and can perform any action on auth tables. Dashboard code may map that role to `super_admin`, but backend auth RLS must not require a separate database role row for that bypass.
-- Public auth flows such as registration, login, confirmation, recovery, visitor creation, and service user lookup must use narrow system contexts (`system_create`, `system_login`, `system_confirm`, `system_recovery`, `system_visitor`, `system_service`) instead of privileged runtime queries.
+- Public auth flows such as registration, login, recovery, visitor creation, and service user lookup must use narrow system contexts (`system_create`, `system_login`, `system_recovery`, `system_visitor`, `system_service`) instead of privileged runtime queries.
 
 - `ms-auth` controller exports use concise action names such as `loginUser`,
   `registerUser`, `getUserDetail`, and `renewJwt`; route middleware and router
@@ -416,7 +420,7 @@ the authenticated dashboard.
 
 ## Security Requirements
 
-- Treat authentication, authorization, JWT, password, email confirmation,
+- Treat authentication, authorization, JWT, password, email verification,
   recovery, file upload, CORS, rate limits, and error response behavior as
   security-sensitive.
 - Never log or return secrets, tokens, passwords, credentials, private keys,

package/.agents/skills/pkg-validate-coding-standards-and-best-practices/SKILL.md

@@ -0,0 +1,165 @@
+---
+name: pkg-validate-coding-standards-and-best-practices
+description: 'Mandatory for every pkg-validate task, including analysis, clarification, planning, implementation, review, debugging, documentation, public API work, skill maintenance, and validation. Use before every narrower skill.'
+---
+
+# Pkg Validate Coding Standards And Best Practices
+
+Non-negotiable root-cause solution rule: Always identify and solve the verified
+root cause, use the stronger solution, and deliver a correct, durable,
+production-quality result. Never treat a temporary workaround, resource
+increase, retry, suppression, bypass, or symptom-only patch as completion.
+Validate the root-cause fix against the real failing workflow and prove the end
+state.
+
+Non-negotiable error and warning rule: Never suppress, silence, hide, downgrade,
+filter, ignore, skip, or bypass errors or warnings from code, tests, tools,
+compilers, linters, or validation. Fix the root cause, then rerun the affected
+check and require a clean result. Expected error-path tests may assert errors,
+but must not conceal unexpected failures.
+
+Non-negotiable repository isolation rule: Every repository must run its Husky
+hooks and tests using only files, code, fixtures, dependencies, and services
+contained within that repository. Tests and Husky scripts must not import,
+require, read, execute, or otherwise depend on sibling repositories or paths
+outside the repository root. app-e2e-tests is the only exception because
+cross-repository end-to-end testing is its explicit responsibility.
+
+## Mandatory Use And Authorities
+
+Load this skill before doing any work in `pkg-validate`, including read-only
+and documentation-only work. Then load every narrower skill that owns the
+affected package contract.
+
+Use these existing authorities instead of duplicating them:
+
+- `$carecard-workspace-standards` for TDD, root-cause solutions, dependencies,
+  errors, isolation, and repository workflow;
+- `$software-design-patterns-and-clean-code` for design, DRY, KISS,
+  testability, and clean-code details;
+- `$pkg-validate-validation-library` for validators, sanitization, whitelist
+  behavior, exports, types, coverage, and validation; and
+- `$pkg-publish` only when runtime package artifacts or consumer versions must
+  be published and propagated.
+
+This skill adds the function-evolution, direct-contract, composition, and
+completion rules below without weakening those companion skills.
+
+## Requirement Judgment
+
+1. Read the complete request and inspect implementation, public exports,
+   declarations, validation call sites, tests, documentation, and consumers
+   before deciding how to change the package.
+2. Translate the request into a coherent technical contract. Do not apply
+   wording mechanically when it is contradictory, unsafe, impossible, or
+   incompatible with validation or package architecture.
+3. Make low-risk, reversible assumptions only when they preserve requested
+   behavior and scope.
+4. Ask for clarification when an unresolved choice would materially change a
+   public API, accepted or rejected input, error behavior, security, consumer
+   behavior, destructive scope, or the repositories that must change.
+5. Explain architectural tradeoffs before a major API, validator, sanitizer,
+   type, module, package, or dependency change.
+
+## Scope And Quality
+
+- Treat every workspace repository as independent and validate it from its own
+  root.
+- Update every skill, document, source, runtime test, type test, export,
+  declaration, consumer, and package version genuinely required for a coherent
+  task.
+- Do not broaden the task into unrelated cleanup.
+- Preserve CommonJS, predicate, sanitization, whitelist, declaration, naming,
+  and test conventions unless the task explicitly replaces them.
+- Prefer Node core and existing helpers over new dependencies.
+- Prefer readable deterministic implementation over clever compression or a
+  temporary workaround.
+- Use meaningful names that describe validation and sanitization intent.
+
+## Function Evolution
+
+Before changing a function's behavior or signature, inventory every direct,
+indirect, test, exported, validator-map, callback, configuration-driven, and
+dynamic consumer.
+
+- If exactly one consumer is proven, change the function only when required.
+- If two or more consumers exist, do not change the shared function's behavior.
+  Create a new purpose-named function and migrate only intended consumers.
+- If every consumer needs the new contract, migrate all consumers and delete
+  the old function after proving it unused.
+- Treat every exported, declared, public, registered, callback, or dynamically
+  discovered function as shared unless single use is conclusively proven.
+- Do not add caller branches, mode flags, or optional parameters merely to
+  make one shared function serve incompatible contracts.
+- Cover the new function, public surface, types, and every migrated consumer
+  through TDD.
+
+## Direct Contract Without Backward Compatibility
+
+When the active task replaces a contract, implement the requested end state
+directly. Do not add legacy aliases, deprecated wrappers, compatibility
+overloads, duplicate exports, dual validation paths, transitional names, or
+fallback behavior solely to preserve the superseded contract.
+
+Delete obsolete functions and exports after all intended consumers have
+migrated and repository-native search, runtime tests, type tests, and coverage
+prove them unused. This does not authorize unrelated API removal. If an
+existing published or security contract requires compatibility and the request
+does not clearly supersede it, explain the conflict and ask first.
+
+## TDD And Root-Cause Gate
+
+Follow `$carecard-workspace-standards` and
+`$pkg-validate-validation-library` for the complete failing-test-first,
+root-cause, and 100-percent-coverage workflow. Documentation and skill changes
+require a focused structural validation before prose changes. Do not accept
+retries, suppressed diagnostics, weakened types, reduced coverage, disabled
+tests, forced success, compatibility patches, or symptom-only workarounds as
+completion.
+
+## Function Size
+
+Every new or materially changed function must contain at most 25 logical code
+lines.
+
+- Count executable statements, branches, loop headers, side-effecting calls,
+  returns, and throws.
+- Exclude signatures, type-only declarations, blank lines, comments, and
+  isolated braces.
+- Extract cohesive purpose-named helpers and compose them when needed.
+- Keep parsing, predicate evaluation, sanitization, transformation, and error
+  mapping responsibilities explicit rather than hiding them in one long
+  function.
+- Avoid meaningless forwarding wrappers and do not refactor untouched
+  functions solely to satisfy this limit.
+
+## UI Composition
+
+This package does not own UI. If a package contract requires UI changes, make
+them in the owning app repository. There, create focused components, compose
+existing and new components, and delete obsolete components only after proving
+them unused and replaced.
+
+## Skills, Documentation, And Database Boundaries
+
+- Update affected skills, README guidance, examples, exports, and declarations
+  with behavior or validation changes.
+- Reference existing authoritative skills instead of copying their details.
+- If work reaches an `ms-*` database, change SQL only in the owning repository
+  using its database-migration-ownership skill. For first-create work, edit the
+  existing migration and matching rollback directly rather than adding a
+  compatibility migration.
+- Keep persistence and service behavior in their owning repositories.
+
+## Completion
+
+1. Review each changed repository's diff and status independently.
+2. Run focused runtime, type, and coverage tests, then all broader checks
+   required by local skills.
+3. If every changed file in a repository is Markdown (`*.md`), skip Husky and
+   run only focused Markdown validation.
+4. If any changed file is not Markdown, run every direct `.husky` script. If
+   none exists, run the strongest repository-native focused validation.
+5. Fix every in-scope failure at its root cause and rerun the exact command.
+6. Report exact commands, results, limitations, and remaining risk.
+7. Do not perform remote Git or GitHub operations unless explicitly requested.

package/.agents/skills/pkg-validate-coding-standards-and-best-practices/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+    display_name: 'Pkg Validate Coding Standards'
+    short_description: 'Apply mandatory validation package standards'
+    default_prompt: 'Use $pkg-validate-coding-standards-and-best-practices before every pkg-validate task and apply all narrower skills that the task requires.'

package/.codex/AGENTS.md

@@ -1,5 +1,13 @@
 # Codex Instructions For pkg-validate
 
+## Non-negotiable Codex banked-reset requirement
+
+- Never use or consume a banked Codex rate-limit reset automatically.
+- Before using any banked Codex rate-limit reset, stop, ask the user for explicit, direct approval for that specific reset, and wait for their reply.
+- Never treat earlier approval, a standing instruction, silence, urgency, an unfinished task, or a request to continue as approval for a future reset.
+- Do not invoke `/usage` redemption, a reset-consumption action, a reset API or tool, or any equivalent mechanism unless the user explicitly approved that specific reset.
+- If a Codex limit is reached without that approval, pause and let the user reset it manually. Never consume a banked reset to keep working.
+
 Non-negotiable test order invariance rule: Every test must pass independently of which tests run before or after it, and the suite must pass in every execution order. Each test must establish the state it needs, isolate mutable state, and clean up state it owns; it must never rely on another test's setup, mutations, or cleanup. Default test, CI, and Husky commands must use the test framework's ordinary ordering and must not force randomized ordering. Random-order execution is an explicit diagnostic only, and every failure it exposes must be fixed at the root cause.
 
 Non-negotiable code organization rule: Functions with the same or equivalent behavior must use the same or clearly corresponding descriptive names across CareCard repositories, and equivalent functionality must live in files with the same names within each repository's established architecture. No backward compatibility names, aliases, or duplicate locations are allowed.
@@ -147,7 +155,7 @@ The `pkg-*` directories are reusable CareCard packages. Shared API response, err
 
 ### Security Requirements
 
-- Treat authentication, authorization, JWT, password, email confirmation, recovery, file upload, CORS, rate limits, and error response behavior as security-sensitive.
+- Treat authentication, authorization, JWT, password, email verification, recovery, file upload, CORS, rate limits, and error response behavior as security-sensitive.
 - Never log or return secrets, tokens, passwords, credentials, private keys, full JWT payloads, or sensitive personal data.
 - Use safe error messages for users and structured details only when they do not reveal sensitive implementation or data.
 - Keep body-size limits, Helmet, CORS allow-lists, and rate-limit behavior intact unless a task explicitly changes them.

package/AGENTS.md

@@ -0,0 +1,15 @@
+# Codex Instructions
+
+## Non-negotiable Codex banked-reset requirement
+
+- Never use or consume a banked Codex rate-limit reset automatically.
+- Before using any banked Codex rate-limit reset, stop, ask the user for explicit, direct approval for that specific reset, and wait for their reply.
+- Never treat earlier approval, a standing instruction, silence, urgency, an unfinished task, or a request to continue as approval for a future reset.
+- Do not invoke `/usage` redemption, a reset-consumption action, a reset API or tool, or any equivalent mechanism unless the user explicitly approved that specific reset.
+- If a Codex limit is reached without that approval, pause and let the user reset it manually. Never consume a banked reset to keep working.
+
+## Repository validation contracts
+
+Non-negotiable repository isolation rule: Every repository must run its Husky hooks and tests using only files, code, fixtures, dependencies, and services contained within that repository. Tests and Husky scripts must not import, require, read, execute, or otherwise depend on sibling repositories or paths outside the repository root. app-e2e-tests is the only exception because cross-repository end-to-end testing is its explicit responsibility.
+
+Non-negotiable code organization rule: Functions with the same or equivalent behavior must use the same or clearly corresponding descriptive names across CareCard repositories, and equivalent functionality must live in files with the same names within each repository's established architecture. No backward compatibility names, aliases, or duplicate locations are allowed.

package/lib/validateProperties.js

@@ -138,8 +138,8 @@ function validateProperties(obj = {}) {
                 }
                 break;
             case 'token':
-            case 'email_confirm_token':
-            case 'emailConfirmToken':
+            case 'email_verification_token':
+            case 'emailVerificationToken':
             case 'verification_token':
             case 'verificationToken':
                 if (isUrlSafeString(value)) {

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@carecard/validate",
-    "version": "3.13.0",
+    "version": "3.14.0",
     "repository": {
         "type": "git",
         "url": "git+https://github.com/CareCard-ca/pkg-validate.git"
@@ -39,7 +39,7 @@
         "typescript": "6.0.3"
     },
     "dependencies": {
-        "@carecard/common-util": "3.13.0"
+        "@carecard/common-util": "3.14.0"
     },
     "nyc": {
         "all": true,

package/readme.md

@@ -124,7 +124,7 @@ where the package supports both.
 | `isEmailString`                                           | `email`                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   |
 | `isPhoneNumber`                                           | `phone_number`, `phoneNumber`                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             |
 | `isCountryCodeString`                                     | `country_code`, `countryCode`                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             |
-| `isUrlSafeString`                                         | `token`, `email_confirm_token`, `emailConfirmToken`, `verification_token`, `verificationToken`                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            |
+| `isUrlSafeString`                                         | `token`, `email_verification_token`, `emailVerificationToken`, `verification_token`, `verificationToken`                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  |
 | `isValidUuidString`                                       | `uuid`, `item_id`, `itemId`, `user_id`, `userId`, `address_id`, `addressId`, `order_id`, `orderId`, `category_id`, `categoryId`, `parent_id`, `parentId`, `college_id`, `collegeId`, `campus_id`, `campusId`, `program_id`, `programId`, `program_term_id`, `programTermId`, `template_id`, `templateId`, `program_template_id`, `programTemplateId`, `user_item_id`, `userItemId`, `user_item_status_id`, `userItemStatusId`, `requirement_item_id`, `requirementItemId`, `program_document_id`, `programDocumentId`, `id`, `institution_id`, `institutionId`, `role_assignment_id`, `roleAssignmentId`, `user_role_id`, `userRoleId`, `phone_number_id`, `phoneNumberId`, `entity_id`, `entityId`, `changed_by`, `changedBy`, `request_id`, `requestId` |
 | `isCcIdString`                                            | `cc_id`, `ccId`                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           |
 | `isValidIntegerString`                                    | `offset_number`, `offsetNumber`, `number_of_orders`, `numberOfOrders`, `price`, `from`, `number`, `limit`, `offset`                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       |