v0.16.0

Minor Changes

• 253086d: Add opt-in absolute (path-alias) import enforcement: createRecommendedVitePlusConfig({ absoluteImports: { files } }) appends an Oxlint override scoping import/no-relative-parent-imports to the given globs, and createAbsoluteImportsOxlintOverride exposes the same override for standalone Oxlint configs.

• 45ff273: Share skill-source and Effect-source downloads through a machine-global cache.

  Catalog source checkouts now materialize into $XDG_CACHE_HOME/dev-kit
  (~/Library/Caches/dev-kit on macOS, ~/.cache/dev-kit elsewhere, overridable
  with DEV_KIT_CACHE_DIR) keyed by source id and resolved commit SHA, instead
  of the per-project .dev-kit/cache. A fresh git worktree with the same pinned
  sources applies without any network access, and dev-kit plan no longer
  re-fetches catalog sources on every run — the dry-run path reads and populates
  the same cache. Cache population stages into a temp sibling and renames
  atomically, so concurrent applies from different worktrees are safe. Because
  entries are immutable and commit-keyed, populating the cache is not project
  state; planning and --locked verification use it without violating their
  read-only project semantics.

  The setup.effectSource checkout keeps its per-project .repos/effect
  working copy but clones and fetches tags from a shared cached repository in
  the same global cache, contacting the network only when a tag is missing from
  the cache.

  The cache does not grow without bounds. Every use refreshes a recency stamp;
  dev-kit apply sweeps content unused for 30 days at most once a day, dropping
  stale catalog entries and unused Effect tags (removing a shared repository
  entirely once it holds no tags). The new dev-kit cache prune command sweeps
  on demand, with --max-age-days to tune the threshold and --all to clear
  the cache entirely. Eviction is always safe: entries are regenerable and are
  re-fetched on next use.

  Stale project-local .dev-kit/cache/catalog directories left by earlier
  versions are removed on apply (best effort); they were regenerable and are no
  longer read.

• 129e052: Split the consumer half of build-effect-apis into a new effect-atom-state skill so client-side work actually triggers it.

  • New effect-atom-state skill owns Effect Atom client state and React integration: deriving AtomHttpApi/HttpApiClient clients, query/mutation atoms, reactivity keys, Atom.fn workflows, optimistic updates, lifecycle, testing, and TanStack Start. Its description triggers on writing or refactoring React components that read or dispatch atoms — the case the old server-flavored description never matched. The skill body carries the Effect→Promise boundary doctrine: business logic stays in Effect, promise-mode dispatches are returned bare to promise-shaped leaf components, multi-step workflows compose atoms through the fn context, cross-query invalidation is declared as reactivity keys, and optimistic state lives in Atom.family atoms.
  • build-effect-apis keeps the contract spine and server: shared contracts, handlers and middleware, runtime assembly, Cloudflare Workers, and verification. It routes consumer changes to $effect-atom-state. The effect family now installs both.
  • setup.agentInstructions renders a terse Effect Atom client boundary section into the managed AGENTS.md when the project (or one of its workspace packages) depends on @effect/atom-react.