@plasius/react-state 1.0.10 → 1.0.11

package/.github/workflows/cd.yml

@@ -1,186 +0,0 @@
-name: CD (Publish to npm)
-
-on:
-  workflow_dispatch:
-
-permissions:
-  contents: write
-  id-token: write # for npm provenance (requires Node 18+ and npm >=9)
-  attestations: write
-
-jobs:
-  publish:
-    runs-on: ubuntu-latest
-    environment: production
-    steps:
-      - name: Checkout
-        uses: actions/checkout@v4
-
-      - name: Use Node.js 22
-        uses: actions/setup-node@v4
-        with:
-          node-version-file: '.nvmrc'
-          cache: 'npm'
-
-      - name: Bump version & decide publish flags
-        id: pkg
-        env:
-          NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
-        run: |
-          set -euo pipefail
-          git config user.name "github-actions[bot]"
-          git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
-          NEW_VER=$(npm version patch -m "chore: release v%s [skip ci]")
-          echo "New version: $NEW_VER"
-          git push --follow-tags
-          
-          # Expose tag (vX.Y.Z) and version (X.Y.Z) for later steps
-          VER_NO_V=${NEW_VER#v}
-          echo "tag=$NEW_VER" >> "$GITHUB_OUTPUT"
-          echo "version=$VER_NO_V" >> "$GITHUB_OUTPUT"
-
-          NAME=$(node -p "require('./package.json').name")
-          echo "name=$NAME" >> "$GITHUB_OUTPUT"
-          if npm view "$NAME" version >/dev/null 2>&1; then
-            echo "flags=" >> "$GITHUB_OUTPUT"
-          else
-            echo "flags=--access public" >> "$GITHUB_OUTPUT"
-          fi
-          
-      - name: Install deps (CI)
-        run: npm ci
-
-      - name: Test (coverage)
-        run: npm run test -- --coverage
-        
-      - name: Upload coverage to Codecov
-        uses: codecov/codecov-action@v4
-        with:
-         token: ${{ secrets.CODECOV_TOKEN }}
-         files: ./coverage/lcov.info
-         flags: unittests
-         fail_ci_if_error: true
-
-      - name: Build
-        run: npm run build --if-present
-
-      - name: Generate SBOM (CycloneDX)
-        run: npm sbom --sbom-format=cyclonedx --sbom-type=library --omit dev > sbom.cdx.json
-
-      - name: Attest SBOM (GitHub Artifact Attestations)
-        uses: actions/attest-build-provenance@v3
-        with:
-          subject-path: sbom.cdx.json
-
-      - name: Update CHANGELOG.md (move Unreleased to new version)
-        env:
-          VERSION: ${{ steps.pkg.outputs.version }}
-          TAG: ${{ steps.pkg.outputs.tag }}
-          GITHUB_REPOSITORY: ${{ github.repository }}
-          verbose: true
-        run: |
-          set -euo pipefail
-          git config user.name "github-actions[bot]"
-          git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
-
-          FILE="CHANGELOG.md"
-          if [ ! -f "$FILE" ]; then
-            echo "No CHANGELOG.md found; skipping changelog update."
-            exit 0
-          fi
-
-          DATE=$(date -u +%Y-%m-%d)
-          VERSION_LINE="## [${VERSION}] - ${DATE}"
-
-          # Identify Unreleased block boundaries
-          UNREL_START=$(grep -n '^## \[Unreleased\]' "$FILE" | cut -d: -f1 || true)
-          if [ -z "$UNREL_START" ]; then
-            echo "No '## [Unreleased]' section found; skipping changelog update."
-            exit 0
-          fi
-          NEXT_HDR=$(awk 'NR>'"$UNREL_START"' && /^## \[/{print NR; exit}' "$FILE")
-          if [ -z "$NEXT_HDR" ]; then
-            NEXT_HDR=$(wc -l < "$FILE")
-            NEXT_HDR=$((NEXT_HDR+1))
-          fi
-
-          # Extract sections
-          HEADER=$(sed -n "1,${UNREL_START}p" "$FILE")
-          UNREL_CONTENT=$(sed -n "$((UNREL_START+1)),$((NEXT_HDR-1))p" "$FILE")
-          TAIL=$(sed -n "${NEXT_HDR},\$p" "$FILE")
-
-          # Prepare new Unreleased template (Keep a Changelog style) without tabs/indent issues
-          NEW_UNRELEASED=$(printf '%s\n' \
-            '' \
-            '- **Added**' \
-            '  - (placeholder)' \
-            '' \
-            '- **Changed**' \
-            '  - (placeholder)' \
-            '' \
-            '- **Fixed**' \
-            '  - (placeholder)' \
-            '' \
-            '- **Security**' \
-            '  - (placeholder)')
-
-          # Build the new CHANGELOG content
-          TMP_FILE=$(mktemp)
-          {
-            printf "%s\n" "$HEADER"
-            printf "%s\n\n" "$NEW_UNRELEASED"
-            printf "%s\n" "$VERSION_LINE"
-            # If Unreleased was empty, at least add a placeholder so the section isn't blank
-            if [ -z "$(echo "$UNREL_CONTENT" | tr -d '\n' | tr -d '[:space:]')" ]; then
-              printf "### Changed\n- (no notable changes)\n\n"
-            else
-              printf "%s\n" "$UNREL_CONTENT"
-              # Ensure a trailing newline after the inserted section
-              printf "\n"
-            fi
-            printf "%s\n" "$TAIL"
-          } > "$TMP_FILE"
-
-          mv "$TMP_FILE" "$FILE"
-
-          # Update bottom compare links
-          # Update [Unreleased] compare to start at v${VERSION}
-          COMPARE_URL="https://github.com/${GITHUB_REPOSITORY}/compare/v${VERSION}...HEAD"
-          awk -v repl="[Unreleased]: ${COMPARE_URL}" 'BEGIN{OFS=FS} { if ($0 ~ /^\[Unreleased\]: /) { print repl } else { print } }' "$FILE" > "$FILE.tmp"
-          mv "$FILE.tmp" "$FILE"
-
-          # Append a link for the new version if not present
-          if ! grep -q "^\[${VERSION}\]:" "$FILE"; then
-            echo "[${VERSION}]: https://github.com/${GITHUB_REPOSITORY}/releases/tag/v${VERSION}" >> "$FILE"
-          fi
-
-          git add "$FILE"
-          git commit -m "docs(changelog): release v${VERSION}"
-          git push
-
-      - name: Create GitHub Release from tag (first-party)
-        env:
-          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-        run: |
-          set -euo pipefail
-          TAG="${{ steps.pkg.outputs.tag }}"
-          if gh release view "$TAG" >/dev/null 2>&1; then
-            echo "Release $TAG already exists; uploading SBOM asset."
-          else
-            gh release create "$TAG" \
-              --title "Release $TAG" \
-              --generate-notes \
-              --latest
-          fi
-          # Upload/overwrite the SBOM asset on the release
-          if [ -f sbom.cdx.json ]; then
-            gh release upload "$TAG" sbom.cdx.json --clobber
-          else
-            echo "No SBOM generated; skipping upload."
-          fi
-
-      - name: Publish
-        env:
-          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
-        run: |
-          npm publish ${{ steps.pkg.outputs.flags }} --provenance

package/.github/workflows/ci.yml

@@ -1,16 +0,0 @@
-name: CI
-on:
-  push: { branches: [main] }
-  pull_request: { branches: [main] }
-jobs:
-  build-test:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-      - uses: actions/setup-node@v4
-        with:
-          node-version: "22"
-          cache: "npm"
-      - run: npm ci
-      - run: npm run build
-      - run: npm test

package/.nvmrc

@@ -1 +0,0 @@
-22

package/.vscode/launch.json

@@ -1,15 +0,0 @@
-{
-  "version": "0.2.0",
-  "configurations": [
-    {
-      "type": "node",
-      "request": "launch",
-      "name": "Debug Vitest",
-      "program": "${workspaceFolder}/node_modules/vitest/vitest.mjs",
-      "args": ["run"],
-      "cwd": "${workspaceFolder}",
-      "console": "integratedTerminal",
-      "skipFiles": ["<node_internals>/**"]
-    }
-  ]
-}

package/CHANGELOG.md

@@ -1,72 +0,0 @@
-
-# Changelog
-
-All notable changes to this project will be documented in this file.
-
-The format is based on **[Keep a Changelog](https://keepachangelog.com/en/1.1.0/)**, and this project adheres to **[Semantic Versioning](https://semver.org/spec/v2.0.0.html)**.
-
----
-
-## [Unreleased]
-
-- **Added**
-  - (placeholder)
-
-- **Changed**
-  - (placeholder)
-
-- **Fixed**
-  - (placeholder)
-
-- **Security**
-  - (placeholder)
-
-## [1.0.10] - 2025-09-17
-
-- **Fixed**
-  - CD Pipeline ordering fix for version in CHANGELOG.md 
-
-## [1.0.7] - 2025-09-17
-
-- **Added**
-  - Code coverage added.
-
----
-
-## [1.0.0] - 2025-09-16
-
-- **Added**
-
-  - Initial public release of `@plasius/react-state`.
-  - `createStore` for basic state container functionality with `dispatch`, `getState`, and subscription API.
-  - `createScopedStoreContext` for React integration:
-    - `<Provider>` component wrapping React trees,
-    - `useStore()` to access state,
-    - `useDispatch()` to dispatch actions.
-  - Support for per-key subscriptions and selector-based subscriptions.
-  - Unit tests with Vitest and component tests with React Testing Library.
-
-- **Changed**
-  - N/A (initial release)
-
-- **Fixed**
-  - N/A (initial release)
-
----
-
-## Release process (maintainers)
-
-1. Update `CHANGELOG.md` under **Unreleased** with user‑visible changes.
-2. Bump version in `package.json` following SemVer (major/minor/patch).
-3. Move entries from **Unreleased** to a new version section with the current date.
-4. Tag the release in Git (`vX.Y.Z`) and push tags.
-5. Publish to npm (via CI/CD or `npm publish`).
-
-> Tip: Use Conventional Commits in PR titles/bodies to make changelog updates easier.
-
----
-
-[Unreleased]: https://github.com/Plasius-LTD/react-state/compare/v1.0.10...HEAD
-[1.0.0]: https://github.com/Plasius-LTD/react-state/releases/tag/v1.0.0
-[1.0.7]: https://github.com/Plasius-LTD/react-state/releases/tag/v1.0.7
-[1.0.10]: https://github.com/Plasius-LTD/react-state/releases/tag/v1.0.10

package/CODE_OF_CONDUCT.md

@@ -1,79 +0,0 @@
-# Contributor Covenant Code of Conduct v2.1
-
-## Our Pledge
-
-We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.
-
-We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.
-
-## Our Standards
-
-Examples of behavior that contributes to a positive environment for our community include:
-
-- Demonstrating empathy and kindness toward other people
-- Being respectful of differing opinions, viewpoints, and experiences
-- Giving and gracefully accepting constructive feedback
-- Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience
-- Focusing on what is best not just for us as individuals, but for the overall community
-
-Examples of unacceptable behavior include:
-
-- The use of sexualized language or imagery, and sexual attention or advances of any kind
-- Trolling, insulting or derogatory comments, and personal or political attacks
-- Public or private harassment
-- Publishing others’ private information, such as a physical or email address, without their explicit permission
-- Other conduct which could reasonably be considered inappropriate in a professional setting
-
-## Enforcement Responsibilities
-
-Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful.
-
-Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for moderation decisions when appropriate.
-
-## Scope
-
-This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event.
-
-## Enforcement
-
-Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the community leaders responsible for enforcement at [conduct@plasius.co.uk](mailto:conduct@plasius.co.uk). All complaints will be reviewed and investigated promptly and fairly.
-
-All community leaders are obligated to respect the privacy and security of the reporter of any incident.
-
-## Enforcement Guidelines
-
-Community leaders will follow these Enforcement Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct:
-
-### 1. Correction
-
-**Community Impact:** Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the community.
-
-**Consequence:** A private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate. A public apology may be requested.
-
-### 2. Warning
-
-**Community Impact:** A violation through a single incident or series of actions.
-
-**Consequence:** A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban.
-
-### 3. Temporary Ban
-
-**Community Impact:** A serious violation of community standards, including sustained inappropriate behavior.
-
-**Consequence:** A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban.
-
-### 4. Permanent Ban
-
-**Community Impact:** Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals.
-
-**Consequence:** A permanent ban from any sort of public interaction within the community.
-
-## Attribution
-
-This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 2.1, available at [https://www.contributor-covenant.org/version/2/1/code_of_conduct.html](https://www.contributor-covenant.org/version/2/1/code_of_conduct.html)
-
-For answers to common questions about this code of conduct, see the [FAQ](https://www.contributor-covenant.org/faq)
-
-[homepage]: [https://www.contributor-covenant.org](https://www.contributor-covenant.org)
-
-If you have any questions or concerns regarding this Code of Conduct, please contact us at [conduct@plasius.co.uk](mailto:conduct@plasius.co.uk).

package/CONTRIBUTING.md

@@ -1,201 +0,0 @@
-# Contributing to @plasius/react-state
-
-First off: thanks for taking the time to contribute!
-This document explains how to work on the project, how to propose changes, and what we expect in pull requests.
-
-> TL;DR
->
-> - Be respectful and follow the Code of Conduct.
-> - Open an issue before large changes; small fixes can go straight to a PR.
-> - Write tests, keep coverage steady or improving.
-> - Use Conventional Commits.
-> - Don’t include real PII in code, issues, tests, or logs.
-
----
-
-## Code of Conduct
-
-Participation in this project is governed by our **Code of Conduct** (see `CODE_OF_CONDUCT.md`). By participating, you agree to abide by it.
-
-## Licensing & CLA
-
-This project is open source (see `LICENSE`). To protect contributors and users, we require contributors to agree to our **Contributor License Agreement (CLA)** before we can merge PRs (see `legal/CLA.md`). You’ll be prompted automatically by the CLA bot on your first PR.
-
-> If your company has special legal needs, please contact the maintainers before sending large PRs.
-
-## Security
-
-**Never** report security issues in public issues or PRs. Instead, follow the process in `SECURITY.md`.
-
----
-
-## What this project does
-
-`@plasius/react-state` provides a small, strongly-typed schema library:
-
-- A fluent field builder (e.g. `field().string().required()`),
-- Built-in validators for common standards (ISO/RFC/OWASP, etc.),
-- PII annotations + redaction utilities,
-- Type inference for safe, consistent entities across projects.
-
-Contributions typically fall into: new validators, field builder features, type improvements, docs, and tooling quality.
-
----
-
-## Getting started (local dev)
-
-### Prerequisites
-
-- Node.js (use the version specified in `.nvmrc` if present: `nvm use`).
-- npm (we use npm scripts in this repo).
-
-### Install
-
-```bash
-npm ci
-```
-
-### Build
-
-```bash
-npm run build
-```
-
-### Test
-
-```bash
-npm test
-# or, if using Vitest in watch mode
-npm run test:watch
-```
-
-### Lint & format
-
-```bash
-npm run lint
-npm run format
-```
-
-> Tip: set up your editor to run ESLint and Prettier on save.
-
----
-
-## How to propose a change
-
-### 1) For bugs
-
-- Search existing issues first.
-- Open a new issue with:
-  - Clear title, steps to reproduce, expected vs actual behaviour,
-  - Minimal repro (code snippet or small repo),
-  - Environment info (OS, Node, package version).
-
-### 2) For features / refactors
-
-- For anything non-trivial, open an issue first and outline the proposal.
-- If the change affects public API or architecture, add an ADR draft (see `docs/adrs/`).
-
-### 3) Good first issues
-
-We label approachable tasks as **good first issue** and **help wanted**.
-
----
-
-## Branch, commit, PR
-
-### Branching
-
-- Fork or create a feature branch from `main`: `feat/xyz` or `fix/abc`.
-
-### **Commit messages** (Conventional Commits)
-
-- `feat: add ISO-3166 alpha-3 validator`
-- `fix: correct RFC5322 email regex edge-case`
-- `docs: expand PII redaction examples`
-- `refactor: simplify field builder pipeline`
-- `test: add cases for currency code`
-- `chore: bump dev deps`
-
-### **Pull Requests**
-
-- Keep PRs focused and small when possible.
-- Include tests for new/changed behaviour.
-- Update docs (README, JSDoc, ADRs) as needed.
-- Add a clear description of what & why, with before/after examples if useful.
-- Ensure CI is green (lint, build, tests).
-
-### **PR checklist**
-
-- [ ] Title uses Conventional Commits
-- [ ] Tests added/updated
-- [ ] Lint passes (`npm run lint`)
-- [ ] Build passes (`npm run build`)
-- [ ] Docs updated (README/ADR/CHANGELOG if needed)
-- [ ] No real PII in code, tests, or logs
-
----
-
-## Coding standards
-
-- **Language:** TypeScript with `strict` types.
-- **Style:** ESLint + Prettier.
-- **Tests:** Prefer Vitest (or Jest) + `@testing-library/*` for React-facing bits.
-- **Public API:** Aim for backward compatibility; use SemVer and mark breaking changes clearly (`feat!:` or `fix!:`).
-- **Performance:** Avoid excessive allocations in hot paths; prefer immutable patterns but mind GC pressure.
-- **Docs:** Add TSDoc comments for exported types/functions.
-
-### Validators
-
-- Add tests covering common/edge cases.
-- Cite the source/standard (e.g., ISO/RFC) in comments.
-- Keep regexes readable (use `x`/comments where possible) and benchmark if complex.
-
-### PII handling
-
-- Never include real PII in fixtures or examples.
-- Ensure redaction/cleaning functions operate **before** logging.
-- Add tests confirming no PII leaks to logs or thrown errors.
-
----
-
-## Adding dependencies
-
-- Minimise runtime dependencies; prefer dev dependencies.
-- Justify any new runtime dependency in the PR description (size, security, maintenance).
-- Avoid transitive heavy deps unless critical.
-
----
-
-## Versioning & releases
-
-- We follow **SemVer**.
-- Breaking changes require a major bump and migration notes.
-- Keep the `CHANGELOG.md` (or release notes) clear about user-facing changes.
-
----
-
-## Documentation
-
-- Update `README.md` with new features or setup steps.
-- Add or update ADRs in `docs/adrs/` for architectural decisions.
-- Keep examples minimal, copy-pasteable, and tested when feasible.
-
----
-
-## Maintainers’ process (overview)
-
-- Triage new issues weekly; label and assign.
-- Review PRs for correctness, tests, and docs.
-- Squash-merge with Conventional Commit titles.
-- Publish from CI when applicable.
-
----
-
-## Questions
-
-If you have questions or want feedback before building:
-
-- Open a discussion or issue with a short proposal,
-- Or draft a PR early (mark as **Draft**) to get directional feedback.
-
-Thanks again for contributing 💛

package/CONTRIBUTORS.md

@@ -1,27 +0,0 @@
-# Contributing Guidelines
-
-Thank you for considering contributing to this project! We welcome contributions that improve the code, documentation, and overall project quality.
-
-## Getting Started
-
-- Fork the repository.
-- Create a feature branch from `main`.
-- Commit your changes with clear messages (we follow **Conventional Commits**).
-- Push your branch and open a Pull Request (PR).
-
-## Requirements
-
-- Write tests alongside code where possible.
-- Ensure all tests pass before submitting a PR.
-- Follow the repository’s coding style and linting rules.
-- Update documentation (README, ADRs, etc.) when making significant changes.
-- When making architectural changes, create a new ADR (Architecture Decision Record) that **succeeds** the previous one rather than modifying old ADRs. This preserves history and ensures decisions are traceable.
-- Use the [ADR template](./docs/adrs/adr-template.md) when writing new ADRs to ensure consistency.
-- Before your first contribution, sign the appropriate Contributor License Agreement (CLA). See [legal/CLA.md](legal/CLA.md) for details, then email the signed document to [contributors@plasius.co.uk](mailto:contributors@plasius.co.uk).
-
-## Communication
-
-- Use GitHub Issues for bugs and feature requests.
-- Pull Requests should describe the problem, solution, and trade-offs.
-
-We appreciate your support in making this project better!

package/SECURITY.md

@@ -1,17 +0,0 @@
-# Security Policy
-
-## Supported Versions
-
-We currently support the latest major version of this project. Older versions may not receive security updates.
-
-## Reporting a Vulnerability
-
-If you discover a security vulnerability, please report it privately by emailing us at [security@plasius.co.uk](mailto:security@plasius.co.uk). Please do not create a public issue for security-related matters.
-
-## Response Timeline
-
-We aim to acknowledge your report within 2 business days and to provide a more detailed response (including next steps and, if applicable, a timeline for a fix) within 7 business days.
-
-## Disclosure Policy
-
-We request that you give us the opportunity to address the vulnerability before publicly disclosing it. We will coordinate with you on public disclosure once a fix is available and deployed.

package/docs/adrs/adr-0001: React store.md

@@ -1,42 +0,0 @@
-# ADR-0001: React State Store Purpose and Scope
-
-## Status
-
-- Proposed → Accepted
-- Date: 2025-09-12
-- Version: 1.0
-- Supersedes: N/A
-- Superseded by: N/A
-
-## Context
-
-Managing React application state across multiple components is a common challenge. Existing solutions (Redux, Zustand, Jotai, etc.) offer different trade-offs in complexity, ergonomics, and bundle size. For the Plasius ecosystem, we want:
-
-- A minimal, type-safe state container,
-- Strong integration with React via Context and Hooks,
-- Support for both global and scoped stores,
-- Predictable subscription and unsubscribe behaviour,
-- Alignment with SOLID principles and enterprise-grade maintainability.
-
-## Decision
-
-We will build a dedicated library, `@plasius/react-state`, that:
-
-- Provides a `createStore` primitive for basic state containers,
-- Provides `createScopedStoreContext` to integrate with React Context/Provider patterns,
-- Exposes hooks (`useStore`, `useDispatch`) to read state and dispatch actions,
-- Supports subscriptions: global, per-key, and selector-based,
-- Ensures distinct-until-changed semantics to avoid unnecessary re-renders,
-- Is published as an open source package under the Plasius-LTD organisation.
-
-## Consequences
-
-- **Positive:** Consistent and predictable state handling across Plasius projects, type-safe APIs, lighter alternative to Redux, improved testability, open source adoption possible.
-- **Negative:** Adds maintenance burden to keep feature parity with evolving React ecosystem; community may default to established libraries.
-- **Neutral:** Internal consumers may still choose other state management libs if required, but Plasius packages will standardise on this one.
-
-## Alternatives Considered
-
-- **Use Redux or Redux Toolkit:** Very mature, but verbose and heavier than desired.
-- **Use Zustand or Jotai:** Good ergonomics, but external dependency risk and less control over PII handling and subscription semantics.
-- **React Context alone:** Too minimal, lacking structured dispatch and subscribe/unsubscribe APIs.