v1.1 closeout: accept integrated release validation

Release validation of candidate 87a4032, not a work package. No product code
changed, no requirement or acceptance test changed, no schema or bundle format
changed, and nothing is tagged or merged by it.

V1.1 RELEASE VALIDATION: PASS

What was run, on this candidate:

- v1 contract: 82 REQUIRED tests — 81 PASS, H09 NOT APPLICABLE, 0 waived,
  0 weakened, 0 reclassified.
- Suites: backend 1,723 passed / 17 skipped / 0 failed / 0 xfailed; frontend
  175 passed; lint 0 errors (15 documented warnings); production build clean.
- Docker: docker build --no-cache; the image's SPA is file-for-file identical
  to the local build (16 files, same combined sha256).
- Offline: 23/23 against the candidate image with no network and a fresh volume.
- Browser: 101 passed / 0 failed / 0 skipped (M11 38, WP-C 53, WP-E 10) over
  trusted-LAN HTTPS with a private CA; every narrator turn "fits".
- Long run: 102 accepted turns at a verified 16,384 window with memory on,
  3 process restarts, M01-M04 pass, 0 post-turn failures, 0 database locks.
- A1: every turn "fits"; the ten largest prompts re-counted against the server
  keep the documented reserve, smallest margin 879 tokens against v1's 23-42.
- A2: release-gate leak count 0 across 105 stored replies.
- Identity: 0 signals and 0 stored protocol shapes, with memory on; the
  scripted detector still fires on an injected defect.
- Recovery: 16/16 on the long run's own bundle, into a database and directory
  that never existed.
- Upgrade: a campaign built and played by the v1.0.0 application compares
  identical on all 15 census fields, schema parity at user_version 94, and both
  bundle directions import.
- Release smoke: 15/15 from the shipped image — loopback only, private CA
  verified, public endpoint refused, a real turn, restart, persistence, and
  Firefox rendering the reopened campaign.

Carried residuals, stated rather than summarised away:

- WP-B: deterministic independent-memory recovery PASS; reference-model
  independent-memory recovery FAIL at memory creation — the owner-accepted
  limitation, unchanged and not a new regression.
- The mid-reply instruction echo A2's trailing cleanup does not remove is still
  reproducible on the stored WP-B.1 fixture (1 of 105), and did not recur in
  release evidence.
- The doubled full stop in the memory-search scene text.
- K1 ("Correct" on an Important Facts row is refused) is classified v1.2
  backlog, reproduced and not fixed during validation.

Three harness corrections were made during validation — the identity diagnostic
did not enable memory, the smoke test needed hostname resolution inside the
container, and the first upgrade campaign was too short to write memories. All
harness-only; each corrected harness repeated its own check, and no product
evidence became stale.

Docs: README, V1.1-PLAN, planning/README and VERSION now say v1.0.0 remains the
released version, that v1.1 is implemented and validated, and that no v1.1.0 tag
exists. WP-E's report records OWNER SCREENSHOT APPROVAL: APPROVED, sourced to
the owner's brief. New harness tools: v11_upgrade_check.py, v11_release_smoke.py.

Still the owner's to do: sign the release commit, update main, tag v1.1.0.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VvegagkhuCZoFPdv4M1egY

planning/V1.1-PLAN.md

@@ -20,12 +20,23 @@ coverage, is committed and signed as `59b5ebc`. Its final run passed 91 checks
 (the 38 existing and 53 new) with 0 failed and 0 skipped, over trusted-LAN HTTPS,
 including real export downloads (`reports/v1.1/V1.1-WP-C-REPORT.md`).
 **WP-D** (recovery honesty) and **WP-E**
-(control-boundary contrast) are complete and staged for owner review, each with
-its own report: `V1.1-WP-D-REPORT.md` and `V1.1-WP-E-REPORT.md`. The final
-browser run covers all three suites — M11 38, WP-C 53, WP-E 10: **101 passed, 0
-failed, 0 skipped**. Every planned v1.1 work package (WP-A1, WP-A2, WP-B, WP-C,
-WP-D, WP-E) is now implemented and reported; release validation has not begun,
-and no v1.1 version or tag exists.
+(control-boundary contrast) are committed and signed as `87a4032`, each with its
+own report: `V1.1-WP-D-REPORT.md` and `V1.1-WP-E-REPORT.md`.
+
+**Integrated release validation has since run on candidate `87a4032` and
+passed** (`reports/v1.1/V1.1-RELEASE-REPORT.md`): the 82 REQUIRED v1 tests hold
+(81 PASS, H09 NOT APPLICABLE), backend 1,723 / frontend 175 / lint 0 errors, a
+`--no-cache` image whose SPA is file-for-file identical to the local build,
+offline 23/23, browser 101/0/0 over trusted-LAN HTTPS, a 102-turn 16,384-window
+run passing M01-M04 with every turn `fits` and an A2 leak count of 0, identity
+0 signals / 0 protocol shapes, recovery 16/16, a real v1.0.0 upgrade comparing
+identical on all 15 fields with both bundle directions importing, and a release
+smoke of 15/15.
+
+WP-B's reference-model memory limitation is carried as an accepted residual, as
+are the mid-reply instruction echo and the doubled full stop; K1 is classified as
+v1.2 backlog. **No `v1.1.0` tag exists, `main` is unchanged, and no release
+commit has been made** — those three remain the owner's separate events.
 
 This document replaces nothing. `BUILD-MILESTONES.md` stays as the closed v1
 history (M1-M11), and its *Post-v1 backlog* is this plan's input. The v1