Vault Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for secrets/vault storage: This bundle is the "buy/borrow" option for encrypted-at-rest data (vault items, shareable records) in a Symfony PHP app. Each release like this one tells you whether you keep maintaining it or inherit it — v1.8.2 is pure maintenance, so the "buy" case holds.
• Feature scope for sharing flows: The functional change is that vault/share.html.twig and _share_form_fields.html.twig now render form bodies through the child loop ({% for child in form %} + not child.rendered + form_row(child)). For a PM this means new form fields and field types get rendered automatically — no per-field template edits to ship a new share attribute. That removes a recurring engineering tax from the roadmap every time the share form grows.
• Customization/theming roadmap: Because item-type-specific fields are still laid out per type and the loop skips fields the current type doesn't show, you can promise "custom item types and themed forms" without forking templates. Good for white-label or tenant-specific UX requests.
• Release risk assessment for the next sprint: No schema changes, no migrations, no public API changes; rendered fields are explicitly unchanged. That means this can be absorbed in a routine dependency-update slot rather than a dedicated hardening sprint.
• Dependency posture as a decision input: Bumps to doctrine-encrypt-bundle (2.5.0 → 2.8.0), form-kit-bundle, doctrine/mongodb-odm, and phpstan-frankenphp indicate an actively patched crypto/ODM stack — relevant if you're making a security-review or procurement argument.
• Documentation/SDD maturity as a vendor signal: Wave-1 REQ compliance, functional scope/non-goals, canonical issue templates, CONTRIBUTING Code of Conduct, Spec Kit inventory at 123/123. This is the kind of artifact set that shortens due-diligence questionnaires and reduces onboarding cost for a new engineer.

When to Consider This Package

Consider it when:

• You are on Symfony (8.1 badge now listed) and need a ready-made vault/secret-item domain with encrypted Doctrine persistence, sharing, and item-type-specific forms.
• You want form rendering that is future-proof against field additions — the child-loop change is exactly the property you want if your share form is expected to evolve.
• You value low-ceremony patch releases: dependency hygiene, coding-standard automation (ParallelConfig(2) in .php-cs-fixer.dist.php), and documented upgrade paths (UPGRADING.md#to-182) over a large in-house maintenance surface.
• You need an auditable, documented open-source dependency for a security-adjacent feature and want the docs/SDD trail to exist before you're asked for it.

Look elsewhere when:

• You are on Laravel. This is a Symfony bundle (Twig views, Doctrine ODM/ORM, Symfony form component). The Laravel-equivalent decision is a different package entirely; adopting this would mean running a Symfony subsystem alongside Laravel, which is not a PM decision you want to defend.
• You need a managed external secret store (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) as the system of record rather than app-embedded encrypted entities.
• You require a stable, versioned public template/API contract — the templates are being refactored release-to-release (hand-placed _token widget removed in favor of the loop). If your team has forked or overridden these templates, verify against UPGRADING.md#to-182 before upgrading, and budget a regression pass on the share and item forms.
• Your compliance regime demands formal CVE/advisory tracking per dependency — the release notes show version bumps but not the rationale or advisory IDs; you'd need your own SCA tooling on top.

How to Pitch It (Stakeholders)

For executives: v1.8.2 is a low-risk maintenance release of our vault/secrets component — no breaking changes, no data migrations, no user-visible behavior change. It refreshes dependencies (including the encryption library) and cleans up how share and item forms are rendered so that future field additions don't require template surgery. Cost to adopt: a routine upgrade slot plus a short regression check on the share and item forms.

For engineering: The meaningful change is REQ-TWIG-003 — share forms now render through the child loop with not child.rendered and form_row(child), one grid column per child, and the item form replaces its hand-placed _token widget with the same loop while preserving per-item-type layout and skipping non-applicable fields. Rendered output is stated to be unchanged, so expect no visual diff. Also included: dependency bumps (doctrine-encrypt-bundle 2.5.0 → 2.8.0, form-kit-bundle 2.11.0 → 2.12.0, doctrine/mongodb-odm* patches, phpstan-frankenphp 1.3.0), new ParallelConfig(2) for php-cs-fixer, and docs/badge/issue-template compliance work. Action: read UPGRADING.md#to-182, upgrade in a maintenance window, and smoke-test the share form and each item type.

Caveat to state up front: this is a Symfony/PHP bundle, not a Laravel package — confirm the target application's framework before this goes on any roadmap.