Kickoff Laravel Package

Technical Evaluation

Architecture fit

• Kickoff is a Laravel application scaffold/starter kit rather than a drop-in library: adopting 1.39.0 means taking a baseline of the whole app skeleton (config, deploy scripts, Docker, CI, seeders, auth views), not a composable dependency. TPM framing: treat this as a platform baseline upgrade, not a package bump.
• The release is explicitly a hardening pass sourced from a 113-draft / 81-devlog review, so the value is concentrated in security posture, deploy correctness, and test guardrails — exactly the areas a TPM can defend to security review and audit.
• It introduces companion package coupling: laravel-config-sso ^1.1 and laravel-config-webhook ^1.1 are required for the new SSO-claim and webhook-signing semantics. This is a coordinated multi-repo release, which raises release-management overhead.

Integration feasibility

• Hard gate: PHP 8.5+ required for Kickoff and generated apps; generated apps pin Node 26. Teams on PHP 8.4 are explicitly parked on 1.38. Feasibility therefore reduces to "can we move the runtime?" — not "can we install the package?"
• Upgrade path is documented and tool-assisted: kickoff-patch skill, re-publish media-manager-views, QUEUE_CONNECTION=redis + scheduler cron, and the CACHE_DRIVER → CACHE_STORE rename. That is a finite, enumerable checklist, which is favourable for planning.
• Several fixes repair things that were silently broken rather than merely suboptimal (see risk).

Technical risk

• PHP 8.5 / Node 26 are leading-edge runtimes. Ecosystem compatibility (Horizon, queue workers, image/native extensions, CI images) is the primary schedule risk and should be timeboxed as a spike before commitment.
• Deploy script was not running operations at all. 1.39.0 notes operations --isolated (--force never existed — operations did not run). Any app deployed on ≤1.38 should assume post-deploy operations were skipped; retro-verification of past releases is warranted.
• Backups may have been unverified and GPG failures swallowed. bin/backup-db now verifies archives and exits non-zero on GPG failure — implying earlier runs could report success while producing unusable artifacts. Restore-test historical backups before relying on them.
• php artisan optimize failed on two-factor installs (non-existent <x-input-otp>) — production optimisation was unavailable for a subset of apps.
• Behavioural changes with user-visible blast radius:
  • SSO: an unverified email match is now claimed with credentials revoked instead of handed over — an account-takeover mitigation, but it will generate support tickets for legitimately matching users.
  • Webhooks now send exactly the signed bytes and refuse private/metadata hosts — SSRF protection, but consumers that relied on re-serialised payloads may break.
  • Docker services bound to 127.0.0.1 and no production wildcard trusted proxies — will break remote-dev, CI service containers, and any proxy-terminated deployment until config/trustedproxy.php is populated.
• Strict Eloquent (lazy loading / discarded attributes) outside production can turn latent N+1s into hard failures in dev and CI — good hygiene, but a short-term velocity hit.

Key questions

1. What is the support window for 1.38 — security-only backports, and for how long? Is there a 1.38.x for CVE-class fixes?
2. Is the SSO email-claim change considered breaking, and is there a comms/migration note for existing federated users?
3. Are webhook payload bytes identical to what ≤1.38 signed, or does signature verification change for consumers?
4. Do the laravel-config-sso / laravel-config-webhook ^1.1 releases ship independently, and what is the minimum-version pin strategy?
5. Is operations --isolated available in the ops CLI version we run — and what is the rollback contract ("honest rollback")?
6. Does the composed CSP cover every third-party origin our product adds (support chat, error tracking, A/B tooling) or do we own an extension point?

Integration Approach

Stack fit

• Target: Laravel app on PHP 8.5, Node 26 (.nvmrc + engines.node), Redis for QUEUE_CONNECTION, Horizon for workers, scheduler via routes/console.php, Docker with loopback-bound services, GPG-backed DB backups.
• If the platform is on PHP 8.4, the fit is conditional: stay on 1.38 (with the known deploy/backup gaps documented as accepted risk) until the runtime upgrade lands.
• The CSP is composed from origins Kickoff views load (fonts, GTM/GA, g8desk) — clean for greenfield, but any existing app with extra third-party scripts must extend it deliberately.

Migration path

1. Runtime first: PHP 8.5 + Node 26 in CI, Docker base images, and hosting. Validate Horizon, queue workers, and native extensions before touching Kickoff.
2. Pin and branch: composer require 1.39.0 on a dedicated upgrade branch; keep 1.38 as the rollback artefact.
3. Run kickoff-patch to reconcile the skeleton diff (config, supervisord.ini placeholder fix, withEvents(discover: false), seeder changes).
4. Env cutover: rename CACHE_DRIVER → CACHE_STORE; set QUEUE_CONNECTION=redis; verify no stale keys remain in staging config.
5. Re-publish media-manager-views (and any other published vendor views) before validating UI.
6. Re-baseline auth: confirm real auth views render SSO buttons, login works with registration disabled, and 2FA settings save without breaking optimize.
7. Deploy pipeline rework: adopt new bin/deploy (fail-fast, operations --isolated, health checks on /up and /), configure config/trustedproxy.php, add the scheduler cron, verify bin/backup-db archive check and GPG non-zero exit.

