Jetstream–Fortify integration boundary: repairing published scaffolding after a partial upgrade desynchronizes the auth backend

Jetstream publishes Livewire or Inertia scaffolding into the application, while Fortify owns authentication routes and feature toggles through config/fortify.php. A failed upgrade can leave the vendor package advanced while published views, the service provider registration, or Fortify's enabled features remain at the previous state, producing missing routes or broken links.

The documented install command, php artisan jetstream:install, is the only supported path for materializing those files, but it is not presented as idempotent. It may prompt to overwrite customized components and does not remove files that a newer version dropped, so stale scaffolding can survive. Fortify's config is similarly not guaranteed to reconcile automatically if defaults change between versions.

Because the published files live in the application rather than in vendor/, Composer cannot restore them. The unresolved decision is whether re-running the installer is a safe repair mechanism for a Jetstream–Fortify mismatch, or whether it risks compounding drift by mixing old and new published artifacts.

What is the supported boundary for recovering a desynchronized Jetstream–Fortify state without switching stacks? Does re-running jetstream:install restore contract consistency between published UI components and Fortify's auth routes, or must the published files be manually diffed against the installed stubs? How should config/fortify.php be reconciled when feature defaults change during a partial upgrade?