Add cross-repository schema impact guidance

- Add REST source (winget-cli-restsource) section to UserMessages spec
  covering schema, API versioning, and storage changes
- Add Community Repository (winget-pkgs) section covering validation
  pipeline and schema version acceptance policy
- Update spec template with cross-repo comment directive
- Update Copilot instructions with Cross-Repository Impact section

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Author: denelon

.github/instructions/specs.instructions.md

@@ -87,6 +87,16 @@ A complete specification should address all areas the feature touches. For WinGe
 - Older clients silently ignore unknown fields. Do not rely on older clients reading new fields.
 - The winget-pkgs community repository enforces schema version n or n-1 for new submissions. This is the practical mechanism that drives publisher adoption of new fields.
 
+### Cross-Repository Impact
+
+Schema changes in `winget-cli` have downstream impact across several repositories. A complete specification should address:
+
+- **winget-cli** — Client implementation, schema files, settings, and CLI arguments.
+- **winget-cli-restsource** — The REST source reference implementation must be updated to support new schema fields so enterprise REST sources can serve the new data. Enterprise scenarios do not carry the same deprecation concerns as the community repository since organizations control their own source update cadence.
+- **winget-pkgs** — The community repository's validation pipeline must be updated to accept (and validate) new fields. The n/n-1 schema version acceptance policy at winget-pkgs is the practical driver for publisher adoption and eventual deprecation of replaced fields.
+
+When writing the spec, describe the end-to-end customer impact across these repositories so reviewers understand the full scope of work required.
+
 ### Interactivity
 
 WinGet has multiple interactivity modes that specifications must account for:

doc/specs/#3483 - UserMessages.md

@@ -373,6 +373,28 @@ WinGet Configuration is inherently non-interactive. When a configuration file re
 
 This specification does not introduce new Group Policy settings. Group Policy controls for `UserMessages` (e.g., enforcing or suppressing messages across managed devices) are deferred to a future specification. The existing Group Policy infrastructure is not affected.
 
+### REST Source (winget-cli-restsource)
+
+The [winget-cli-restsource](https://github.com/microsoft/winget-cli-restsource) reference implementation must be updated to support the new `UserMessages` fields so enterprise REST sources can serve this data. Changes include:
+
+- **Schema update** — Add `UserMessages` fields to the REST source data model and API response contracts.
+- **API versioning** — Introduce a new API version that includes `UserMessages` in the package version response. Older API versions continue to function without the new fields.
+- **Storage** — The backing data store (Azure Cosmos DB / SQL) must accommodate the new fields.
+
+> [!NOTE]
+> Enterprise REST sources do not carry the same deprecation concerns as the WinGet Community Repository. Organizations control their own source update cadence and can adopt new schema fields on their own timeline.
+
+### Community Repository (winget-pkgs)
+
+The [winget-pkgs](https://github.com/microsoft/winget-pkgs) community repository is impacted in two ways:
+
+1. **Validation pipeline** — The automated validation tooling must be updated to:
+   - Accept `UserMessages` fields in manifests using the new schema version.
+   - Validate field lengths (2048 for pre-action, 10000 for post-action) and structure.
+   - Ensure validation runs are non-interactive — pre-action messages must not block the pipeline.
+
+2. **Schema version acceptance policy** — The community repository accepts manifests at schema version **n** or **n-1**. As the minimum accepted version advances to include the `UserMessages` schema, manifest authors will be required to adopt the new fields and migrate away from `InstallationNotes`. This is the practical mechanism that drives deprecation of the older field.
+
 ### Manifest Examples
 
 #### Transition period — both fields for compatibility

doc/specs/spec-template.md

@@ -21,6 +21,7 @@ issue id: <github issue id>
 
 [comment]: # Outline the design of the solution. Feel free to include ASCII-art diagrams, etc.
 [comment]: # When proposing new settings, also propose corresponding CLI arguments (and vice versa). Settings define user defaults; CLI arguments provide per-invocation overrides.
+[comment]: # When proposing schema changes, address the cross-repository impact: winget-cli (client and schema), winget-cli-restsource (enterprise REST source), and winget-pkgs (validation pipeline and deprecation policy).
 
 ## UI/UX Design