@carecard/jwt-read 3.13.0 → 3.14.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -7,6 +7,10 @@ Non-negotiable root-cause solution rule: Always identify and solve the verified
7
7
 
8
8
  # CareCard Workspace Standards
9
9
 
10
+ Mandatory companion: load
11
+ `$pkg-jwt-read-coding-standards-and-best-practices` before this skill for every
12
+ task in this repository.
13
+
10
14
  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.
11
15
 
12
16
  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.
@@ -412,9 +416,9 @@ the authenticated dashboard.
412
416
  may map that role to `super_admin`, but backend auth RLS must not require a
413
417
  separate database role row for that bypass.
414
418
  - Public auth flows such as registration, login, server-auth session create and
415
- introspection, confirmation, recovery, visitor creation, and service user
419
+ introspection, recovery, visitor creation, and service user
416
420
  lookup must use narrow system contexts (`system_create`, `system_login`,
417
- `system_confirm`, `system_recovery`, `system_visitor`, `system_service`)
421
+ `system_recovery`, `system_visitor`, `system_service`)
418
422
  instead of privileged runtime queries.
419
423
 
420
424
  - `ms-auth` controller exports use concise action names such as `loginUser`,
@@ -425,7 +429,7 @@ the authenticated dashboard.
425
429
 
426
430
  ## Security Requirements
427
431
 
428
- - Treat authentication, authorization, JWT, password, email confirmation,
432
+ - Treat authentication, authorization, JWT, password, email verification,
429
433
  recovery, file upload, CORS, rate limits, and error response behavior as
430
434
  security-sensitive.
431
435
  - Never log or return secrets, tokens, passwords, credentials, private keys,
