@carecard/auth-util 3.18.0 → 3.20.0

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

@@ -15,10 +15,13 @@ Non-negotiable test order invariance rule: Every test must pass independently of
 
 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.
 
-Non-negotiable TDD rule: Always write the failing test first, run it to confirm it fails for the intended reason, then implement the code and rerun the test until it passes. Test Driven Development is required for all coding work and must not be skipped. For documentation- or skill-only edits, add or update the relevant validation check before changing the prose.
+Non-negotiable TDD rule: Always write the failing test first, run it to confirm it fails for the intended reason, then implement the code and rerun the test until it passes. Test Driven Development is required for all coding work and must not be skipped. For documentation- or skill-only edits, run the relevant focused non-test
+validation before changing the prose; do not add automated tests that inspect
+prose, files, or repository structure.
 
-This requirement is non-negotiable and may be overridden only with the user's
-explicit, direct approval.
+The TDD and validation requirements are non-negotiable and cannot be
+overridden. The separate pre-existing-test protection still requires the
+user's fresh, explicit permission for each exact proposed test modification.
 
 A pre-existing test—defined as any test present before work on the current task
 begins—must not be deleted, disabled, skipped, weakened, excluded from execution,
@@ -30,6 +33,11 @@ precise proposed modification, provide detailed technical justification, and
 explain all known or reasonably foreseeable regression risks. Until approval is
 granted, leave every pre-existing test unchanged.
 
+An implementation-detail test remains invalid under the authoritative TDD and
+validation policy. Identify the exact test and obtain the user's explicit
+approval before rewriting or removing it. Until approval is granted, leave the
+test unchanged and report the blocked correction.
+
 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 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.
@@ -70,8 +78,10 @@ Use before modifying, testing, reviewing, or debugging any CareCard workspace re
 
 ## Testing Expectations
 
-- Write or update package tests before behavior or public API changes.
-- Include type/export compatibility tests where the package already has them.
+- Write a new failing consumer-facing test through the supported package root
+  before behavior or public API changes. Modify a pre-existing test only after
+  the user grants fresh, explicit permission for that exact change.
+- Include consumer-facing runtime and compilation tests through the supported package root. Exercise public behavior and realistic type usage without inspecting export objects, source files, or module layout.
 - Run package test, lint, type, and Husky validation commands required by the changed area.
 
 ## Safety Constraints
@@ -106,9 +116,10 @@ config.
 - Follow the owner's coding style, naming conventions, and project structure.
 - Put code, tests, docs, services, validation, transforms, components, and
   helpers where the current repository expects them.
-- Use Test-Driven Development for behavior changes: write or update focused
-  tests first, verify they fail for the missing behavior when practical, then
-  implement.
+- Use Test-Driven Development for behavior changes: write a focused
+  functional test first or, after fresh permission for the exact change,
+  update a pre-existing test. Run the selected test, confirm it fails for the
+  missing behavior, then implement.
 - Never suppress errors, TypeScript errors, linter warnings, authorization
   failures, RLS failures, build failures, hydration issues, or failing tests.
   Do not add `eslint-disable`, `@ts-ignore`, broad catches, empty catches, or
@@ -309,10 +320,11 @@ existing TypeScript style.
 ## Tests
 
 - Testing is mandatory before finalizing code changes.
-- Code coverage percentage must not decrease from the previous commit; it can
-  stay the same or increase. When coverage tooling exists, compare against the
-  previous commit or recorded baseline, add tests to maintain or improve
-  coverage, and never reduce coverage thresholds to pass checks.
+- Use coverage reports only as diagnostics for potentially untested observable
+  behavior. Percentages for lines, branches, functions, and statements are not
+  functional evidence and must not determine test assertions. Never add
+  implementation-detail tests to preserve a metric or lower thresholds to hide
+  a failing check; report any conflict with the behavior-only policy.
 - Keep tests readable and domain-specific.
 - Tests must cover desired or happy paths and prevention or rejection of
   undesired behavior.
@@ -324,14 +336,14 @@ existing TypeScript style.
   Selenium for end-to-end flows.
 - For database tests, use existing seed, migration, rollback, and cleanup
   patterns.
