Fix/dependency vulnerabilities

.codex-kit-state.json

@@ -1,9 +1,9 @@
 {
   "version": 1,
   "template": {
-    "availableHash": "fcb414d590e1fe1333f365a1f7fd0df4f2eaed249465c9e2c0e5849712b1cccf",
-    "availableVersion": "1.0.18",
-    "appliedHash": "fcb414d590e1fe1333f365a1f7fd0df4f2eaed249465c9e2c0e5849712b1cccf",
-    "appliedAt": "2026-07-26T11:14:37.996Z"
+    "availableHash": "f6a02cb2b17078ae108000975e2c2105b6e208e8f7cfeeb19e1765fb52d39b81",
+    "availableVersion": "1.1.5",
+    "appliedHash": "f6a02cb2b17078ae108000975e2c2105b6e208e8f7cfeeb19e1765fb52d39b81",
+    "appliedAt": "2026-08-14T05:46:22.901Z"
   }
 }

AGENTS.md

@@ -17,6 +17,13 @@
   and colocate tests in `<kebab-case-name>.test.ts`.
 - Match nearby source, JSDoc, and test patterns. Biome formatting uses two
   spaces, single quotes, semicolons, and an 80-column line width.
+- Name domain values and helpers by intent. Keep casing consistent in code-owned
+  representations; preserve external names at the boundary and map them once.
+  Comment only non-obvious constraints, invariants, tradeoffs, or workarounds.
+- Name constants for domain rules, limits, durations, units, and protocol
+  values; keep obvious indexes and empty-state literals inline. For repeated
+  closed-set runtime values, use one immutable source and derive TypeScript
+  types from it.
 - `src/index.ts` is generated by `pnpm run generate-index`; do not hand-edit it.
   A public utility's directory and source filename must match for the generator
   to include it.
@@ -29,7 +36,10 @@
 
 - Match existing structure and reuse existing types and helpers. Keep changes
   minimal, localized, and limited to the requested behavior.
-- Add or update the smallest focused colocated Vitest tests for behavior changes.
+- Add or update focused colocated Vitest tests for changed contracts,
+  regressions, and meaningful boundaries, using one representative case per
+  equivalent behavior. Preserve existing assertions unless behavior
+  intentionally changes; skip redundant and implementation-detail cases.
 - After adding, updating, moving, or removing source code, use the project
   `$verify-source-changes` skill to determine the next SemVer version, update
   `docs-md/changelog.md`, regenerate documentation and exports, then inspect

TEMPLATE_AGENTS.md

@@ -92,6 +92,14 @@ conditional procedures into validated project skills.
 - Reuse existing constants, schemas, enums, shared types, and components before
   creating duplicates. Add reusable domain values at their existing source of
   truth instead of scattering magic strings.
+- Replace numeric literals that encode domain rules, limits, durations, units,
+  or protocol values with descriptively named constants. Universally obvious
+  structural values, such as basic indexes or empty-state values, may remain
+  inline.
+- Promote repeated closed-set domain values used in production control flow to
+  feature-owned immutable runtime constants. Where the language supports it,
+  derive static types from that runtime source; keep incidental presentation,
+  browser, protocol, route, environment, and test-contract strings inline.
 
 ## Project Discovery
 
@@ -100,18 +108,53 @@ conditional procedures into validated project skills.
   Do not assume tools from other projects.
 - Keep discovered stack-specific guidance in the project's
   `# Project-Specific Instructions`, not in this shared template.
+- For user-facing work, perform a UI/style preflight before editing: inspect the
+  closest same-purpose shipped features (especially tables, filters, search,
+  forms, dialogs, and page layouts) and identify their design-system primitives,
+  tokens, spacing, typography, responsive behavior, interactions, states, and
+  accessibility conventions. Reuse applicable components and patterns.
+- For new or materially changed user-facing interfaces, preserve accessibility
+  as a baseline: prefer semantic elements and native controls; provide accessible
+  names, labels, instructions, errors, and state; support keyboard operation,
+  logical focus order, visible focus, and appropriate focus management; provide
+  meaningful text alternatives; maintain readable typography and sufficient
+  contrast; and never rely on color alone to communicate meaning. Use ARIA only
+  when native semantics are insufficient, and keep ARIA roles, properties, and
+  states valid and synchronized with behavior.
+- When practical, verify changed interaction paths with the repository's
+  accessibility tooling and a manual keyboard/focus check. Report any unavailable
+  checks or known limitations.
+- If no written standard exists but trustworthy repeated precedent does, derive
+  concise durable guidance in the project: always-on conventions belong in
+  `AGENTS.md`; feature-specific decisions and approved exceptions belong in
+  `PLANS.md`. During development, keep new UI aligned with that standard.
+- Pause and ask the user whether to keep, update, or override the standard
+  before deliberate visual divergence, changing an established guideline,
+  resolving conflicting precedents, or proceeding without a trustworthy
+  analogue. Include the evidence and affected pattern in the question.
+- If browser or screenshot tooling exists, compare the rendered feature with
+  the analogue across relevant responsive sizes and states. Otherwise, report
+  that rendered comparison was unavailable.
 
 ## Commands And Verification
 
 - Avoid broad commands. After changes, run the smallest targeted verification
   that meaningfully validates them when practical, then report the command and
   result. Use the repository's documented package manager and scripts.
