Define ownership and automated sync for Windows app-model conformance vectors

[Evangelink]

Summary

Define canonical ownership and automated synchronization for the shared Windows app-model conformance vectors consumed by TestFx and WinAppCLI.

This is test-data governance, not a runtime-code sharing request.

Current State

TestFx introduced implementation-neutral vectors for publisher hashing, package family names, AUMIDs, runtime/trust behavior, activation arguments, AppContainer behavior, and nested executable layouts in #10891. TestFx executes them against Microsoft.Testing.Extensions.PackagedApp manifest parsing (consumer test).

WinAppCLI then copied the fixture byte-for-byte in microsoft/winappCli#797. The commit explicitly calls the TestFx vectors canonical, and WinAppCLI runs its own implementation against the copy. At the reviewed WinAppCLI revision, the file still says it is intended for reuse by TestFx, WinAppCLI, and other Windows app tooling and contains the expected publisher ID/PFN/AUMID and app-model fields (fixture header and first vector, additional runtime/trust/nested-layout vectors).

The shared seam is valuable: it keeps two independently implemented Windows app launch/manifest stacks aligned without making either runtime depend on the other. The remaining risk is silent drift because each repository currently owns a physical copy and no issue or automated freshness check documents how updates propagate.

Problem

When either repository fixes or adds a Windows app-model edge case, the other copy can remain stale:

• publisher distinguished-name normalization and publisher hash/PFN expectations;
• package family and AUMID construction;
• RuntimeBehavior/TrustLevel defaulting;
• activation-argument and AppContainer expectations;
• nested executable paths and future manifest-layout cases.

A stale copy gives false confidence: both suites pass, but they are no longer checking the same contract.

Proposed Task

Keep the JSON fixture as the shared contract, but make its ownership and propagation machine-checkable.

Preferred shape:

1. Declare TestFx's test/Shared/WindowsAppModel/appx-manifest-conformance-vectors.json as the canonical upstream source (matching the history in Add WinApp CLI interoperability coverage #10891 and Test shared Windows app-model conformance vectors winappCli#797), or explicitly choose a different neutral canonical location.
2. Document the schema/versioning and contribution flow in the fixture or adjacent documentation.
3. Add an automated sync/update mechanism for WinAppCLI's copy, such as a pinned-source update script/bot PR, or a CI freshness check that compares the consumer copy with a pinned/upstream artifact and gives an actionable update command.
4. Ensure a source update and consumer update can be reviewed independently without requiring a runtime package dependency or network access during ordinary unit tests.
5. Add a clear compatibility rule for schema changes so older consumers fail with an actionable message rather than silently ignoring fields they are expected to validate.
6. Record which expected fields each consumer currently asserts. The fixture may contain forward-compatible fields, but unasserted fields should be visible rather than accidentally assumed covered.

An automated vendored-data flow is preferable to publishing runtime code or introducing a dependency between the two products.

Compatibility and Tradeoffs

• Unit tests should remain hermetic and consume a checked-in fixture.
• Sync automation should pin the upstream revision/content hash so a compromised or accidental upstream change cannot silently alter a consumer build.
• Schema evolution should be additive when possible; a schema-version bump should force explicit consumer acknowledgement.
• Cross-repository automation credentials/permissions may be undesirable. A deterministic local update script plus CI digest/freshness check is an acceptable alternative.
• The canonical source should stay implementation-neutral and avoid TestFx- or WinAppCLI-specific runtime assumptions.

Non-goals

• Sharing or packaging Microsoft.Testing.Extensions.PackagedApp runtime code.
• Replacing TestFx's packaged-app stack with WinAppCLI.
• Taking a dependency on the full WinAppCLI, its Sandbox protocol, generic process runner, runtime/SDK installation, or launch targets.
• Requiring network access during TestFx or WinAppCLI unit tests.
• Expanding the corpus into general end-to-end launch orchestration; it should remain focused on stable app-model inputs and expected outputs.

Acceptance Criteria

• One repository/location is explicitly documented as the canonical vector source.
• The consumer-copy update process is deterministic and documented.
• CI or automation detects when WinAppCLI's checked-in copy differs from the canonical content and provides an actionable remediation.
• The source revision or content hash used by each consumer is auditable.
• Schema-version compatibility and required-field behavior are documented and tested.
• Both repositories continue to run their own implementations against the same vectors without a runtime dependency between products.
• At least publisher hash/PFN/AUMID, runtime/trust defaults, AppContainer/activation behavior, and nested executable layouts remain covered.

Reasoning

The current duplicate fixture is a good architectural boundary: test data can encode a shared Windows contract while the implementations remain independent. The missing piece is normal vendored-data discipline. Explicit ownership plus automated drift detection provides most of the benefit of a shared package with much less coupling.