@carecard/auth-util 3.6.0 → 3.8.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.
@@ -5,6 +5,10 @@ description: 'Follow the shared SO_CareCardCa/CareCard workspace coding, testing
5
5
 
6
6
  # CareCard Workspace Standards
7
7
 
8
+ 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.
9
+
10
+ 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.
11
+
8
12
  ## Purpose
9
13
 
10
14
  Use before modifying, testing, reviewing, or debugging any CareCard workspace repository or cross-repository contract.
@@ -5,6 +5,10 @@ description: 'Use only when the user explicitly asks for remote Git or GitHub PR
5
5
 
6
6
  # Pull Request Create
7
7
 
8
+ 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.
9
+
10
+ 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.
11
+
8
12
  ## Purpose
9
13
 
10
14
  After the user explicitly asks for remote Git or GitHub PR work, create,
@@ -5,6 +5,10 @@ description: 'Use only when the user explicitly asks for remote Git or GitHub PR
5
5
 
6
6
  # Pull Request Merge Close
7
7
 
8
+ 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.
9
+
10
+ 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.
11
+
8
12
  ## Purpose
9
13
 
10
14
  After the user explicitly asks for remote Git or GitHub PR work, push the
@@ -5,6 +5,10 @@ description: 'Use when changing pkg-auth-util auth, password, JWT, crypto, key,
5
5
 
6
6
  # Package Auth Util
7
7
 
8
+ 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.
9
+
10
+ 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.
11
+
8
12
  ## Purpose
9
13
 
10
14
  CareCard auth utility package for JWT creation/verification primitives, password hashing, crypto helpers, key generation, and tests.
