NTFSSecurity/Tests/Lab/Acceptance-2026-10-09-quality-gate-paths.md

# Quality-gate paths follow-up acceptance, 2026-10-09

Live acceptance, in the lab, of the behavior that the fixes of
`ai/quality-gate-paths` change, as the handoff table of the
[path report](../Coverage/Quality-Gate-Paths-2026-10-09.md) asks. The branch
(28 commits on `f11ff41`, the head of #117; head `83149ee`, draft #118) is a
local candidate, tested from its extracted package with `-ModulePath`. It is
not a published package, and this record is not a claim that the quality gate
is complete. Architecture and cmdlet-design choices remain with the
maintainer (Decisions 16, 21, and 22).

## Method

New live tests, case 10 and one test of the Server role, check what each fix
changed. The same tests, controller, and lab ran against two builds, in new
processes for each edition: the candidate (`83149ee`) and the baseline
(`f11ff41`, the base of the branch). A test is evidence of a fix when it
passes on the candidate and fails on the baseline; a test that passes on both
is a control.

## Candidate and artifact identity

| | Candidate | Baseline |
| --- | --- | --- |
| Commit | `83149eedee0684bd0a0522865abd0bc6127f6bf5` | `f11ff412947b35d682878ac4a8121c949868fcb2` |
| `NTFSSecurity.dll` SHA-256 | `40D0C8A6B819F15AE69A21D4D510B3B3CFCE2D93294368046C707BD558E67C1F` | `96F087E2AA39D521018346CC9F0A23C8AE2EE2D8CB39AE0E9B7A9325CF47AB73` |
| `NTFSSecurity.5.0.0-rc7.nupkg` SHA-256 | `2AAE3403A2D1C3AEE5156F05441E46B85B855AF95B46A7B73D2F80435513D71D` | `06244B161F76F3A9DCCCFDE3D7D6C5D0D5FEB625127FBF1B298D935BCBD8A2E2` |
| `NTFSSecurity.zip` SHA-256 | `A5AFA241DCA5DF87080A9801BB336282BD424D70DA395F6456F2D74B7FC8076A` | `3DF287C9AC4A311E4093DE519DED046B94109F51B513ACBC1653EF483DB3A2C0` |

- Each build is a Release build (.NET Framework 4.5.2) in an isolated worktree
  of its commit, packaged by `.github/scripts/New-ModulePackage.ps1`. Both
  carry the label `5.0.0-rc7` and one assembly version, so every run used a
  new process. All 11 files of each tested module folder equal the extracted
  `NTFSSecurity.zip` byte for byte (SHA-256). The first packaging attempt, at
  20:41 UTC, stopped in both builds at the check of the build script that
  compares the package folder with the extracted zip ("The extracted ZIP
  differs from the module folder"); the logs of that attempt are kept. I
  changed the script (20:43) and built both again; the files that the lab
  tested are those of the second attempt, and the cause of the first
  mismatch wasn't recorded.
- Test source, identical in both runs (last written 20:56 and 20:54 UTC,
  before the candidate run started at 21:02): `NTFSSecurity.Live.Tests.ps1`
  (Git blob `67b85efeb45af67070538f241c203c4afa38b6f4`) and
  `Invoke-NTFSSecurityLabTest.ps1` (blob
  `0b46427bc32b0b15449e283a2a6cf67879937541`). Both are in the commit that
  adds this record.

## Tests added

Case 10 adds 78 tests per edition to the 166 of the acceptance at `3442194`
(244 in all): 75 in the roles on the client and 3 for the state that the file
server finds. The fixture adds the folder `Case10` with delegated Full
Control, the folder `Locked` that Administrators own, and files that
Administrators own for the cases of `Set-NTFSOwner`.

| Describe (roles) | Tests | Fail on baseline | Fail on candidate | Fix |
| --- | ---: | ---: | ---: | --- |
| An item that the account owns and whose owner may not change its permissions (Delegate) | 2 | 2 | 0 | `c7a0383` owner restore |
| InheritedFrom of access entries that Windows cannot resolve (3 roles) | 3 | 3 | 0 | `2909a1c` |
| InheritedFrom of audit entries that Windows cannot resolve (ServerAdmin, Admin) | 2 | 2 | 0 | `2909a1c` |
| InheritedFrom of an item below a folder whose permissions the account cannot read (Delegate) | 2 | 1 | 0 | `2909a1c` |
| A later command that ends the pipeline or throws, for the item cmdlets (3 roles; 16 each) | 48 | 48 | 0 | `c77ecbf`, `40bf6a8` |
| A later command and the error of a folder that Get-ChildItem2 cannot read (Delegate) | 3 | 2 | 0 | `c77ecbf` (break), `d44a200` (throw) |
| Get-ChildItem2 -Filter (3 roles; brackets, `*.*`, null) | 9 | 9 | 0 | `ee7c105`, `40bf6a8`, `ae3078f` |
| Privileges when a later command takes the debug messages (Delegate, Admin) | 6 | 4 | 0 | `d44a200` |
| State of the file server: only the first item changed (Server; one per role) | 3 | 3 | 0 | `c77ecbf`, `40bf6a8` |

The tests that pass on the baseline are controls (a precondition, or the
privileges the cmdlets hold). `b14c90b` (public object APIs) has no lab
scenario; the package smoke below runs its unit tests. The fix of the leaked
native buffer has no observable guard.

A first run of the new tests on the candidate in Windows PowerShell failed
five tests. All five were errors of the tests, not of the module: a native
`icacls` call that Pester's `Stop` turned into a terminating error, and
assertions that expected a descriptor to be written at a verbose stop, which
that stop prevents. The tests were corrected, and the runs below are complete
runs of the final test files.

## Package smoke

Before the lab run, the eight unit-test files that guard the fixes ran
against the extracted candidate package in a scratch tree, in the four
configurations of the report (650 cases each): elevated Desktop 643 passed,
elevated Core 642, basic Desktop 528, basic Core 527; none failed; 7, 8, 122,
and 123 were skipped by their own conditions, which the report's eligibility
check covers.

## Lab and rollback evidence

`WindowsAccessControlLab`: F1ADC1, F1BDC1, F2DC1, F3DC1, F1AFile1 (client),
and F1AFile2 (file server), all Windows Server 2025 (10.0.26100). At
20:41 UTC, authenticated WinRM, LDAP RootDSE, Kerberos tickets, member secure
channels, and clocks (skew at most 7 s) passed on all six machines. At 20:43
UTC, before the first test run, no `NTFSSecurityLive` OU or `NtfsLive*`
account existed. The runs changed no VM, operating system, or network
setting. A process listing at the start showed no other controller of these
tests on the host; it wasn't kept as a log.

Six checkpoints named `ntfs-qg-paths-83149ee-before-acceptance` were taken
at 20:45 to 20:46 UTC, one per machine; the Hyper-V listing that shows the
names is kept with the evidence. The policy of each machine is Production,
but Hyper-V reports the type Standard. As before, Production classification
is unverified, and no checkpoint was restored or deleted. Every machine now
carries seven checkpoints of the acceptances since 2026-10-08, F1AFile1 eight.

## Live results

Candidate run 21:02 to 21:19 UTC, baseline run 21:22 to 21:39 UTC, each in
Windows PowerShell 5.1 and PowerShell 7 against the extracted package. Both
editions gave the same counts in each build.

| Build | Role | Passed | Failed | Skipped |
| --- | --- | ---: | ---: | ---: |
| Candidate | Delegate | 69 | 0 | 0 |
| Candidate | ServerAdmin | 34 | 0 | 0 |
| Candidate | Admin | 64 | 0 | 0 |
| Candidate | Server | 76 | 0 | 1 |
| Baseline | Delegate | 42 | 27 | 0 |
| Baseline | ServerAdmin | 13 | 21 | 0 |
| Baseline | Admin | 41 | 23 | 0 |
| Baseline | Server | 73 | 3 | 1 |

Candidate, both editions: 486 passed, zero failed, two skipped; the skip is
the test that needs the module in the Server role, which doesn't import it.
Baseline, both editions: 338 passed, 148 failed, two skipped. Every role
exited 0 on the candidate. A joined verification of the result files (not of
the counts) found the same 488 tests in both builds, no duplicate, and every
one of the 148 baseline failures passed on the candidate. The 148 failures
are 74 tests in each edition, all among the 78 new tests of each edition
(case 10 and the state test); the four that pass on both builds are
preconditions. [The results file](Acceptance-2026-10-09-quality-gate-paths-Results.csv)
lists the 156 results (78 tests in two editions) with both outcomes and the
first line of the baseline message.

What the baseline shows, from its messages:

- Owner: `RestoreOwnerError ... (5) Access is denied` for the unchanged owner.
- `InheritedFrom`: a text of 13 characters instead of the 14 of
  `unknown parent`.
- Later command: the `Downstream failure` of a `throw` never reached the
  caller (the messages read `Expected like wildcard '*Downstream failure*' to
  match $null`), and a `break` of a later command didn't leave the caller's
  loop. For `Select-Object -First 1`, see the next section.
- `-Filter`: no result for a name with brackets; `*.*` returned only the
  three names with a dot and dropped `NoExtension` and `NoExtensionFolder`;
  `$null` gave `ArgumentNull` instead of the parameter validation error.
- Privileges: `TakeOwnership` still enabled after the pipeline stopped.

### Baseline failures without a message

Seven tests of each role, 21 per edition and 42 in all, fail on the baseline
with an empty message, and Pester prints no line for them: `Select-Object
-First 1` for the five item cmdlets, the verbose stop of
`Set-NTFSSecurityDescriptor`, and the debug stop of `Set-NTFSOwner`. This lab
run doesn't show what the baseline did in them. The State test of the Server
role shows it only for `Remove-Item2`: in each role, the second item was
removed after `Select-Object -First 1`. That test stops at its first failed
assertion, so it says nothing about the other cmdlets, and its assertions for
the debug and verbose stops check only that the second item is as it was,
which is also true when the client test never ran.

To close the gap, the bodies of these tests ran afterwards on this host, in a
sandbox below TEMP, with the settings of the runner (Pester 5.7.1,
`ErrorActionPreference` Stop), one build in one edition per process
(`Acceptance\Probe-LaterCommand.ps1`; it isn't part of the acceptance, and
it didn't run on a share). The result is the same in Windows PowerShell 5.1
and PowerShell 7:

| Cmdlet | Baseline `f11ff41`, after `Select-Object -First 1` and after `throw` | Candidate `83149ee` |
| --- | --- | --- |
| `Remove-Item2` | both items removed | the second item stays |
| `Copy-Item2` | both items copied | only the first is copied |
| `Move-Item2` | both items moved | the second item stays |
| `Set-NTFSOwner` | both owners changed, also at the debug stop | the second owner stays Administrators |
| `Set-NTFSSecurityDescriptor` | both descriptors written | only the first is written |

All 12 tests of the probe (seven stop rows, five `throw` rows) fail on the
baseline, the seven stop rows with no error record, as in the lab, and the
`throw` rows with the message of the lab; all 12 pass on the candidate. At the
verbose stop of `Set-NTFSSecurityDescriptor`, neither build writes a
descriptor, because the stop comes before the first write, so that failure on
the baseline isn't a change of state.

## Cleanup and review

Before the removal, the SIDs of the fixture were saved from the four domains
(10: seven in `a.forest1.net`, one each in `b.forest1.net`, `forest2.net`,
and `forest3.net`). The fixture was removed at 21:40 to 21:41 UTC with
`Invoke-NTFSSecurityLabTest.ps1 -RemoveFixture`. A separate read-only check
at 21:41 UTC, not the wrapper's marker, found in all four domains no
`NTFSSecurityLive` OU and no `NtfsLive*` account, and on F1AFile1 and
F1AFile2 no share, no `C:\NTFSSecurityLive` or `C:\NTFSSecurityLab`, no
`NtfsLiveLocal` group, no fixture member of Administrators, Access Control
Assistance Operators, or Remote Management Users, and no profile of the ten
SIDs. No checkpoint was restored.

One independent, read-only, static review of the finished change (tests,
fixture, README, this record and its results file, and Decision 22) ran
before the first commit. The custom `security-reviewer` can't start because
its configured model is unavailable, so the built-in code-review agent did
it. Verdict: approve with Minor; no Blocker and no Major. It confirmed that
the new tests can't pass vacuously (every precondition is asserted, the data
rows are not empty, nothing is shared between rows), that the fixture stays
below the guarded folders and throws when Administrators don't own the
files, and that the counts, the hashes, the 156 results, and the cleanup
facts of this record match the evidence. Its findings, all corrected in the
commit that follows the first: the fix that this record credited for the
`break` row, the claims about the State test and the 42 messageless
failures (now the section above, with the diagnostic), this heading, the
count of results, the wording about the folders before the run, the
truncated messages in the results file, the README row of case 10, and the
migration hint of item 8 and the comparison with `Copy-Item` in Decision 22.
It could not run anything, so the run state and the lab-wide claims rest on
the logs; the diagnostic above and the checkpoint listing close two of its
open points.

## Limits

- `Get-NTFSAudit` below an unreadable parent folder can't be built here: an
  account that may read the audit entries (it holds the Security privilege)
  also reads the DACL of an Administrators-owned folder. The audit scenario
  uses a file that was deleted after it was read, which reaches the same
  `unknown parent` text.
- The run covers the candidate package from disk (`-ModulePath`), not the
  published package, one lab, and Windows Server 2025 only. The other
  operating systems of Decision 21, the acceptance of the published
  prerelease, and the answer of a non-Windows file server (#34) stay with the
  other gates. The stable version remains 4.2.6.
- The candidate and the baseline differ only by the 28 commits; the test and
  controller files are the same.
- What the baseline did in the 42 failures without a message is shown by a
  local diagnostic, not by this lab run. A State test split per cmdlet and
  stop style would show it on the share too, and would need both lab runs
  again.

## Evidence

The result files, logs, hashes, readiness, checkpoint, snapshot, and cleanup
logs of both runs are in the session artifact
`4b12e2f4-d4c7-4a5d-883a-ddb7421c4848\files\lab-qg-paths` (local, not in Git);
so are the Hyper-V listing of the checkpoint names
(`checkpoints-83149ee-names.csv`) and the outputs of the diagnostic
(`runs\diagnostic-mute`, and `runs\diagnostic-mute-first-run` from before the
probe listed owners and entries). The per-test results of case 10 are in
[the results file](Acceptance-2026-10-09-quality-gate-paths-Results.csv). The
scripts that build, package, run, and clean up in this acceptance contain
paths of the session folder and stay in the session artifact; the generic
ones that it used, `Validate-LabResults.ps1` (the check of the result files)
and `Probe-LaterCommand.ps1` (the diagnostic), are in the folder
[Acceptance](Acceptance).