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
- 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.
- 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 without distorting the app contract.
- Keep vendor patches minimal. Avoid unrelated formatting, generated churn,
mass mechanical rewrites, or local style normalization inside the vendor
tree. Record the upstream source or base version and patch rationale using
the repository's existing convention.
- Validate the app-owned seam and the narrowest relevant vendor build or test
path the repo supports. Inspect the final diff for accidental vendor churn.
- Update notices, provenance, upstream version, local patch records, install
rules, or shipped metadata only when the vendor change affects them; do not
rewrite these files for an app-only adapter change.
Treat fetching or replacing upstream source, moving a submodule, and filing an
upstream issue or contribution as separate actions with their own network and
external side effects. Do not edit generated vendor artifacts manually when a
documented regeneration path owns them.
1---2name: project-vendor-boundary3description: Project overlay for checked-in or submodule-managed third-party source, provenance, local patches, and the app-owned integration seam. Not for package-manager dependency changes without vendored source.4---56# Project Vendor Boundary78This is a composable project overlay. Add matching implementation guidance when9the work requires language-specific code judgment.1011For review, inspect provenance, local patches, and integration behavior without12updating, fetching, or replacing the vendor tree. During implementation, preserve13pre-existing local changes and apply only the requested integration or update.1415## When to use1617The change involves checked-in third-party source, a subtree or submodule, a18vendor directory, copied sources, a local vendor patch, or the app-owned adapter19around that material.2021## Not for2223Do not use this for ordinary package-manager version or lockfile changes with no24checked-in third-party source, app-owned code unrelated to the integration seam,25or generated outputs that must be changed through their generator. Use26`project-release-maintainer` for release concerns and compose it only when a27vendor change also affects shipped metadata. Use `security` first when exploit28review is the primary job.2930## Workflow31321. Classify the material before editing: app-owned source, checked-in vendor33 source, submodule, generated output, or package-managed dependency. Read the34 repository's update instructions, provenance record, patch convention, and35 license or notice files when they exist.362. Prefer an adapter or wrapper change in app-owned code when the integration37 seam can reasonably absorb it. Patch vendor source only when the seam cannot38 solve the problem without distorting the app contract.393. Keep vendor patches minimal. Avoid unrelated formatting, generated churn,40 mass mechanical rewrites, or local style normalization inside the vendor41 tree. Record the upstream source or base version and patch rationale using42 the repository's existing convention.434. Validate the app-owned seam and the narrowest relevant vendor build or test44 path the repo supports. Inspect the final diff for accidental vendor churn.455. Update notices, provenance, upstream version, local patch records, install46 rules, or shipped metadata only when the vendor change affects them; do not47 rewrite these files for an app-only adapter change.4849Treat fetching or replacing upstream source, moving a submodule, and filing an50upstream issue or contribution as separate actions with their own network and51external side effects. Do not edit generated vendor artifacts manually when a52documented regeneration path owns them.
n-n-code