@@ -0,0 +1,112 @@
1
+ ---
2
+ name: pkg-publish
3
+ description: 'Use when any pkg-* repository has non-Markdown package changes, including source code, public types, tests, scripts, package metadata, lockfiles, dependency behavior, or validation config, and the CareCard packages must be versioned, published in order with just-in-time package pushes, and propagated to pkg-*, ms-*, and app-dashboard consumers. Do not use for Markdown-only changes.'
4
+ ---
5
+
6
+ # pkg Publish
7
+
8
+ 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.
9
+
10
+ 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.
11
+
12
+ ## Trigger
13
+
14
+ Run this skill after every `pkg-*` repository change that touches non-Markdown
15
+ package files: source code, public type declarations, tests, scripts,
16
+ configuration, package metadata, lockfiles, dependency behavior, or validation
17
+ behavior.
18
+
19
+ Do not run this skill for Markdown-only changes, including README-only or
20
+ `*.md` skill-documentation-only updates.
21
+
22
+ ## Version Rule
23
+
24
+ 1. Check `package.json` in all four package repositories:
25
+ `pkg-common-util`, `pkg-validate`, `pkg-auth-util`, and `pkg-jwt-read`.
26
+ 2. Select one minor version higher than the highest current package version.
27
+ If the highest version is `3.7.0`, the coordinated target version is
28
+ `3.8.0`.
29
+ 3. Use the same target version for all four packages.
30
+ 4. Update each package's `package.json` and `package-lock.json`, then commit the
31
+ version change on a package release branch before publishing.
32
+
33
+ ## Publish Order
34
+
35
+ Always publish packages in this order, one repository at a time:
36
+
37
+ 1. `@carecard/common-util`
38
+ 2. `@carecard/validate`
39
+ 3. `@carecard/auth-util`
40
+ 4. `@carecard/jwt-read`
41
+
42
+ Publish by pushing the package release branch, creating or reusing a pull
43
+ request into `development`, marking it ready, waiting for checks, squash-merging
44
+ with administrator privileges, and verifying npm publication with:
45
+
46
+ ```sh
47
+ npm view <package-name>@<target-version> version
48
+ ```
49
+
50
+ The package GitHub workflow publishes automatically from `development`. Do not
51
+ create a `main` merge unless the user explicitly asks for it.
52
+
53
+ ## Deferred Package Push
54
+
55
+ Commit coordinated version and dependency updates locally as the release sequence
56
+ progresses. Do not push a `pkg-*` release branch until that package is the next
57
+ package being published by merge into `development`.
58
+
59
+ Immediately before each package's publishing turn:
60
+
61
+ 1. Verify the repository is on the intended release branch and has a clean
62
+ working tree.
63
+ 2. Run required validation and every direct `.husky` script for that repository.
64
+ 3. Push that package's release branch.
65
+ 4. Create or reuse the pull request into `development`, merge it, and wait for
66
+ npm publication before continuing to dependency fanout.
67
+
68
+ ## Dependency Fanout
69
+
70
+ After each package publishes, update every package repository that depends on
71
+ that package to the exact target version and commit the change before
72
+ continuing:
73
+
74
+ 1. After publishing `@carecard/common-util`, update it in `pkg-validate`,
75
+ `pkg-auth-util`, and `pkg-jwt-read` when declared.
76
+ 2. After publishing `@carecard/validate`, update it in `pkg-auth-util` and
77
+ `pkg-jwt-read` when declared.
78
+ 3. After publishing `@carecard/auth-util`, update it in `pkg-jwt-read` when
79
+ declared.
80
+ 4. `@carecard/jwt-read` is last, so no later package repository depends on it.
81
+
82
+ Use exact installs so `package.json` and `package-lock.json` stay aligned:
83
+
84
+ ```sh
85
+ npm install <package-name>@<target-version> --save-exact
86
+ ```
87
+
88
+ ## Service And Dashboard Consumers
89
+
90
+ After all four packages are published, update all `ms-*` repositories and
91
+ `app-dashboard` that declare any `@carecard/*` package dependency. Install the
92
+ latest exact target version for every declared CareCard package, run the
93
+ repository's required validation, and commit the dependency updates locally.
94
+
95
+ Do not push, open pull requests, or merge service/dashboard consumer dependency
96
+ commits unless the user explicitly asks for remote GitHub work for those
97
+ repositories.
98
+
99
+ ## Validation
100
+
101
+ For each changed repository:
102
+
103
+ - Run `git diff --check`.
104
+ - Run every direct script in `.husky`; do not bypass hooks.
105
+ - For package repositories, run the package tests, type checks, and lint/format
106
+ checks required by the hook.
107
+ - For `app-dashboard`, run both `.husky/pre-commit` and `.husky/pre-push` when
108
+ dependencies change.
109
+
110
+ Finish by verifying that all four packages are published at the same target
111
+ version and every declared `@carecard/*` dependency in `pkg-*`, `ms-*`, and
112
+ `app-dashboard` is pinned to that version.
@@ -0,0 +1,5 @@
1
+ interface:
2
+ display_name: 'pkg Publish'
3
+ short_description: 'Publish CareCard packages in order with just-in-time pushes.'
4
+ brand_color: '#0F766E'
5
+ default_prompt: 'Use $pkg-publish to publish coordinated CareCard package releases.'
@@ -5,6 +5,10 @@ description: 'Use every time before coding, refactoring, debugging, or reviewing
5
5
 
6
6
  # Software Design Patterns And Clean Code
7
7
 
8
+ 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.
9
+
10
+ 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.
11
+
8
12
  ## Purpose
9
13
 
10
14
  Use this skill with every coding, refactoring, debugging, or review task in
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@carecard/auth-util",
3
- "version": "3.6.0",
3
+ "version": "3.8.0",
4
4
  "repository": "https://github.com/CareCard-ca/pkg-auth-util.git",
5
5
  "description": "Auth utility functions",
6
6
  "main": "index.js",
@@ -42,8 +42,8 @@
42
42
  "typescript": "6.0.3"
43
43
  },
44
44
  "dependencies": {
45
- "@carecard/common-util": "3.6.0",
46
- "@carecard/validate": "3.6.0"
45
+ "@carecard/common-util": "3.8.0",
46
+ "@carecard/validate": "3.8.0"
47
47
  },