-- For behavior changes and bug fixes, add or update the smallest focused
-  automated tests that meaningfully prevent regression when the repository has
-  an established test setup.
-- Do not introduce a test framework or create low-value tests solely to satisfy
-  this rule. If automated coverage is impractical, explain why and perform the
-  strongest targeted verification available.
+- Select tests for regression value rather than exhaustive coverage. When the
+  repository has an established test setup, cover changed observable contracts,
+  reported regressions, meaningful boundaries, and plausible costly failures,
+  especially security, trust-boundary, or data-loss risks.
+- Use one representative case per equivalent behavior class. Skip redundant
+  permutations, implementation-detail assertions, and contrived or unreachable
+  states unless a requirement or past defect justifies them.
+- Treat existing tests as regression contracts. Preserve their assertions unless
+  the requested behavior intentionally changes. When behavior changes, update
+  only the affected tests and add coverage for the new contract; never weaken or
+  delete tests merely to make the suite pass.
+- Do not introduce a test framework solely to satisfy this rule. If automated
+  coverage is impractical, explain why and perform the strongest targeted
+  verification available.
 - Run the relevant focused tests after changing tested behavior.
 - When adding or updating dependencies, pin exact versions rather than ranges.
   With pnpm, use `pnpm add -E` (`--save-exact`).
@@ -121,20 +164,63 @@ conditional procedures into validated project skills.
 
 ## Structure
 
-- Follow the repository's organization and naming. Prefer focused files and
-  split mixed responsibilities when readability improves.
-- Keep route and page files focused on page-level composition, data loading, and
-  orchestration. Extract substantial self-contained UI sections and complex
-  page-specific logic into colocated feature components or modules. Keep small
-  one-use markup inline; do not create components solely to reduce line count.
+- Follow the repository's organization and naming. Organize feature-specific
+  code under the feature's existing directory; when a feature contains multiple
+  substantial UI pieces, place them in a `<feature>/components` subdirectory.
+  Keep broadly reused code in the repository's established shared locations.
+- Complete every new or materially changed feature through a semantic pass:
+  implement and stabilize it, map each responsibility to its final file, extract
+  independently understandable concerns, validate the decomposed implementation,
+  then hand it off to `code-reviewer`. Pages, routes, controllers, commands, and
+  entrypoints contain composition and orchestration only. Web page files may keep
+  framework exports, metadata, loading, guards, page-level state, minimal layout
+  wrappers, and imported child composition, but not child components, substantial
+  UI sections, or domain logic. Independently changeable UI concerns (tables,
+  filters, forms, dialogs, and sections) belong in descriptive feature-local
+  component files. Hooks, schemas, data access, transformations, and domain logic
+  move out of presentation files when independently testable or when they obscure
+  the component's primary responsibility. Avoid generic `utils`, `helpers`, or
+  `components` dumping grounds; filenames must identify owned behavior. Keep
+  components feature-local by default; promote them to shared/design-system
+  locations only when reused across features or explicitly global primitives.
+  Tiny private helpers or markup may remain inline only when inseparable from the
+  file's single responsibility. Do not broaden an unrelated small fix, but leave
+  any new or materially changed feature decomposed. Every completed feature gets
+  an automatic `code-reviewer` structure review; exceptions require a concrete
+  framework or tooling constraint identified in the handoff.
 - Use intent-revealing domain names. A reader should understand what a variable
   contains or what a helper guarantees at the call site without opening its
   implementation. Avoid vague transformation names such as `normalized`,
   `processed`, `result`, or `data` when a value- or behavior-specific name is
-  available.
+  available. Prefer clear structure, and simplify or extract complex logic before
+  relying on comments. Use comments to explain non-obvious purpose, constraints,
+  invariants, tradeoffs, or workarounds, not to narrate statements.
+- Keep naming conventions consistent within each code-owned object, schema,
+  type, and module. Do not mix identifier casing styles in the same
+  representation unless required by an external contract or framework.
+  Preserve externally defined names at the boundary, then map them once to the
+  project's internal convention.
 - Do not reorganize feature directories, shared modules, routes, server
   boundaries, schemas, or state patterns unless requested and approved.
 
+## React And React Native TypeScript Naming
+
+- In React, React Native, and Expo projects using TypeScript, use `kebab-case`
+  for code-owned file and directory names. Preserve framework-mandated and
+  contract-derived names, including Expo Router notation and React Native
+  platform suffixes such as `.ios.tsx`, `.android.tsx`, and `.native.tsx`.
+- Use `PascalCase` for components, context providers and consumers, type aliases,
+  interfaces, and enums.
+- Use `camelCase` for functions, variables, props, state, and code-owned object
+  properties.
+- Name custom hooks as `useThing`, higher-order components as `withThing`, and
+  local event-handler functions as `handleThing`. Name callback props with `on`,
+  such as `onSubmit`.
+- Prefix boolean props, state, and variables with `is`, `has`, or `should`
+  when the prefix accurately describes their meaning.
+- Use `UPPER_SNAKE_CASE` for module-level constants and enum members. Keep
+  ordinary local `const` bindings in `camelCase`.
+
 ## Data And Validation
 
 - Update schemas first, then generate migrations or derived types. Never edit

docs-md/changelog.md

@@ -5,6 +5,9 @@ id: changelog
 
 # Changelog
 
+##### 4.4.1
+
+- Fix vulnerability issues
 
 ##### 4.4.0
 
@@ -15,6 +18,7 @@ id: changelog
 - Fix API documentation generation for utilities with TypeScript imports
 
 ##### 4.3.4
+
 - Trying to fix some publish workflow issue
 - Some changes to bundling
 - Replace eslint and prettier with biome

package.json

@@ -1,6 +1,6 @@
 {
   "name": "common-utils-pkg",
-  "version": "4.4.0",
+  "version": "4.4.1",
   "description": "A package of commonly used JavaScript utilities.",
   "keywords": ["utilities", "npm", "module", "javascript", "es6", "functions"],
   "homepage": "https://common-utils-pkg.js.org/",