Clarify ownership of upstream integration tests

docs/roadmap/upgrades.md

@@ -283,11 +283,22 @@ does not require a CommandKit version to mirror any upstream version.
 
 ### Evidence for the eventual implementation
 
-The implementation plan should select proportionate evidence for native source
-placement/version disclosure, direct prompt selection, absent/empty labels,
-preserved requirements behavior, optional catalog availability, scoped/default
-and explicit listing filters, errors, and output delivery. Use maintained offline
-consumers and existing release-launcher coverage where applicable.
+The implementation plan should test CommandKit-owned interfaces and adaptation
+under the [upstream testing ownership policy](../policy/testing.md#upstream-integration-testing-ownership).
+Verify that command inputs and context reach the intended native APIs, including
+ID-only prompt requests and default/explicit listing filters. Verify faithful
+representation of upstream-returned source evidence, optional labels, inventories,
+diagnostics, and errors, together with CommandKit's optional command availability,
+invocation lifetimes, outcome classification, and output delivery.
+
+These checks establish CommandKit's access to the capabilities. They should not
+test whether ConfigKit correctly places or composes sources, checks versions,
+or classifies sensitivity, nor whether PromptKit correctly resolves namespaces,
+discovers requirements, or validates concrete requests. Those domain tests belong
+to the upstream libraries. Real upstream fixtures and maintained offline
+consumers can exercise CommandKit's boundary without duplicating native feature
+test matrices. Existing release-launcher coverage likewise owns CommandKit's
+tool invocation, not ReleaseKit's publication algorithms.
 
 Verify all affected modules both in the local workspace and with their own
 readonly dependency graphs. Temporary replacements for unpublished CommandKit