feat(mcode-island): add sub-step progress fields to status.json (v0.4.0)

[antianqi]

Extends status.json schema with three optional fields — step, total,
detail — so agents can publish per-iteration progress during Computer
Use loops, multi-step plans, and long-running tool sequences. The widget
now renders "step N[/M] · detail" instead of only the coarse state, so
the user can see what the agent is doing right now without waiting for
it to finish.

Surface changes

notify-island.ps1
New params: -Step , -Total , -Detail
All default to -1 / -1 / "" for full backward compatibility.
The status.json payload now writes step/total/detail alongside the
existing state/message/progress fields. Old callers (omitting the
new params) produce identical status.json behavior except for three
extra fields whose values are the sentinels.

mcode-island.ps1 (widget)
New Build-DisplayMessage helper that converts the schema fields into
the visible pill text. Render branches:
step > 0 + total > 0 -> "step N/M · "
step > 0 + total <= 0 -> "step N · "
step > 0 + detail == "" -> "step N[/M]" (avoid message stacking)
step <= 0 -> original message (legacy path)
The poll-handler signature and init block were extended with the same
three fields and the change-detection string now includes them, so
consecutive working+message pushes with different step values are
not collapsed by the 400 ms dedupe.

io.minimax.mcode/hooks/scripts/_lib.ps1
Push-Island now accepts -Step/-Total/-Detail and forwards them to
notify-island.ps1. Format-ToolSummary has a new mcode-computer-use
branch that extracts action + coordinate with explicit -join ","
so coordinate arrays render as "(x,y)" not PowerShell's default
"(x y)" (the latter looked like a truncated number on the pill).

io.minimax.mcode/hooks/scripts/post-tool-use.ps1
Pushes -Detail with the Format-ToolSummary output split so the pill
shows "Bash ok · ls -la /tmp" instead of "Bash ok". pre-tool-use.ps1
already used Format-ToolSummary so no change there.

Backward compatibility

All new schema fields are optional. notify-island.ps1 callers that
omit -Step/-Total/-Detail see no behavior change. Widget versions that
do not know the new fields ignore them (PSObject.Properties[name]
everywhere). Verified by smoke.mjs case "backward compat: old callers
produce step=-1, total=-1, detail=""" and test-substep-progress.mjs
case "Push-Island backward compat: missing new params -> step=-1,
total=-1, detail=""".

Design compliance (per PR #21 round-11 standards)

no credentials : none added; the IPC is local-filesystem only
no network : no network calls added; notify-island.ps1 still
writes status.json under %APPDATA%/mcode-island
no telemetry : no telemetry added; the existing append-only
island.log is unchanged and the 400 ms polling
cadence is unchanged
no third-party svcs : no new third-party deps; the change is pure
PowerShell + schema
cross-platform : no hardcoded host paths; no /Users/ /home/
C:\ /mnt/ literals introduced; the existing
smoke.mjs cross-platform scan still passes
atomic write : notify-island.ps1 already writes status.json
atomically via staging + rename; no change
closed schema : status.json is open by design (not contract-
locked), but each new field has a documented
sentinel (-1 / -1 / "") so absent fields are
semantically equivalent to explicit sentinels
smoke self-check : smoke.mjs gained 5 new checks under section
5c1; locked the new surface contract so a
future refactor that drops the params surfaces
in smoke before reaching the slower pwsh-spawned
tests

Validation

smoke.mjs : 48 pass, 7 warn, 0 fail
(7 warn are pre-existing "forward" event catalog entries pending
mcode 0.2.4+ Runtime confirmation; unchanged by this PR)

scripts/test-substep-progress.mjs : 26 pass, 0 fail
Sections:
1. notify-island.ps1 schema round-trip (4 cases)
- all three new fields round-trip with explicit values
- step without total: step=5, total stays -1
- backward compat: step=-1, total=-1, detail=""
- existing fields (state/message/progress/ts/source) preserved
2. Build-DisplayMessage function contract (9 cases)
covering include step values, total omission, detail omission,
empty message, total=0 edge, step=-1 with orphan detail
3. Format-ToolSummary for mcode-computer-use (7 cases)
including Bash / Read / Edit regression coverage
4. Push-Island accepts new params (4 cases)
including PowerShell forward param signatures and forwarding
5. Push-Island end-to-end (hook -> status.json) (2 cases)

Test evidence (negative-injection verified)

Per the round-4 lesson (test pass != contract honored), I broke the
coordinate formatter in _lib.ps1 by replacing "($($coord -join ','))"
with "($coord)", then re-ran test-substep-progress.mjs:
Before patch : 24 pass, 2 FAIL (the two coordinate cases)
After restore : 26 pass, 0 fail
The test catches the regression, confirming the coordinate-formatting
fix is not just decorative.

Widget visual verified locally:
notify-island.ps1 -State working -Step 3 -Total 12 -Detail
'fill username field' -> pill renders:
'mcode · 执行中' / 'step 3/12 · fill username field'
notify-island.ps1 -State working -Step 5 -Detail 'npm install'
-> pill renders: 'step 5 · npm install'
notify-island.ps1 -State working -Message 'Read ok'
-> pill renders: 'Read ok' (legacy path, no step prefix)

Migration

No data migration. Existing status.json consumers see three new fields
they can ignore. Existing notify-island.ps1 callers see no behavior
change. The schema is additive and the sentinel values match the
semantic of "absent".

Reference

Companion docs updated:
skills/mcode-island/SKILL.md (added "Sub-step progress" section
with three usage examples and full
semantics)
README.md (added brief mention in the
notify-island.ps1 section with
a forward pointer to SKILL.md)
Bump plugin.json 0.3.0 -> 0.4.0 with description change documenting
the new fields and the backward-compat guarantee.
No upstream protocol changes. (Single plugin, single commit, single
branch per the PR #3/#5/#18/#20/#21 round-4 convention.)

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[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).