T-6OQZ-explorer-display-relabel
Status: planning/backlog · Impact: low · Complexity: small
The Browse/Notes unification left one experience that is really “the file
explorer”, still displayed as “Notes”. The owner’s #1305 call was to keep
the name — no renaming at all — so this task exists to make the optional
display-only relabel (“Explorer”) a deliberate future decision rather than
drift. It is two strings; the id, routes, and deep links stay notes
regardless.
| Location | Role today |
|---|---|
solutions/determined/experiences/notes/app/plugins/register.ts | The experience registration: title: 'Notes' and the nav entry label: 'Notes' |
Proposed
Section titled “Proposed”Either the owner confirms “Notes” stays (close as wontdo, decision recorded), or the two display strings become “Explorer” with everything mechanical — id, routes, storage keys, testids — untouched.
Approach
Section titled “Approach”- Owner call: relabel or keep.
- If relabeling: change the registration’s
titleand navlabel; sweep e2e for copy assertions on the visible name.
Files to touch
Section titled “Files to touch”| Location | Kind | Change |
|---|---|---|
solutions/determined/experiences/notes/app/plugins/register.ts | modify | The two display strings |
Acceptance criteria
Section titled “Acceptance criteria”- AC-1: The relabel question has an owner answer; the visible name matches it; nothing route- or id-shaped changed.
Out of scope
Section titled “Out of scope”- Any rename of the experience id, routes, or persisted keys — #1305
settled that these stay
notes.
Dependencies
Section titled “Dependencies”- none
Discovery context
Section titled “Discovery context”- Parked as an open follow-up in the tree-unify plan when #1305 merged the
Browse/Notes surfaces;
need_human_reviewbecause the whole task IS an owner decision.