ARCADIA-Studio/harness/scenario-group-removal-evidence-20260925/native-review.md

Bounded native evidence review — Scenario group removal

Reviewed 2026-09-25 UTC. Captured source: 43340b94a13f192c3b5d3c3112dbe87246790a44, build removal-app-build-1. No blocker found for accepting the two documented native runs as bounded evidence of this fixture/workflow. This is not acceptance of every #29 interaction, default-branch integration, or a release.

Reviewer independence and method

This reviewer authored the pure group-removal planner, preparation fixture, source-derived byte oracle, and initial provenance helpers. Therefore this is self-review of those parts, not an independent correctness endorsement of their shared assumptions. Other agents authored the App/view/input integration; review of its captured presentation and operation is independent of that implementation. The parent performed the native interactions. I inspected existing original images and records, independently recomputed hashes and direct whole-file equality in a read-only Python script, and did not run the product, archived helpers, Cargo, Git, or GUI automation. Only this review document was written.

Records examined: native-observation-notes.md; root fixture manifest and both source files; each run's prepared.json, started.json, finished.json, all twelve prepared immutable files, captured build result.json/source-proof.json/inputs.json, all saved-source snapshot receipts and evaluator outputs, all capture JSON records and existence of their listed images; fixture-preflight-1/result.json, both CLI reports/logs/fixture copies and its CLI executable. I checked the captured proof-to-build/input bindings, not a fresh reconstruction of Git blob provenance or the current checkout. Packaging/archive validation is outside this review.

Original images inspected

All names below are within run-1 unless stated otherwise. I inspected the full original image, using -1.jpg where the capture also contains the 16×16 window icon; -0.jpg is the full image for the compact/nonmaximized captures.

Captures	Direct visual result
27-review-page-one, 28-review-page-two	Review says 2 Scenario objects, 2 removed / 10 updated, 12 matches, two pages. The pages expose intake_lane, a, review_flow, b–h, saved_a and saved_b with distinct aliases despite repeated message names. Disposition labels distinguish removed selected objects from updated preserved records. Both footer actions are visible.
30-alias-filter, 31-empty-filter, 32-enter-keeps-review	@h shows only preserved h; @h_absent shows the explicit no-match state. The total impact remains 2/10. Capture 32 still shows the open review and unchanged empty query result. This corroborates the parent's reported Enter attempt, but screenshots alone do not prove which key was delivered or its focus route.
33-canceled, 35-delete-opens-review	No review; two selected remain, including primary alias a and highlighted participant/message. Capture 33 reports cancellation. Capture 35's filename is inaccurate: it provides no evidence that Delete opened a review. The notes correctly exclude native focused-Delete success.
38-confirmed-removal	Selection becomes zero; Intake participant/a disappear, two participant headers and seven unfinished message bodies remain. Status says two selected Scenario objects removed in one change, definitions preserved. The three operational activities remain listed. Saved A explains that seven unfinished positions are retained until endpoints are complete.
40-undo	Three participant headers and eight message arrows return; status says model change undone; selection remains zero. This corroborates the model transition, not restoration of transient selection.
47-size-recovery, 55-compact-review-expired	Expiry text is explicit and Remove is disabled; Cancel remains enabled and visible. The compact image is 1102×732 including window chrome. Its body scrolls while the notice/footer remain visible.
56-escape-cancel, 57-compact-valid-review, 59-compact-second-page	After the reported Escape, the review is gone and two selected remain. A fresh compact review has an enabled explicit Remove action. Both pages retain readable aliases; page two exposes e–h and both saved views. The footer is visible. This supports this fixture's compact layout, not arbitrary alias length, scale, or keyboard/screen-reader completeness.
61-redo, 64-saved-b-preserved	Redo status and the removed model recur with zero selected. Saved B remains navigable and shows its two participants/seven unfinished messages.
run-2/14-reopened-saved-a, run-2/15-reopen-saved	Fresh-process source shows Saved A, two participants, seven unfinished messages, and all three reusable operational activities. Capture 15 reports all source files saved.

