@carecard/validate 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/logged-in-user-profile-page/SKILL.md

@@ -7,7 +7,9 @@ Non-negotiable root-cause solution rule: Always identify and solve the verified
 
 # Logged-In User Profile Page
 
-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,3 +43,22 @@ Relevant profile/settings fields:
 - Run focused Mocha tests for the changed validator keys.
 - Run `npm run test:types` when public exports or declarations are affected.
 - Run `npm run test:All` for validator contract changes before finalizing.
+
+## 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/pkg-validate-coding-standards-and-best-practices/SKILL.md

@@ -5,6 +5,19 @@ description: 'Mandatory for every pkg-validate task, including analysis, clarifi
 
 # Pkg Validate 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, predicate, sanitization, whitelist, declaration, naming,
   and test conventions unless the task explicitly replaces them.
@@ -102,17 +117,21 @@ 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.
+migrated and repository-native search proves them unused. Runtime and type
+tests verify the supported public behavior and consumer contract without
+inspecting implementation structure; coverage measures exercised observable
+behavior. 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
+root-cause, behavior-focused validation, and diagnostic-coverage workflow.
+Coverage never authorizes implementation-detail tests. 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, reduced coverage, disabled
 tests, forced success, compatibility patches, or symptom-only workarounds as
 completion.
@@ -163,3 +182,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-validate-validation-library/SKILL.md

@@ -7,7 +7,9 @@ Non-negotiable root-cause solution rule: Always identify and solve the verified
 
 # Package Validate
 
-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 validation package for deterministic validators, sanitization, whitelis
 
 ## 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
@@ -77,8 +81,10 @@ depend on those folders being present.
   option, result, generic, or `unknown` types with narrowing.
 - Follow this repository's coding style, naming conventions, and CommonJS
   project structure.
-- Use Test-Driven Development: add or update relevant Mocha or type tests before
-  changing behavior.
+- 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
@@ -125,22 +131,28 @@ depend on those folders being present.
   validators, and failure-message helpers explicitly in `index.d.ts`.
 - When existing declarations are too loose, improve them with specific types as
   part of the touched change instead of adding new loose types.
-- Update `test/types.test.ts` whenever public types, exports, options, return
-  values, or validators change.
+- When public types, options, return values, or validator behavior changes,
+  compile realistic consumer usage through the supported package root. Do not
+  assert that named exports or declaration nodes exist.
 - Keep runtime exports, README examples, and type declarations in sync.
 - Preserve validation behavior for invalid, missing, extra, and valid fields.
 
 ## Tests And Coverage
 
 - Use Mocha for runtime tests under `test`.
-- Use `test/types.test.ts` for TypeScript declaration coverage through
-  `npm run test:types`.
-- Add focused tests for valid input, invalid input, missing fields, optional
-  fields, array handling, nested paths, casing conversion, flattening, and error
-  messages when those areas change.
+- Use `npm run test:types` to compile realistic consumer code through the
+  supported package root and verify externally visible declaration behavior.
+- Add new focused consumer-facing tests through the supported package root for
+  valid input, invalid input, missing fields, optional fields, array handling,
+  nested paths, casing conversion, flattening, and error messages when those
+  areas change. Modify a pre-existing test only after the user grants fresh,
+  explicit permission for that exact change.
 - Keep tests deterministic and avoid real external services.
-- This package enforces 100% coverage for branches, functions, lines, and
-  statements through `nyc`; do not reduce thresholds.
+- The existing `nyc` command reports branches, functions, lines, and
+  statements. Treat those percentages only as diagnostics, never as
+  functional evidence or a reason to assert implementation details. Do not
+  add tests solely to satisfy the metric or lower thresholds to hide a
+  failure; report any threshold conflict with the behavior-only policy.
 
 ## Legacy Junie Source Notes
 
@@ -228,3 +240,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/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/.codex/AGENTS.md

@@ -16,8 +16,9 @@ Non-negotiable repository isolation rule: Every repository must run its Husky ho
 
 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.
 
-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,
@@ -29,6 +30,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.
+
 These instructions apply to the `pkg-validate` repository. This file is self-contained:
 it includes the workspace-level instructions that were previously read from
 `/Users/pankajpriscilla/SO_CareCardCa/.codex/AGENTS.md`, followed by
@@ -45,7 +51,7 @@ These instructions apply to the whole workspace. The workspace is a collection o
 - **Always follow the owner's coding style.** Preserve the existing style in the file and repository you are editing.
 - **Always follow the owner's naming conventions.** Use meaningful function, variable, file, test, and type names that match the surrounding code.
 - **Always follow the existing project structure.** Put code, tests, docs, services, validation, transforms, components, and helpers where the current repository already expects them.
