# FriiDump homepage, Linux parity, and release automation campaign

## Governing order

1. Candidate11 Linux Xbox/XGD user-path parity.
2. Release automation v1 with exact-tag builders and immutable artifacts.
3. Compatibility site v1.3.0 promoted into the FriiDump project homepage.
4. MinGW cross-build investigation after the MSVC and native-Linux pipeline is
   established and verified.

## Candidate11

The validated Windows/MSVC build remains the Windows authority. Linux reuses
FriiDump's portable MMC transport and receives equivalent Xbox metadata,
output, cancellation, hashing, and native-report behavior. Development-only
XGD1 probes are a separate substage.

## Release automation v1

A validated annotated tag creates a small build request. Compilation does not
run inside the Git hook.

- Linux worker: exact tag, GCC/CMake, x86_64 artifact.
- Windows worker: exact tag, Visual Studio 2019 Build Tools, x86 artifact.
- Both workers run tests and publish signed-by-hash build manifests to staging.
- A publisher verifies all required artifacts and atomically publishes an
  immutable release directory plus `latest.json`.
- Failed or incomplete builds remain in staging and never change `latest`.

## Site v1.3.0

The public site becomes the FriiDump homepage with:

- Windows and Linux download cards;
- source archive, tag, commit, tree, and SHA-256 identity;
- compatibility table and evidence views;
- report submission;
- documentation and release history;
- machine-readable `latest.json` and immutable release manifests.

The Git repository may remain LAN-only. Public source ZIPs and exact provenance
are sufficient; public Gitweb is optional.

## MinGW follow-up

MinGW is the preferred eventual Windows automation path after initial setup and
verification. It must be introduced as a separate toolchain identity, compared
against the validated MSVC behavior, and promoted only after real-drive and
native-report parity is demonstrated.