@carecard/auth-util 3.28.0 → 3.30.0

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

@@ -54,30 +54,89 @@ Always publish packages in this order, one repository at a time:
 5. `@carecard/telemetry`
 
 Publish by pushing the package release branch, creating or reusing a pull
-request into `development`, marking it ready, waiting for checks, squash-merging
+request into `main`, marking it ready, waiting for checks, squash-merging
 with administrator privileges, and verifying npm publication with:
 
 ```sh
 npm view <package-name>@<target-version> version
 ```
 
-The package GitHub workflow publishes automatically from `development`. Do not
-create a `main` merge unless the user explicitly asks for it.
+The package GitHub workflows accept pushes to `main` and `development` and
+publish an unpublished version. Use the `main` squash merge as the release
+path and verify npm publication before continuing. Subsequent development
+synchronization must reuse the same version; it is not a second release.
+
+## Default Git Policy
+
+Reuse the current working branch for every follow-up request, even when the
+subject changes or the working tree is clean. Create a branch only when no
+working branch exists or the checkout is on `main` or `development`. Otherwise,
+fetch remote `main` HEAD and rebase the same working branch onto that fetched
+commit, preserving its commits and uncommitted work.
+
+Apply these defaults unless the user explicitly specifies otherwise. The
+prohibition on deleting or force-pushing `main` always applies.
+
+1. Use `main` as the PR base and freshly fetched `origin/main` as the source of
+   truth. `origin/HEAD`, a stale local `main`, and the presence of `development`
+   do not change this default. If remote `main` is missing or cannot be fetched,
+   report the blocker instead of selecting another base.
+2. At task start, fetch `origin/main`. Create `<agent-name>/<branch-name>`
+   from that commit only when no working branch exists or the current branch is
+   `main` or `development`.
+   Otherwise keep and rebase the current branch onto that commit, preserving
+   its existing commits and building subsequent task commits on top. Honor an
+   explicit working-branch instruction; it changes branch selection, not
+   freshness.
+3. Fetch again before every source-branch push. Rebase when the working branch
+   does not already contain the latest `origin/main`; a clean mergeability
+   check is not proof that rebasing is unnecessary. If it already contains that
+   commit, no rebase is needed. The direct `development` replacement below is a
+   ref synchronization, not a source-branch rebase.
+4. Squash-merge into remote `main` after the applicable validation passes.
+   Administrator privileges may be used to merge without GitHub reviews; they
+   do not authorize bypassing required checks. Verify the merge, then delete
+   the merged source branch remotely and locally.
+5. Fetch the latest remote `main` after merging and fast-forward local `main`
+   to that commit. Preserve divergent local work and report a blocked update
+   rather than discarding it.
+6. Replace branches named exactly `development`, locally and remotely, with
+   the latest remote `main` commit. Use an explicit, observed-commit
+   `--force-with-lease` for a non-fast-forward remote update. Create a missing
+   counterpart when local or remote `development` exists; leave repositories
+   with neither unchanged. If `development` was the merged source, recreate
+   it from the new `main` after deleting it. Other working branches are not
+   development synchronization targets.
+7. Never delete local or remote `main`, and never force-push to remote `main`,
+   including with `--force-with-lease`, a forced refspec, or a mirror push.
+   Check the exact destination ref before every deletion or forced update.
+
+Fetches needed to establish a fresh `origin/main` at task start and before a
+source-branch push are authorized without a separate approval question. Commits,
+pushes, PR mutations, and branch cleanup require an authorized task; a request
+for local work alone does not authorize publication. An authorized squash merge
+into `main` includes the merged-source cleanup, local `main` update, and
+`development` synchronization below unless the user explicitly says otherwise.
+Never delete local or remote `main`, or force-push to remote `main`, including
+with `--force-with-lease`.
 
 ## Deferred Package Push
 
 Commit coordinated version and dependency updates locally as the release sequence
 progresses. Do not push a `pkg-*` release branch until that package is the next
-package being published by merge into `development`.
+package being published by merge into `main`.
 
 Immediately before each package's publishing turn:
 
 1. Verify the repository is on the intended release branch and has a clean
    working tree.
 2. Run required validation and every direct `.husky` script for that repository.
