Fw Bundle Laravel Package

Product Decisions This Supports

Correct a category error before any decision is made. The evaluation ticket frames this as a "Laravel/PHP package." It is not. survos/fw-bundle is a Symfony bundle (namespace Survos\FwBundle, registered via src/SurvosFwBundle.php, consumed through Twig, AssetMapper/importmap, and Stimulus). The Laravel-shaped assessments in the packet are template artifacts, not evidence. Any decision, budget line, or architecture review that treats this as Laravel-compatible is wrong and should be rejected at intake. This is the single highest-value product call in the package.

What it actually buys you. A packaged mobile-app shell for Framework7 v9 on Symfony: an opinionated base Twig template (fw-base.html.twig, start.html.twig, components/), a Stimulus controller base class (assets/src/controllers/mobile_controller.js, importable as @survos-mobile/mobile), importmap/AssetMapper registration, and reusable configuration and service defaults. In PM terms it is scaffolding-as-a-package, not a feature library.

Build vs. buy. Read this as buy vs. copy. The bundle is small, unversioned in practice, and zero-adoption — so "buying" is really "adopting a Survos-internal convention." The genuine asset is not the code volume, it's the encoded knowledge in docs/events.md: a verified map of Framework7 v9's real page/tab lifecycle events (DOM events vs. F7's internal pub/sub, checked against compiled source rather than documentation). That is a scarce, expensive-to-rediscover artifact. The templates and controller base are cheap to reproduce; the event wiring is not. Price the adoption accordingly.

Roadmap and portfolio levers it supports.

• Standardization: one shared F7 mobile shell across Survos apps instead of N divergent Twig/Stimulus scaffolds.
• Time-to-demo: fastest path from a Symfony app to a working mobile UI with real F7 event handling.
• Platform alignment: the stated modernization direction targets Symfony 8.1 (beta tolerated pre-stable), survos/kit-bundle, and the AbstractUxBundle pattern — so adopting this bundle is also a vote to keep the app on that modernization track.
• Reuse boundary: useful if two or more apps need the same F7 shell. For a single app, vendor the source into the app and own it outright.

Use cases worth naming in a roadmap doc: internal/demo mobile clients, PWA-style front-ends over existing Symfony apps, multi-tenant Survos products needing a consistent mobile chrome, and teams that have already committed to AssetMapper + Stimulus + Framework7 v9.

What it should not be used for: anything customer-facing and contractual on a fixed date, anything requiring a documented public API, anything outside the Survos ecosystem, and anything where a Laravel or non-Symfony stack is non-negotiable.

When to Consider This Package

Adopt only when all of these hold:

• The application is Symfony, on the versions the bundle's composer.json actually declares, plausibly 7.x → 8.1.
• Front-end assets are managed via AssetMapper/importmap plus Stimulus — the bundle registers importmap metadata and a Stimulus controller, so an Encore or Vite pipeline means re-plumbing the integration yourself.
• The target UI is Framework7 v9, and you have read docs/events.md before writing any listener. F7's event model is not the intuitive one; this file is the reason to adopt and the reason a naive integration fails.
• You are inside the Survos ecosystem: survos/kit-bundle present, AbstractUxBundle conventions acceptable, setup kept in SurvosFwBundle.php rather than legacy DependencyInjection/*Extension.php classes.
• You can accept an unowned upstream by default and assign an internal owner anyway.

Look elsewhere when:

• Any non-Symfony stack. Hard stop. Laravel, plain PHP, or a JS-first app: there is nothing here for you.
• A mobile UI framework other than Framework7 v9 is in play (v8, Ionic, Capacitor-only, React Native). Event semantics differ; the bundle's core value evaporates.
• You require published documentation, a changelog, a support commitment, or a security-response process. Release notes read only "initial version." There is no changelog, no tag history, no issue-response track record — 0 stars and 0 dependents mean no field evidence whatsoever.
• You need a stable public API contract. The 1.0 tag asserts semver stability, but a first release with no changelog gives you no way to audit what that promise covers.
• The work is one app's one-off screen. Write the Twig and the controller in-app; do not take a dependency for it.
• Your asset pipeline is not importmap-based, or Twig components are not in use.
• You cannot tolerate a Symfony 8.1 beta-era constraint, since the bundle's modernization direction explicitly permits beta dependencies.

Pre-adoption spike, one day, in a throwaway branch: composer validate; install and confirm bundle registration and service wiring in src/SurvosFwBundle.php; run bin/console debug:asset-map to confirm the importmap entries actually land; bin/console lint:twig templates/; load one page and verify the Stimulus @survos-mobile/mobile controller attaches and a real F7 v9 lifecycle event fires in a browser. Then install it in a real app without using it and run the existing test suite to catch boot-time conflicts. Note the date in docs/events.md reads 2026-07-29 — flag that inconsistency to the maintainer rather than assuming it's a typo; it undermines confidence in the document you're most reliant on.

How to Pitch It (Stakeholders)

To executives — one paragraph. This is a small internal Symfony bundle that gives our mobile front-ends a pre-built Framework7 shell: page templates, a mobile UI controller, and — most importantly — hard-won, source-verified knowledge of how Framework7 v9's event system actually behaves, which is the part teams reliably get wrong and pay for twice. It is cheap to adopt and cheap to abandon, and it keeps our mobile apps on the same Symfony modernization track. It is not a vendor product: zero external users, no documentation beyond a short description, no changelog, no support, a single-maintainer risk profile, and it is Symfony-only — it does not work with Laravel, which the evaluation ticket incorrectly implied. Recommendation: approve a capped, time-boxed pilot on one non-critical app behind a feature flag; do not put it on a critical path and do not let it appear in a customer commitment.

To engineering — the practical case. Adopt it as a convention, not as a dependency you trust. Three things to bank: (1) docs/events.md — read it before touching event wiring, in this bundle or in any app built on it; (2) the Twig base template and components/ as a starting chrome rather than a from-scratch layout; (3) the Stimulus base controller, imported as @survos-mobile/mobile, as your app_controller.js superclass. Three things to guard: pin an exact version, not a caret range, because a first release with no changelog has no auditable breakage signal; vendor it behind your own interface — a thin adapter plus a fake binding in tests — so replacement is one file, not forty call sites; and keep the integration inside SurvosFwBundle.php per the repo's own modernization direction, avoiding legacy DependencyInjection/*Extension.php side-files. Verify importmap metadata, Stimulus registration, Twig component names, and the app's framework7/framework7-bundle imports together — Framework7 integration fails in exactly the seam between those four, and each looks fine in isolation. Gate the merge on composer validate, phpstan analyse, debug:asset-map, lint:twig, and one real browser check of an F7 v9 lifecycle event. Assign a named internal owner; an unowned third-party package surfaces as a surprise during the next Symfony upgrade, not before it.