Core Laravel Package

Product Decisions This Supports

• Build vs. buy for admin/CMS layer on Laravel: cms-orbit/core (with the orbit:frontend-sync command) sits in the "buy/adopt" bucket for the CMS scaffolding + TypeScript frontend bridge. 4.6.2 is a maintenance release — it does not change the buy calculus, but it does remove a class of integration breakage that would otherwise push teams toward custom in-house glue.
• Frontend toolchain ownership: The package now writes bare aliases (packages exposing index.ts/index.tsx/index.js) into tsconfig.json, not just explicit subpath aliases. This means custom component registration imported directly from @cms-orbit/core resolves cleanly. Relevant to any roadmap item that lets product/ops teams register custom components without engineering involvement.
• Onboarding and time-to-first-screen: Every alias the sync command writes automatically is a manual setup step engineering does not have to document or hand-maintain. Fewer "add these paths to your tsconfig" steps in the setup guide translates directly into reduced integration time per new app.
• Documentation reliability as a quality signal: 4.6.1 shipped the alias fix only in the manual guidance block while auto-sync lagged behind. 4.6.2 unifies both on the same path-generation function. This is a governance point: when automated output and documented output diverge, support tickets and "the docs are wrong" complaints follow. Worth tracking as an ongoing quality metric for the package maintainers.
• Environment/runtime matrix: The package declares laravel/octane as a suggest (now actually present, having been omitted from the 4.6.1 metadata). If your roadmap includes Octane for throughput, this confirms Octane is supported-but-optional — factor it into hosting and capacity planning rather than assuming it.
• Not a roadmap feature release: 4.6.2 adds no new product capabilities. Do not treat it as a milestone; treat it as a hygiene upgrade to schedule.

When to Consider This Package

Adopt / upgrade to 4.6.2 when:

• You are on 4.6.1 or earlier and you register custom components imported directly from @cms-orbit/core — the bare-alias bug (#9) causes TypeScript module resolution errors that will surface as failing builds or red squiggles in editors for your team.
• Your app's tsconfig.json is generated or path-managed by tooling and you want the auto-sync and the manual instructions to agree (4.6.2 fixes the drift introduced by 4.6.1).
• You are standardizing on a Laravel CMS/admin layer and want the TypeScript path wiring to be a solved, non-hand-maintained problem.
• You are evaluating Octane and want the package's official position (it is a suggest, i.e. optional and not required).

Look elsewhere or defer when:

• Your frontend does not use TypeScript path aliases, or you do not use the orbit:frontend-sync command at all — this release is inert for you; upgrade at your normal cadence.
• Your tsconfig.json is hand-maintained with comments (JSONC). The command writes its output but you must manually copy the emitted paths in; there is no automatic merge. If you cannot tolerate a manual step, that is a workflow constraint to accept or work around, not something 4.6.2 removes.
• You need the sync command to be idempotent and comment-preserving in-place — verify against your own config before committing to the upgrade; the release notes explicitly delegate commented configs back to a manual step.
• You are evaluating the package for the first time and need evidence of feature velocity — this release is a bug-fix patch plus bookkeeping (merging a stray 4.6.1 branch history into main, tags preserved). It says nothing about the roadmap.

Upgrade instruction for engineering: composer update cms-orbit/core, then php artisan orbit:frontend-sync. Committed tsconfig.json with comments must have the emitted paths applied by hand. Low risk: the changes are alias generation, a suggest entry, and branch hygiene; PHP 8.4/8.5 tests, Pint, and the TypeScript CI all pass.

How to Pitch It (Stakeholders)

For executives (30 seconds): A small maintenance release for our Laravel CMS package. It fixes a bug that broke TypeScript resolution for teams registering custom components, and it makes the automated setup match the written setup instructions again. No new features, no breaking changes, no cost. It is a routine "stay current, avoid papercut bugs" update — recommend we take it at the next maintenance window.

For engineering leads: 4.6.2 closes the gap where orbit:frontend-sync failed to write bare aliases for packages exposing index.ts/index.tsx/index.js into tsconfig.json — this was the root cause of the @cms-orbit/core module-resolution errors reported in #9. It also refactors auto-sync and the manual guidance block onto a single path-generation function so the two can no longer disagree, which was the residual defect from 4.6.1. The laravel/octane suggest that was documented in 4.6.1 but missing from composer.json is now actually declared. Release history for 4.6.1 was merged into main with tags intact — no action needed. Upgrade path is composer update plus php artisan orbit:frontend-sync; hand-apply emitted paths if your tsconfig.json contains comments. Verified on PHP 8.4 and 8.5, Pint clean, TypeScript CI green. Verdict: safe, recommended, low urgency.

For product: Treat this as unblocking, not capability-adding. The practical win is that teams following the setup docs and teams relying on the automated sync now land in the same state — fewer "my component won't resolve" support threads during onboarding. No demo-able surface area changed; do not schedule release communications beyond the standard changelog.