-- In database `rls_logic.test.js` files, assert RLS logic only by calling
-  `carecard.can_access_row(...)` and checking the intended boolean. Put table
-  CRUD and lower RLS helper checks in query/enforcement tests.
+- Test row-level security through app-equivalent SQL operations under the
+  intended caller context. Assert returned rows, successful writes, and
+  authorization denials without calling internal RLS helpers or inspecting SQL
+  text.
 - Add tests for API success responses, validation errors, auth/authz errors,
   JWT errors, not-found/conflict cases, and unexpected error handling when
   those paths change.
-- For frontend changes, test validation, transforms, query/mutation wrappers,
-  components, and user-visible flows at the narrowest practical level first.
+- For frontend changes, test rendered UI, public HTTP or network outcomes, navigation, accessibility, and user-visible flows at the narrowest practical level first. Use focused non-test dependency checks for validation, transform, query, mutation, hook, and module organization.
 - If a test or repository check fails, fix the issue and rerun the failing
   command. Only finalize with failing checks when the failure is unrelated or
   blocked by environment constraints, and document that explicitly.
@@ -370,9 +382,7 @@ Dashboard service and test conventions:
 - Profile, settings, notifications, institutions, and user authorization UI
   prefer service snackbar helpers for user-friendly fallback errors, technical
   error filtering, mutation result handling, and duplicate error suppression.
-- `tests/app/dashboard/profile/page.test.tsx` keeps dynamic profile children
-  inert in the shell-level page test to avoid async imports resolving after
-  Vitest tears down jsdom in CI.
+- Profile page tests assert visible loading, navigation, form, and error behavior through the rendered route. They must not depend on dynamic-import structure or a specific mocking strategy.
 
 ## Public Website Frontends
 
@@ -432,3 +442,22 @@ the authenticated dashboard.
   intact unless a task explicitly changes them.
 - Document remaining security concerns that require product, infrastructure, or
   deployment decisions.
+
+## TDD And Validation
+
+Test Driven Development is a non-negotiable requirement.
+
+The sole purpose of automated tests is to verify observable functionality and externally visible behavior.
+Tests must validate what the system does through its public interfaces and expected outcomes.
+
+Tests must not assert, inspect, or depend on implementation details, including but not limited to:
+
+- The existence of specific lines of code, statements, functions, classes, files, or modules.
+- Specific algorithms, control flow, variable names, method calls, code snippets, or internal implementation choices.
+- Any internal structure that can change without changing externally observable behavior.
+
+A correct implementation may be completely rewritten or refactored without requiring changes to functional tests, provided its externally observable behavior remains unchanged.
+
+Any test that fails solely because the implementation changed while the externally observable behavior remained correct is incorrectly designed and must be rewritten or removed.
+
+This requirement is mandatory for all new tests and must be applied whenever existing tests are modified.

package/.agents/skills/github-pr-create-update/SKILL.md

@@ -7,7 +7,9 @@ Non-negotiable root-cause solution rule: Always identify and solve the verified
 
 # Pull Request Create
 
-Non-negotiable TDD rule: Always write the failing test first, run it to confirm it fails for the intended reason, then implement the code and rerun the test until it passes. Test Driven Development is required for all coding work and must not be skipped. For documentation- or skill-only edits, add or update the relevant validation check before changing the prose.
+Non-negotiable TDD rule: Always write the failing test first, run it to confirm it fails for the intended reason, then implement the code and rerun the test until it passes. Test Driven Development is required for all coding work and must not be skipped. For documentation- or skill-only edits, run the relevant focused non-test
+validation before changing the prose; do not add automated tests that inspect
+prose, files, or repository structure.
 
 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.
 
@@ -181,3 +183,22 @@ Do not continue automatically when:
 10. Final response should include the PR URL, selected base branch, whether a
     rebase was performed, whether an existing PR was reused or marked ready,
     and any validation that could not be run.
+
+## TDD And Validation
+
+Test Driven Development is a non-negotiable requirement.
+
+The sole purpose of automated tests is to verify observable functionality and externally visible behavior.
+Tests must validate what the system does through its public interfaces and expected outcomes.
+
+Tests must not assert, inspect, or depend on implementation details, including but not limited to:
+
+- The existence of specific lines of code, statements, functions, classes, files, or modules.
+- Specific algorithms, control flow, variable names, method calls, code snippets, or internal implementation choices.
+- Any internal structure that can change without changing externally observable behavior.
+
+A correct implementation may be completely rewritten or refactored without requiring changes to functional tests, provided its externally observable behavior remains unchanged.
+
+Any test that fails solely because the implementation changed while the externally observable behavior remained correct is incorrectly designed and must be rewritten or removed.
+
+This requirement is mandatory for all new tests and must be applied whenever existing tests are modified.

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

