Nightly maintenance log

[ww-mw]

This issue is the log for the unattended nightly maintenance pass on this repository.

A scheduled agent runs once a night and posts one comment per run here: what it landed, what it captured for a human decision, what it was blocked on, and what it skipped. It is the single place to read to find out what happened while nobody was watching.

What a pass does

1. Preflight — abort if either working tree is dirty or main's CI is red (fixing red CI preempts everything).
2. Triage each open issue with no agent:* label: reproduce against a real build, post a diagnosis naming the file and function, and say whether the cause is in this repo or upstream in data-explorer-core.
3. Fix at most one issue per run, and only one that clears a strict confidence gate — reproduced by a test it wrote, root cause named, fix local, correct behaviour unambiguous, full suite green with no existing test modified.
4. Qualify anything customer-visible in a real browser against the shipped dist/webview bundle, because the unit suite composites no alpha and lays nothing out.
5. Refresh dependencies and the data-explorer-core pin, as its own PR.
6. Changelog and version bump, then a vX.Y.Z tag.

What it deliberately does not do

• It never publishes to the Marketplace. That stays the maintainer's manual step; a run only says whether a publish looks warranted.
• It never decides a design, UX, wording, or contrast question. A 2am run has nobody to ask, so anything with two defensible answers is captured, not attempted: labelled agent:needs-discussion, with a comment giving the measurement and two or three concrete options with a recommendation. Capturing well is a successful outcome.
• It never pushes to main directly — every change lands via a PR with green CI.

Labels it uses

label	meaning
agent:triaged	diagnosed; a run has looked at it
agent:fixing	a fix is in progress
agent:needs-discussion	needs a human decision; options are in the issue comment
agent:blocked	waiting on a human reply (the reporter is asked once, not nightly)
agent:log	this issue

Comments posted by the agent end with an invisible marker, which is how a later run tells its own words from a human's. If you reply to an agent:blocked issue, the next run picks the reply up and re-triages with it.

[ww-mw]

2026-09-19

Scheduled 02:17 pass, live (not a dry run), attempt 1 of 3 — no resume.

Landed — issue #24: a JSON dictionary opened with the binary editable view threw invalid zip data instead of opening. BinarySlddEditorProvider.openCustomDocument called unzipSync unconditionally; it now guards on isZipBytes and hands a non-zip .sldd back to dataExplorer.binaryView, which owns the single format-to-editor rule, rather than duplicating that rule. PR #28 → v1.24.5 (.vsix on the release). No core change, so the pin stays at core v1.25.0. Also added the CHANGELOG entry v1.24.4 never got.

Needs discussion — 4 items, all with options and a recommendation on the issue:

• Data Explorer menu has 3 options - 1 of which throws an error #24 (second half): two menu entries are both named Data Explorer (editable), and picking the text-backed one for a binary .sldd still opens a tab VS Code cannot populate — our provider is never reached, so unlike the fixed direction it cannot self-correct. Measured that vscode.openWith honours an explicit viewType whose selector does not match, so removing the editable entries from the menu is feasible; recommended.
• Cell background color and text color contrast issue for read-only cells #26: read-only text contrast. Measured against the shipped bundle in all four default themes — 3.69 Dark, 2.13 Light, 3.77 HC Light all fail WCAG AA; Light fails even AA-Large. Cause is --dex-color-text-muted → --vscode-disabledForeground, which is 50% alpha in VS Code's colour registry. The obvious swap to descriptionForeground passes AA in all four but makes read-only text pixel-identical to editable text in Light Modern, so it is a real trade-off, not a one-liner. Per the rules a contrast finding is a capture, never an unattended fix.
• Modified status only appears for a second then disappears #23: "Modified" marks clearing on their own is two mechanisms — (1) the mark means differs from the last save and is pinned by two existing tests, so with files.autoSave: afterDelay it clears ~1 s after typing, by design; (2) a genuine latent bug — SlddTextEditorProvider tracks initialized per panel but clears the URI-keyed baseline on any panel dispose, so closing one of two tabs on the same dictionary wipes the surviving tab's marks. (2) is a confident fix for a future run (the binary provider already fixed it document-scoped); it did not land tonight only because the one-fix-per-run slot went to Data Explorer menu has 3 options - 1 of which throws an error #24. Asked the reporter one closed question: their files.autoSave setting.
• Dictionary contents don't include referenced dictionaries #25: showing entries inherited from a referenced dictionary. Core's resolveDictionaryReferences exists but has zero callers here, deliberately — its contract forbids grafting inherited entries because the same tree is the save payload, so inline greyed rows would write edits to the wrong file. Recommended a read-only "Referenced Dictionaries" section instead; asked the reporter whether they want to navigate or to see the merged set.

Blocked — #6 (MATLAB does not see saved edits): labelled agent:blocked, no new comment. The cause is a MATLAB-side cache, outside this project's scope, and the maintainer already gave the Simulink.dd.cachePath workaround and asked @guirlo to confirm on a post-NoDMR build on 2026-09-10. The reporter is asked once, not nightly.

Skipped — dependency bumps: guardrail 4 is patch-only, and every available update is minor or major (fast-xml-parser 5.10.1→5.11.1, happy-dom 20.11.1→20.14.3, highlight.js 11.11.1→11.12.0, @types/vscode 1.125.0→1.137.0 minor; @types/node, vitest/coverage-v8, vite, typescript, mocha, esbuild major). None qualified, so no deps PR. @types/vscode is the one to look at deliberately rather than routinely: raising it widens the API surface the compiler accepts against the engines.vscode: ^1.90.0 floor, which is a compatibility decision about the minimum VS Code version we support — not something to bump silently. The core pin was already at core's latest tag.

Not done — two writes were denied as sensitive files, and per the rules a denied tool is not a tool to work around, so this is reported rather than routed around. The allow-list needs fixing:

1. ~/.claude/maintenance-logs/agenda.md — the agenda was not updated this run. The four needs-discussion write-ups above exist in full on their issues, so nothing is lost, but the daytime agenda file is stale and still shows only the earlier Cell background color and text color contrast issue for read-only cells #26 measurement and the deferred-deps note.
2. ~/.claude/skills/dex-maintenance/harness/scenarios/ — could not save the per-issue scenario copy for Cell background color and text color contrast issue for read-only cells #26. The measurements were taken with the shipped scenarios/customer-view.mjs unchanged, which already covers both read-only styles, the section header, the editable control and the toggle; what is missing is the kept, re-runnable copy.

On qualification — #24 was qualified in real VS Code (a new integration test that drives the provider and asserts which tab the user ends up on), not in the Playwright harness. Deliberate: the bug is editor routing, which has no CSS dimension, and the harness renders the webview bundle in Chromium with no notion of editors or tabs. The browser harness was used for #26, which is the visible one.

Publish? — Yes. v1.24.5 fixes a customer-visible error: on the affected path the file did not open at all and the user got invalid zip data. It is reachable from VS Code's own "Reopen Editor With…" menu on any JSON .sldd, which is the majority format, so it is worth shipping to the gallery rather than waiting to ride along with the next release.