project-vendor-boundarylisted

# Project Vendor Boundary This is a composable project overlay. Add matching implementation guidance when the work requires language-specific code judgment. For review, inspect provenance, local patches, and integration behavior without updating, fetching, or replacing the vendor tree. During implementation, preserve pre-existing local changes and apply only the requested integration or update. ## When to use The change involves checked-in third-party source, a subtree or submodule, a vendor directory, copied sources, a local vendor patch, or the app-owned adapter around that material. ## Not for Do not use this for ordinary package-manager version or lockfile changes with no checked-in third-party source, app-owned code unrelated to the integration seam, or generated outputs that must be changed through their generator. Use `project-release-maintainer` for release concerns and compose it only when a vendor change also affects shipped metadata. Use `security` first when exploit review is the primary job. ## Workflow 1. Classify the material before editing: app-owned source, checked-in vendor source, submodule, generated output, or package-managed dependency. Read the repository's update instructions, provenance record, patch convention, and license or notice files when they exist. 2. Prefer an adapter or wrapper change in app-owned code when the integration seam can reasonably absorb it. Patch vendor source only when the seam cannot solve the problem wi