# Documentation ownership deployment fix, 2026-09-09

The owner's two Execute attempts for release `20260909-175028-829c4bb` failed at
Install ordinal 5, the `Sibyla.Docs` ownership check. Web/API ownership passed.
The journal records `SIBYLA-S2-PRECONDITION-OWNERSHIP`; all later installation
steps were not reached. Before/after IIS configuration and production metadata
hashes match. Failure journals and IIS backups were created; no host activation
occurred. Evidence remains under
`local/artifacts/persistence-regression-260909/release/E2-Execute-20260909-233245-*`
and the earlier `233148` attempt.

IIS correctly serves `D:\fileStorage\repos\GOTT.Sibyla\docs`. The input validator
had already been updated after the repository rename to reject
`GOTT.Sibyla.Legacy`, but the Windows adapter independently rejected `GOTT.Sibyla`.
The adapter now uses `DocsPath.ForbiddenSegment`, sharing the validator's rule.
Exact documentation-root equality and exclusive pool/site ownership still apply.
No IIS path or legacy resource was changed to work around the check.

The module was built in the isolated
`D:/fileStorage/tmp/sibyla-deploy/docs-ownership-260909/candidate` checkout because
the owner's existing PowerShell console locks the original module DLLs. The new
launcher must start a fresh Windows PowerShell process to load the corrected
module rather than reuse assemblies already loaded in that console.

Read-only adapter verification passed for the current web/API/docs sites, rejected
a wrong docs root, accepted the current repository and rejected the renamed legacy
repository in both normal and mixed case. The IIS configuration hash was unchanged.
The probe and result are `check-ownership.ps1` and `ownership-check-rerun.txt` in
the release evidence directory. The first probe compile error is retained separately.
The same probe against the original module reproduces only the docs ownership
failure. The full deployment suite passes 1,266/1,266 tests, and all 173 published
application files still match their recorded hashes.

The application release remains pinned to `829c4bb`; only the deployment tooling
candidate changes. A new candidate fingerprint and fresh WhatIf are required before
retrying Execute. The prior failed attempts are not resumed because no deployment
mutation needing compensation was reached. C6 protections remain unchanged.