@carecard/jwt-read 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
 
@@ -441,3 +451,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-jwt-read-coding-standards-and-best-practices/SKILL.md

@@ -5,6 +5,19 @@ description: 'Mandatory for every pkg-jwt-read task, including analysis, clarifi
 
 # Pkg JWT Read 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, middleware, request-context, role, declaration, naming,
   and test conventions unless the task explicitly replaces them.
@@ -102,8 +117,8 @@ overloads, duplicate exports, dual auth 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 first.
 
@@ -111,8 +126,9 @@ clearly supersede it, explain the conflict and ask first.
 
 Follow `$carecard-workspace-standards` and
 `$pkg-jwt-read-jwt-middleware-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-jwt-read-jwt-middleware-library/SKILL.md

@@ -7,7 +7,9 @@ Non-negotiable root-cause solution rule: Always identify and solve the verified
 
 # Package JWT Read
 
-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.
 
@@ -51,8 +53,10 @@ CareCard JWT read package for parsing, request attachment, visitor tokens, role
 
 ## 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.
   header, role, 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.
+- Use Test-Driven Development: add a new failing consumer-facing Mocha or type
+  test through the supported package root before changing behavior. Modify a
+  pre-existing test only after the user grants fresh, explicit permission for
+  that exact change.
 - 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
@@ -209,17 +215,19 @@ role names, such as `ad` and `admin`.
 - When existing declarations are too loose, improve them with specific types as
   part of the touched change instead of adding new loose types.
 - Keep overloads for context-bound helpers such as `jwtIsExpired` readable and
-  covered by type tests.
-- Update `test/types.test.ts` whenever public types, exports, overloads, or
-  attached request methods change.
+  verify them by compiling realistic consumer usage through the package root.
+- When public types, overloads, or attached request behavior changes, compile
+  the supported consumer contract without asserting that named exports or
+  declaration nodes exist.
 
 ## Tests
 
 - Use Mocha for runtime tests under `test`.
-- `lib` modules should have corresponding test files under `test`.
-- `test/attachedMethods.test.js` covers methods attached to objects or used as
-  context.
-- `test/types.test.ts` verifies TypeScript declarations with `tsc`.
+- Exercise runtime behavior only through the package's supported root exports;
+  tests must not mirror `lib` modules or depend on internal file layout.
+- Verify request-attachment and context-bound behavior through those public
+  exports without asserting internal method calls.
+- Compile realistic consumer code through the package root with `tsc` to verify externally visible declaration behavior.
 - Add focused tests for valid JWTs, invalid JWTs, missing headers, role checks,
   visitor token extraction, expiration behavior, request attachment behavior,
   server-auth introspection success/failure, NoThrow behavior, and
@@ -307,3 +315,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-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

@@ -380,7 +380,11 @@ export function jwtValidateAndExtractWebToken(
 /**
  * Validates the JWT from the Authorization header and extracts it into req.jwt (no-throw).
  */
-export function jwtValidateAndExtractNoThrow(req: AuthenticatedRequest, publicKey: string, options?: UserAuthorizationReadOptions): void;
+export function jwtValidateAndExtractNoThrow(
+  req: AuthenticatedRequest,
+  publicKey: string,
+  options?: UserAuthorizationReadOptions,
+): void;
 
 /**
  * Validates the JWT from a custom header and extracts it into req.jwt (no-throw).

package/index.js

@@ -21,7 +21,8 @@ module.exports = {
   jwtGetContext: jwtRoles.getContext,
   jwtValidateAndExtract: jwtLib.validateAndExtractJwtObject,
   jwtValidateAndExtractUserAuthorization: jwtLib.validateAndExtractUserAuthorizationObject,
-  jwtValidateAndExtractUserAuthorizationNoThrow: jwtLib.validateAndExtractUserAuthorizationObjectNoThrow,
+  jwtValidateAndExtractUserAuthorizationNoThrow:
+    jwtLib.validateAndExtractUserAuthorizationObjectNoThrow,
   jwtValidateAndExtractService: jwtLib.validateAndExtractServiceJwtObject,
   jwtValidateAndExtractOrServerAuth: jwtLib.validateAndExtractJwtOrServerAuthObject,
   jwtValidateAndExtractWebToken: jwtLib.validateAndExtractWebToken,