Let the test and architecture documents catch up with what landed

test-strategy.md described the integration fixture as a procedure somebody
follows, and made more than one biome optional, when the game test builds that
world on every push and worldledger corpus now requires every shape in the list.
It also gave the release gates without the two the project leans on hardest --
the capture fingerprint comparison and the corpus check -- so a contributor
reading it to find out what protects this repository would not learn that either
exists. Its closing line still said the cross-platform records were owed before
the capture milestone could be called complete; both exist and agree byte for
byte.

The reason the corpus check is needed belongs there too, because on its own the
fingerprint reads like enough. It cannot tell a thinner world from a changed
one: the game test does not read the results of the commands that build its
world, so a block a release renames places nothing and fails nothing, and what
surfaces is a mismatched fingerprint, which is also what a real game change
looks like. Update the reference once the release explains it and the smaller
world compares clean from then on.

architecture.md had no mention of the desktop application, and what it left out
is a boundary rather than a screen. The window is a second Go module so that the
core keeps no external dependencies at all, because the core's claim is that
anybody can recompute an observation's identity, and every dependency in the
module that computes it is something a reader has to audit before that claim
means anything.

Author: TonyLu786

docs/architecture.md

@@ -126,3 +126,11 @@ The first game-facing integration uses a filesystem spool rather than an in-proc
 Minecraft Java chunk components are defined independently of Fabric implementation details in [`../spec/minecraft-java-chunk-v1.md`](../spec/minecraft-java-chunk-v1.md). Unknown state is represented by component absence, not by fabricated defaults; see [ADR 0002](decisions/0002-observed-state.md).
 
 The 26.2 Fabric adapter copies bounded semantic snapshots on the client thread, then performs canonical encoding, hashing, manifest generation, fsync, and ready publication on one background writer. A bounded queue makes lost coverage observable instead of allowing disk pressure to grow the heap without limit. Complete temporary bundles are recovered at startup; invalid ones are quarantined rather than published or silently removed.
+
+## Presentation, and where dependencies are allowed to live
+
+The desktop application is a second Go module under `desktop/`, with its own `go.mod` that reaches the core through a `replace` directive. The split is a dependency boundary, not a build convenience. The core's claim is that anybody can recompute an observation's identity from the specification, and every third-party package in the module that computes it is something a reader has to audit before that claim means anything, so the core stays on the standard library and the window's dependencies stay on the far side of the line.
+
+The application is a loopback HTTP server with the interface embedded in the binary, and the native window is a shell over it. That is also why the interface is HTML rather than native controls: where a window cannot be created the same application runs in a browser, with nothing removed. It calls `internal/` directly and never parses command output, so there is one implementation of each operation rather than a second one behind a screen.
+
+The operations it does not offer are deliberate. Seeding, attestation, redaction, transfer, and landmarks are for whoever runs an archive rather than whoever plays, and putting them behind buttons would make the dangerous ones easy and the rest confusing.

docs/test-strategy.md

@@ -77,9 +77,9 @@ Pure-Java tests cover sequence monotonicity/exhaustion, due and final dirty clai
 
 Maintain a small controlled 26.2 server fixture with known coordinates containing:
 
-- air/stone terrain;
-- block states with several properties;
-- multiple biomes if practical;
+- air/stone terrain, with a mixed section at each end of the build range;
+- block states with several properties, and waterlogging on a block that is not water;
+- more than one biome in a chunk;
 - signs or another block entity with visible update NBT;
 - a container whose contents are intentionally not opened during one capture pass.
 
@@ -94,7 +94,11 @@ Test procedure:
 7. compare expected observation/component digests;
 8. verify that unopened container contents are not asserted by v1 data.
 
-The versioned procedure and evidence template live in `examples/minecraft-26.2-fixture`. A written procedure is not a passing integration run; Windows and Linux evidence records are required before the Java capture milestone is marked complete.
+This stopped being a procedure somebody follows. `adapters/fabric/src/gametest` builds that world with server commands, drives a real client through it, and runs the steps above on every push. The versioned procedure and evidence template in `examples/minecraft-26.2-fixture` remain as the record of what the world is meant to contain, and both the Windows and the Linux record the Java capture milestone waited on now exist and agree byte for byte.
+
+Two committed things stand behind that world. `testdata/capture-fingerprint-reference.txt` pins what a capture of it canonicalizes to, so a change in the encoding fails the build rather than waiting to be noticed. `worldledger corpus` requires each shape in the list above to actually be present — including the last one, which is the absence of something: a container was observed and its contents were not.
+
+The second exists because the first cannot tell a thinner world from a changed one. The game test does not read the results of the commands that build its world, so a block a release renames places nothing and fails nothing. What shows up is a fingerprint that no longer matches, which is also what a genuine game change looks like, and [`upgrading-minecraft.md`](upgrading-minecraft.md) tells a maintainer to update the reference once the release explains it. From that run on, the smaller world compares clean forever.
 
 ## 6. Release gates
 
@@ -115,7 +119,11 @@ cd adapters/fabric
 ./gradlew --no-daemon clean build --warning-mode all
 ```
 
-CI runs all Go gates on Linux and separately tests, vets, and builds the Windows-specific filesystem and locking paths. The Fabric build runs in Linux CI and is also verified locally on Windows; the live cross-platform client records remain a separate release gate.
+CI runs all Go gates on Linux and separately tests, vets, and builds the Windows-specific filesystem and locking paths. The Fabric build runs in Linux CI and is also verified locally on Windows.
+
+Two gates are not in the list above, because they need a running client rather than a compiler. The capture game test rebuilds the capture fingerprint and compares it against the committed reference, and runs `worldledger corpus` over what it captured. Both run in Linux CI on every push; `scripts/run-client-gametest.ps1` runs the same pair on Windows, including where Gradle will not start. The cross-platform comparison the Java capture milestone waited on is one of them now, rather than something a person remembers to do at release time.
+
+The desktop application is a separate Go module and is tested and built as one, on Linux and on Windows. Its tests do not touch a real Minecraft directory: the installer is exercised against a fabricated one, and the check for a running launcher is injectable, because a suite whose result depends on whether somebody has the game open is not a gate.
 
 ## 7. Performance guardrails