@@ -7,7 +7,9 @@ Non-negotiable root-cause solution rule: Always identify and solve the verified
 
 # Pull Request Merge Close
 
-Non-negotiable TDD rule: Always write the failing test first, run it to confirm it fails for the intended reason, then implement the code and rerun the test until it passes. Test Driven Development is required for all coding work and must not be skipped. For documentation- or skill-only edits, add or update the relevant validation check before changing the prose.
+Non-negotiable TDD rule: Always write the failing test first, run it to confirm it fails for the intended reason, then implement the code and rerun the test until it passes. Test Driven Development is required for all coding work and must not be skipped. For documentation- or skill-only edits, run the relevant focused non-test
+validation before changing the prose; do not add automated tests that inspect
+prose, files, or repository structure.
 
 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.
 
@@ -233,3 +235,22 @@ completion.
     cleanup commit was added, whether the remote target branch was deleted or
     protected, whether the local target branch was deleted, and whether local
     base branch is up to date.
+
+## TDD And Validation
+
+Test Driven Development is a non-negotiable requirement.
+
+The sole purpose of automated tests is to verify observable functionality and externally visible behavior.
+Tests must validate what the system does through its public interfaces and expected outcomes.
+
+Tests must not assert, inspect, or depend on implementation details, including but not limited to:
+
+- The existence of specific lines of code, statements, functions, classes, files, or modules.
+- Specific algorithms, control flow, variable names, method calls, code snippets, or internal implementation choices.
+- Any internal structure that can change without changing externally observable behavior.
+
+A correct implementation may be completely rewritten or refactored without requiring changes to functional tests, provided its externally observable behavior remains unchanged.
+
+Any test that fails solely because the implementation changed while the externally observable behavior remained correct is incorrectly designed and must be rewritten or removed.
+
+This requirement is mandatory for all new tests and must be applied whenever existing tests are modified.

package/.agents/skills/pkg-auth-util-auth-crypto-library/SKILL.md

@@ -7,7 +7,9 @@ Non-negotiable root-cause solution rule: Always identify and solve the verified
 
 # Package Auth Util
 
-Non-negotiable TDD rule: Always write the failing test first, run it to confirm it fails for the intended reason, then implement the code and rerun the test until it passes. Test Driven Development is required for all coding work and must not be skipped. For documentation- or skill-only edits, add or update the relevant validation check before changing the prose.
+Non-negotiable TDD rule: Always write the failing test first, run it to confirm it fails for the intended reason, then implement the code and rerun the test until it passes. Test Driven Development is required for all coding work and must not be skipped. For documentation- or skill-only edits, run the relevant focused non-test
+validation before changing the prose; do not add automated tests that inspect
+prose, files, or repository structure.
 
 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.
 
@@ -49,8 +51,10 @@ CareCard auth utility package for JWT creation/verification primitives, password
 
 ## Testing Expectations
 
-- Write or update package tests before behavior or public API changes.
-- Include type/export compatibility tests where the package already has them.
+- Write a new failing consumer-facing test through the supported package root
+  before behavior or public API changes. Modify a pre-existing test only after
+  the user grants fresh, explicit permission for that exact change.
+- Include consumer-facing runtime and compilation tests through the supported package root. Exercise public behavior and realistic type usage without inspecting export objects, source files, or module layout.
 - Run package test, lint, type, and Husky validation commands required by the changed area.
 
 ## Safety Constraints
@@ -82,8 +86,10 @@ depend on those folders being present.
   - Internal helpers use the established underscore prefix.
 - Keep public exports in `index.js`, declarations in `index.d.ts`,
   implementation modules in `lib`, and tests in `test`.
-- Use Test-Driven Development. Add or update Mocha and type tests before
-  changing behavior or exported API.
+- Use Test-Driven Development. Add a new failing consumer-facing Mocha or type
+  test through the supported package root before changing behavior or exported
+  API. Modify a pre-existing test only after the user grants fresh, explicit
+  permission for that exact change.
 - Never suppress errors, type errors, linter warnings, crypto failures, or
   failing tests. Fix the cause.
 - Do not add dependencies unless absolutely required. Ask for confirmation first
@@ -168,20 +174,20 @@ depend on those folders being present.
 - Keep `index.d.ts` in sync with every public export in `index.js`.
 - Avoid new loose index signatures. If payloads need custom claims, type them as
   `Record<string, unknown>` or a named claim interface.