-- **Always use Test-Driven Development.** Write or update focused tests first, verify they fail for the missing behavior when practical, then implement the code.
+- **Always use Test-Driven Development.** 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 the code.
 - **Never suppress errors, TypeScript errors, linter warnings, or failing tests.** Do not add `eslint-disable`, `@ts-ignore`, broad catches, empty catches, or other suppression. Fix the root cause.
 - **Do not add new dependencies unless they are clearly necessary.** If a dependency might be needed, stop and ask for confirmation first, with a clear reason, tradeoff, and why existing code cannot reasonably solve it.
 - **Before finalizing any response for a repository, run every script in that repository's `.husky` directory.** Do not bypass hooks. If a `.husky` script fails, fix the underlying issue and rerun it. If it cannot run because of environment constraints, report the exact script and reason.
@@ -57,7 +63,10 @@ These instructions apply to the whole workspace. The workspace is a collection o
 - Explain architectural tradeoffs before major changes, especially changes that affect shared packages, API contracts, security, persistence, authentication, or frontend/backend boundaries.
 - Favor readable, maintainable code over short clever code.
 - Preserve the existing project style, file structure, naming style, module system, and test framework.
-- Use Test-Driven Development: write or update focused tests first, then implement the code.
+- Use Test-Driven Development: write a new focused functional test through a
+  public interface first, confirm the intended behavioral failure, then
+  implement the code. Modify a pre-existing test only after the user grants
+  fresh, explicit permission for that exact change.
 - Use meaningful function and variable names. Names should expose intent and domain behavior.
 - Use specific types everywhere. Do not use `any`.
 - Keep changes scoped and easy to review. Avoid unrelated formatting churn or opportunistic refactors.
@@ -119,9 +128,9 @@ The `pkg-*` directories are reusable CareCard packages. Shared API response, err
 
 ### Tests
 
-- Write or update tests before implementation whenever changing behavior.
+- Write a focused functional test before implementation whenever behavior changes. Modify a pre-existing test only after the user grants fresh, explicit permission for that exact change.
 - Testing is mandatory before finalizing code changes. Do not stop after implementation if tests, `.junie`, or `.husky` checks remain unrun.
-- Code coverage must never be lower than the previous commit. When coverage tooling exists, compare against the previous commit or recorded baseline before finalizing, add tests to maintain or improve coverage, and never reduce coverage thresholds to make checks pass.
+- 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. Prefer explicit helper names over generic test utilities that hide important behavior.
 - Use existing test frameworks and layouts:
     - JavaScript `api-*`: usually Mocha, Supertest, `test/index.test.js`, and Docker-backed Postgres scripts.
@@ -130,7 +139,7 @@ The `pkg-*` directories are reusable CareCard packages. Shared API response, err
     - `app-dashboard`: Vitest, React Testing Library, mock API tests, and Selenium for end-to-end flows.
 - For database tests, use existing seed, migration, rollback, and cleanup patterns. Keep tests isolated and make cleanup reliable even after failures.
 - 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 any test or repository check fails, fix the issue and rerun the failing command. Only finalize with failing checks when the failure is unrelated to the change or blocked by environment constraints, and document that explicitly.
 
 ### Dashboard Frontend
@@ -167,7 +176,10 @@ The `pkg-*` directories are reusable CareCard packages. Shared API response, err
 
 - Never use TypeScript type `any`. Use specific value, record, validator, option, result, generic, or `unknown` types with narrowing.
 - Always follow this repository's coding style, naming conventions, and CommonJS project structure.
-- Always use Test-Driven Development: add or update the relevant Mocha or type tests before changing behavior.
+- Always 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 new dependencies unless they are absolutely needed. Ask for confirmation first with the reason and tradeoff.
 - Before finalizing work in this repository, run every script in `.husky/` and fix anything they report.
@@ -197,13 +209,32 @@ The `pkg-*` directories are reusable CareCard packages. Shared API response, err
 
 - Model input and output records, whitelist options, flattened output behavior, validators, and failure-message helpers explicitly in `index.d.ts`.
 - When existing declarations are too loose, improve them with specific types as part of the touched change instead of adding new loose types.
-- Update `test/types.test.ts` whenever public types, exports, options, return values, or validators change.
+- When public types, options, return values, or validator behavior changes, compile realistic consumer usage through the supported package root. Do not assert that named exports or declaration nodes exist.
 - Keep runtime exports, README examples, and type declarations in sync.
 
 ### Tests
 
 - Use Mocha for runtime tests under `test/`.
-- Use `test/types.test.ts` for TypeScript declaration coverage through `npm run test:types`.
+- Use `npm run test:types` to compile realistic consumer code through the supported package root and verify externally visible declaration behavior.
 - Add focused tests for valid input, invalid input, missing fields, optional fields, array handling, nested paths, casing conversion, flattening, and error messages when those areas change.
 - Keep tests deterministic and avoid relying on real external services.
 - Before pushing or finalizing, run `.husky/pre-commit`; it runs lint fixing, formatting, and `npm run test:All`.
+
+## 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.