The full compact captures are genuinely 1102×732 images; they do not establish that the client area has those dimensions. I did not infer successful panning, 100%-zoom header usability, or reliable initial nonmaximized navigation from the failed/recovered attempts described in the notes.

Exact source, immutable inputs, and lifecycle readback

Independent direct byte comparisons passed, without invoking the comparator or normalizing whitespace:

• Run 1 01-baseline, 02-cancel, 04-undo: exact original 4389 bytes, SHA256 70c32355b82393c03ef87b24862863e0a06c4dcb00cf2c0a84a7cfd2da687a8a.
• Run 1 03-removed, 05-redo and Run 2 01-reopened: exact original removal oracle 3856 bytes, SHA256 1cb04cbab8428fc672293f29783fffdeecaf6ec6d81d5439501c32e866c8264f.
• Both final working copies also equal that removal oracle. Every snapshot receipt pins the actual file, records exit 0, and has a matching PASS evaluator report and empty evaluator stderr. All snapshot timestamps fall within their recorded process lifetimes.

These complete-file comparisons substantiate the intended two deletions, seven sender clears, owner-list update, and pruning of only the deleted rows in both layouts, including preservation of all other source content/trivia. They also demonstrate that the source-derived oracle needed no post-observation revision. They do not replace an independent core semantics specification review.

Both runs' twelve prepared immutable files match their recorded hashes now, including the exact 120067072-byte GUI executable SHA256 e118e7f0a2ff53ac9c22a73d07555929d11e1ad917d430a7ae88d469aaa91155 and pinned libunwind.dll. GUI artifact hashes match the captured build receipt. Build/proof/input pins agree on source 43340b94…, 823 inputs, successful exit, and unchanged captured inputs. Run 2's initial pin and actual initial source equal Run 1's saved 05-redo bytes.

Run 1 PID 7904: started 01:55:58.923381, finished 02:09:03.784416 UTC. Run 2 PID 6756: started 02:09:43.998114, finished 02:12:09.320969 UTC. Both supervisors record exit 0, immutableUnchanged: true, and zero-byte stdout/stderr; these hashes recompute correctly. Started receipts bind their prepared records, executable paths, process creation identities and initial sources. All discovered capture records identify the corresponding run executable and have timestamps within its lifetime. This is recorded lifecycle evidence, not a fresh query of already-exited OS processes.

Run 1 has 62 capture records / 101 referenced image files; Run 2 has 15 / 29. Every image referenced by a saved capture record exists. No 46* record or image exists. The reported capture46 failure therefore has no image to inspect; its error/recovery description is the parent's operational account. It must remain a failed attempt, never be counted as a successful capture or replaced with capture47. This is consistent with discovery-based packaging; numeric labels are not a promise of a contiguous screenshot inventory.

The CLI preflight's two fixture copies, captured report/log pins and CLI executable pin match. Both reports say checked, exit 0, written: false; warnings are present. This establishes recorded parser/check success, not zero diagnostics or a full-model JSON export.

Acceptance boundary

The evidence supports contextual additive group selection, whole-set impact review/search/paging, explicit cancellation, explicit removal through the documented review, exact source restoration/reapplication after the reported Undo/Redo, safe expired-review presentation after resizing, compact review discoverability for these twelve rows, both surviving saved views, and persistence after fresh-process reopening.

The one-Undo/one-Redo claim combines the parent's action account, UI status/captures and exact source states. I did not directly introspect the history stack or independently replay the keys. Likewise, no screenshot proves rejection of every stale packet. Native Shift-click, successful focused Delete entry, keyboard-only confirmation, complete accessibility, larger/longer-label stress, Fragment/SA/reference-expansion cases, actual source-write failure, other platforms, integration and release acceptance remain outside these runs. Separate mounted/core tests must be cited under their own scope. With these limits retained, I recommend the parent accept the two runs for their stated bounded workflows and proceed to package verification.