34 added, 18 removed. Audit A to A.
---
name: project-vendor-boundary
- description: Overlay for app-owned versus vendored dependency boundaries. Portable across repos that vendor third-party code. Use when work touches vendored dependencies or their integration seam.
+ description: 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.
---
# Project Vendor Boundary
- This is a composable overlay, not a standalone workflow.
- Use alongside the repo's implementation skill when work touches vendored
- dependencies or their integration boundary.
+ This is a composable project overlay. Add matching implementation guidance when
+ the work requires language-specific code judgment.
## When to use
- The change involves vendored third-party code, the boundary between app-owned
- and vendored code, or dependency integration (subtrees, vendor directories,
- copied sources).
+ 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
- App-owned code that does not touch vendor boundaries (use the implementation
- skill directly), or release/packaging concerns (use **project-release-maintainer**).
+ 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.
- ## Rules
+ ## Workflow
- - prefer app-side integration changes before editing vendored code
- - treat vendored code as subtree/vendor content, not normal project code
- - keep notices, provenance, upstream version/source, local patch rationale, and
- install rules aligned with vendor changes
- - prefer adapter or wrapper changes in app-owned code before patching vendored
- sources; patch vendor code only when the seam cannot reasonably absorb the
- change
- - avoid unrelated churn inside vendor trees
+ 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 without distorting the app contract.
+ 3. 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.
+ 4. 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.
+ 5. 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.