Reconcile documentation after temp safety issue closures

CHANGELOG.md

@@ -6,6 +6,8 @@ Following the `0.0.15-beta` prerelease, Windows client/server, IIS, Exchange, pr
 
 ### Changed
 
+- Reconcile current documentation after PRs #42, #43 and #44 closed issues #30, #28 and #29. Record their exact reviewed-head and merged-source evidence, preserve the published `0.0.15-beta` artifact as a distinct historical package, close stale issue #26 URL wording, and keep deferred Windows/ReFS/IIS/Exchange/profile labs and final 1.0 acceptance explicit.
+
 - Complete issue #28's public-command directory-identity regressions for empty and populated replacements, retained-handle prevention, defensive identity refusal, deepest-first pruning, preservation boundaries, WhatIf and terminating errors. The fixture note distinguishes reachable production behavior from injected handle-loss tests; executable runtime behavior and lab gates are unchanged.
 
 - Complete issue #29's NTFS ACL regressions for both temp commands: prove denied content reads still permit authorized deletion, denied deletion reports errors and honors Stop, substitutions/disappearance are preserved, and native identity uses all 128 bits with fail-closed errors. Document the conservative sharing decision and ReFS API semantics separately from deferred ReFS runtime acceptance.

docs/Clear-CurrentUserTemp.md

