Product Decisions This Supports

Build vs. buy for settings/secrets management: Adopt the package instead of building encrypted settings storage, panel bindings, JSON endpoints, and CLI export/list. v2.0.1 hardens the boundary: encrypted values are write-only outside application code, so the package can be used in admin-facing surfaces without leaking secrets.
Feature: secure settings screens. The new filled and encrypted panel fields enable “configured / not configured” UX for secrets. Product can ship admin screens where users set or rotate secrets without ever seeing the stored value; removal is explicit via DELETE /settings/me/{key}.
Roadmap: security and compliance. The release supports secret-handling controls: panel/JSON endpoints return null for encrypted values, JSON ignores null/empty values to prevent accidental wipes, settings:export skips secrets unless --with-secrets, and settings:list masks values. These are evidence points for SOC2/ISO-style reviews.
Use cases: per-user API keys, SMTP/third-party tokens, tenant settings, global defaults with per-model overrides, Blade/Livewire/SPA settings pages, and CLI ops export/list.
Decision: For Laravel products exposing settings via panel or JSON API, require v2.0.1+ and design secret fields as write-only. Avoid prefilled secret values; use filled to indicate presence and only submit when the user types a new value.

When to Consider This Package

You are building on Laravel and need typed, persistent settings with global and per-model scopes.
You need encrypted-at-rest settings and a safe admin/panel or JSON surface where secrets are never returned.
You want ready-made CLI commands (settings:export, settings:list) with safe defaults for secrets.
You plan Blade, Livewire, or SPA settings screens and can follow the package’s new guide.
You need explicit secret removal semantics and protection against accidental wipes when saving unchanged panels.
Look elsewhere if: you need a dedicated secrets manager (Vault, AWS Secrets Manager) with rotation/leases; you need remote config/feature flags with targeting and analytics; you are not on Laravel; you need customer-managed encryption keys beyond Laravel’s encrypter; or you only need static config values that Laravel config files already cover.

Executives: This package cuts build time and security risk for settings and secrets. v2.0.1 fixes a leak where encrypted values could be exposed through admin panels and JSON endpoints. Secrets are now write-only outside application code, export is gated, and list output is masked. That supports compliance and reduces the chance of accidental disclosure. Adoption cost is low for Laravel teams.
Engineering: Upgrade to v2.0.1+ if you use encrypted settings with panel(), JSON endpoints, or settings:export. Update any settings UI that displayed decrypted values: use filled/encrypted flags, render “configured” state, and only send a new value when the user types one. get() still returns decrypted values in code. Use DELETE /settings/me/{key} for explicit removal. Restrict access to settings:export --with-secrets.
Product/Design: Treat secret fields as write-only. Show presence via filled, never prefill the secret, and provide an explicit “remove” action. This prevents accidental wipes and aligns UX with the new security model.
Security/Compliance: Document that encrypted settings are not returned by panel/JSON/export by default. Log and restrict --with-secrets usage. Treat v2.0.1 as the minimum version for any product exposing settings to users or APIs.