Compatibility

• Two supported lines: 1.38 (PHP 8.4) and 1.39 (PHP 8.5). Anything shared — CI templates, docs, runbooks — must be line-aware or it will drift.
• Docker loopback binding is incompatible with remote-access dev setups and CI service-container patterns; expect a local-dev remediation step.
• Trusted proxies without a production wildcard is compatible with a single well-defined ingress; multi-hop or CDN-fronted topologies need explicit configuration.
• AccessControlSeeder is now additive, so re-seeding is safe — but existing role assignments should be asserted post-upgrade.

Sequencing

• Recommend a three-stage rollout: (a) runtime + CI readiness spike (timeboxed), (b) staging upgrade with full deploy/rollback rehearsal, (c) production cutover with a restore-tested backup immediately prior.
• Do not bundle the runtime jump, the skeleton patch, and product feature work in one release train — the failure surface is too wide to attribute.
• If time-to-market dominates: ship on 1.38 now with compensating controls (manual post-deploy ops checklist, independent backup verification, optimize workaround if 2FA is in scope), and schedule 1.39 as a dedicated hardening milestone.

Operational Impact

Maintenance

• Net reduction in toil: fail-fast deploys, verified backups, scheduler shipped in code, placeholder bugs fixed, and guardrail tests (RouteSmokeTest, DeployParityTest, FluxIconsExistTest, ContentSecurityPolicyTest) that catch regressions before production.
• New maintenance obligations: keeping laravel-config-sso and laravel-config-webhook ≥1.1 in lockstep, owning the CSP origin allowlist, and maintaining config/trustedproxy.php per environment.
• Strict Eloquent outside production means CI will now fail on lazy-loading — assign ownership for triaging these or pipelines will stall.

Support

• Expect an initial ticket wave on SSO email-claim (users with pre-existing local accounts getting credentials revoked) and on third-party scripts blocked by CSP.
• Bulk actions now explain why users were skipped — a support-deflection win; document it so first-line can point to it.
• Mail open/click tracking moving into Admin > Settings > Mail shifts a former ops task to admins; update internal docs.

Scaling

• Redis queue + Horizon + in-code scheduler is the right shape for horizontal scale; note the scheduler is a single-runner concern (cron on one host or a leader-elected job) to avoid duplicate data:purge/pruning.
• Audit-trail exclusions (passwords, remember tokens, 2FA secrets) meaningfully reduce both audit table growth and secret-sprawl risk — a scaling and compliance win.
• #[Url] perPage clamping removes a cheap DoS/pagination-abuse vector.
• Loopback-bound Docker services reduce exposure surface in single-host deployments but constrain multi-host/service-mesh topologies.

Failure modes

• Deploy halts: fail-fast set -Eeuo pipefail plus health checks on /up and / mean previously "green-but-broken" deploys now go red. That is correct behaviour but will surface latent health-check misconfiguration as release blockers.
• Backup pipeline breaks loudly: GPG failures now exit non-zero — good, but any CI job that tolerated non-zero exits will start failing; audit wrapper scripts.
• Rollback ambiguity resolved ("honest rollback"), but the rollback path must be rehearsed against the new operations --isolated invocation, including whether migrations are reversible.
• Worker restarts on settings save cause brief queue latency spikes — schedule-sensitive jobs should tolerate it.
• Trusted proxy misconfiguration yields wrong client IPs, breaking rate limiting, geo logic, and audit attribution — validate post-cutover.
• SSO credential revocation is irreversible from the user's perspective; without pre-comms it reads as an outage.
• Historical silent failures: deployments on ≤1.38 may have skipped operations and produced unverified backups. Treat as an incident-review item, not a footnote.

Ramp-up

• Engineering: kickoff-patch skill, env var rename, strict-Eloquent workflow, and the new deploy/rollback runbook. Estimate a short, focused enablement session rather than broad training.
• Platform/SRE: PHP 8.5 and Node 26 image maintenance, trusted-proxy topology, GPG key custody for backups.
• Support/Admin: SSO claim behaviour, CSP-blocked-script triage, and the new Mail settings screen.
• Overall: moderate ramp-up concentrated in platform/SRE, low for product engineers — but the PHP 8.5 prerequisite is the gating item and should be sized before this release is committed to a roadmap date.