[antianqi]

Scope note. This PR grew over 21 review rounds. It started as "add
three optional fields to status.json" and now carries the whole
mcode-island widget: click-to-toggle, tool-verb messages, family
tinting, secret redaction, and the status.json write protocol. The
description below is organised by what the change does, not by the
round it was written in. Each section names the review round that
asked for it, so a reviewer can go straight to the part they care
about.

Round 21 (the head of this branch) answers the three remaining
blockers from the 2026-10-09 review, one commit each:

commit	addresses
614d9a1	the detector surviving a terminating error in the main loop
4ae074f	#1 — the metadata refresh was not an atomic read-modify-write
3df799d	#2 — PostToolUse classified a structured result as a success
807aaf5	#3 — the local runner ran fewer steps than the workflow
d4ab8e3	the hook subprocess section is Windows-only
3bae385	dragging the pill no longer shows a white box

What this changes

1. The status.json write protocol is now atomic across processes

status.json has two independent writers: the detector daemon
(mcode-status-detect.ps1) and the agent hooks (through
notify-island.ps1, a child process per tool call). They had no mutual
exclusion at all.

scripts/lib/Status-Store.ps1   (new)

One place holds the protocol, shared by both writers:

Enter-StatusLock / Exit-StatusLock	exclusive cross-process lock on a sibling lock file, opened with FileShare.None — a real OS file lock, not a flag file whose presence we poll
Read-StatusSnapshot	one read of the whole status object
Write-StatusSnapshot	atomic replace (staging file + rename) that stamps a monotonic version and ts

Three defects came out of this:

• The detector read the file twice per write. The loop read
  state/message/family at the call site, then Write-Status read
  step/detail/source again. A hook write landing between the two
  reads was either mixed into a stale payload or lost outright.
  Everything now derives from one snapshot, taken under the lock.

• Both writers staged through the same status.json.tmp path. One
  could rename the other's half-written file into place, and the loser
  then failed its Move-Item. The detector runs under
  $ErrorActionPreference = 'Stop' with no catch around the write, so
  that failure killed the daemon — the pill froze on the last
  status.json with no visible cause.

• The replace could lose a sharing violation. MoveFileEx with
  REPLACE_EXISTING fails when the target is open by a reader that did
  not share delete, and the widget polls status.json every 400 ms
  with Get-Content, which opens with FileShare.Read. Measured on
  the dev host, not inferred. The replace now retries briefly.

The arbitration read and the write it authorises are now one critical
section too: previously a hook push could be judged against a stale
snapshot and then overwritten by the write that stale snapshot had
authorised.

Schema change (additive): status.json gains a version field. It
is optional — the widget reads every field through
PSObject.Properties, so an older widget ignores it and a newer one
tolerates its absence. The existing sentinel convention is unchanged:
absent means -1 / -1 / "".

2. A failed tool no longer shows as a success

PostToolUse classified the tool result by stringifying it and matching
a textual error prefix. A structured {isError: true} stringifies to
@{isError=True; ...}, which matches no prefix — so a failed tool
was reported as done and the pill showed green. The detector already
read the structured boolean from the session log, so the two producers
of the same state disagreed about what a failure was.

Test-ToolResultError now reads the structured boolean first and falls
back to the textual heuristic only for a bare string.

3. The detector survives a terminating error in the main loop

The loop had no catch. Any terminating error escaped it, fired the
finally, logged "detector stopped" and exited the process — while the
widget kept running, so the pill just froze with no visible cause. The
loop now logs the exception type and retries on the next tick.

4. The pill: click-to-toggle, tool verbs, family tinting

• Click the pill to show or hide the CLI window. The show path uses
  SW_MAXIMIZE: SW_SHOW and SW_RESTORE both preserve the window's
  pre-hide size, so a window that had been accidentally resized came
  back as a 480×84 strip.
• Tool verbs instead of bare tool names. bash : {"command":...}
  became Running git status / Ran / Command failed. The mcode CLI
  TUI already had this descriptor table; the pill now does too.
• Family tinting. Seven families (shell / read / write / search /
  task / web / plan) each get their own colour on the dot, the pulse
  ring and the progress bar. The palette is asserted to be at least
  CIE76 dE 20 apart in CIELAB — plan and search were both
  purple at dE 10.1 and are not distinguishable on the pill.
• ask_user reports waiting, not working. On a full access
  setup the permission hook never fires, so waiting was unreachable
  and ask_user was the only thing that could actually block the
  agent — while wearing the blue "leave it alone, it is making progress"
  signal.

5. Redaction, log bounds, and the UTF-8 BOM

• Typed Computer Use text never reaches a summary. The string was
  reaching status.json, the always-on-top pill and the append-only
  log — so anything typed through Computer Use landed in a screenshot or
  a screen recording. It now reports the action plus a character count.
• Credentials in a command are redacted too. The Bash branch was
  never touched, so curl -H "Authorization: Bearer ..." reached all
  three sinks in the clear. Two independent producers of that text
  exist (the hook path and the detector re-deriving it from the session
  log), so the helper lives in a shared lib and the check asserts that
  both consumers invoke it.
• Both append-only logs are capped at 1 MB / 300 lines. widget.log
  measured 37.2 MB and island.log 18.0 MB after 38 days, with
  widget.log growing ~3.6 MB/day.
• Non-ASCII .ps1 files carry a UTF-8 BOM. Windows PowerShell 5.1
  decodes a BOM-less script with the system ANSI codepage; on a zh-CN
  host that is GBK, so the detector's C# here-string stopped being a
  here-string and the script died before its first statement. This is
  pre-existing, not a regression from this branch — the round-19 head
  fails under 5.1 with byte-identical output. It had simply never been
  synced from a clean checkout on a non-UTF-8 host.
• The 5h-usage disclosure named a host the code never called. The
  README claimed the token is "never sent to a host other than
  api.minimax.io" — the code never contacted that host at all. The
  check now decodes the endpoint's byte array and compares the docs
  against that decoded truth, so it cannot rot into a second copy of the
  disclosure it is policing.

6. The pill no longer renders raw tool JSON, and skips boilerplate

