docs(planning): log the persistent saved-state indicator todo

[dknauss]

Captures the design question raised at Phase 25's checkpoint: should the save marker persist?

The problem

The indicator is event feedback that erases itself — maestro.js ~L1748 sets a 2s timer flipping saved → idle, blanking both glyph and SR text. Seconds after a rename commits there's no on-screen answer to "did that save?", and the only recourse is to change something else and watch again.

Phase 25 reserved the status slot so it stopped shoving the toolbar sideways — the jarring half. This is the other half, and it's a design change rather than a bug fix, so it was deliberately kept out of 25-02 rather than smuggled in under the layout work.

Why persistent is the WordPress-native answer

Core doesn't use the self-erasing toast:

Surface	Pattern
Block editor	"Saved" persists until the document is dirty again
Classic autosave	"Draft saved at 3:15:45 pm." — persistent, timestamped
Customizer	Encoded in the control: Publish → Published (disabled)
Quick Edit	No chip — the updated row is the feedback

Gutenberg is the closest precedent because both autosave: the user never presses Save, so they need standing reassurance rather than a moment of it.

The proposal keeps it glyph-only (the toolbar is icon-only by design, slot is 24px) and stays empty until the first save, since claiming "Saved" on entry would be a small lie.

Two caveats, recorded rather than left to be discovered

1 · It collides with the modified dot. That per-row • means "differs from the WordPress default" — not "unsaved". A persistent toolbar check alongside it puts two persistent indicators on screen meaning different things, and the difference isn't self-evident. The todo lists options including the one it explicitly doesn't recommend: repurposing the dot to mean "unsaved" would break the documented WCAG 1.4.1 non-colour-signal reasoning at maestro.js ~L136-146.

2 · The live region wants a listen, not an assumption. role=status + aria-live + aria-atomic="true" already pairs with an explicit speak() on the same transition — a double-announcement risk. Pre-existing rather than introduced, but persistence makes it more noticeable, and this is the natural moment to check.

One correction to something I said out loud

I'd flagged that the error state might also self-erase and be worth checking. It doesn't — the timer is gated on if ( ok ), so an error correctly persists until the next change. Verified before writing this up.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.