Docs/repository refresh rc4

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,11 +1,13 @@
-## What changes for visitors
+## What changes
 
-Describe the concrete behavior and reason for it. Include desktop/mobile screenshots for visual changes.
+Describe the concrete change and reason for it. For repository-only work, identify the documentation or tooling improvement and whether visitor behavior changes. Include desktop/mobile screenshots for website visual changes.
 
 ## Validation
 
 List checks actually run, measured results and remaining limitations. Do not present older QA results as verification of this revision.
 
+For documentation and version updates, verify links, image paths, package/lockfile versions and publication dates. Keep new changes unreleased until deployment is verified, and preserve historical test evidence.
+
 ## Publication
 
 Merging into `main` triggers my GitHub Pages workflow. Confirm that the change is ready for me to publish, preserves `wizardloop.com` and existing URLs, and includes any relevant rollback notes. I review publication separately; a pull request does not itself merge or deploy the change.

CHANGELOG.md

@@ -2,6 +2,15 @@
 
 I record source changes here and identify verified deployments separately. A version heading alone does not establish that a Git tag or GitHub Release exists.
 
+## 1.0.0-rc.4 - Deployed 2026-10-29
+
+- I redesigned my README with a visual introduction, quick navigation, a publication-status table and clearer setup, editing and documentation guides.
+- I recorded the verified publication date and deployment evidence for rc.3, keeping that published website separate from this repository update.
+- I clarified first-person writing, documentation-only validation and version maintenance in my contribution guide and pull request template.
+- I updated my package and lockfile version metadata together. I changed no website source, media, dependencies, tests or workflows.
+
+This repository-only update is prepared for review. I have not merged or deployed it, created a Git tag or published a GitHub Release.
+
 ## 1.0.0-rc.3 - Deployed 2026-10-28
 
 - I added Silver Grimoire to Home, About and Posts, with local still previews and the existing motion controls.
@@ -11,7 +20,7 @@ I record source changes here and identify verified deployments separately. A ver
 - I added regression checks for SVG identity, delayed animation loading, independent playback and lifecycle recovery, plus Linux Lighthouse reports in review CI.
 - I rewrote my site and repository prose in my own first-person voice while preserving factual history and third-party legal notices.
 
-This source candidate has not been deployed. I recorded its measured browser checks, performance samples and the local Home performance limitation separately from the historical baseline in [QA.md](docs/QA.md).
+I published this version after [PR #5](https://github.com/WizardLoop/wizardloop.github.io/pull/5) merged at `062bdad623c53c2bd10661c3fe578f1cfc62b2b2`. [Deployment run 40700122492](https://github.com/WizardLoop/wizardloop.github.io/actions/runs/40700122492) completed successfully on **2026-10-28 at 15:57:11 Asia/Jerusalem (13:57:11 UTC)**. I verified HTTPS 200 and the Silver Grimoire artwork and SVG mark on my live Home page. This publication record does not imply a Git tag or GitHub Release. I retain the version's measured checks and known limits in [QA.md](docs/QA.md).
 
 ## 1.0.0-rc.2 - Deployed 2026-10-28
 

CONTRIBUTING.md

@@ -14,6 +14,7 @@ Preserve `wizardloop.com`, both source CNAME files and existing public routes. I
 ## Content and interface
 
 - Use English by default and correct direction handling for Hebrew.
+- Write my personal site copy and repository narrative in first person, as WizardLoop: "I updated my site", not "I built this for the owner". Preserve third-party legal notices and factual attribution.
 - Verify claims and links. Do not invent clients, achievements or profiles.
 - Use a regular hyphen instead of U+2014 in controlled content and metadata.
 - Preserve keyboard access, visible focus, semantic headings, contrast and narrow-screen layouts. Honor reduced motion and the global motion control.
@@ -26,6 +27,10 @@ Run `npm run check`. For layout or interaction changes, run relevant browser tes
 
 Describe the concrete change, validation actually performed and remaining limits. Include desktop/mobile screenshots and both themes for visual changes. Do not treat older QA reports as verification of the new revision.
 
+For documentation-only changes, check Markdown links and anchors, referenced images, factual dates and version consistency, then run `npm run check`. State that visitor behavior is unchanged. Existing CI still runs the browser and Lighthouse suites; a prose edit does not need a new screenshot or a new test that mirrors the text.
+
+When changing my source version, update `package.json`, both root version entries in `package-lock.json`, and `CHANGELOG.md` together. Check existing tags and Releases first. Keep the new entry unreleased until publication is verified; record the actual deployment date and workflow when marking a version published. Preserve historical QA versions and measurements rather than changing their labels to the newest version. A published website does not automatically create a Git tag or GitHub Release.
+
 Keep lockfile updates with dependency changes. Exclude installed packages, build output, test artifacts, `.env` files, credentials and personal messages. Review the diff before submitting.
 
 **A merge I approve into `main` triggers publication after checks pass.** Creating a pull request does not authorize someone else to merge it. Confirm publication readiness with me before merging and follow [DEPLOYMENT.md](docs/DEPLOYMENT.md). I decide separately about tags, releases and DNS changes.