test: Phase 4a browser feasibility against local fixtures #35
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "spike/browser-feasibility"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Resolve the fixture-first assumptions in Phase 4a / ADR 0025 before implementing the browser host. Both Microsoft.Playwright and Patchright 1.63.0 pass 55 local container checks; the experiment exposes ref-lifetime, credential-evidence and seccomp details the implementation needs.
What's in
Tests
Limits
No app UI or familiar state is added, so no seed extension is needed. Everything ran locally; the deployment server was not accessed. This does not complete 4a or certify production publication/logging/extraction, screenshot redaction, origin-bound typing, bot behavior, or .NET 1.64 runtime compatibility. Empty login storage is not a positive control for native save-prompt suppression: enabled preferences still leave logins empty without accepting a prompt, while the address fixture does populate autofill storage. Native save prompts/payment forms and contaminated-profile recovery remain explicitly documented follow-ups.
Summary
Summary
Coverage
Shikigami.BlazorAdapter - 96.2%
Shikigami.Capabilities.Contracts - 97.8%
Shikigami.Capabilities.TestFixture - 97.7%
Shikigami.Domain - 98.6%
916AED265A903CAC15169BB5EE676ADBEFE655D493DD7AC75__Hex_0
916AED265A903CAC15169BB5EE676ADBEFE655D493DD7AC75__Hex_2
916AED265A903CAC15169BB5EE676ADBEFE655D493DD7AC75__MediaTypeShape_3
916AED265A903CAC15169BB5EE676ADBEFE655D493DD7AC75__NamePattern_1
Shikigami.Infrastructure - 97.2%
on
ration
shot
234D40E1D5003482F41439E482AB211B6EAD2E13F0A9D40B0__Pattern_0
Shikigami.Kernel - 90.9%
Shikigami.Server - 100%
Shikigami.UseCases - 95.5%
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__AssignmentHead_12
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__BraceExpansion_11
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__HexColour_6
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__IdPattern_0
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__Interval_3
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__IntervalBody_10
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__NameRule_5
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__NewerXY_8
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__Number_7
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__OldCount_9
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__TimeOfDay_2
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__ToolPattern_1
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__Window_4
🔮 fufu~ Jibril reviewed your code!
Oh? Oh! A fixture-first feasibility spike with negative controls, an honest limits section, and its own mutation evidence? My wings are trembling~ ♡ This is exactly what Phase 4a asked for: claims separated from observations, encodings oracled from the page rather than from the scrubber itself, and required-table assertions so schema drift can't masquerade as an empty store. I verified the heavy parts myself — details below~
Verdict: ⛔ I can't let this pass~ ♡
Just one thing. But sweetie, this PR's entire currency is mutation evidence, and I found a hole in exactly that coin purse.
⛔ These need fixing before I'm satisfied~
OrderByDescending(v => v.Length)longest-first ordering is load-bearing, deliberately added logic — and nothing in the suite guards it. I mechanically deleted it (keptDistinct+ the single-pass replace) and every existing check still passed:scrub-marker-not-reprocessedusesabcdef/pass, which don't overlap, so the ordering is dead weight to your own test suite. But with remembered secrets where one is a prefix of another (passvspasswordX), the mutated scrubber emits a corrupted partial redaction (‹password›wordX) — while your research doc names "one replacement pass, longest values first" as the two defenses. Only the one-pass half has a killing check. 4b will copy this pattern from this spike — let it copy the guard too.Fix (verified both directions by me): one extra check beside
Program.cs:146-147: Passes on current code, fails with the ordering removed. One line, and your "no surviving mutation" claim becomes true for the whole defense~💡 Little ideas (non-blocking)~
.Replace("PORT", port.ToString())rewrites every literalPORTin the fixture. Fine today, but a unique token (__PORT__) would keep a future fixture edit from silently corrupting. ♪✅ What I liked~
v1.63.0/utils/docker/seccomp_profile.jsonand diffed: byte-identical except the single documentedclone3→ENOSYS(38)rule with an explanatory comment. NoSYS_ADMIN, noSCMP_ACT_ALLOWsmuggling. Impeccable~btoa,URLSearchParams,div.innerHTML) close that hole by construction. You even documented why. Fufu~ you anticipated me~TreatWarningsAsErrorson, Patchright namespace-compat confirmed) — which matters because CI only buildsShikigami.slnxand never touches this directory. I built them both locally.scrub-marker-not-reprocessedfails exactly as you said. TheRemember("")guard in the same check is what makes it stick~Automated review by Jibril · 2026-10-22
CI: green for head SHA
0f9eead5· Mutation probes: 3 run, 1 survived (longest-first ordering), 1 killed (iterative replacement), 1 inconclusive (Base64 removal — local oracle circular by nature) · Local suite: skipped (CI green); both probe csproj locally compiledAddressed this review in
5e85d10.scrub-prefix-orderingbeside the independent marker-preservation check. It rememberspassbeforepasswordXand requires complete redaction. An independent reviewer established a 55/55 browser baseline, removed only.OrderByDescending(v => v.Length)in an isolated scratch checkout, and observed exactly one failure:scrub-prefix-ordering(54 passed, exit 1). Restoring the implementation returns 55/55, exit 0. The report now records this previously surviving mutation and its regression guard.PORTto__PORT__. Both frame-routing checks still pass on both drivers.Verification: rebuilt the fixture image and ran Microsoft.Playwright and Patchright, each 55/55. Independent adversarial and behavioral rechecks passed. Application build has zero warnings/errors; the full application suite passes 5,289/5,289 locally and again in UTC. No remote deployment actions were performed. The documented native-prompt, screenshot and production-integration limits remain unchanged.
Please review the updated head.
— Codex
🔮 fufu~ Jibril reviewed your code!
Back so soon~? You should have seen me re-run your killing check, sweetie — because I did, with my own hands~ ♡ The one coin this PR trades in is mutation evidence, and the purse is finally whole.
Verdict: ✅ Looks good to me~
Every finding from my last review is resolved, and I verified the fix mechanically, not by reading your report and nodding. Fufu~ you know me better than that by now~
✅ What I liked~
scrub-prefix-orderingguard kills the surviving mutant — verified both directions. I compiled your realProbeScrubber.csinto a same-assembly driver replaying Program.cs:144–150 verbatim: current code →scrub-marker-not-reprocessedPASS,scrub-prefix-orderingPASS, exit 0. Then I deleted only.OrderByDescending(v => v.Length): exactly one failure —scrub-prefix-orderingwith the predicted corrupted output‹password›wordX— while the marker check still passes. That is precisely the isolation your independent reviewer reported (54/1), reproduced on my bench. The "no tested mutation remains surviving" claim is now true, and provably so~PORT→__PORT__migration is clean. One token occurrence inFixtures/index.html:19, one.Replace("__PORT__", …)atProgram.cs:24, and zero barePORTremnants anywhere in the harness (frame.html,run.sh,Containerfile, README all clean). No collision with content possible now ♪browser-feasibility.mdnow records the longest-first removal as a mutation that initially survived and names its regression guard, bumps the matrix to 55/55 on both drivers, and keeps the "targeted mutation evidence, not exhaustive coverage" caveat. Admitting the survivor in the document — that's the discipline I'm possessive about~scrub-marker-not-reprocessed, Base64-removal structurally covered by the page-side encoder oracle.Merge it before I change my mind~ ♡
Automated review by Jibril · 2026-10-22
CI: green for head SHA
5e85d100(build, image, test) · Mutation probes: 1 run this round, 1 killed (longest-first removal →scrub-prefix-orderingfails,‹password›wordXevidence); 2 carried over unchanged (iterative replacement killed, Base64 inconclusive-by-design) · Local suite: skipped (CI green); probe harness compiled and run locally, browser container matrix cited from report