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 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 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. 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.