48
48
  "overrides": {
49
49
  "diff": "8.0.4",
package/readme.md CHANGED
@@ -5,6 +5,12 @@
5
5
 
6
6
  Utility package for authentication and authorization in the CareCard ecosystem.
7
7
 
8
+ ## Development Rule
9
+
10
+ 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.
11
+
12
+ 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.
13
+
8
14
  ## Features
9
15
 
10
16
  - **JWT Utilities**: Create, verify, and parse JSON Web Tokens with support for EdDSA (Ed25519) and RSA.
@@ -1,75 +0,0 @@
1
- ---
2
- name: npm-package-flow
3
- description: 'Use in pkg-* repositories when publishable package code changes require a version bump, GitHub development/main squash-merge flow, npm publication, and uncommitted consumer package updates in ms-* and app-dashboard.'
4
- ---
5
-
6
- # npm Package Flow
7
-
8
- ## Purpose
9
-
10
- Use this skill in a `pkg-*` repository when package code changes need to be
11
- published to npm and propagated to CareCard consumers.
12
-
13
- The package name is the `name` field in the repository `package.json`.
14
-
15
- ## Publishable vs Non-Publishable Changes
16
-
17
- Publishable package changes include runtime source changes, public exports,
18
- TypeScript declarations, package metadata that affects consumers, security
19
- behavior, or dependency behavior that changes the package contract.
20
-
21
- The following are not publishable package changes by themselves:
22
-
23
- - Skills or `.agents` guidance.
24
- - Documentation and README updates.
25
- - Tests, fixtures, mocks, snapshots, or validation-only changes.
26
- - Formatting-only changes and comments.
27
-
28
- For non-publishable changes, do not bump the package version, publish to npm,
29
- or update `ms-*` and `app-dashboard` package versions.
30
-
31
- ## Required Flow For Publishable Changes
32
-
33
- Run this workflow only when the user explicitly asks for package publication,
34
- remote GitHub merge work, or the full package-flow completion. Remote Git and
35
- GitHub operations must not be inferred.
36
-
37
- 1. Finish package code, tests, documentation, and skill updates inside the
38
- current `pkg-*` repository.
39
- 2. Bump the package version in `package.json` and `package-lock.json` according
40
- to the user request or the package change scope.
41
- 3. Run the package's required tests, lint, type checks, and every direct Husky
42
- script. Fix failures before continuing.
43
- 4. Commit the package changes to the current branch.
44
- 5. Push the current branch, create or reuse the PR into `development`,
45
- squash-merge it with administrator privileges, and delete the merged branch.
46
- 6. Create a new merge branch from the updated `development` branch and use that
47
- branch to open a PR into `main`.
48
- 7. Squash-merge the merge branch into `main` with administrator privileges and
49
- delete the merge branch. This `main` merge publishes the package.
50
- 8. Confirm publication with `npm view <package-name>@<version> version`.
51
- 9. Check out a fresh local branch with the same name as the deleted working
52
- branch from the updated `development` branch.
53
- 10. Update the new `@carecard/...` package version in `app-dashboard` and in
54
- only the `ms-*` repositories that already declare the package, plus any
55
- explicitly intended new consumers.
56
- 11. Run `npm install` and relevant validation in each updated consumer.
57
- 12. Do not commit the `ms-*` or `app-dashboard` consumer updates unless the user
58
- explicitly asks.
59
-
60
- ## Consumer Update Rules
61
-
62
- - Discover existing consumers by checking each target repository `package.json`
63
- for the published package name.
64
- - Install exact package versions, for example
65
- `npm install <package-name>@<version> --save-exact`.
66
- - Keep consumer updates local and uncommitted unless the user gives a separate
67
- commit or PR instruction.
68
- - If a consumer should become a new dependency, require explicit user intent for
69
- that repository.
70
-
71
- ## Reporting
72
-
73
- Report the package name, published version, development PR, main PR, npm
74
- publication check, consumer repositories updated, validation commands run, and
75
- any consumer updates intentionally left uncommitted.
@@ -1,5 +0,0 @@
1
- interface:
2
- display_name: 'npm Package Flow'
3
- short_description: 'Use in pkg-* repositories when publishable @carecard package code changes need npm publication and consumer updates.'
4
- brand_color: '#0F766E'
5
- default_prompt: 'Use $npm-package-flow when this task matches the skill scope.'