[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 23: the session list

This PR now carries the session list on top of the sub-step progress
fields: 17 commits on the previous head (d3115f3), 55 in total.

The feature

Resting the mouse on the pill expands a list of every session that is
currently live, not just the one the detector follows. The detector
still follows a single session -- the one that wrote its log most
recently -- but on a machine with a CLI session, a desktop-app session
and a couple of side agents, the interesting one is usually the other
one.

   ●  剪映插件开发                          3 分钟前
      执行 bash                              运行中

Each row carries four things:

part	where it comes from
status dot	the same state vocabulary the pill uses, same text and same color
title	the session's real name, from the runtime's own SQLite store (local_runtime_sessions.title)
preview	the last thing that session said, so "running" and "stuck on one tool" are distinguishable
timestamp	how long ago that session last moved, plus its state word

The title is the session's name, not a summary -- that is the whole
point of reading runtime-state.sqlite instead of re-deriving a name
from the message log. When that store is not reachable (a host without
the usual node paths), the widget falls back to the first thing the
user said in that session, so a row is never blank.

The list reuses the pill's vocabulary instead of inventing its own:
working / thinking / waiting / idle / done / error, rendered
with the same words and the same colors as on the pill. The one
addition is 已停止 ("stopped"), which is not a message type but a
liveness fallback -- a session that has not moved for five minutes is
no longer "running", even though nothing said so.

Clicking a row goes back to that session. It never opens a second
one. The widget enumerates the Windows Terminal tabs, matches the
session name against the title history that session has had, selects
that tab, and brings the terminal window to the front. When no tab
matches (the terminal was renamed, or the session runs inside the
desktop app rather than Windows Terminal), the widget still raises the
terminal window instead of starting a new mcode --session <id> -- a
second terminal for the same session is exactly the bug this feature
is meant to remove. Clicking a row also dismisses it: the session
leaves the list and stays out until it starts its next round.

The detector writes sessions.json next to status.json in
%APPDATA%\mcode-island\; that file is the contract between the
detector and the widget, and the widget only reads it.

The commits

commit	what
8cc8df5	the detector tracks every live session, not just the newest
37652f0	the list opens when the mouse rests on the pill
7ab8726	merge feat/substep-progress into the feature branch
74641fb	the row layout: two lines of text plus a timestamp on the right
71436c8	the title is the session's real name, from the runtime's SQLite store
c2f6ff5	the title lookup survives a host without the usual node paths
b225995	a session that stopped no longer says it is running
ee06a14	the list uses the pill's state vocabulary, same text and same color
83c3856	a finished tool is not a finished round
a644ab4	clicking a session goes back to its terminal instead of opening a second one
7b40377	the title no longer degrades into a message summary
e73aa8f	injected system messages are not something anyone said
2a45bbc	the last row of the list is not cut in half
633ceae	the terminal actually comes to the front
f9c98da	a session click no longer loses the foreground
0c22cc7	the terminal comes back full-screen, not as a strip in the corner
ff25a4b	release 0.5.0: version, description, README

A bug this PR already had

Focus-Window passed cx=0/cy=0 and X=0/Y=0 to SetWindowPos as a
shorthand for "keep the current size and position" -- but that
shorthand only holds when the matching flag is present:

[WinAPI]::SetWindowPos($Target.Hwnd, [WinAPI]::HWND_TOPMOST, 0, 0, 0, 0, [WinAPI]::SWP_NOACTIVATE) | Out-Null

Windows read that as "resize to 0x0" and "move to (0,0)". Windows
Terminal clamps a 0x0 request to its minimum size, so the window
collapsed into a ~480x84 strip in the top-left corner of the screen --
and its restored size stayed that broken value, so every later
restore brought the strip back.

Round 19 item #3 already asked for SWP_NOMOVE on the restore path;
the same call site in Focus-Window was missed. Mode = 'focus' covers
the pinned window, the desktop app, and the "no caller terminal"
fallback -- and the Marketplace build flips $script:clickPrefers to
'app', so that is the path every Marketplace user takes.

Fixed in 0c22cc7. smoke.mjs now fails the build on any
SetWindowPos that passes cx=0/cy=0 without SWP_NOSIZE, or
X=0/Y=0 without SWP_NOMOVE -- negative-injected to confirm it
bites.

One more of the same family

The new focus code assigned to $pid, which in PowerShell is the
read-only automatic $PID (variable names are case-insensitive). The
assignment threw, a catch around it swallowed the error, and the
focus step silently never ran. Fixed in f9c98da, and smoke.mjs now
scans every .ps1 in the plugin for assignments to a read-only
automatic variable ($pid, $home, $host, ...), including inside a
param() block. This is the third time this family of bug has cost a
round here ($home in the title lookup, $args in the detector), so
the guard is generic rather than a one-off.

Test evidence

• node scripts/smoke.mjs -> 154 pass / 0 fail
• node scripts/test-substep-progress.mjs -> 133 pass / 0 fail / 1 skipped
• pwsh -File scripts/test-session-tracker.ps1 -> 65 pass / 0 fail
• pwsh -File scripts/test-windows-workflow-local.ps1 -> all 5 steps OK

Both new guards were negative-injected: changing one line makes the
corresponding assertion fail, and restoring it makes the suite green
again.

The window behaviour was verified on the real machine, not just in the
suite. A real mouse event on a session row, checked from an
independent process:

build	foreground window	terminal rect	verdict
before 0c22cc7	Windows Terminal	(0,0)-(480,84) -- a strip in the corner	fail
0c22cc7	Windows Terminal	(-8,-8)-(2568,1400) = 2576x1408	pass

The same check also asserts the window's restored placement is a real
full-screen size, so the broken 480x84 cannot survive the next
restore.

[antianqi]

Review response: all four blockers, and where they landed

This is a response to the two CHANGES_REQUESTED reviews
(hetaoBackend, 09-25 @ b73752b and 10-09 @ a6a17f3). It maps each
blocker to the commit that addresses it and to the check that proves it,
so a re-review does not have to re-read the tree.

Current head is ff25a4b.

#	blocker	addressed in	proved by
09-25 #1	typed Computer Use text can leak into the pill, status.json and the append-only log	1daee4b	scripts/test-substep-progress.mjs secret canary
09-25 #2	the detector's rewrite drops step / total / detail	6fe1665	the same suite + mcode-status-detect.ps1:788-790
10-09 #1	the metadata refresh is not an atomic read-modify-write	4ae074f	scripts/test-substep-progress.mjs:785 (two writers, one file)
10-09 #2	PostToolUse stringifies the result and only recognizes textual error prefixes	3df799d	post-tool-use.ps1:15 + the hook subprocess tests

09-25 #1 -- typed text

tool_input.text is whatever the user typed, so it never reaches a
persistent or displayed summary. io.minimax.mcode/hooks/scripts/_lib.ps1
carries the rule and the redaction (Protect-SecretText $detail), and
the suite drives a real Computer Use type action whose payload is a
canary -- SUPER-SECRET-PASSWORD-8f3a91c2 -- then asserts the canary
appears nowhere in the pill output, in status.json, or in the log, and
that what is written instead is a redacted placeholder of the same
length.

09-25 #2 -- the detector erasing the sub-step fields

The detector now carries the fields through its rewrite instead of
rebuilding the object without them
(mcode-status-detect.ps1:788-790 reading $prev.step / $prev.total
/ $prev.detail, and :802-804 writing them back), so a usage or todo
refresh no longer erases "step 3/12".

10-09 #1 -- the metadata refresh

Three changes, together:

• One snapshot. Write-StatusUnderLock reads the previous state
  once ("The one snapshot. Every field below is derived from it, so the
  payload is always a single coherent generation") and derives every
  field from it.
• A lock. scripts/lib/Status-Store.ps1 takes an exclusive OS file
  lock (Enter-StatusLock / Exit-StatusLock). The lock is not
  re-entrant, so the body is split into Write-StatusUnderLock for
  callers that already hold it -- a nested take would deadlock against
  itself.
• A version. Every write stamps a monotonic version, and the
  file is replaced through a staging file, so two writers can never
  mint the same version and a torn file is not observable.

The regression is scripts/test-substep-progress.mjs:785 -- "Two
writers, one file (round-21 review hetaoBackend #1)" -- which runs two
real writers against one status file and asserts the result is a single
coherent generation.

10-09 #2 -- structured isError

io.minimax.mcode/hooks/scripts/post-tool-use.ps1:15 calls
Test-ToolResultError $evt.tool_result, which prefers the structured
isError boolean on the result object. A textual error prefix is only
the fallback for a bare string result, so {isError:true,...} can no
longer be reported as done. The tests drive the hook as a real
subprocess with object, string and null success and failure payloads.

Also on this head since the last review

• 807aaf5 -- the detector survives a terminating error in the main
  loop instead of taking the pill down with it.
• d3115f3 -- the 5h usage badge stays on the pill
  (Get-PlanUsage was clearing the cached percentage on its way in).
• ff25a4b and the 16 commits below it -- the session list, which is
  a new user-facing feature rather than a response to a blocker. It is
  described in the round-23 comment above, and it is what moved the
  plugin to 0.5.0.

State of the checks

• node scripts/smoke.mjs -> 154 pass / 0 fail
• node scripts/test-substep-progress.mjs -> 133 pass / 0 fail / 1 skipped
• pwsh -File scripts/test-session-tracker.ps1 -> 65 pass / 0 fail
• pwsh -File scripts/test-windows-workflow-local.ps1 -> all 5 steps OK

The two blockers that asked for a regression test are the reason the
workflow runs the behavioral suite at all now: 807aaf5 made the CI
step execute it, because a suite that only ever runs on the runner
stops being evidence for the person running it.

If something above is still not what you asked for, pointing at the
specific line is the fastest way to get it fixed -- the work is
already split into one commit per item for exactly that.

[hetaoBackend]

Request changes for exact current head ff25a4b.

Blocking findings:

1. The PR deletes the complete existing plugins/weekbin/mcode-trajectory-studio and its workflow relative to base 39ddd2c: 161 files and about 45168 lines. This is an unrelated product deletion and must be reverted or explicitly justified and approved.

2. Command injection in plugins/antianqi/mcode-island/mcode-island.ps1:933-943: Start-SessionTerminal interpolates the session id into a PowerShell -Command string. The id is decoded from session directory names in scripts/lib/Session-Tracker.ps1:81-90 without a strict allowlist, and restored sessions.json ids are trusted. A crafted id such as x; Set-Content $env:TEMP\pr62-pwned 1; can execute arbitrary PowerShell when a row is clicked. Validate the id and pass it as a non-evaluated argument; add a regression test.

3. Get-SessionTitle and Get-SessionPreview in scripts/lib/Session-Tracker.ps1:140-193 and 303-323 write user or assistant text to sessions.json and render it in the always-on-top pill without Protect-SecretText. Tokens, passwords, or API keys in prompts can therefore be persisted and displayed. Redact before persistence and add JSON, Bearer, JWT, and key-value canaries.

4. The tracker has no maximum session count, preview size, sessions.json size, or UI height. Session-Tracker.ps1:400-579 retains stopped sessions and serializes all full previews, while mcode-island.ps1:617-633 creates a row for every entry. Add bounded data and eviction tests.

5. If title matching cannot find an existing terminal, mcode-island.ps1:929-943 starts another mcode --session terminal. This contradicts the no-second-terminal contract and can duplicate a live session. Fail closed or prove the session is not already running before launching a new terminal.

The current repository-owned CI, CodeQL, Windows job, and validate checks are green, but they do not cover these blockers.

[antianqi]

Round-3 blockers, all addressed in ad4d4ac (current head of this PR).

#	Blocker	What changed
1	plugins/weekbin/mcode-trajectory-studio deleted	Not a deletion: that plugin landed upstream in 39ddd2c, after this branch's merge base. upstream/main is merged in f246247; all 161 files are back.
2	Start-SessionTerminal command injection	The function is deleted, not re-quoted — the point is to remove the path that turns data into code. The id is now shape-checked at every entry point (session directory name, sessions.json restore, click handler): ^[A-Za-z0-9][A-Za-z0-9_-]{0,127}$.
3	title/preview not redacted	Already redacted on ff25a4b: Get-SessionTitle and Get-SessionPreview both call Protect-SessionText. What was missing was evidence of coverage, so the tracker suite now dot-sources the real Protect-Text.ps1 (it used a stub that only knew sk-) and plants JWT / Bearer / JSON-token / kv-password canaries in both the title and the preview. Each assertion requires the redaction marker to be present, so "secret absent" cannot pass by truncation, and sessions.json is checked too.
4	no session / UI bounds	Data side: MAX_SESSIONS = 20, evicting by last activity — but only sessions that are already idle. Evicting an active one is self-defeating: the next scan re-adds it from the same directory, so the list flickers. UI side: MAX_SESSION_ROWS = 12, a "还有 N 条" row instead of silent truncation, and the list height clamped to the work area.
5	opens a terminal when nothing matches	Fail closed: log and stop. A session running in a host we cannot see (embedded terminal, another terminal app) would otherwise get a second terminal — exactly what this list exists to prevent.

Verification: smoke.mjs 163 pass / 0 fail, test-session-tracker.ps1 110 pass / 0 fail, test-substep-progress.mjs 139 pass / 0 fail (1 platform skip). Every new lock was negative-injected: 12 mutations, each turned its own assertion red, then the file was restored byte-identically and the suites went green again.

[antianqi]

Round 24: a per-row dismiss that does not switch sessions

aa6bf54 (current head) adds a dismiss mark to every row of the session list.

Clicking a row means "take me back to that session". The new × means "I am done with this one". Those are two different intentions: often the rows are conversations already dealt with, and the user does not want to be dragged out of whatever they are doing just to clear them. So the × dismisses the row and nothing else:

• it does not switch to the session, and does not open a terminal;
• it does not close the list — the row disappears, the list shrinks, and the next row's × is right there, so several rows can be dismissed in a row;
• it gives the focus back to the window that had it.

That last one was a real defect found on the machine, not a design choice. Pressing the mouse button hands the focus to the pill; for "jump to that session" that is fine, but for "just dismiss this" it cost the user their editor's focus, and the next keystroke went somewhere unknown. The widget now captures the foreground window when the mouse enters the pill — the last moment it still has it — and hands it back after the dismissal, then reads the foreground back to confirm it actually landed.

Two things the dismiss button forced

The ack file has to carry more than one id. It was one id per file, and the detector consumes it once a second, so a second dismiss within that second overwrote the first and that row never went away — with the × looking like it had worked. ack.signal is now one id per line, and the detector consumes it by renaming the file aside before reading it: an ack written while it is reading is not lost, and a half-written file is never parsed.

A dismissed row has to disappear immediately. The detector needs up to a second to confirm, and until then the row is still in sessions.json — so the widget keeps a local set of dismissed ids and hides them while rendering. The set converges on its own: once an id is gone from sessions.json, the detector has confirmed it and the widget drops it from the set.

Verification

• scripts/smoke.mjs: 170 pass, 7 warn, 0 fail
• scripts/test-session-tracker.ps1: 115 pass, 0 fail
• scripts/test-substep-progress.mjs: 139 pass, 0 fail (1 platform skip)

Every new lock was negative-injected: 13 mutations, each turned its own assertion red, then the file was restored byte-identically and the suites went green again. Two of them (C1, C3) initially stayed green because the row's own comment mentions Invoke-SessionDismiss by name and satisfied the text search — the locks now strip comment lines before matching.

On the live widget with real mouse clicks: the dismissed row is gone from sessions.json within a second, the list stays open and shrinks by one row, the foreground pid and hwnd are identical before and after the click, and two dismissals in one second both land.

This adds to the round-3 blockers already addressed in ad4d4ac; the mcode-trajectory-studio deletion was the upstream merge in f246247.

[hetaoBackend]

Request changes for exact current head aa6bf54.

Blocking security issue: the session log scanners still recurse without a reparse-point or containment boundary:

• plugins/antianqi/mcode-island/scripts/lib/Session-Tracker.ps1:152-170 uses [System.IO.Directory]::EnumerateDirectories($root, 'session_', 'AllDirectories') and then reads ledger/messages files under every returned directory.
• plugins/antianqi/mcode-island/mcode-status-detect.ps1:313-341 uses [System.IO.Directory]::EnumerateFiles($sessionsRoot, '*.jsonl', 'AllDirectories') and selects files from the recursive result.

There is no canonical-path containment check and no explicit rejection of symlink/junction/reparse-point entries. On Windows, a reparse point under the sessions root can redirect recursive enumeration or a selected log outside the intended sessions root, causing the detector/list UI to read and expose an unrelated JSONL file. The current test-session-tracker.ps1 fixture covers ordinary directories and log parsing, but has no outside-target junction/symlink/path-escape regression; the exact-head Windows check name only supplies parse/token/hook/mock-API evidence for this review.

Please make traversal fail closed: canonicalize the root and every candidate, reject reparse-point ancestors/entries (including junctions/symlinks), enforce canonical containment before opening a log, and add a Windows regression fixture proving an outside target is never read. Keep the fix in both scanners and rerun the exact-head Windows behavioral evidence.

The exact-head repository Checks are otherwise green, but green Checks do not cover this path boundary. [code]smith is skipped and is not evidence.

[antianqi]

New commit on top of feat/substep-progress (aa6bf54 → afbb6d5, "feat(mcode-island): a Liquid Glass material, judged per surface") — this is the material rework, please re-review on the new head.

What changed

• The pill is no longer a translucent grey plate (hard-coded #99232734 over a #F21A1A20 panel). It is now a material engine: live screen capture behind the widget (SetWindowDisplayAffinity/exclude-from-capture), 4× downsample, WPF BlurEffect, scaled back up (24 physical px of blur radius), ≤3% grain on top, specular rim + inner edge + soft shadow, real rounded clip.
• Two poles — dark glass/white content and light glass/dark content — switched with hysteresis (light past 0.60, dark past 0.58). The thresholds are derived from the 4.5:1 requirement for the primary text, not picked by eye.
• Each surface picks its own pole. The pill and the expanded panel are two separate pieces of glass; the old build shared one global polarity, so the panel's decision overwrote the pill's (dark glass with dark text, and the two flipped each other every 100 ms). Polarity, foreground colours and the grain brush are now per surface; the session rows take their ink from the panel they are drawn on.
• Apple system colours: the dark pole uses the dark-mode system palette, the light pole the macOS black-transparent label colours, with a light-pole twin of the state and family tables (closest pair dE 30.4).
• materialPole in config.json: auto (default) / dark / light.

Validation

• scripts/smoke.mjs: 199 pass, 7 warn, 0 fail (the 7 are the pre-existing "runtime not ready yet" hook events).
• scripts/test-session-tracker.ps1: 115 pass, 0 fail.
• scripts/test-substep-progress.mjs: 139 pass, 0 fail, 1 platform skip.
• New scripts/test-material-injection.mjs — 22 single-line mutations, each asserted to turn its own check red, source restored byte-identically afterwards, suite green again. All 22 behaved as expected.

Live machine

• Split backdrop (bright strip under the pill, dark terminal under the panel): the pill rendered as pale glass with dark text while the panel rendered as deep glass with white text, simultaneously and stably (Pill L=0.837 pole=light / Panel L=0.528 pole=dark). The harness proves the stacking with WindowFromPoint before grabbing, so a run cannot report success while the strip sits on top of the widget.
• Dark backdrop: pill and panel both dark glass with white text, the terminal clock behind the panel blurred to a smear.

Known trade-off (unchanged, documented in the README): SetWindowDisplayAffinity hides the widget from screen recorders for the ~10–30 ms of each capture window, every 2.5 s.

[antianqi]

New commit on top of feat/substep-progress (afbb6d5 -> a3961c1, "feat(mcode-island): a black glass that stays black, whatever is behind it") — the material rework the user asked for after seeing the island render as mud over a white page. Please re-review on the new head.

What changed

• The island is now one black slab, whatever is behind it — the way macOS's Dynamic Island is. Over a white page it used to render as mid grey (#6A6A6A) with dark labels on top; the user called it "灰突突" and asked for unified black.

• The material model changed from "mix a fixed proportion of black into the backdrop" to solving for a target grey, which is what HIG "Materials" actually asks for ("adjusts the luminosity of background content to maintain legibility of text"):

  behind is brighter than the target  ->  mix in black:  veil = 1 - target / L
  behind is darker than the target    ->  mix in white:  lift = (target - L) / (1 - L)
  

  The dark pole targets 0.115 (byte 29, #1D1D1D — the black macOS's Dynamic Island uses); the pale pole converges on near-white the same way, so pinning light gives a crisp pale material instead of a grey wash. materialPole now defaults to dark.

• Because the glass lands on one grey over every backdrop, contrast stops depending on the backdrop: worst case went from 5.35:1 / 5.13:1 primary and 2.70:1 / 2.98:1 secondary to 16.57:1 / 10.56:1 and 5.86:1 / 3.88:1. The old "secondary text below WCAG AA on a bright backdrop" trade-off is gone.

• The frost keeps the backdrop's hue: a blue shape behind the glass came through as rgb(15,29,43) — 11.5 % of rgb(0,122,255). Adjusting luminance instead of washing grey over it is what makes that possible.

Validation

• scripts/smoke.mjs: 203 pass, 7 warn, 0 fail.
• scripts/test-session-tracker.ps1: 115 pass, 0 fail.
• scripts/test-substep-progress.mjs: 139 pass, 0 fail, 1 platform skip.
• Negative injection: 27 single-line mutations, each asserted to turn its own check red, source restored byte-identically afterwards. The new ones cover the convergence formula being replaced by a fixed wash, the dark target lifted off the island black, the light target collapsed, the default material no longer black, and the thickness factor shadowing the typed $Thick parameter.

Live machine

• Deterministic white backdrop: the island renders as black glass with white text and a visible frost; the pixel sample above is from that screenshot.
• Dark terminal: the same black slab, with the terminal's clock and text coming through the panel blurred.

One bug worth naming: the thickness factor was written $thick while the parameter is [bool]$Thick. PowerShell variable names are case-insensitive and the parameter's type constraint still applies, so $thick = 0.25 was coerced to $true, (1.0 - $thick) evaluated to 0, and the target grey collapsed to 0 — the glass went pure black. Renamed $thickMix, and the suite now asserts the factor does not shadow the typed parameter. Static assertions cannot see that class of bug: every number in the source was correct.

[antianqi]

Head is now a2520bf -- the conflict is resolved, please re-review

This PR was showing as CONFLICTING against main. That is fixed: a2520bf merges upstream/main (01c44b6) into the branch, and GitHub now reports the PR as MERGEABLE.

What the merge brought in (merge-base 39ddd2c -> 01c44b6):

• 0125d0f -- rename plugins/stevenjj33/web-research -> plugins/stevenjj33/web-search
• 01c44b6 -- chore: ignore credential files (#76)

The one conflict was .gitignore, where both sides appended a new block to the same base. Both are kept: upstream's credential rules (.env, .env.*, *.env, !.env.example, secrets/, credentials.json, *credentials.json, *.pem, *.p12) first, then this branch's stale-widget-backup rule (*.bak-r16) in its own commented block. No rule is dropped, none is duplicated.

The renamed web-search tree matches upstream/main byte for byte -- git recorded it as a pure rename with no content conflict.

Re-run after the merge (the merge touched no plugin source, but the tree changed, so the suites were run again on the merged result):

• scripts/smoke.mjs: 203 pass, 7 warn, 0 fail
• scripts/test-session-tracker.ps1: 115 pass, 0 fail
• scripts/test-substep-progress.mjs: 139 pass, 0 fail, 1 platform skip

Still open from the aa6bf54 review -- not addressed yet. The path-traversal finding (recursive enumeration of the sessions root without canonical-path containment, and without rejecting reparse points / junctions) is a real blocker and this merge does not touch it. The two scanners that need it are scripts/lib/Session-Tracker.ps1:155 and mcode-status-detect.ps1:321. That is the next round of work, with a Windows junction fixture proving an outside target is never read; the re-review above does not claim it is fixed.

The material rework is unchanged from the two notes above (afbb6d5, a3961c1).

[antianqi]

Head is now 2ae7407 -- the CodeQL check is green again

The PR was red on CodeQL with one high-severity alert, in this PR's own code. It is fixed, and the whole check suite is green on the new head.

What the alert was. scripts/smoke.mjs strips the XML comments out of the widget's XAML before the material assertions read it, so that a comment in the source cannot feed an assertion. The strip used:

replace(/<!--[\s\S]*?-->/g, '')

That regex only removes a <!-- that has a matching --> -- an unclosed <!-- survives the "sanitisation" intact, so the sanitisation was incomplete, and a comment could still feed the assertions. CodeQL said so twice, in two different rules, and it was right both times:

1. js/incomplete-sanitization -- "This string may still contain <!-- ..."
2. js/bad-html-filtering-regexp -- "This regular expression only parses --> and not --!> as a HTML comment end tag.

HTML5 accepts --!> as a comment end as well, so the filter has to know both forms.

The fix. A text walk instead of a regex replace, through one helper that recognises both end tags and advances by the tag's real length (--> is three characters, --!> is four). A paired comment is dropped whole; an unpaired <!-- drops everything after it. The stripped XAML therefore never carries a comment marker, which is the property the assertions actually need.

A probe caught a real bug in the first attempt. The advance was written as close + 3, carried over from the --> case; the new assertion went red immediately, because with --!> a character survived the comment. The advance is now close.at + close.len. The probe is what says so:

xaml comments: the strip recognises every HTML comment end tag

It runs the strip over <a><!-- c --!><b>keep</b> and requires <a><b>keep</b> back. The probe is the only way to prove it -- the widget's own XAML never uses --!>, so a strip that knew only --> would look perfect against the real file.

Four assertions now say it out loud instead of leaving it implied: every comment in the XAML is closed; the stripped XAML carries no marker left; the strip recognises every HTML comment end tag; and the XAML block cannot be read at all (before, an unreadable XAML produced an empty string and the material assertions quietly ran against nothing).

Validation

• scripts/smoke.mjs: 206 pass, 7 warn, 0 fail
• scripts/test-session-tracker.ps1: 115 pass, 0 fail
• scripts/test-substep-progress.mjs: 139 pass, 0 fail, 1 platform skip
• Negative injection: 32 single-line mutations (was 27), each asserted to turn its own check red, source restored byte-identically afterwards. All 32 behaved as expected; the suite is green again at the end.
• The five new cases: an XML comment left unclosed in the XAML, the XAML block unreadable, the comment strip itself broken, the strip knowing only one of the two HTML comment end tags, and the strip advancing by the wrong length.

Checks on this head: validate (ubuntu-latest), analyze, mcode-island on windows-latest (parse + token + hook + mock-API) and CodeQL -- all green. The PR is MERGEABLE with merge state CLEAN.

Still open from the aa6bf54 review -- not addressed by this head either. The path-traversal finding (recursive enumeration of the sessions root without canonical-path containment, and without rejecting reparse points / junctions) is a real blocker and nothing in these three commits touches it. The two scanners that need it are scripts/lib/Session-Tracker.ps1:155 and mcode-status-detect.ps1:321. That is the next round of work, with a Windows junction fixture proving an outside target is never read.

[hetaoBackend]

Request changes for exact current head 2ae7407.\n\nThe session-log traversal boundary remains unresolved on this head:\n\n- plugins/antianqi/mcode-island/scripts/lib/Session-Tracker.ps1:155 calls Directory.EnumerateDirectories($root, "session_", "AllDirectories").\n- plugins/antianqi/mcode-island/mcode-status-detect.ps1:321 calls Directory.EnumerateFiles($sessionsRoot, "*.jsonl", "AllDirectories").\n\nMicrosoft documents that SearchOption.AllDirectories includes reparse points such as symbolic links and mounted drives (https://learn.microsoft.com/en-us/dotnet/api/system.io.searchoption?view=net-10.0). The returned paths are then inspected/opened without canonical containment or explicit reparse-point rejection. A junction/symlink under the sessions root can therefore cause the island/session detector to read session-like directories or JSONL logs outside the intended root. This can expose unrelated local session content in the widget/status.\n\nThe added scripts/test-session-tracker.ps1 has no outside-target junction/symlink/path-escape regression, and .github/workflows/mcode-island-windows.yml only parses scripts and exercises token/hook/mock-API contracts; it does not run the session traversal behavior test.\n\nPlease replace blind AllDirectories recursion with a traversal that rejects reparse-point entries/ancestors and verifies each canonical candidate remains under the canonical sessions root before opening it. Add and run a Windows junction/symlink regression that proves an outside JSONL file is never read. The exact-head Checks are green, but they do not cover this path-boundary case.

[hetaoBackend]

Readable follow-up to review 5761764089 for exact current head 2ae7407.

The session-log traversal boundary remains unresolved:

• Session-Tracker.ps1:155 uses Directory.EnumerateDirectories($root, "*session_*", "AllDirectories").
• mcode-status-detect.ps1:321 uses Directory.EnumerateFiles($sessionsRoot, "*.jsonl", "AllDirectories").

Microsoft documents that SearchOption.AllDirectories includes reparse points such as symbolic links and mounted drives: https://learn.microsoft.com/en-us/dotnet/api/system.io.searchoption?view=net-10.0. The results are inspected/opened without canonical containment or explicit reparse-point rejection, so a junction/symlink under the sessions root can make the widget or detector read JSONL outside that root.

test-session-tracker.ps1 has no outside-target junction/symlink regression, and the Windows workflow does not run this traversal behavior test. Please reject reparse-point entries/ancestors, enforce canonical containment before opening candidates, and add/run a Windows junction or symlink regression proving an outside log is never read. The current-head checks are green but do not cover this path boundary.