@@ -12,7 +12,7 @@ Clear-CurrentUserTemp [-Days <Int16>] [-RemoveEmptyDirectory] [-PassThru] [-What
 
 ## Behavior
 
-Resolve the temporary directory using `[System.IO.Path]::GetTempPath()` on Windows. Select files of any extension whose `LastWriteTimeUtc` is at or before one UTC cutoff. `-Days` defaults to 30 and accepts positive Int16 values. Reparse points are excluded before traversal. Literal paths, ancestry, type, identity, and timestamps are revalidated before removal. The native deletion handle requests `DELETE` and `FILE_READ_ATTRIBUTES` without file-content read access and without sharing writes or deletes, so the final timestamp is read from the opened object and an active writer or rename cannot move the candidate after validation.
+Resolve the temporary directory using `[System.IO.Path]::GetTempPath()` on Windows. Select files of any extension whose `LastWriteTimeUtc` is at or before one UTC cutoff. `-Days` defaults to 30 and accepts positive Int16 values. Reparse points are excluded before traversal. Literal paths, ancestry, type, identity, and timestamps are revalidated before removal. The native deletion handle requests `DELETE` and `FILE_READ_ATTRIBUTES` without file-content read access and without sharing writes or deletes, so the final timestamp is read from the opened object and an ordinary content/data writer or rename cannot move the candidate after validation.
 
 Retention and byte totals use metadata observed from the deletion handle. The same object can remain eligible after a content change if its observed timestamp is still old. Read-only sharing blocks data writers and renames, but attribute-only timestamp changes can still occur after the observation; the retention check and deletion are not atomic. See the [full retention contract and regression evidence](issue-30-retention-handle.md).
 

docs/Clear-WindowsTemp.md

@@ -12,7 +12,7 @@ Clear-WindowsTemp [-Days <Int16>] [-RemoveEmptyDirectory] [-PassThru] [-WhatIf]
 
 ## Behavior
 
-Select files of any extension whose `LastWriteTimeUtc` is at or before one UTC cutoff. `-Days` defaults to 30 and accepts positive Int16 values. Reparse points are excluded before traversal. Literal paths, ancestry, type, identity, and timestamps are revalidated before removal. The native deletion handle requests `DELETE` and `FILE_READ_ATTRIBUTES` without file-content read access and without sharing writes or deletes, so the final timestamp is read from the opened object and an active writer or rename cannot move the candidate after validation. The Windows temp root is derived from the Windows special-folder API with a SystemRoot fallback, not from an environment variable alone. Run elevated for system-owned files; actual OS-root acceptance remains a 1.0 gate.
+Select files of any extension whose `LastWriteTimeUtc` is at or before one UTC cutoff. `-Days` defaults to 30 and accepts positive Int16 values. Reparse points are excluded before traversal. Literal paths, ancestry, type, identity, and timestamps are revalidated before removal. The native deletion handle requests `DELETE` and `FILE_READ_ATTRIBUTES` without file-content read access and without sharing writes or deletes, so the final timestamp is read from the opened object and an ordinary content/data writer or rename cannot move the candidate after validation. The Windows temp root is derived from the Windows special-folder API with a SystemRoot fallback, not from an environment variable alone. Run elevated for system-owned files; actual OS-root acceptance remains a 1.0 gate.
 
 Retention and byte totals use metadata observed from the deletion handle. The same object can remain eligible after a content change if its observed timestamp is still old. Read-only sharing blocks data writers and renames, but attribute-only timestamp changes can still occur after the observation; the retention check and deletion are not atomic. See the [full retention contract and regression evidence](issue-30-retention-handle.md).
 

docs/command-contracts.md

@@ -53,7 +53,7 @@ The temp commands own their mutations. They discover under an approved root, cap
 
 Retention and removed-byte accounting use the current metadata observed from the deletion handle. Discovery establishes identity and candidacy, not an immutable content snapshot. A same-object file may be removed after a content/length change if its observed last-write time still meets the cutoff. Read-only sharing blocks data writers and renames but does not block every attribute-only timestamp update; metadata validation and disposition are not atomic. The [issue #30 contract and fixtures](issue-30-retention-handle.md) define these limits.
 
-The implementation follows the safety intent tracked in [issue #28](https://github.com/SamErde/TheCleaners/issues/28) and [issue #29](https://github.com/SamErde/TheCleaners/issues/29). Broader NTFS/ReFS and Windows client/server acceptance still requires disposable Windows environments with recorded filesystem and runtime evidence; deterministic issue fixtures do not replace those gates.
+The closed [issue #28 directory-identity packet](issue-28-directory-identity.md) and [issue #29 deletion-rights packet](issue-29-delete-rights.md) record the merged deterministic evidence for this implementation. Broader NTFS/ReFS and Windows client/server acceptance still requires disposable Windows environments with recorded filesystem and runtime evidence; deterministic issue fixtures do not replace those gates.
 
 ## Preview contract
 

docs/deployment-validation.md

@@ -1,8 +1,8 @@
 # Documentation deployment gate
 
-The canonical documentation URL is `https://day3bits.com/TheCleaners/`, including the title-case path. Configuration, source help, the manifest, generated references, and canonical links must use that casing. The Zensical migration is open in [PR #41](https://github.com/SamErde/TheCleaners/pull/41); review, merge, fresh deployment, and lowercase-path acceptance remain open under [issue #26](https://github.com/SamErde/TheCleaners/issues/26).
+The canonical documentation URL is `https://day3bits.com/TheCleaners/`, including the title-case path. Configuration, source help, the manifest, generated references, and canonical links use that casing. Zensical [PR #41](https://github.com/SamErde/TheCleaners/pull/41) merged as `af330858b41335366476f0b845e3f73a3c1497d1`, and [issue #26](https://github.com/SamErde/TheCleaners/issues/26) is closed. Deployment run [35282935445](https://github.com/SamErde/TheCleaners/actions/runs/35282935445) and an independent live recheck verified its 36 canonical files and required navigation. Later deployments supersede that byte snapshot and require their own source-bound evidence.
 
-The lowercase project-prefix request is handled by the account-root Pages site before this project's generated files are selected. Zensical's native redirects map paths within the documentation output, so they cannot repair that missing project prefix. Case-only alias directories would also collide with canonical mixed-case directories on Windows. A companion account-root redirect is the remaining hosting-level option; this repository does not add ineffective redirect maps.
+The lowercase project-prefix request is handled by the separately owned account-root Pages site before this project's generated files are selected. Companion [SamErde/samerde.github.io#13](https://github.com/SamErde/samerde.github.io/pull/13) merged as `0b096e19b6058a0c60119d20b57ba7de7aa3236c`. Its account-root 404 page uses JavaScript to send the lowercase project prefix to the canonical title-case path; this is a fallback from an HTTP 404 response, not an HTTP 301/302 redirect. Zensical's native redirects map paths only within this documentation output, and case-only alias directories would collide on Windows.
 
 A documentation deployment is accepted only when the workflow proves all of the following for one source commit:
 
@@ -78,7 +78,7 @@ The following retained baseline validates the exact deployment gate for PR #37 m
 | Workflow verification | Passed after three complete attempts during propagation |
 | Independent live verification | Passed all 71 files and five navigation routes in one attempt |
 
-This closes exact deployed-byte and representative-navigation verification for that source commit only. The Zensical migration changes the generated site and therefore requires a fresh merged-source deployment and retained evidence before it can replace this baseline. Lowercase `/thecleaners/` acceptance also remains open in issue #26.
+This closes exact deployed-byte and representative-navigation verification for that source commit only. It is a historical pre-Zensical baseline. The Zensical migration checkpoint is the 36-file verification for `af330858b41335366476f0b845e3f73a3c1497d1` above; later source changes and deployments need fresh retained evidence. Lowercase compatibility is supplied by the separately owned account-root 404/JavaScript fallback described above.
 
 Before this gate was implemented, the September 17, 2026 live check found title-case `/TheCleaners/` HTTP 200 and lowercase `/thecleaners/` HTTP 404. GitHub Pages reported the title-case site URL, and the maintainer selected that working path as canonical.
 
@@ -92,4 +92,4 @@ The historical live check on September 16, 2026 found:
 | `https://day3bits.com/TheCleaners/` | HTTP 200 with the deployed MkDocs site. |
 | `https://day3bits.com/TheCleaners` | HTTP 301 to `/TheCleaners/`. |
 
-The historical run above remains useful only as the pre-gate baseline. Run 35257555130 and its independently checked retained evidence establish the current exact-source deployment claim.
+The historical run above remains useful only as the pre-gate baseline. Run 35257555130 established the later exact-source pre-Zensical deployment claim; the merged Zensical checkpoint and subsequent source-bound deployments supersede it.

docs/index.md

@@ -22,4 +22,4 @@ The temp cleaners preserve directories unless `-RemoveEmptyDirectory` is supplie
 
 Read [safety and confirmation](safety-and-confirmation.md), [migration notes](migration-to-1.0.md), and the [1.0 implementation ledger](release-plan-1.0.md) before using this prerelease. The ledger distinguishes prerelease evidence from product/lab and final 1.0 acceptance. The [repository README](https://github.com/SamErde/TheCleaners#readme) distinguishes the published Gallery prerelease from a source checkout.
 
-Canonical documentation: <https://day3bits.com/TheCleaners/>. The [Zensical migration](https://github.com/SamErde/TheCleaners/issues/26) is open in [PR #41](https://github.com/SamErde/TheCleaners/pull/41); review, merge, fresh deployment, and lowercase-path acceptance remain open.
+Canonical documentation: <https://day3bits.com/TheCleaners/>. The [Zensical migration](https://github.com/SamErde/TheCleaners/issues/26) merged in [PR #41](https://github.com/SamErde/TheCleaners/pull/41), and its canonical deployment was verified. The separately owned account-root site supplies lowercase compatibility through JavaScript on its 404 page; it is not an HTTP redirect.

docs/issue-28-directory-identity.md

@@ -2,9 +2,9 @@
 
 ## Scope and result
 
-This packet closes the remaining deterministic fixture gap in [issue #28](https://github.com/SamErde/TheCleaners/issues/28). The runtime already retains native Windows directory handles through candidate mutation and compares volume/file identity before non-recursive pruning. No runtime defect was found, so this packet adds a dedicated public-command regression suite without changing production behavior.
+This packet closes the remaining deterministic fixture gap in [issue #28](https://github.com/SamErde/TheCleaners/issues/28). [PR #43](https://github.com/SamErde/TheCleaners/pull/43) merged as `0829d076ac13095ed016c54ea96c4a8b6abd8287` and closed the issue. The runtime already retains native Windows directory handles through candidate mutation and compares volume/file identity before non-recursive pruning. No runtime defect was found, so the packet adds a dedicated public-command regression suite without changing production behavior.
 
-The initial implementation checkpoint used base commit `af330858b41335366476f0b845e3f73a3c1497d1` plus uncommitted test/documentation changes. It is retained below as historical evidence. The clean metadata-correction checkpoint records local committed fixture validation; final-head hosted CI across all supported runtimes and post-merge evidence remain separate checks.
+The initial implementation checkpoint used base commit `af330858b41335366476f0b845e3f73a3c1497d1` plus uncommitted test/documentation changes. It is retained below as historical evidence. Exact reviewed head `12db558565d39e1a52c726160a6b4014b72cf5ff` and the merged-source workflow results are recorded in the [release ledger](release-plan-1.0.md); they supersede the pending language in the historical checkpoints below.
 
 ## Deterministic fixture design
 
@@ -28,7 +28,7 @@ The second case demonstrates defense in depth when the primary handle barrier is
 | Preserve root, unrelated empty branches, recent files, and reparse points | The end-to-end boundary case retains the fixture root, an unrelated empty directory, a recent-file branch, a junction, and the junction target outside the cleanup root. |
 | Avoid path/timestamp-only identity proof | Tests use `FILE_ID_INFO` identities from the native interop. The fallback fixture explicitly matches creation time, last-write time, and attributes, then records unequal original and replacement identities while confirming the displaced original retains its planned identity. |
 | Keep `ShouldProcess` and error behavior | `-WhatIf` reports candidates and performs no mutation; mutation cases use explicit `-Confirm:$false`; a locked candidate with `-ErrorAction Stop` terminates with `TempFileRemovalFailed` and preserves directory ancestry. |
-| Validate the supported runtime matrix | Local coverage passed on PowerShell 7.6.6 and Windows PowerShell 5.1.26100.9444 with Pester 5.7.1. Full-matrix acceptance remains pending inspection of exact final-head hosted results, including PowerShell 7.4.20 and 7.5.11. |
+| Validate the supported runtime matrix | Local coverage passed on PowerShell 7.6.6 and Windows PowerShell 5.1.26100.9444 with Pester 5.7.1. Exact final-head and merged-source hosted evidence for PowerShell 7.4.20, 7.5.11, 7.6.6 and Windows PowerShell 5.1 is recorded in the release ledger. |
 
 ## Validation evidence
 
@@ -41,7 +41,7 @@ Local fixture runs used Windows **10.0.26200.0**, PowerShell **7.6.6** and Windo
 | Review base `581907e7d83c283de423c0f36d02b735c7153876` plus uncommitted refinement | 14 passed, zero failed/skipped/not-run | Historical first run with matching replacement metadata; reports `pester-review-followup-ps766.xml` and `pester-review-followup-ps51.xml` in the same temporary evidence directory. |
 | Clean correction `2372a218d04354df100c2d9188bc30c419764151` | 18/18 passed, zero failed/skipped/not-run | Includes the metadata-matching assertions and four documentation contracts. Retained reports: `issue28-final2372-ps7.json/.xml` and `issue28-final2372-ps51.json/.xml`. Test-file SHA-256: `d6f2c31c5625cec86cabee0fb5d9f856a40ed2f43ff3e479dbe326a2a8f8a6fa`. Strict Zensical 0.0.62 passed. |
 
-The clean correction's hosted build failed test-source analysis because two display-only `Article` parameters were unused; it did not pass the full build. Commit `da99d4ebdd0e8c76cba332eb506e06d2eda43691` removed those unused parameters and simplified the test descriptions without changing fixture logic. Its PowerShell parsers and PR-range whitespace check passed. Final-head hosted runtime reports, artifact inspection and post-merge results remain separate gates and are recorded in the PR and release ledger when verified.
+The clean correction's hosted build failed test-source analysis because two display-only `Article` parameters were unused; it did not pass the full build. Commit `da99d4ebdd0e8c76cba332eb506e06d2eda43691` removed those unused parameters and simplified the test descriptions without changing fixture logic. Its PowerShell parsers and PR-range whitespace check passed. These are historical correction checkpoints; the final-head and merged-source runtime, artifact and deployment results are recorded in the PR and release ledger.
 
 ## Limitations
 This is deterministic local NTFS fixture evidence, not Windows client/server, ReFS, real-system-root, elevated/non-elevated, hostile-filter, or product lab acceptance. Issue #28 does not require ReFS validation, and the production help already states that the checks cannot provide an atomic defense when a filesystem or filter does not provide stable file IDs. Deferred lab gates and final 1.0 acceptance remain open.

docs/issue-29-delete-rights.md

@@ -6,6 +6,14 @@ exact source and test results recorded below. It does not establish Windows
 client/server product acceptance, actual Windows-root cleanup, or ReFS runtime
 acceptance; those remain TC-003/004 release gates.
 
+[PR #44](https://github.com/SamErde/TheCleaners/pull/44) merged as
+`6fd8af169da631d17579a3c7eb3fa0aa8b285be0` and closed the issue. Exact reviewed
+head `abe5f4275b2d5b9a7a510aa0759413dbcf91a727` and merged source
+`6fd8af169da631d17579a3c7eb3fa0aa8b285be0` passed the supported hosted
+runtime/artifact matrix; merged-source analyzer and 39-file documentation
+deployment verification also passed. The [release ledger](release-plan-1.0.md)
+records the immutable runs, counts, digests and review boundary.
+
 No executable runtime source changed in this packet. The base implementation
 already met the selected native contract; the new work supplies the missing
 both-command ACL, error, identity, and reconciliation evidence.
@@ -95,8 +103,8 @@ Its merged source passed
 tests on PS5.1, with zero failures/skips/not-run. All eleven artifact wrappers,
 source/runtime reports and archives were independently verified. Issue #28's
 directory-identity packet also merged in [PR #43](https://github.com/SamErde/TheCleaners/pull/43)
-as `0829d076ac13095ed016c54ea96c4a8b6abd8287`. This packet is rebased onto both
-merges and will run the combined suite on its own final head before closure.
+as `0829d076ac13095ed016c54ea96c4a8b6abd8287`. This packet was rebased onto both
+merges before its own reviewed-head and merged-source verification.
 
 ## ReFS disposition
 
@@ -124,8 +132,8 @@ contracts, under PowerShell **7.6.6** and Windows PowerShell
 JSON/XML evidence is named `issue29-rebased-ps7` and `issue29-rebased-ps51`.
 The test-file SHA-256 is
 `d439b0d1fc4edc0ab2eb4f11fca87dd6a523c5667f6411169e2105e90581c082`.
-Final-head hosted validation and merged-source verification remain separate
-gates; these local results do not establish either one.
+These local results do not establish final-head hosted or merged-source
+verification; the later exact evidence is recorded above and in the release ledger.
 
 Independent Astra high review also ran exact clean pre-rebase head
 `7ce8c0f6796617c47c046a4d4c90ca2ed86d4a96` in fresh processes, with the native