-- Keep deprecated APIs marked as deprecated and prefer direct export examples in
-  docs and tests.
-- Update type tests whenever public exports, overloads, return values, payload
-  shapes, or declaration behavior changes.
+- Keep deprecated APIs marked as deprecated and prefer direct public-package
+  usage examples in documentation.
+- When public types, overloads, return values, payload shapes, or declaration
+  behavior change, compile realistic consumer usage through the supported
+  package root. Do not assert that a named export or declaration node exists.
 
 ## Tests
 
 - Use Mocha for runtime tests under `test`.
-- Every implementation module in `lib` should have matching tests under `test`.
-  For example, `lib/jwtUtilAuth.js` should be covered by
-  `test/jwtUtilAuth.test.js`.
-- `test/index.test.js` should cover scenarios through the public exports from
-  `index.js`.
-- `test/types.test.ts` verifies TypeScript declarations with `tsc`.
+- Exercise runtime scenarios only through the supported package root. Tests
+  must not mirror `lib` modules, depend on internal file layout, or inspect
+  named exports for existence.
+- Compile realistic consumer code through the package root with `tsc` to
+  verify externally visible declaration behavior.
 - Cover success and failure cases for JWT parsing, signature verification,
   password hashing, saved-hash verification, key generation, base64 conversion,
   URL-safe conversion, and string parsing.
@@ -267,3 +273,22 @@ immediately when no helper remains, allow only a bounded 250 ms settlement
 window for already-stopping helpers, fail persistent descendants, preserve
 failures and output, use exit code `124` only for a real outer deadline, and
 remain a final guard rather than a substitute for explicit cleanup.
+
+## TDD And Validation
+
+Test Driven Development is a non-negotiable requirement.
+
+The sole purpose of automated tests is to verify observable functionality and externally visible behavior.
+Tests must validate what the system does through its public interfaces and expected outcomes.
+
+Tests must not assert, inspect, or depend on implementation details, including but not limited to:
+
+- The existence of specific lines of code, statements, functions, classes, files, or modules.
+- Specific algorithms, control flow, variable names, method calls, code snippets, or internal implementation choices.
+- Any internal structure that can change without changing externally observable behavior.
+
+A correct implementation may be completely rewritten or refactored without requiring changes to functional tests, provided its externally observable behavior remains unchanged.
+
+Any test that fails solely because the implementation changed while the externally observable behavior remained correct is incorrectly designed and must be rewritten or removed.
+
+This requirement is mandatory for all new tests and must be applied whenever existing tests are modified.

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

@@ -5,6 +5,19 @@ description: 'Mandatory for every pkg-auth-util task, including analysis, clarif
 
 # Pkg Auth Util Coding Standards And Best Practices
 
+## JavaScript And TypeScript Style Contract
+
+- Require braces around every optional control-flow body through ESLint core
+  `curly: ['error', 'all']`. Single-expression arrow functions may remain
+  expression-bodied.
+- Require semicolons on every applicable statement through Prettier's
+  `semi: true` option. Do not add a second semicolon linter.
+- Keep the shared Prettier baseline and lint-staged command order consistent
+  across CareCard repositories: run ESLint fixes before Prettier writes.
+- Use `lint`, `lint:fix`, `format`, `format:check`, and `lint-staged` as the
+  direct script names. Whole-repository lint and formatting checks must fail on
+  warnings or style drift.
+
 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
@@ -65,9 +78,11 @@ completion rules below without weakening those companion skills.
 
 - 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.
+- Update every skill, document, source, export, declaration, consumer, and
+  package version genuinely required for a coherent task, and add every new
+  consumer-facing runtime or type test the behavior requires. Modify a
+  pre-existing test only after the user grants fresh, explicit permission for
+  that exact change.
 - Do not broaden the task into unrelated cleanup.
 - Preserve CommonJS structure, established public surfaces, naming, and test
   conventions unless the task explicitly replaces them.
@@ -101,8 +116,8 @@ overloads, duplicate exports, dual 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, and type tests prove them
-unused. This does not authorize unrelated API removal. If an existing
+migrated and repository-native search proves them unused, while runtime and type tests
+verify the remaining public contract. 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 before changing it.
 
@@ -110,8 +125,9 @@ clearly supersede it, explain the conflict and ask before changing it.
 
 Follow `$carecard-workspace-standards` and
 `$pkg-auth-util-auth-crypto-library` for the complete failing-test-first and
