Starterkit Larawire Agentic Laravel Package

Product Decisions This Supports

• In-product branding self-service: The new dependency-free Canvas crop workflow (800×200 logos, 256×256 favicons, PNG-only export) turns "upload a logo" from an engineering ticket into a user-completable task. This directly supports decisions to ship tenant/workspace branding, white-label configurations, and self-serve onboarding without building a custom image pipeline.
• Build vs. buy on asset handling: Because cropping, zoom, keyboard/pointer positioning, contain/cover modes, and accessible modals now ship in the package, the "build" option for logo/favicon editing collapses to configuration plus host-owned view overrides. That reframes the decision from "do we staff an editor sprint?" to "do we accept the package's crop UX and validation envelope?"
• Feature investment where differentiation actually lives: Accepting PNG, JPG, and WebP sources up to 10 MB / 8192 px per side / 32 MP, with authoritative server validation unchanged, means the package owns input normalization and the guardrailed upload lifecycle (submission guarded during decode/crop/upload, retryable failures, cancel preserving saved and pending assets). PM effort redirects to workflow and policy rather than file plumbing.
• Roadmap sequencing for design-system parity: Explicit support across DashCode, Tabler, and Vuexy, plus removal of decorative backgrounds/borders/shadows from navigation logos so transparency renders unchanged, signals the package is tracking theme parity as a first-class concern. Teams running multiple admin themes can plan a single branding feature rather than per-theme variants.
• Risk posture on upgrades: A backward-compatible minor with no migrations, dependency additions, env vars, or runtime ZIP changes, plus an explicit rollback pin to 1.8.0, makes this cheap to slot into a maintenance window. Low upgrade cost raises the priority of adopting it now versus deferring.
• Use cases this unlocks: tenant branding setup, brand-safe favicon generation, agency/client handoff templates, starter-kit resale with per-client identity, and admin-console theming for multi-brand portfolios.
• Governance decision: The package's starter:sync / starter:views-* / starter:deploy model makes "who owns the views" an explicit product decision. The release's emphasis on reviewing host-owned overrides with --dry-run before any replacement forces a documented override policy — a worthwhile artifact regardless of adoption.

When to Consider This Package

Adopt when:

• You are on a Laravel + Livewire stack using one of the supported admin themes (DashCode, Tabler, Vuexy) and would otherwise hand-roll logo/favicon upload.
• Branding or white-labeling is on the roadmap and you want logo/favicon editing without adding an image-cropping JS dependency.
• You want a fixed, predictable output contract (single approved PNG at 800×200 or 256×256) rather than arbitrary user-supplied dimensions.
• Accessibility is a requirement — theme-native modals with keyboard positioning are included, not bolted on.
• You can live with a host-owned view override workflow (starter:views-status, starter:views-replace --dry-run) and will commit the override review to your release checklist.
• Your deployment discipline can honor the documented path: composer install --no-dev --optimize-autoloader plus starter:deploy in production, and never starter:sync against production.

Look elsewhere, or defer, when:

• You need SVG logos, animated assets, or formats beyond PNG/JPG/WebP, or export sizes other than 800×200 and 256×256.
• Your sources routinely exceed 10 MB, 8192 px per side, or 32 MP — the client will reject them before upload, and the server-side limits are unchanged, so oversized-asset workflows stay unsupported.
• You run an admin theme outside the three supported ones; the canvas workflow's styling is theme-native, so parity is not guaranteed.
• You require server-side re-cropping or audit of the crop region — only the approved PNG is submitted, so the crop decision is client-side and the server sees the result, not the intent.
• You cannot maintain a view-override review process. Merging business customizations before explicit replacement is a manual, recurring obligation; teams without that discipline will accumulate silent drift.
• You need a stable API surface for deep integration; this is a starter-kit/scaffolding package with an opinionated sync model, not a general media library.

How to Pitch It (Stakeholders)

To executives: This minor release closes the last gap that made branding a engineering task. Users can now crop and approve their own logo and favicon in-product — no new dependency, no migration, no infrastructure change, and a one-line rollback if anything misbehaves. It converts a recurring services cost into a self-serve capability and de-risks our white-label roadmap. Upgrade cost is a maintenance-window item, not a project.

To engineering: Dependency-free Canvas cropping with pointer and keyboard positioning, contain/cover modes, and accessible theme-native modals. Client exports a single approved PNG (800×200 logo, 256×256 favicon) before Livewire upload; profile submission is guarded through decode, crop, and upload, cancel preserves both saved and pending assets, and failed uploads stay retryable. Server-side validation is untouched — this is purely a better front door. Accepted inputs are PNG/JPG/WebP up to 10 MB, 8192 px per side, 32 MP. Upgrade is composer update, starter:sync, then a disciplined pass on host-owned overrides via starter:views-status and starter:views-replace --dry-run — merge customizations before any explicit replacement. Production uses composer install --no-dev --optimize-autoloader plus starter:deploy; do not run starter:sync in production. Rollback is a pin to 1.8.0 and the standard install/sync path.

To design and support: Logos now render exactly as uploaded — decorative backgrounds, borders, and shadows have been stripped from navigation logos, so transparency survives. Support gets a clear story for failed uploads (retryable, nothing lost) and cancelled edits (saved and pending assets preserved). Expect questions about accepted formats and size ceilings; document the 10 MB / 8192 px / 32 MP limits and the PNG-only output up front to preempt them.

Ask: Approve the upgrade in the next maintenance window with one owner assigned to the host-override dry-run review, and confirm the documented production deploy path is what our pipeline actually runs.