-3. Push that package's release branch.
-4. Create or reuse the pull request into `development`, merge it, and wait for
-   npm publication before continuing to dependency fanout.
+3. Fetch `origin/main` again, rebase the release branch when it does not already
+   contain that commit, and push with hooks enabled. Use an explicit observed-commit
+   lease if a rebase requires rewriting an already-pushed source branch.
+4. Create or reuse the pull request into `main`, merge it, and wait for
+   npm publication before continuing to dependency fanout. Complete merged-source
+   cleanup and main/development synchronization under the default Git policy.
 
 ## Dependency Fanout
 

package/AGENTS.md

@@ -1,4 +1,16 @@
-# Codex Instructions
+# Agent Instructions
+
+## Mandatory startup for every agent
+
+Every agent, including Codex, Claude, other assistants, and delegated agents,
+must read and follow [carecard-must-do](.agents/skills/carecard-must-do/SKILL.md)
+before beginning or resuming any task. This includes planning, questions,
+read-only investigation, coding, review, documentation, and validation.
+
+Then load the [repository engineering standards](.agents/skills/pkg-auth-util-coding-standards-and-best-practices/SKILL.md)
+and the specialist skills relevant to the task.
+An agent without automatic skill discovery must open the skill explicitly;
+the requirement applies regardless of the agent platform.
 
 ## Non-negotiable Codex banked-reset requirement
 

package/CLAUDE.md

@@ -0,0 +1,43 @@
+# Repository Agent Instructions
+
+## Mandatory startup for every agent
+
+Every agent, including Codex, Claude, other assistants, and delegated agents,
+must read and follow [carecard-must-do](.agents/skills/carecard-must-do/SKILL.md)
+before beginning or resuming any task. This includes planning, questions,
+read-only investigation, coding, review, documentation, and validation.
+
+Then load the [repository engineering standards](.agents/skills/pkg-auth-util-coding-standards-and-best-practices/SKILL.md)
+and the specialist skills relevant to the task.
+An agent without automatic skill discovery must open the skill explicitly;
+the requirement applies regardless of the agent platform.
+
+Also read [AGENTS.md](AGENTS.md) for the full repository instructions.
+
+## Existing repository isolation contract
+
+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.
+
+## Existing test-preservation policy
+
+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,
+or otherwise removed. A pre-existing test must not be modified without the
+user's explicit approval for the exact proposed change. If changing a
+pre-existing test is believed necessary, stop before making the change and
+request approval. The request must identify every affected test, describe the
+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.
+
+Also apply [$carecard-workspace-standards](.agents/skills/carecard-workspace-standards/SKILL.md)
+for the mandatory TDD and code organization rules.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@carecard/auth-util",
-  "version": "3.28.0",
+  "version": "3.30.0",
   "repository": "https://github.com/CareCard-ca/pkg-auth-util.git",
   "description": "Auth utility functions",
   "main": "index.js",
@@ -50,8 +50,8 @@
     "typescript": "6.0.3"
   },
   "dependencies": {
-    "@carecard/common-util": "3.28.0",
-    "@carecard/validate": "3.28.0",
+    "@carecard/common-util": "3.30.0",
+    "@carecard/validate": "3.30.0",
     "@types/express": "5.0.6"
   },
   "overrides": {
@@ -60,6 +60,6 @@
     "brace-expansion": "5.0.9",
     "minimatch": "10.2.6",
     "serialize-javascript": "7.0.5",
-    "js-yaml": "4.3.1"
+    "js-yaml": "4.3.2"
   }
 }

package/readme.md

@@ -1,5 +1,19 @@
 # @carecard/auth-util
 
+## Release 1.1.1 and production data
+
+CareCard Release 1.1.1 is the production baseline. Seeding with
+`--seed-release-data` is complete. Production cluster data, database rows,
+and stored user files will be preserved going forward. There will be no
+complete user-data wipeout and re-creation.
+
+Future production changes must use data-preserving migrations. Do not replay
+the completed initialization or run reset, rollback, or seed workflows as part
+of ordinary production deployment.
+
+The [completed seed inventory and verification record](https://github.com/CareCard-ca/cc-seed-data/blob/main/plans/production-seed-result.md)
+documents the accepted release baseline and verification limitations.
+
 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 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 increase, retry, suppression, bypass, or symptom-only patch as completion. Validate the root-cause fix against the real failing workflow and prove the end state.