-root-cause workflow. Documentation and skill changes require a focused
-structural validation before prose changes. Do not accept retries, suppressed
+root-cause workflow. Documentation and skill changes require focused non-test validation before
+prose changes; do not add automated tests that inspect prose, files, or
+repository structure. Do not accept retries, suppressed
 diagnostics, weakened types, disabled tests, forced success, compatibility
 patches, or symptom-only workarounds as completion.
 
@@ -160,3 +176,22 @@ them unused and replaced.
 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.
+
+## TDD And Validation
+
+Test Driven Development is a non-negotiable requirement.
+
+The sole purpose of automated tests is to verify observable functionality and externally visible behavior.
+Tests must validate what the system does through its public interfaces and expected outcomes.
+
+Tests must not assert, inspect, or depend on implementation details, including but not limited to:
+
+- The existence of specific lines of code, statements, functions, classes, files, or modules.
+- Specific algorithms, control flow, variable names, method calls, code snippets, or internal implementation choices.
+- Any internal structure that can change without changing externally observable behavior.
+
+A correct implementation may be completely rewritten or refactored without requiring changes to functional tests, provided its externally observable behavior remains unchanged.
+
+Any test that fails solely because the implementation changed while the externally observable behavior remained correct is incorrectly designed and must be rewritten or removed.
+
+This requirement is mandatory for all new tests and must be applied whenever existing tests are modified.

package/.agents/skills/pkg-publish/SKILL.md

@@ -9,7 +9,9 @@ Non-negotiable root-cause solution rule: Always identify and solve the verified
 
 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 TDD rule: Always write the failing test first, run it to confirm it fails for the intended reason, then implement the code and rerun the test until it passes. Test Driven Development is required for all coding work and must not be skipped. For documentation- or skill-only edits, add or update the relevant validation check before changing the prose.
+Non-negotiable TDD rule: Always write the failing test first, run it to confirm it fails for the intended reason, then implement the code and rerun the test until it passes. Test Driven Development is required for all coding work and must not be skipped. For documentation- or skill-only edits, run the relevant focused non-test
+validation before changing the prose; do not add automated tests that inspect
+prose, files, or repository structure.
 
 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.
 
@@ -123,3 +125,22 @@ For each changed repository:
 Finish by verifying that all five packages are published at the same target
 version and every declared `@carecard/*` dependency in `pkg-*`, `ms-*`, and
 `app-dashboard` is pinned to that version.
+
+## TDD And Validation
+
+Test Driven Development is a non-negotiable requirement.
+
+The sole purpose of automated tests is to verify observable functionality and externally visible behavior.
+Tests must validate what the system does through its public interfaces and expected outcomes.
+
+Tests must not assert, inspect, or depend on implementation details, including but not limited to:
+
+- The existence of specific lines of code, statements, functions, classes, files, or modules.
+- Specific algorithms, control flow, variable names, method calls, code snippets, or internal implementation choices.
+- Any internal structure that can change without changing externally observable behavior.
+
+A correct implementation may be completely rewritten or refactored without requiring changes to functional tests, provided its externally observable behavior remains unchanged.
+
+Any test that fails solely because the implementation changed while the externally observable behavior remained correct is incorrectly designed and must be rewritten or removed.
+
+This requirement is mandatory for all new tests and must be applied whenever existing tests are modified.

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

@@ -7,7 +7,9 @@ Non-negotiable root-cause solution rule: Always identify and solve the verified
 
 # Software Design Patterns And Clean Code
 
-Non-negotiable TDD rule: Always write the failing test first, run it to confirm it fails for the intended reason, then implement the code and rerun the test until it passes. Test Driven Development is required for all coding work and must not be skipped. For documentation- or skill-only edits, add or update the relevant validation check before changing the prose.
+Non-negotiable TDD rule: Always write the failing test first, run it to confirm it fails for the intended reason, then implement the code and rerun the test until it passes. Test Driven Development is required for all coding work and must not be skipped. For documentation- or skill-only edits, run the relevant focused non-test
+validation before changing the prose; do not add automated tests that inspect
+prose, files, or repository structure.
 
 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.
 
@@ -41,8 +43,7 @@ validation commands, and API contracts.
 - 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.