@@ -0,0 +1,162 @@
1
+ ---
2
+ name: pkg-jwt-read-coding-standards-and-best-practices
3
+ description: 'Mandatory for every pkg-jwt-read task, including analysis, clarification, planning, implementation, review, debugging, documentation, public API work, skill maintenance, and validation. Use before every narrower skill.'
4
+ ---
5
+
6
+ # Pkg JWT Read Coding Standards And Best Practices
7
+
8
+ Non-negotiable root-cause solution rule: Always identify and solve the verified
9
+ root cause, use the stronger solution, and deliver a correct, durable,
10
+ production-quality result. Never treat a temporary workaround, resource
11
+ increase, retry, suppression, bypass, or symptom-only patch as completion.
12
+ Validate the root-cause fix against the real failing workflow and prove the end
13
+ state.
14
+
15
+ Non-negotiable error and warning rule: Never suppress, silence, hide, downgrade,
16
+ filter, ignore, skip, or bypass errors or warnings from code, tests, tools,
17
+ compilers, linters, or validation. Fix the root cause, then rerun the affected
18
+ check and require a clean result. Expected error-path tests may assert errors,
19
+ but must not conceal unexpected failures.
20
+
21
+ Non-negotiable repository isolation rule: Every repository must run its Husky
22
+ hooks and tests using only files, code, fixtures, dependencies, and services
23
+ contained within that repository. Tests and Husky scripts must not import,
24
+ require, read, execute, or otherwise depend on sibling repositories or paths
25
+ outside the repository root. app-e2e-tests is the only exception because
26
+ cross-repository end-to-end testing is its explicit responsibility.
27
+
28
+ ## Mandatory Use And Authorities
29
+
30
+ Load this skill before doing any work in `pkg-jwt-read`, including read-only
31
+ and documentation-only work. Then load every narrower skill that owns the
32
+ affected package contract.
33
+
34
+ Use these existing authorities instead of duplicating them:
35
+
36
+ - `$carecard-workspace-standards` for TDD, root-cause solutions, dependencies,
37
+ errors, isolation, and repository workflow;
38
+ - `$software-design-patterns-and-clean-code` for design, DRY, KISS,
39
+ testability, and clean-code details;
40
+ - `$pkg-jwt-read-jwt-middleware-library` for JWT middleware, auth context,
41
+ exports, types, security, and validation; and
42
+ - `$pkg-publish` only when runtime package artifacts or consumer versions must
43
+ be published and propagated.
44
+
45
+ This skill adds the function-evolution, direct-contract, composition, and
46
+ completion rules below without weakening those companion skills.
47
+
48
+ ## Requirement Judgment
49
+
50
+ 1. Read the complete request and inspect implementation, public exports,
51
+ declarations, middleware call sites, tests, documentation, and consumers
52
+ before deciding how to change the package.
53
+ 2. Translate the request into a coherent technical contract. Do not apply
54
+ wording mechanically when it is contradictory, unsafe, impossible, or
55
+ incompatible with authentication or package architecture.
56
+ 3. Make low-risk, reversible assumptions only when they preserve requested
57
+ behavior and scope.
58
+ 4. Ask for clarification when an unresolved choice would materially change a
59
+ public API, authentication or authorization behavior, security, consumer
60
+ behavior, destructive scope, or the repositories that must change.
61
+ 5. Explain architectural tradeoffs before a major API, middleware, type,
62
+ authentication, module, package, or dependency change.
63
+
64
+ ## Scope And Quality
65
+
66
+ - Treat every workspace repository as independent and validate it from its own
67
+ root.
68
+ - Update every skill, document, source, runtime test, type test, export,
69
+ declaration, consumer, and package version genuinely required for a coherent
70
+ task.
71
+ - Do not broaden the task into unrelated cleanup.
72
+ - Preserve CommonJS, middleware, request-context, role, declaration, naming,
73
+ and test conventions unless the task explicitly replaces them.
74
+ - Prefer Node core and existing package helpers over new dependencies.
75
+ - Prefer readable direct implementation over clever compression or a temporary
76
+ workaround.
77
+ - Use meaningful names that describe authentication and authorization intent.
78
+
79
+ ## Function Evolution
80
+
81
+ Before changing a function's behavior or signature, inventory every direct,
82
+ indirect, test, exported, middleware, callback, configuration-driven, and
83
+ dynamic consumer.
84
+
85
+ - If exactly one consumer is proven, change the function only when required.
86
+ - If two or more consumers exist, do not change the shared function's behavior.
87
+ Create a new purpose-named function and migrate only intended consumers.
88
+ - If every consumer needs the new contract, migrate all consumers and delete
89
+ the old function after proving it unused.
90
+ - Treat every exported, declared, public, middleware, callback, or dynamically
91
+ discovered function as shared unless single use is conclusively proven.
92
+ - Do not add caller branches, mode flags, or optional parameters merely to
93
+ make one shared function serve incompatible contracts.
94
+ - Cover the new function, public surface, types, and every migrated consumer
95
+ through TDD.
96
+
97
+ ## Direct Contract Without Backward Compatibility
98
+
99
+ When the active task replaces a contract, implement the requested end state
100
+ directly. Do not add legacy aliases, deprecated wrappers, compatibility
101
+ overloads, duplicate exports, dual auth paths, transitional names, or fallback
102
+ behavior solely to preserve the superseded contract.
103
+
104
+ Delete obsolete functions and exports after all intended consumers have
105
+ migrated and repository-native search, runtime tests, and type tests prove them
106
+ unused. This does not authorize unrelated API removal. If an existing
107
+ published or security contract requires compatibility and the request does not
108
+ clearly supersede it, explain the conflict and ask first.
109
+
110
+ ## TDD And Root-Cause Gate
111
+
112
+ Follow `$carecard-workspace-standards` and
113
+ `$pkg-jwt-read-jwt-middleware-library` for the complete failing-test-first and
114
+ root-cause workflow. Documentation and skill changes require a focused
115
+ structural validation before prose changes. Do not accept retries, suppressed
116
+ diagnostics, weakened types, disabled tests, forced success, compatibility
117
+ patches, or symptom-only workarounds as completion.
118
+
119
+ ## Function Size
120
+
121
+ Every new or materially changed function or middleware body must contain at most 25 logical code lines.
122
+
123
+ - Count executable statements, branches, loop headers, side-effecting calls,
124
+ returns, and throws.
125
+ - Exclude signatures, type-only declarations, blank lines, comments, and
126
+ isolated braces.
127
+ - Extract cohesive purpose-named helpers and compose them when needed.
128
+ - Keep parsing, verification, attachment, role evaluation, and error behavior
129
+ explicit rather than hiding them in one long function.
130
+ - Avoid meaningless forwarding wrappers and do not refactor untouched
131
+ functions solely to satisfy this limit.
132
+
133
+ ## UI Composition
134
+
135
+ This package does not own UI. If a package contract requires UI changes, make
136
+ them in the owning app repository. There, create focused components, compose
137
+ existing and new components, and delete obsolete components only after proving
138
+ them unused and replaced.
139
+
140
+ ## Skills, Documentation, And Database Boundaries
141
+
142
+ - Update affected skills, README guidance, examples, exports, and declarations
143
+ with behavior or validation changes.
144
+ - Reference existing authoritative skills instead of copying their details.
145
+ - If work reaches an `ms-*` database, change SQL only in the owning repository
146
+ using its database-migration-ownership skill. For first-create work, edit the
147
+ existing migration and matching rollback directly rather than adding a
148
+ compatibility migration.
149
+ - Keep persistence and service behavior in their owning repositories.
150
+
151
+ ## Completion
152
+
153
+ 1. Review each changed repository's diff and status independently.
154
+ 2. Run focused runtime and type tests, then all broader checks required by
155
+ local skills.
156
+ 3. If every changed file in a repository is Markdown (`*.md`), skip Husky and
157
+ run only focused Markdown validation.
158
+ 4. If any changed file is not Markdown, run every direct `.husky` script. If
159
+ none exists, run the strongest repository-native focused validation.
160
+ 5. Fix every in-scope failure at its root cause and rerun the exact command.
161
+ 6. Report exact commands, results, limitations, and remaining risk.
162
+ 7. Do not perform remote Git or GitHub operations unless explicitly requested.
@@ -0,0 +1,4 @@
1
+ interface:
2
+ display_name: 'Pkg JWT Read Coding Standards'
3
+ short_description: 'Apply mandatory JWT package standards'
4
+ default_prompt: 'Use $pkg-jwt-read-coding-standards-and-best-practices before every pkg-jwt-read task and apply all narrower skills that the task requires.'
@@ -126,9 +126,9 @@ depend on those folders being present.
126
126
  - Server-auth request attachment behavior that normalizes introspected claims
