Files
stack/docs/reports/verification/1050-successor-remediation
be-coder-07 378bc1afe3
ci/woodpecker/pr/ci Pipeline was successful
ci/woodpecker/pr/greenfield-install Pipeline failed
fix(installer): close detector false-pass gaps
2026-08-05 19:00:22 -05:00
..

#1050 successor remediation verification

Head under test before remediation: e5d5c8495a070af2dcd393cace287fe74a8a819e.

This change strengthens the expected-RED detector; it does not repair the intentionally failing greenfield rows. The #869 hooks remain unwired.

A1 — P0 reason binding

RED first:

$ bash tools/verify-greenfield-expected-red.test.sh
[test] FAIL: vacuous P0 PASS satisfied the expected-RED contract without identity/context evidence
exit=1

The pinned manifest now has an explicit phase-reason binding against the final P0 row: target mosaic, uid 1001, equal HOME and passwd HOME, /bin/bash, privilege=user, x86_64, glibc, and version-shaped Node/npm evidence. All three cases structurally require exactly one P0 reason binding. The greenfield fixture's final P0 row now emits and validates the same complete identity/context evidence, so an unrelated earlier P0 line cannot satisfy the binding for a vacuous final row.

Pipeline 2224 and the successor's pre-change fixture run also exposed a stale next-lane P6 reason left behind by the already-closed B6 remediation: actual behavior is a fail-closed runtime-link action refusal with #869 hooks left inactive and a persisted required P6 failure, while the manifest still expected dead hooks to be active. The pinned reason now matches the stronger measured refusal (runtime linking/activation action reported a required failure); no verdict changed and #869 remains unwired.

GREEN:

[test] PASS: P0 PASS must bind target identity, HOME, shell, privilege, architecture, and runtime reason

A2 — fail-closed P4 enumeration

RED first: a find control emitted only the safe root, omitted an unsafe mode-0666 child, and exited 73. The process-substitution consumer discarded that status:

[test] FAIL: P4 accepted a partial created-path inventory after find failed
[test] FAIL: P4 did not report failed created-path enumeration
exit=1

P4 now captures the NUL-delimited walk into a temporary file, checks find to completion, and only then evaluates the complete inventory. A failed walk reports that enumeration failed and returns a P4 finding.

GREEN:

[test] PASS: P4 rejects an incomplete created-path inventory
[test] PASS: P4 attributes the failed created-path enumeration

B — deterministic TERM no-exit control

Woodpecker pipeline 2224 at the original head reported 32 passed, 2 failed: the no-exit fixture did not exit zero or report sync success. The premise was not stale: the same fixture passed 34/34 on another filesystem.

A controlled reverse-sorted find -print0 walk reproduced the pipeline result exactly (32 passed, 2 failed). Root cause: signal injection was tied to guides/E2E-DELIVERY.md; whether required tools/ content remained after restore depended on filesystem enumeration order. The test was measuring path order as well as trap semantics.

The generated fixtures now damage a real target path after the snapshot is armed, self-signal immediately before the complete normal sync, and differ only in the explicit handler exit. Therefore a no-exit handler always restores, returns, runs the full sync, mutates the restored target again, and reports completion independent of walk order.

GREEN on both native and reverse-sorted enumeration:

RESULT: 36 passed, 0 failed

Mutation sensitivity: restoring exit 1 to the nominal no-exit fixture makes the control RED (32 passed, 4 failed), including failures of the zero-exit and resumed-success assertions. The control can still fail for its stated reason.

Enumeration-class sweep

The sweep covered production enumeration in tools/install.sh and packages/mosaic/framework/install.sh, plus process-substitution consumers in the C1 shell-test surfaces. Framework installer file, operator, durable-snapshot, and pruning walks already capture and check their producer status. P4's created-path walk was the reviewed unchecked instance.

One additional order/completeness dependency was found in source acquisition: find "$WORK_DIR" ... | head -1 hid find failure and selected arbitrarily when an archive produced multiple top-level directories. RED first, the extraction fake produced two roots and the lane test stopped at that new assertion with exit 1 because today's code selected one. Source acquisition now captures and checks the complete NUL-delimited walk and requires exactly one extracted root. The lane suite is green with the multiple-root rejection. No remaining production installer enumeration uses unchecked process substitution or first-row order as authority.