+- Design code so behavior can be tested through focused public interfaces, integration boundaries, and observable outcomes without fragile setup or internal-module assertions.
 - Avoid unnecessary dependencies. Use existing language, framework, and local
   helper capabilities before adding packages.
 
@@ -83,3 +84,22 @@ async function loadProfile(...) { ... }
   only have one trivial implementation unless they clarify a boundary.
 - Preserve the repository's existing style, naming, module system, and testing
   approach.
+
+## TDD And Validation
+
+Test Driven Development is a non-negotiable requirement.
+
+The sole purpose of automated tests is to verify observable functionality and externally visible behavior.
+Tests must validate what the system does through its public interfaces and expected outcomes.
+
+Tests must not assert, inspect, or depend on implementation details, including but not limited to:
+
+- The existence of specific lines of code, statements, functions, classes, files, or modules.
+- Specific algorithms, control flow, variable names, method calls, code snippets, or internal implementation choices.
+- Any internal structure that can change without changing externally observable behavior.
+
+A correct implementation may be completely rewritten or refactored without requiring changes to functional tests, provided its externally observable behavior remains unchanged.
+
+Any test that fails solely because the implementation changed while the externally observable behavior remained correct is incorrectly designed and must be rewritten or removed.
+
+This requirement is mandatory for all new tests and must be applied whenever existing tests are modified.

package/.prettierrc.js

@@ -4,7 +4,9 @@ module.exports = {
   bracketSpacing: true,
   singleQuote: true,
   trailingComma: 'all',
-  printWidth: 140,
+  printWidth: 100,
+  semi: true,
+  tabWidth: 2,
   useTabs: false,
-  endOfLine: 'auto',
+  endOfLine: 'lf',
 };

package/AGENTS.md

@@ -13,3 +13,22 @@
 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.
+
+## TDD And Validation
+
+Test Driven Development is a non-negotiable requirement.
+
+The sole purpose of automated tests is to verify observable functionality and externally visible behavior.
+Tests must validate what the system does through its public interfaces and expected outcomes.
+
+Tests must not assert, inspect, or depend on implementation details, including but not limited to:
+
+- The existence of specific lines of code, statements, functions, classes, files, or modules.
+- Specific algorithms, control flow, variable names, method calls, code snippets, or internal implementation choices.
+- Any internal structure that can change without changing externally observable behavior.
+
+A correct implementation may be completely rewritten or refactored without requiring changes to functional tests, provided its externally observable behavior remains unchanged.
+
+Any test that fails solely because the implementation changed while the externally observable behavior remained correct is incorrectly designed and must be rewritten or removed.
+
+This requirement is mandatory for all new tests and must be applied whenever existing tests are modified.

package/eslint.config.mjs

@@ -1,4 +1,7 @@
+import js from '@eslint/js';
+import tsParser from '@typescript-eslint/parser';
 import { defineConfig, globalIgnores } from 'eslint/config';