127
127
  into `req.jwt.payload` with `authMode: "server-auth"` and
128
128
  `auth_mode: "server-auth"`.
129
- - Server-auth email confirmation claims are copied only when present. The
130
- `emailVerified`, `email_verified`, `emailConfirmed`, and `email_confirmed`
131
- aliases retain their exact names and values, and omission remains omission.
129
+ - Server-auth email verification claims are copied only when present. The
130
+ `emailVerified` and `email_verified` names retain their exact values, and
131
+ omission remains omission.
132
132
  - Integration with `@carecard/common-util` for standardized login and
133
133
  authorization errors.
134
134
 
package/AGENTS.md ADDED
@@ -0,0 +1,15 @@
1
+ # Codex Instructions
2
+
3
+ ## Non-negotiable Codex banked-reset requirement
4
+
5
+ - Never use or consume a banked Codex rate-limit reset automatically.
6
+ - Before using any banked Codex rate-limit reset, stop, ask the user for explicit, direct approval for that specific reset, and wait for their reply.
7
+ - Never treat earlier approval, a standing instruction, silence, urgency, an unfinished task, or a request to continue as approval for a future reset.
8
+ - Do not invoke `/usage` redemption, a reset-consumption action, a reset API or tool, or any equivalent mechanism unless the user explicitly approved that specific reset.
9
+ - If a Codex limit is reached without that approval, pause and let the user reset it manually. Never consume a banked reset to keep working.
10
+
11
+ ## Repository validation contracts
12
+
13
+ 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.
14
+
15
+ Non-negotiable code organization rule: Functions with the same or equivalent behavior must use the same or clearly corresponding descriptive names across CareCard repositories, and equivalent functionality must live in files with the same names within each repository's established architecture. No backward compatibility names, aliases, or duplicate locations are allowed.
package/index.d.ts CHANGED
@@ -147,8 +147,6 @@ export interface ServerAuthIntrospectionClaims {
147
147
  email?: string;
148
148
  emailVerified?: boolean;
149
149
  email_verified?: boolean;
150
- emailConfirmed?: boolean;
151
- email_confirmed?: boolean;
152
150
  roles?: string[];
153
151
  sessionId?: string;
154
152
  session_id?: string;
package/lib/jwtLib.js CHANGED
@@ -5,7 +5,7 @@ const { throwLoginRequiredError, throwNotAuthorizedError } = require('@carecard/
5
5
 
6
6
  const DEFAULT_USER_AUTHORIZATION_HEADER_NAME = 'X-Authorization-Context';
7
7
  const DEFAULT_USER_AUTHORIZATION_MAX_TOKEN_LENGTH = 2048;
8
- const EMAIL_CONFIRMATION_CLAIM_NAMES = ['emailVerified', 'email_verified', 'emailConfirmed', 'email_confirmed'];
8
+ const EMAIL_VERIFICATION_CLAIM_NAMES = ['emailVerified', 'email_verified'];
9
9
 
10
10
  function jwtClientId(req) {
11
11
  const jwtObj = req?.jwt || this;
@@ -436,22 +436,22 @@ function attachServerAuthClaims(req, claims, customErrorFunction) {
436
436
  _attachJwtMethods(req.jwt);
437
437
  }
438
438
 
439
- // Pattern: Projection - copies only authoritative confirmation aliases and preserves their exact values.
440
- function pickEmailConfirmationClaims(claims) {
439
+ // Pattern: Projection - copies only authoritative verification names and preserves their exact values.
440
+ function pickEmailVerificationClaims(claims) {
441
441
  return Object.fromEntries(
442
- EMAIL_CONFIRMATION_CLAIM_NAMES.filter(claimName => Object.prototype.hasOwnProperty.call(claims, claimName)).map(claimName => [
442
+ EMAIL_VERIFICATION_CLAIM_NAMES.filter(claimName => Object.prototype.hasOwnProperty.call(claims, claimName)).map(claimName => [
443
443
  claimName,
444
444
  claims[claimName],
445
445
  ]),
446
446
  );
447
447
  }
448
448
 
449
- // Pattern: Mapper - attaches server-auth metadata while preserving authoritative confirmation claims.
449
+ // Pattern: Mapper - attaches server-auth metadata while preserving authoritative verification claims.
450
450
  function createServerAuthPayload(claims) {
451
451
  return {
452
452
  sub: claims.sub || claims.userId || claims.user_id,
453
453
  email: claims.email || '',
454
- ...pickEmailConfirmationClaims(claims),
454
+ ...pickEmailVerificationClaims(claims),
455
455
  roles: Array.isArray(claims.roles) ? claims.roles : [],
456
456
  authMode: 'server-auth',
457
457
  auth_mode: 'server-auth',
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@carecard/jwt-read",
3
- "version": "3.13.0",
3
+ "version": "3.14.0",
4
4
  "repository": {
5
5
  "type": "git",
6
6
  "url": "https://github.com/CareCard-ca/pkg-jwt-read.git"
@@ -42,9 +42,9 @@
42
42
  "typescript": "6.0.3"
43
43
  },
44
44
  "dependencies": {
45
- "@carecard/auth-util": "3.13.0",
46
- "@carecard/common-util": "3.13.0",
47
- "@carecard/validate": "3.13.0"
45
+ "@carecard/auth-util": "3.14.0",
46
+ "@carecard/common-util": "3.14.0",
47
+ "@carecard/validate": "3.14.0"
48
48
  },
49
49
  "overrides": {
50
50
  "diff": "8.0.4",
package/readme.md CHANGED
@@ -152,9 +152,9 @@ those claims onto `req.jwt.payload` with `authMode: "server-auth"` and
152
152
  `auth_mode: "server-auth"` so services can keep their existing JWT-backed
153
153
  database context and role checks.
154
154
 
155
- Server-auth email confirmation claims are copied only when present. The
156
- `emailVerified`, `email_verified`, `emailConfirmed`, and `email_confirmed`
157
- aliases retain their exact names and values, and omission remains omission.
155
+ Server-auth email verification claims are copied only when present. The
156
+ `emailVerified` and `email_verified` names retain their exact values, and
157
+ omission remains omission.
158
158
 
159
159
  ### Scoped User Authorization Context
160
160