The running message used to be "$verb " + (ConvertTo-Json $args), so
the pill showed Running {"command":"$ErrorActionPreference=\u0027Con….
Format-ToolArgs now returns the single most informative field per
tool, and there is no fallback to JSON: an unknown tool degrades to
less information, never to a dump. It also prefers the first line that
actually executes something, skipping the $var = ... preamble that
almost every agent command opens with.

Design compliance

no credentials	none added; the IPC is local-filesystem only. The one credential-shaped change is removing credential text from three sinks
no network	no network calls added. The 5h-usage path is unchanged and still the only outbound call
no telemetry	none added. island.log / widget.log are local append-only files, now size-capped
no third-party services	no new dependencies. Pure PowerShell + Node, no npm packages
cross-platform	no host-absolute paths introduced. The existing hardcoded-path scan covers every edited file
atomic write	staging + rename, now under an exclusive cross-process lock
schema	additive only. version is optional; the sentinel convention is unchanged

Validation

test-substep-progress.mjs   112 pass, 0 fail
smoke.mjs                    125 pass, 7 warn, 0 fail
all 31 .ps1 parse            31 / 31
detector under PS 5.1        exit 0
local Windows runner         all 5 steps OK

The 7 smoke warnings are pre-existing forward event-catalog entries
pending mcode 0.2.4+ Runtime confirmation; unchanged by this PR.

Negative-injection evidence

Per the round-4 lesson — test pass ≠ contract honored — every new
check was observed failing before its fix. 12 cases, each a minimal
change that breaks one clause of the contract; all 12 turn the suite
red, and the baseline restores to green after each:

	case	fails
N1	lock removed from the write path	2
N2	the write path reads the file twice	2
N3	metadata refresh stops preserving the sub-step	4
N4	state-inference stops clearing the sub-step	4
N5	the version counter stops advancing	3
N6	notify-island stages through a shared path again	1
N7	the inference call site passes -MetadataRefresh	1
N8	notify-island stops taking the lock	1
N9	metadata refresh stops preserving the state owner	1
N10	PostToolUse goes back to string-only classification	7
N11	the structured isError flag is ignored	4
N12	the structured failure is classified as a success	8

Three of these checks were false greens before they were right, and the
checks were rewritten rather than the failures being waved off:

1. The behavioral suite extracted a fragment of Write-Status and
   stubbed the reader. That stub is exactly what hid the second read —
   the bug the review named. The suite now runs the real
   Write-Status against a real status.json in an isolated
   %APPDATA%.
2. The two-writer test could have passed for the wrong reason (the
   surviving payload merely looked plausible). The version counter is
   a second, independent witness: two writers that read the same
   generation mint the same version.
3. The first version of the colour check measured raw sRGB luminance,
   which reports blue and purple as identical (0.02 apart) because they
   differ in hue but not brightness, and its regex asked for 6 hex
   digits while the table stores #AARRGGBB — so it matched nothing
   and reported "all 0 family colors are perceptually distinct", a
   vacuous pass.

The two-writer regression, in detail

Two real PowerShell processes interleave on one status.json: writer A
is the detector's read-modify-write, writer B is the agent's full push.
A signals that it has read, then waits for B to signal that it is
about to write; B's signal is published before B takes the lock,
so the ordering is deterministic either way.

with the lock      A holds it, B blocks, A writes, B writes last
                   -> the file carries B's values
without the lock   B writes immediately, A writes 400 ms later from
                   its stale read
                   -> the file carries A's stale values and B's write
                      is gone

CI

The mcode-island (windows-latest) job is the evidence for this
plugin — it is Windows/PowerShell/WPF/Win32, and [code]smith is
skipped on this repository. Five steps: parse every .ps1, token
set/show/clear in an isolated APPDATA, the real PreToolUse hook path
over stdin, a mocked usage-API roundtrip on a localhost listener, and
the behavioral suite. The local runner
(scripts/test-windows-workflow-local.ps1) mirrors it 1:1, all five
steps, so local reproduction and CI are the same test.

Not in this PR, on purpose

• Context-meter and token-speed readouts. The assistant message
  carries model and usage.{input,output,cacheRead,cacheWrite,totalTokens,cost}
  and nothing else — there is no contextWindow and no tps field.
  usage.totalTokens is a usable numerator, but the window size lives
  in mcode's provider config, and a rate derived from message
  timestamps would fold in thinking and tool time, which mcode 0.5.6
  explicitly excludes from the TUI's own figure. Shipping either
  without that denominator would put a number on the pill that
  disagrees with the TUI. Better no readout than a quietly wrong one.
• A faster caller lookup. Get-CallerFocusInfo asks WMI for the
  process chain, one query per level. Where the hook is spawned without
  a console, that measured 6.5 s per hook invocation on the dev host
  (where a console is inherited, the first branch returns
  immediately). Real, but a separate change with its own blast radius.

[antianqi]

Added second commit on top of feat/substep-progress (88bc7f8 → "pill click toggles show / hide CLI window", round-14):

• Extracts Resolve-CallerWindow helper (shared target-resolution logic)
• Adds Toggle-CallerWindow (gates on IsWindowVisible + IsIconic; SW_MINIMIZE for hide, SW_RESTORE + SetForegroundWindow for show)
• Click handler (MouseLeftButtonUp) now invokes Toggle-CallerWindow instead of Focus-CallerWindow — matches the user's 单击调出/单击收起 mental model
• Focus-CallerWindow kept as a thin wrapper, reserved for future auto-focus flows (e.g. needs_input auto-pop)
• smoke.mjs section 5c2 (4 checks) locks the toggle contract; negative-injection verified (replacing Toggle with Focus in click handler surfaces as FAIL)
• Tests: smoke.mjs 55 pass, 0 fail (was 51 before this commit)

Diff stat for just this commit: +120 / -33 across 2 files (mcode-island.ps1, smoke.mjs).

Upstream can squash or keep the two commits separate — they are different features (sub-step schema vs click toggle) with different blast radius, so I left them as two commits for review clarity.

[antianqi]

Updated commit e2f0dd3 (was 88bc7f8): Toggle now uses SW_HIDE / SW_SHOW pair instead of SW_MINIMIZE / SW_RESTORE, per the user's correction that SW_MINIMIZE left a thin Windows Terminal tab-bar strip on the desktop.

Behavior change:

• Click when CLI visible → SW_HIDE (no taskbar entry, no tab-bar artifact, fully gone)
• Click when CLI hidden → SW_SHOW + SetForegroundWindow (back exactly where it was)
• If the user minimized via taskbar (Windows Win+D etc.) instead of our toggle, the restore branch still detects IsIconic and calls SW_RESTORE so we don't end up stuck at the minimized state.

Drift lock updated accordingly: smoke.mjs now requires IsWindowVisible only (the toggle's core gate); the IsIconic check in the restore branch is covered by the existing Focus-CallerWindow smoke (round-11) which has identical Win32 helper imports.

PR comment 5794931764 is still accurate at the file/commit level; this update is just a behavior refinement within the same commit. Upstream can squash or keep separate.

Local validation:

• smoke.mjs: 55 pass, 7 warn, 0 fail (no other gates touched)
• Visual: not yet re-verified by user; waiting on a screenshot after the user clicks the pill post-merge

[antianqi]

round-15 fix: toggle show uses SW_MAXIMIZE to fix 480x84 strip bug

Commit 3b59cd2 on top of e2f0dd3. New force-pushed branch now has 3 commits on top of upstream/main.

Repro: clicking pill to hide WT works, clicking again to show → WT comes back as a thin strip (e.g., 480x84 tab-bar at top-left) instead of full-screen.

Root cause: Toggle-CallerWindow's restore branch called SW_SHOW + IsIconic + SW_RESTORE. All three preserve the window's pre-hide size. If WT got accidentally resized to 480x84 (e.g., mouse_event test artifact, Win11 Snap misfire, manual shrink), the second pill click re-shows it at that broken size — SW_SHOW / SW_RESTORE don't change the size of a non-minimized window.

Fix: switch restore branch to SW_MAXIMIZE. Forces maximize on hidden / minimized / normal windows alike; no-op on already-maximized. Collapses the SW_SHOW + IsIconic + SW_RESTORE triple into one call since SW_MAXIMIZE internally handles all three states.

Drift lock: smoke.mjs section 5c2 now requires the toggle else branch to call ShowWindow($r.Hwnd, 3). Negative-injected by replacing 3 with 5 — smoke emitted FAIL with the specific contract message, restored → PASS.

Local: 56 pass, 7 warn, 0 fail (was 55, +1 for the new check). CI re-running.

[hetaoBackend]

Request changes for exact current head b73752ba9bd23d2b5f5387e3660941e037520c0e.

Blocking issues:

1. plugins/antianqi/mcode-island/io.minimax.mcode/hooks/scripts/_lib.ps1:110-118 includes Computer Use tool_input.text in the status summary. PreToolUse persists/displays it through pre-tool-use.ps1:10-12, notify-island.ps1:115-124, and mcode-island.ps1:463,541-544. Passwords, tokens, verification codes, or other typed secrets can therefore appear in the always-on-top pill, status.json, and append-only log. Never include typed text in persistent/display summaries; add secret canaries.
2. Detector rewrites rebuild the entire status object without step, total, or detail (mcode-status-detect.ps1:398-419,588-612), so normal usage/todo refreshes erase the new sub-step state. Merge/preserve these fields and add an end-to-end writer-interleaving regression.
3. The restore SetWindowPos call (mcode-island.ps1:675-676) uses SWP_NOSIZE|SWP_NOZORDER but omits SWP_NOMOVE; with X/Y=0 it can move a restored secondary-display window to (0,0), while SWP_NOZORDER also ignores HWND_TOP. Correct the flags and test nonzero monitor origins.
4. PostToolUse passes -Detail with default Step=-1, but rendering returns only the base message when Step <= 0 (mcode-island.ps1:417-426), so the advertised visible detail is never shown. Align implementation, tests, and docs.
5. scripts/test-substep-progress.mjs is not invoked by the exact-head Windows workflow and its PowerShell lookup unconditionally returns a user-specific path instead of falling back to PATH. Wire the test into CI and fix executable discovery.

The existing parse/token/hook/mock-API Windows job, Ubuntu validation, and CodeQL are green, but they do not cover these new behaviors. [code]smith is skipped and is not evidence.

[antianqi]

Round 18 — tool-verb messages + family tinting

ab363d2 on top of b73752b.

The problem

The pill showed the bare tool name for every phase:

working → "bash : {"command":"git status"}"
done    → "bash 完成"
error   → "bash 失败"

working and done were both "bash" — indistinguishable at a glance. The mcode CLI TUI already solved this: launcher-GHPADSKI.js carries a descriptor table (HL[]) giving every tool a present-tense verb while in flight and a past-tense one on return, and its CO() renderer picks between them on status.

This port applies the same idea to the pill.

What the pill shows now

	before	after
in flight	bash : {"command":...}	Running git status
returned	bash 完成	Ran
failed	bash 失败	Command failed
unknown tool	mystery_thing	Using mystery_thing / Used mystery_thing

Plus family tinting, so the dot, pulse ring, and progress bar all shift color by what kind of work is happening:

family	tools	color
shell	bash, shell	green
read	read	blue
write	edit, write	yellow
search	grep, search, glob, list	purple
task	task, task_output, task_append, task_query, ask_user	cyan
web	web_search, web_fetch	pink
plan	todowrite, request_feature_enable	violet

Family color applies to thinking / working / waiting only. done stays green and error stays red — the result signal must not be repainted by whatever tool happened to run.

Screenshots (active families + result states)

Implementation notes

• Two tables, four helpers. $TOOL_ACTIONS (18 tools × 3 phases) and $TOOL_FAMILIES feed Get-ToolKey / Get-ToolVerb / Get-ToolVerbFallback / Get-ToolFamily. An unknown tool still gets a verb, so the pill never shows a bare identifier with no phase signal.
• Get-ToolKey caps the name at 64 chars. The name comes out of the session log, so it is untrusted in a hostile repo; a 4 KB "tool name" must not become a hashtable key.
• family joined the poll signature. Without it, two consecutive working states from different families would dedupe and the dot would keep the previous color.
• $MSG_FAIL / $MSG_OK removed. The three tool branches were their only consumers; leaving dead byte-array constants invites a future reader to assume they are still wired.

Validation

98 pass, 7 warn, 0 fail — 36 new checks in smoke sections 5d/5e.

16 negative-injection cases, each a minimal change that breaks one clause of the contract. All 16 turn the suite red; baseline restores to 98/0 after each.

Three of the 16 initially did not go red. Those were false greens, and the checks were rewritten rather than the failures being waved off:

1. The active-state gate was matched as a bare $State -in @('thinking','working','waiting'), but that substring also appears on the pulse, elapsed, and progress branches. Ungating the tint left those three in place and the check stayed green. It now anchors on the $Family -and $State conjunction.
2. The three state-branch locks were presence tests, but each state has two call sites (the ledger.jsonl branch and the messages.jsonl branch). Breaking only one left the other matching. They now assert a minimum occurrence count of 2.
3. The first harness used CRLF anchors against LF-only files, so every case reported SETUP-MISS and the suite looked green while nothing had actually run. Anchors now use LF, and a missing anchor fails loudly instead of counting as a pass.

Design compliance

• No credentials, no network, no telemetry, no third-party services — the tables are static data and the only I/O is the pre-existing status.json write.
• Cross-platform: no host paths introduced; the existing hardcoded-path scan covers both edited files.
• ASCII-only additions, so the PS 5.1 GBK parsing defense is unchanged.
• The session log is a local file the user already owns; reading tool names from it adds no new data source.

[antianqi]

Follow-up: plan vs search were the same purple

862f5a1. Caught while screenshotting the round-18 palette on the live widget.

plan was #8B5CF6 and search is #A855F7. On the dark pill those read as the same purple, so grep and todowrite were not actually distinguishable -- the exact thing the tinting was added to fix. plan moves to a desaturated slate #94A3B8.

smoke.mjs now asserts every pair of family colors is at least CIE76 dE 20 apart in CIELAB. Negative injection confirms it bites: putting plan back to #8B5CF6 fails with search (#A855F7) and plan (#8B5CF6) are only dE 10.1 apart.

The check itself had two false greens before it was right, both worth recording:

1. The color regex asked for 6 hex digits, but the table stores #AARRGGBB. It matched nothing and reported "all 0 family colors are perceptually distinct" -- a vacuous pass. There is now a parse-count guard that fails outright below 7 entries.
2. It first measured raw sRGB luminance, which reports blue vs purple as identical (0.02 apart) because they differ in hue but not brightness. That produced five false alarms on a palette that is fine in practice. Replaced with CIELAB dE.

A third fault was in the screenshot harness, not the code: a fixed 1.1s sleep after pushing status.json sometimes captured the previous frame, which made six of seven rows in the contact sheet look identical. The capture now waits for the widget to log the state it is about to render. Worth noting because it is the same class of bug as a false-green test -- a bad measurement read as a product defect.

All 7 family colors after the fix

100 pass, 7 warn, 0 fail.

[antianqi]

ask_user now reports waiting

012628f.

On a full access setup the permission hook never fires, so waiting was unreachable and ask_user was the only thing that could actually block the agent. It was reporting working:

working :: ask_user : {"mode":"questionnaire","requiresExplicitResponse":true,...

Blue dot, gear icon — the universal "leave it alone, it is making progress" signal — while the agent sat blocked on a questionnaire, plus a truncated JSON blob where the useful text should be. Three occurrences in the 9/24 log, so not a one-off.

Now it reads Asking 2 questions under an amber dot and a ?. It wears the state color rather than a family tint: a blocked agent must not look like an in-flight delegation.

Before / after

Three things this needed

1. $S_WAITING was never defined. The detector referenced it zero times, so any branch using it would have returned $null for the state. It is defined now.

2. waiting had to join both settle sets. The 60s no-activity fallback would otherwise downgrade a pending questionnaire to "已静默 60s" — exactly when the user has been away longest, which is the opposite of when the signal matters. And the takeover arbitration would let the pre-tool-use hook's working shadow it forever.

3. A bug found while testing. Get-AskQuestionCount originally took a parameter named $args, a PowerShell automatic variable. Shadowing it makes every read inside the function return the function's own argument list instead of the caller's value, so the count was 0 for every input and the message degraded to a bare "Asking". Caught by exercising the helper against seven argument shapes before wiring it up. The parameter is $toolArgs now, and smoke locks the name.

Validation

107 pass, 7 warn, 0 fail — 7 new checks in section 5d2, plus 7 negative-injection cases that all turn the suite red.

The real Infer-State from the deployed file was run against nine real messages.jsonl payload shapes: ask_user with 0/1/2/5 questions, a missing questions key, absent arguments, and arguments arriving as a JSON string. All six ask_user shapes infer waiting with no family; bash, read, and todowrite are unchanged.

One deliberate omission: the end-to-end check does not append synthetic toolCall records to a live session log. The running agent is writing to that file, and injecting phantom work into it could make the agent act on it. The check runs the deployed Infer-State over real payload shapes instead — same code path, no agent-state mutation.

[antianqi]

All five blocking items addressed

Five commits, one per review item, so each can be verified independently. 5fbda03.

#	Commit	Fix
1	1daee4b	typed text redacted from tool summaries
2	6fe1665	detector preserves step/total/detail
3	975fc86	restore path gets SWP_NOMOVE, drops SWP_NOZORDER
4	682f999	post-tool-use passes -Step/-Total
5	5fbda03	CI runs the behavioral suite

#1 — tool_input.text is no longer echoed. This was the one that mattered most: the string reached status.json, the append-only island.log, and an always-on-top pill, so anything typed through Computer Use landed in a screenshot or a screen recording. It now reports the action plus a character count and nothing else. Verified against the deployed hook with a canary — P@ssw0rd-CANARY-7d3e91 produced mcode-computer-use : type <22 chars, redacted> in both artifacts, with the canary in neither.

#2 — Write-Status is a read-modify-write now. Verified end to end: the agent pushed step=4 total=12 detail="running the test suite", and 15s later after a detector refresh all three were still there.

#3 — two separate bugs on the restore path. SWP_NOMOVE was missing, so a restored window on any monitor with a non-zero origin gets yanked to (0,0). Separately, SWP_NOZORDER was present alongside HWND_TOP, which makes Windows ignore hWndInsertAfter entirely — the z-order call was doing nothing. Both fixed. My round-17 smoke lock asserted the literal SWP_NOZORDER -bor SWP_NOSIZE, i.e. exactly the pair you asked to change, so it was rewritten rather than updated.

#4 — the detail can now render. Build-DisplayMessage only consults Detail inside the Step > 0 branch, so passing -Detail with the default Step = -1 discarded it on every call. Both Push-Island calls now pass -Step 1 -Total 1; PostToolUse is a single result and should not pretend to be a multi-step sequence.

#5 — the suite is wired. It is now the only suite that executes the PowerShell rather than grepping for substrings, which matters because it is where the canary lives.

Two things I got wrong while fixing this, both caught by negative injection

A false green in my own new test. The -Step check used [\s\S]*? across the whole file, so it passed as soon as one Push-Island call carried the flag. Removing -Step from the error branch alone left the suite green. It now matches each call individually.

A blind spot the flag check cannot see. Passing -Step $step is not enough — if $step is later set to -1, the flag check still passes and the detail is dropped again at render time, because -1 is this plugin's "no sub-step" sentinel everywhere. Setting $step = -1 turned every assertion green. There is now an explicit assertion that the local $step/$total are positive.

Validation

• smoke.mjs: 107 pass, 0 fail
• test-substep-progress.mjs: 25 pass, 0 fail (rewritten as a behavioral suite)
• 11 negative-injection cases, each reverting one clause of one fix; all turn at least one suite red, and the baseline restores after each
• All .ps1 files parse clean

One note on the CI step: on a runner whose console code page is not UTF-8 the suite fails on correct code unless the generated .ps1 gets a BOM and the child sets [Console]::OutputEncoding — a middle dot otherwise comes back as two GBK bytes and two correct assertions fail. Both are handled, because a suite that cries wolf is worse than no suite.

[antianqi]

Round 20 - five defects found auditing this plugin against the mcode 0.5.0-0.5.8 changelog

Three commits on top of the round-19 head (12b70cb, df3c14d, 4876ef1). All five were found by auditing the plugin against what mcode actually changed, and each is reproduced by a check that was observed failing before the fix.

#1 - the 5h-usage disclosure named a host the code never called

This one is a correctness problem for the disclosure itself, so I want to lead with it.

Get-5hUsage.ps1 obfuscates the endpoint into a byte array as a PS 5.1 parser-quirk defense. Those bytes decode to api.minimaxi.com. That is correct, and it is what the deployed detector actually calls - I verified it live rather than reading it: Get-5hUsage returns a real remainingPct with the configured token.

But the trailing comment on that same line said api.minimax.com, and the README said api.minimax.io in three places. One of them is an absolute claim:

The token is never logged, never written to any other file, and never sent to a host other than api.minimax.io.

That claim is false. The code never contacted that host at all. For a plugin whose proposal rests on four independent disclosure sections, an overstated isolation guarantee is worse than no guarantee - a reviewer checking host consistency finds code and docs disagreeing and is right to distrust both.

The new check decodes the byte array and compares the docs against that decoded truth. It deliberately does not hard-code the endpoint, so it cannot rot into a second copy of the disclosure it is policing, and it fails the moment the two drift apart again.

#2 - both append-only logs had no size cap, ever

mcode-island.ps1 has carried the comment "keep only the last 1KB" since the widget was written. Dbg was a bare Add-Content and never implemented it. The comment documented an intent that no code enforced.

Measured on my machine over 38 days: widget.log 37.2 MB, island.log 18.0 MB, with widget.log growing ~3.6 MB/day during active use. That is over a GB a year sitting in %APPDATA%, and nothing ever trimmed it.

Both writers now cap at 1 MB and keep the last 300 lines. The check is counter-gated (fires once per 256 KB written) so the 400 ms poll path does not stat the file on every call. Verified by pushing 3.4 MB through the new Log-Line body: final file 0.64 MB / 7064 lines, cap held across repeated truncation.

#3 - tool input carrying credentials was persisted verbatim

Round-19 #1 redacted Computer Use keystrokes, correctly, because they can be passwords. The Bash branch was never touched, so a command like curl -H "Authorization: Bearer ..." or export API_KEY=sk-... reached all three sinks - status.json, the append-only log, and the always-on-top pill - in the clear. Because the log is append-only and, per #2, was never capped, that credential stayed on disk indefinitely.

The subtlety worth flagging for review: there are two independent producers of this text. The hook path builds it from the hook event; the detector re-derives it from mcode's session log. A helper wired into only one is a silent half-fix - the pill looks clean while the detector keeps writing raw text to disk. So the helper lives in a shared scripts/lib/Protect-Text.ps1, both consumers call it, and the check asserts both consumers invoke it rather than merely defining it.

Scope is deliberately credential-shaped runs rather than whole commands. The command text on the pill is a documented feature (Bash : npm test); blanking every command would trade a real capability for a marginal privacy gain. What is not a feature is a bearer token sitting in a log for ten years.

16/16 cases, including 6 near-miss inputs that must not be redacted (--mode production, Select-String token, Windows paths, --secret-config, --author=, {"author":"Bob"}) so the filter cannot quietly destroy useful signal. And end to end through the deployed hook: Bearer <redacted> and token=<redacted> in status.json, with neither the JWT signature nor the key prefix anywhere in the file.

#4 - every non-ASCII .ps1 needed a UTF-8 BOM, and .gitattributes was the cause

This one I did not expect to find, and it is the most serious of the five.

I hit it while landing the rest of round-20: syncing the committed tree into the install directory with the documented Copy-Item -Recurse -Force flow produced a detector that could not start at all.

Windows PowerShell 5.1 decodes a BOM-less script using the system ANSI codepage. On a zh-CN host that is GBK, so a script containing non-ASCII comments is mis-decoded, the C# here-string in the detector stops being a here-string, using System; is parsed as PowerShell, and the script dies before its first statement with 92 lines of "missing using directive". The reported line number (38) is offset from the real one (46) because the mis-decode also desynchronizes the tokenizer's line count.

The trap: .gitattributes pins *.ps1 text eol=lf, and its comment claimed "PowerShell 5.1 reads CRLF fine, so LF avoids both failure modes." That is backwards. The policy is part of the cause, not a mitigation, and the comment is what let this survive.

This is pre-existing, not a regression from this branch. Control experiment: the detector as of ea96d75 - the round-19 head, before any of my work - fails under 5.1 with byte-identical output. It had simply never been synced from a clean checkout on a non-UTF-8 host.

Isolated A/B on one file, byte-identical except a prepended BOM: parses cleanly under 5.1 and runs to completion. Both CRLF and a BOM fix it; bare LF does not. I used the BOM rather than flipping .gitattributes to CRLF specifically because that would re-break the Linux-side validate.mjs CRLF handling the same comment was written to avoid. 8 files received a BOM, and .gitattributes now documents the constraint and warns that they must not be "cleaned up" - an editor that drops them breaks every sync.

Reviewer note: this commit reads as one changed line in each of 8 files. That is the BOM and nothing else.

#5 - a detector state write was inheriting a stale sub-step

Live symptom: the pill sat on step 1/1 showing a curl command from a tool call that finished several turns earlier, and nothing ever cleared it.

Round-19 #2 made Write-Status a read-modify-write, which is correct for the two metadata refreshes (60 s 5h-usage, todo progress) - those restate the current state rather than announcing a new step. But the detector also writes on state inference: it read a new tool call out of the session log and is asserting "the agent is doing THIS now". That message has no relationship to whatever sub-step a hook pushed last, so it inherited a counter that had no meaning there - and every subsequent write inherited it again, which is why it never cleared.

Write-Status now takes -KeepSubStep: state inference (default) resets, the two metadata refreshes preserve. The caller distinguishes them explicitly, because the inference path also has to be able to win the settle race against an agent push (round-19), so "who wrote last" is not a usable signal.

The checks that matter here are the call-site assertions. A switch nobody passes is dead code, and a test that only exercises the function body would not notice - so the suite asserts that the inference call site does not pass the flag and that exactly two sites do.

Two harness regressions I introduced and then had to repair

Worth stating plainly rather than quietly fixing, because both were shipped in 12b70cb:

1. Format-ToolSummary now calls Protect-SecretText, which lives in a separate lib. The suite extracts the function body and runs it standalone, so it died on an unresolvable command rather than on an assertion. The harness now dot-sources the lib, as _lib.ps1 does in production. smoke did not catch this - smoke is static and this suite is not. I reported "all green" on smoke alone before running it.
2. The round-19 section-3 extraction regex anchored on $prev appearing before $detailField. Wrapping the block in if ($KeepSubStep) inverted that order and the regex stopped matching silently, which would have surfaced as "could not find the preservation block" against a function that works perfectly. It now anchors on the initialisers and the payload construction.

Validation

• smoke.mjs: 116 pass, 0 fail (7 pre-existing forward event warnings)
• test-substep-progress.mjs: 32 pass, 0 fail
• Negative-injection: every new check observed failing before its fix. Check 9 additionally verified by deleting the detector's call site and confirming the suite turns red, then restoring.
• PowerShell 5.1 tokenizer over all 20 non-ASCII .ps1: 0 parse errors (8 failed before the BOM).
• Stale sub-step reset path verified live. The preserve path is not live-verified: observing it requires a tool call, and that call is itself a state inference which resets the sub-step. It is covered by the behavioral suite (real extracted function, real status.json fixtures, both modes) plus the static call-site assertions. I would rather flag that gap than present suite coverage as runtime evidence.

All five CI steps run locally before pushing

Step	Result
1 parse all .ps1	30/30
2 token set/show/clear (isolated APPDATA)	8/8
3 hook stdin/stdout under PS 5.1	5/5
4 Get-5hUsage via lib + mock listener	5/5
5 behavioral suite	32/0

Steps 2 and 3 were the ones at real risk from the BOM and the new dot-source; both run green.

Not in this PR, on purpose

The context-meter and token-speed readouts proposed during the same audit are excluded. Structurally enumerating the session store shows the assistant message carries model and usage.{input,output,cacheRead,cacheWrite,totalTokens,cost} and nothing else - there is no contextWindow and no tps field. usage.totalTokens is a usable context numerator, but the window size lives in mcode's provider config, and a rate derived from message timestamps would fold in thinking and tool time, which mcode 0.5.6 explicitly excludes from the TUI's own figure. Shipping either without that denominator would put a number on the pill that disagrees with the TUI. I would rather leave the pill without the readout than show a figure that is quietly wrong.

[antianqi]

Round 20 #6 - the pill no longer renders raw tool JSON

Reported as: the status line always trails some code.

The running-state message was built as

"$verb " + (ConvertTo-Json $args -Compress)   truncated to 60 chars

so the pill showed:

Running {"command":"$ErrorActionPreference=\u0027Continue\u0027\n...
Reading task {"task_id":"bg_0f858500-...","wai...

A JSON key, escaped quotes, and a truncation that lands mid-token. It was the noisiest thing on screen and the least informative. The done and fail branches were always clean - they render the verb alone - so this was confined to the in-flight state.

Before / after, same command:

	message
before	Running {"command":"$ErrorActionPreference=\u0027Continue\u0027\n...
after	Running $ErrorActionPreference='Continue'

skill turned out to be the worst offender: it is not in $TOOL_ACTIONS or $TOOL_FAMILIES, so it always took the JSON path. One of the most frequent tools on screen was also the least readable, which is what made this worth fixing rather than tuning.

Format-ToolArgs now returns the single most informative field per tool - command for shell, file_path for read/write/edit, pattern for grep/glob, query for web_search, url for web_fetch, name for skill, task_id for the task-output family. Unknown tools get a generic sweep of the common field names first.

There is no fallback to JSON. If Format-ToolArgs returns nothing the pill wears the bare verb: Using reads fine, Using {"name":...} does not. An unknown tool should degrade to less information, never to a dump.

This also fixes multi-line commands. A PowerShell command is usually several lines, so the old collapse-then-truncate showed the middle of a script fragment. It now takes the first non-empty line.

Redaction is unchanged and still applied on this path - the summary runs through Protect-SecretText exactly as the JSON did, so a credential in a command still cannot reach the pill or island.log by this route.

Tests

16 new assertions, negative-first. The blanket rule is asserted per case: no result may contain a JSON key, an escaped quote, or a \uXXXX sequence. Cases cover bash, multi-line bash, read/write/edit, grep, glob, web_search, web_fetch, skill, task_output, an unknown tool with an unrecognised argument shape, and a bearer token inside a command.

One trap, because it produced a genuinely misleading failure

The second parameter is deliberately not named $args. That is a reserved automatic variable in PowerShell, and binding a parameter to it yields the unbound-argument Object[] rather than the object passed in. Verified directly:

function T($n, $args) { $args.command }
T bash ([PSCustomObject]@{ command = 'npm test' })   # -> ''

The symptom is an empty summary for every tool, which reads as "no data" rather than "bad parameter binding". It cost me one debug cycle and would have read as a data problem to anyone else.

Validation

• test-substep-progress.mjs: 47 pass / 0 fail (was 32)
• smoke.mjs: 116 pass / 0 fail
• All 30 .ps1 parse; detector still initialises cleanly under Windows PowerShell 5.1 (exit 0) - the interpreter it runs under in production and the one that breaks on a malformed file
• Verified live against the running detector: the pill text is now the first line of the command, with no JSON key and no mid-token truncation

One thing I checked and did not change

status.json renders apostrophes as \u0027 in the file. That is ConvertTo-Json escaping at serialisation time, not data the detector produced - the widget's ConvertFrom-Json gets the real character back. I was about to add an unescape pass, which would have corrupted the value, since the escape never exists in memory. Recorded here so the next person does not repeat it.

[antianqi]

Round 20 #7 - a metadata refresh no longer steals state ownership

Reported as: the pill stops on Command failed at the end of a turn.

source is not a label. It is the arbitration token: the detector's settle logic reads source == detector as "this state is mine to rewrite" and uses that to decide whether it may overwrite an agent push. But Write-Status stamped source = detector unconditionally, including on the two metadata refreshes (60 s 5h-usage, todo progress) whose only job is to refresh numbers on a state somebody else owns.

The sequence, from island.log on the dev machine:

16:06:24  [detect] error :: Command failed
16:06:25  error      :: Command failed      <- PostToolUse hook, source=agent
16:06:40  [detect] 5h usage refreshed      <- stamps detector over the agent's state
16:06:41  error      :: Command failed
16:07:03  [detect] idle :: waiting           <- 60s no-event fallback, finally

At 16:06:40 the refresh handed write authority back to the detector while leaving state = error. From that point the detector owned the state and re-derived error from the same stale failed toolResult on every poll -- there is nothing newer in the session log to supersede it. When the turn ended and the Stop hook pushed done, the detector was entitled to overwrite it, and the pill went back to red. Nothing cleared it until the 60-second no-event fallback happened to fire.

So the error was accurate when it appeared and wrong the moment the turn moved on. The pill shows a failure that is no longer the current state, and there is no signal that would clear it.

A metadata refresh now preserves the previous owner. The claim-ownership stamp is reserved for state-inference writes, which is the only path that actually asserts a new state.

This is the same distinction #5 drew for step/total/detail -- source is part of the observable state, so it follows the same rule. Worth noting that #5 and #7 are one bug wearing two hats: the metadata path was treated as if it were a state assertion, and every field that participates in arbitration was corrupted by that.

Tests

2 new assertions, negative-first, both observed failing before the fix. They check the ownership token in both directions -- a metadata-refresh write keeps agent, a state-inference write claims detector. One-sided would have been just as happy with the field permanently blank, which is the failure mode that produced the empty-summary bug in #6.

Validation: sub-step suite 49 pass / 0 fail (was 47), smoke 116 pass / 0 fail, all 30 .ps1 parse, detector initialises cleanly under Windows PowerShell 5.1 (exit 0).

[antianqi]

Round 20 #8 - the pill skips the assignment preamble

Follow-up to #6, from using the result.

#6 stopped the pill rendering raw JSON, but the result was still often uninformative:

Running $ErrorActionPreference='Continue'

That is the opening line of most agent commands and says nothing about what is being worked on. On a detached status pill it is close to indistinguishable from the pill being stuck, which is a poor look for a widget whose entire job is to answer "what is it doing right now".

Format-ToolArgs now prefers the first line that actually executes something, skipping variable-assignment and comment lines:

$ErrorActionPreference='Continue'   <- skipped
$env:TEMP="..."                     <- skipped
npm test                            <- shown

Verified live against the running detector with exactly that shape of command:

pill shows: 'Running Write-Output "this line is the first real command - Get-L...'

The fallback is the part worth arguing about

If every line is boilerplate, the first line is still shown rather than leaving the pill blank. An uninformative summary beats no summary, because a bare verb with no detail is indistinguishable from the detector having lost track of the session.

That reasoning is pinned by a test that was written alongside the failing ones and passed before the fix as well - an all-assignment command. It exists so a future "skip more line shapes" change cannot silently blank the pill. Tests that only ever fail before the fix do not constrain the fallback.

Validation: sub-step suite 51 pass / 0 fail (was 49), smoke 116 pass / 0 fail, all 30 .ps1 parse, detector initialises cleanly under Windows PowerShell 5.1 (exit 0).

[hetaoBackend]

Request changes for exact current head a6a17f3eba855e1fe563db0a2948ab3cbfdf65d6.

The typed Computer Use secret path, Win32 flags, visible PostToolUse detail, workflow wiring and PowerShell discovery are improved, but blockers remain:

1. Detector metadata refresh is not an atomic read-modify-write. The loop reads old state/message (mcode-status-detect.ps1:923-943), then Write-Status -KeepSubStep performs a second independent read for step/detail/source (:714-721) before overwriting the file (:723-739). An agent write between the reads produces a mixed-generation payload, or a write after the second read is lost. Use one consistent snapshot plus version/CAS/lock and add a real two-writer interleaving regression.
2. PostToolUse error classification stringifies the result and only recognizes textual error prefixes (io.minimax.mcode/hooks/scripts/post-tool-use.ps1:14-24). A structured {isError:true,...} result can be reported as done. Prefer the structured boolean and test object/string/null success and failure payloads through the real hook subprocess.
3. The local Windows fallback runner still executes only four steps and omits test-substep-progress.mjs, so local reproduction differs from the GitHub workflow. Add the behavioral suite and fail on nonzero exit.

Exact-head Ubuntu, Windows and CodeQL checks are green, but existing tests do not cover the interleaving or structured-result paths. [code]smith is skipped and is not evidence.

[antianqi]

Round 21 — the three remaining blockers

Head 807aaf5, four commits on top of a6a17f3. Each blocker is its own
commit, so it can be verified independently.

commit	addresses
614d9a1	the detector surviving a terminating error in the main loop
4ae074f	#1 — the metadata refresh was not an atomic read-modify-write
3df799d	#2 — PostToolUse classified a structured result as a success
807aaf5	#3 — the local runner ran fewer steps than the workflow

---

#1 — the metadata refresh was not an atomic read-modify-write

"The loop reads old state/message, then Write-Status -KeepSubStep
performs a second independent read for step/detail/source before
overwriting the file. An agent write between the reads produces a
mixed-generation payload, or a write after the second read is lost.
Use one consistent snapshot plus version/CAS/lock and add a real
two-writer interleaving regression."

Agreed, and there was a second writer behind it that made the outcome
worse than a stale payload.

Both writers staged through the same status.json.tmp path.
notify-island.ps1:141 and mcode-status-detect.ps1:671 used the same
absolute path. Two processes, one temp file: one could rename the
other's half-written file into place, and the loser then failed its
Move-Item. The detector runs under $ErrorActionPreference = 'Stop'
with no catch around the write, so that failure killed the daemon —
the pill froze on the last status.json with no visible cause. This is
not the review's hypothesis; it is the same class of bug with a worse
outcome, and it is why the commit carries a per-tick guard as well.

What the fix is. A new scripts/lib/Status-Store.ps1 holds the
protocol, and both writers go through it:

• Enter-StatusLock / Exit-StatusLock — an exclusive cross-process
  lock on a sibling lock file, opened with FileShare.None. A real OS
  file lock, not a flag file whose presence we poll: a flag file has
  the same check-then-act hole the payload has. If a holder dies, the
  OS releases the handle.
• Read-StatusSnapshot — one read. Callers read once and reuse it.
• Write-StatusSnapshot — atomic replace (staging + rename) that
  stamps a monotonic version and ts.

In the detector, Write-Status now takes the lock, reads the snapshot
once, and writes. The body moved to Write-StatusUnderLock so the
arbitration path can read the snapshot and act on it without taking the
lock twice — the lock is not re-entrant, a nested take would deadlock
against itself. The arbitration read and the write it authorises are
now one critical section: previously the read sat outside the lock, so
a hook push could be judged against a stale snapshot and then
overwritten by the write that stale snapshot had authorised.

-KeepSubStep became -MetadataRefresh. The old switch only said
"preserve the sub-step"; the call site still had to read the file
itself to restate the state, which is where the second read came from.
One switch now names the whole semantics, and the two metadata call
sites no longer touch the file at all.

Schema: additive. status.json gains an optional version. The
widget reads every field through PSObject.Properties, so an older
widget ignores it and a newer one tolerates its absence. The sentinel
convention is unchanged: absent means -1 / -1 / "".

The two-writer interleaving regression

Two real PowerShell processes on one status.json: writer A is the
detector's read-modify-write, writer B is the agent's full push. A
signals that it has read, then waits for B to signal that it is about
to write; B's signal is published before B takes the lock, so the
ordering is deterministic either way.

with the lock      A holds it, B blocks, A writes, B writes last
                   -> the file carries B's values
without the lock   B writes immediately, A writes 400 ms later from
                   its stale read
                   -> the file carries A's stale values and B's write
                      is gone

The version counter is a second, independent witness: both writers
derive it from the snapshot they read, so two writers that read the
same generation mint the same version. That collision is visible even
when the surviving payload reads fine.

Two more defects found while doing this

1. The replace could lose a sharing violation. MoveFileEx with
   REPLACE_EXISTING fails when the target is open by a reader that
   did not share delete, and the widget polls status.json every
   400 ms with Get-Content, which opens with FileShare.Read. A
   write landing in that window threw and the update was lost — the
   staging file survived, the target kept the old payload. Measured on
   this host, not inferred. The replace now retries briefly.
2. The write path returned the version, and the detector calls it
   from inside its main loop, so the daemon's stdout got a bare number
   on every write. The store's write function returns nothing now, and
   a check pins that.

About the test harness itself

The old behavioral suite extracted a fragment of Write-Status and
stubbed the reader. That stub is exactly what hid the second read —
the bug the review named — so the old test could not have seen it. The
suite now runs the real Write-Status against a real
status.json in an isolated %APPDATA%.

The two layers are bound explicitly, because section 7 proves the
protocol (hand-written writers, since the deterministic choreography
needs the read separable from the write, and the real code deliberately
does not separate them) while the static checks say the real code
goes through that protocol.

---

#2 — PostToolUse classified a structured result as a success

"PostToolUse error classification stringifies the result and only
recognizes textual error prefixes. A structured {isError:true,...}
result can be reported as done. Prefer the structured boolean and
test object/string/null success and failure payloads through the real
hook subprocess."

Agreed. A structured result stringifies to
@{isError=True; content=...}, which matches no prefix — so a failed
tool was reported as a success and the pill showed green. The detector
already read the structured boolean from the session log, so the two
producers of the same state disagreed about what a failure was.

Test-ToolResultError now reads the structured boolean first and falls
back to the textual heuristic only for a bare string. A result that is
a JSON string is parsed and its flag read, because a producer that
serialises the result before handing it to the hook is still telling us
the truth in a structured field.

Ten cases, every one of them through the real hook as a real child
process, with a real event on stdin, reading back what the hook
wrote to status.json. A function-body test would not prove the hook
wires the classification to the state it pushes.

payload	pushed state
{isError:true}	error
{isError:false}	done
{isError:true, content:{...}}	error
{isError:false, content:{...}}	done
"Error: command not found"	error
"all good"	done
'{"isError":true,...}'	error
'{"isError":false,...}'	done
null	error
""	error

Each case also asserts the pushed message (Bash failed / Bash ok),
because a correct state with a wrong message is still a broken pill.
Each case runs in its own isolated %APPDATA%, so an assertion cannot
read a previous case's status.json.

---

#3 — the local runner ran fewer steps than the workflow

"The local Windows fallback runner still executes only four steps and
omits test-substep-progress.mjs, so local reproduction differs from
the GitHub workflow. Add the behavioral suite and fail on nonzero
exit."

Agreed. The workflow has had step 5 since round-19 #5. A runner that
claims to mirror CI while running fewer steps than CI gives the person
running it false confidence about what CI will say.

Step 5 is added, 1:1 with the workflow's step 5, and fails on a
non-zero exit. The repo root is now resolved from the script's own
location instead of from the current directory — the workflow resolves
it the same way, and the old version only worked when invoked from the
repo root, dying at step 1 with a path error from anywhere else.

---

Validation

test-substep-progress.mjs   116 pass, 0 fail   (was 51)
smoke.mjs                    125 pass, 7 warn, 0 fail   (was 116)
all 31 .ps1 parse            31 / 31
detector under PS 5.1        exit 0
local Windows runner         all 5 steps OK

The 7 smoke warnings are pre-existing forward event-catalog entries
pending mcode 0.2.4+ Runtime confirmation; unchanged by this PR.

12 negative-injection cases. Each is a minimal change that breaks
one clause of the contract; all 12 turn the suite red, and the
baseline restores to green after each.

	case	fails
N1	lock removed from the write path	2
N2	the write path reads the file twice	2
N3	metadata refresh stops preserving the sub-step	4
N4	state-inference stops clearing the sub-step	4
N5	the version counter stops advancing	3
N6	notify-island writes status.json directly again	1
N7	the inference call site passes -MetadataRefresh	1
N8	notify-island stops taking the lock	1
N9	metadata refresh stops preserving the state owner	1
N10	PostToolUse goes back to string-only classification	7
N11	the structured isError flag is ignored	4
N12	the structured failure is classified as a success	8

N6 and N8 did not bite on the first pass, and both were fixed rather
than waved off:

• N6's check looked for the literal "$statusFile.tmp". A rewrite
  that spells the same shared path differently walks straight past it,
  so the suite stayed green while the bug was back. The check now
  asserts the positive contract — status.json may only be written
  through the shared store — instead of one spelling of the bug.
• N8's patch did not apply because the indentation in the patch
  text did not match the file. A setup miss is reported as a setup
  miss, not as a pass.

Two faults in the harness itself were found and fixed along the way,
and they are worth stating plainly rather than quietly repairing:

1. The suite waited for writer A's marker with an unbounded spin.
   If A died first, the suite hung instead of failing — and a hanging
   test looks like a stuck CI job rather than a broken contract. The
   wait is bounded now, and the writers are bounded too.
2. The negative-injection harness ran the suite in the same process as
   itself, so the harness's own error handling could change how the
   suite's output was treated. It runs in its own job now, with a
   timeout, so a hung suite becomes a TIMEOUT verdict instead of a
   stuck harness.

What is not covered, stated rather than implied

• The two-writer regression proves the protocol, not the call site.
  The choreography needs the read separable from the write; the real
  code deliberately does not separate them. The binding between the
  two is static: the arbitration block takes the lock and writes
  through the locked body, and no other call site writes at all.
• notify-island.ps1's lock is asserted statically, not
  behaviourally. The hook spends ~6.5 s in the caller tracking before
  it reaches the lock (see below), which makes a timing-based test of
  it unreliable rather than merely slow.
• The per-tick guard is not covered by an automated test. It is a
  catch around a try that the suite cannot reach without a live
  mcode install. It is verified by inspection and by the detector
  still initialising cleanly under 5.1.

One cost this exposed, not fixed here

Get-CallerFocusInfo asks WMI for the process chain, one query per
level. Where the hook is spawned without a console — a CI runner,
a detached service — GetConsoleWindow returns zero and the whole
chain is walked, which measured 6.5 s per hook invocation on this
host (Add-Type is 97 ms and a single CIM query is ~500 ms, so it is
the chain, not the compile). Where a console is inherited, the first
branch returns immediately.

That is a real latency cost for any deployment without a console, but
it is not what the review asked about and it is a separate change with
its own blast radius, so it is left alone rather than folded into a
commit about something else. The suite is inside the CI budget as
measured (85 s against a ten-minute job).

Design compliance

no credentials	none added. The lock is a local file handle; the one credential-shaped change is removing credential text from three sinks
no network	no network calls added. The 5h-usage path is unchanged and still the only outbound call
no telemetry	none added. island.log / widget.log are local append-only files, now size-capped
no third-party services	no new dependencies. Pure PowerShell + Node, no npm packages
cross-platform	no host-absolute paths introduced. The existing hardcoded-path scan covers every edited file
atomic write	staging + rename, now under an exclusive cross-process lock
schema	additive only. version is optional; the sentinel convention is unchanged
ASCII-only	the new lib is ASCII-only, so it needs no BOM and cannot trip the PS 5.1 codepage trap

[antianqi]

The white box when dragging the pill

Separate from the three blockers, one more commit: 3bae385.

Dragging the pill showed a white rectangle the size of the window
(320x70) in place of the pill.

Why

The drag used WPF's Window.DragMove(), which sends
WM_SYSCOMMAND / SC_MOVE and enters the Win32 modal move loop.
Inside that loop the WPF render thread is not composited: DWM stops
recompositing the layered window — the per-pixel alpha surface that
AllowsTransparency="True" gives the pill its rounded, shadowed shape.
What stays on screen is that surface before it was ever painted.

The DropShadowEffect makes it more obvious, because the effect is
software-rendered and that frame is not drawn at all.

The fix

The drag is implemented directly: the normal message pump updates
Window.Left / Window.Top, so WPF composites every frame as usual
and the artifact cannot appear. The cost is the system-level move feel
of DragMove() (edge snapping), which this pill does not use.

Two details that are easy to get wrong, and both bit during this work:

• GetPosition($window) is relative to the window, and the window is
  following the mouse, so the relative delta is always ~0. The screen
  coordinates (PointToScreen) are differenced instead, and converted
  back to the device-independent units Left/Top use.
• The 5px threshold gates the start of the drag, not the
  movement. A guard that returns once didDrag is set makes the pill
  follow the cursor for exactly one event and then stop.

The mouse is captured on button-down so the drag does not stick when
the pointer leaves the 320x70 window, and released on button-up.

The BOM in this commit is not cosmetic

This file contains non-ASCII and had no UTF-8 BOM. Windows
PowerShell 5.1 — the interpreter the widget actually runs under —
decodes a BOM-less script with the system ANSI codepage, so the C#
here-string stops being a here-string and the file does not parse at
all. Measured on the exact committed bytes, both ways:

no BOM   -> PS 5.1: FAILS: Unexpected token '}' in expression or statement.
with BOM -> PS 5.1: parses OK

This is the round-20 #4 contract ("every non-ASCII .ps1 carries a
UTF-8 BOM"), and this file was the one that had slipped through it.

Evidence

• Windows PowerShell 5.1 parses the committed file: OK
• verified by hand on the target OS: dragging the pill shows no white
  box, and the pill follows the cursor

One note on the automated attempt, because it is a trap worth
recording: injecting a synthetic drag with SetCursorPos +
mouse_event does not reproduce a drag. SetCursorPos moves the
pointer without generating mouse-move messages, so the widget never
sees the movement, and the harness measures nothing while looking like
it measured something. The evidence above is the manual interaction plus
the parse check; the synthetic harness was dropped rather than kept as
false evidence.