+import globals from 'globals';
 
 const eslintConfig = defineConfig([
   globalIgnores([
@@ -8,7 +11,56 @@ const eslintConfig = defineConfig([
     'build/**',
     'next-env.d.ts',
     'node_modules/**',
+    'coverage/**',
+    'dist/**',
   ]),
+  {
+    name: 'carecard/braced-control-flow',
+    files: ['**/*.{js,jsx,mjs,cjs,ts,tsx,mts,cts}'],
+    languageOptions: {
+      ecmaVersion: 'latest',
+      parserOptions: {
+        ecmaFeatures: {
+          jsx: true,
+        },
+      },
+    },
+    rules: {
+      curly: ['error', 'all'],
+    },
+  },
+  {
+    name: 'carecard/javascript-recommended',
+    files: ['**/*.{js,jsx,mjs,cjs}'],
+    languageOptions: {
+      ecmaVersion: 'latest',
+      sourceType: 'commonjs',
+      globals: {
+        ...globals.node,
+        ...globals.mocha,
+      },
+    },
+    rules: {
+      ...js.configs.recommended.rules,
+      eqeqeq: ['error', 'smart'],
+      'no-unused-vars': ['error', { argsIgnorePattern: '^_', caughtErrorsIgnorePattern: '^_' }],
+      'no-var': 'error',
+    },
+  },
+  {
+    name: 'carecard/esm-source-type',
+    files: ['**/*.mjs'],
+    languageOptions: {
+      sourceType: 'module',
+    },
+  },
+  {
+    name: 'carecard/typescript-parser',
+    files: ['**/*.{ts,tsx,mts,cts}'],
+    languageOptions: {
+      parser: tsParser,
+    },
+  },
 ]);
 
 export default eslintConfig;

package/index.d.ts

@@ -150,7 +150,11 @@ export const jwtUtilAuth: {
    * @param privateKey - PEM formatted private key to sign the token.
    * @returns Signed JWT string, or null when the private key is missing. Unexpected failures throw.
    */
-  createSignedJwtFromObject: (headerObject: JwtHeader, payloadObject: JwtPayload, privateKey: string) => string | null;
+  createSignedJwtFromObject: (
+    headerObject: JwtHeader,
+    payloadObject: JwtPayload,
+    privateKey: string,
+  ) => string | null;
   /**
    * Verifies the signature of a JWT using a public key.
    * @param jwt - The JWT string to verify.
@@ -179,7 +183,11 @@ export const pwdUtilAuth: {
    * @param algorithm - The hashing algorithm to use (e.g., 'sha256').
    * @returns A string containing the formatted hash with metadata ($1$alg$hash$salt$) or null if an error occurs.
    */
-  createPasswordHashWithRandomSalt: (password: string, secret: string, algorithm: string) => string | null;
+  createPasswordHashWithRandomSalt: (
+    password: string,
+    secret: string,
+    algorithm: string,
+  ) => string | null;
   /**
    * Generates a password hash using the same algorithm and salt from a previously saved hash.
    * Useful for verifying a password against a stored hash.
@@ -188,7 +196,11 @@ export const pwdUtilAuth: {
    * @param secret - The pepper/secret key used for hashing.
    * @returns A hash string that should match the saved hash if the password is correct, or null if an error occurs.
    */
-  createPasswordHashBasedOnSavedAlgorithmSalt: (password: string, savedPasswordHash: string, secret: string) => string | null;
+  createPasswordHashBasedOnSavedAlgorithmSalt: (
+    password: string,
+    savedPasswordHash: string,
+    secret: string,
+  ) => string | null;
 };
 
 /**
@@ -273,7 +285,11 @@ export function generateKeyPair(algorithm?: 'ed25519' | 'rsa' | string): KeyPair
  * @param privateKey - PEM formatted private key to sign the token.
  * @returns Signed JWT string or null if an error occurs.
  */
-export function jwtCreateSignedToken(headerObject: JwtHeader, payloadObject: JwtPayload, privateKey: string): string | null;
+export function jwtCreateSignedToken(
+  headerObject: JwtHeader,
+  payloadObject: JwtPayload,
+  privateKey: string,
+): string | null;
 
 /**
  * Creates a signed service-to-service JWT using the issuing service's private key.
@@ -312,7 +328,11 @@ export function jwtGetHeaderPayload(jwt: string): JwtParts | null;
  * @param algorithm - The hashing algorithm to use (e.g., 'sha256').
  * @returns A string containing the formatted hash with metadata ($1$alg$hash$salt$) or null if an error occurs.
  */
-export function passwordCreateHashWithRandomSalt(password: string, secret: string, algorithm: string): string | null;
+export function passwordCreateHashWithRandomSalt(
+  password: string,
+  secret: string,
+  algorithm: string,
+): string | null;
 
 /**
  * Generates a password hash using the same algorithm and salt from a previously saved hash.
@@ -322,4 +342,8 @@ export function passwordCreateHashWithRandomSalt(password: string, secret: strin
  * @param secret - The pepper/secret key used for hashing.
  * @returns A hash string that should match the saved hash if the password is correct, or null if an error occurs.
  */
-export function passwordCreateHashFromSavedHash(password: string, savedPasswordHash: string, secret: string): string | null;
+export function passwordCreateHashFromSavedHash(
+  password: string,
+  savedPasswordHash: string,
+  secret: string,
+): string | null;

package/index.js

@@ -27,7 +27,8 @@ module.exports = {
    */
   pwdUtilAuth: {
     createPasswordHashWithRandomSalt: pwdUtilAuth.createPasswordHashWithRandomSalt,
-    createPasswordHashBasedOnSavedAlgorithmSalt: pwdUtilAuth.createPasswordHashBasedOnSavedAlgorithmSalt,
+    createPasswordHashBasedOnSavedAlgorithmSalt:
+      pwdUtilAuth.createPasswordHashBasedOnSavedAlgorithmSalt,
   },
   /**
    * @deprecated Use native Buffer methods or other modern alternatives.