Skip to content

fix: redesign /provider transition microcopy — progressive disclosure, terse confirmations - #268

Merged
Brian Krabach (bkrabach) merged 1 commit into
mainfrom
feat/provider-microcopy-redesign
Aug 13, 2026
Merged

fix: redesign /provider transition microcopy — progressive disclosure, terse confirmations#268
Brian Krabach (bkrabach) merged 1 commit into
mainfrom
feat/provider-microcopy-redesign

Conversation

@bkrabach

Copy link
Copy Markdown
Collaborator

Summary

Progressive disclosure redesign of the /provider use and /provider auto transition messages — moving from 320-char paragraphs with forward-looking predictions to terse, immediately-true confirmations that leverage three persistent UI surfaces already doing the confirming.

The reduction: 320 → 25 chars (use), 284 → 26 chars (auto). No 5-4 line wraps anymore — one line each, plus a one-time teach block on first pin.

Design decisions locked in code

  1. Deliberate asymmetry: use confirmed by signal APPEARING → needs nothing more. auto confirmed by signal DISAPPEARING (weaker) + destroys the only other record of what was pinned → includes (was X). Test documents the reason so nobody "fixes" it into symmetry.

  2. No forward-looking tense: Every string is past-tense or state-descriptive ('pinned', 'unpinned', 'already pinned', 'not pinned') — each true at print time, describing what the system was TOLD not what a model DID. Removed 'takes effect on NEXT turn' entirely. Enforced by runtime + AST checks.

  3. No-op honesty: auto with nothing pinned now says 'not pinned' (was falsely 'unpinned'). Re-pinning already-pinned now says 'already pinned' (was falsely fresh 'pinned'). Still call pin() so unmounted providers surface loud errors, not false confirmations.

Test evidence

  • Unit: 83 passed (was 71). All five message paths verified.
  • Integration: Full suite 1384 passed / 1 skipped / 13 deselected / 1 xfailed.
  • E2E: Real TUI session in DTU — all five states rendered correctly. Teach line appears exactly once per session; no old verbose text; no reappearance after unpin/re-pin cycle.
  • Styling: Dim attribute technically unverified (pyte limitation) but luminance difference measured at ~63% of normal.

Relates to

Follows up PR #267 (the command itself). Same design review process; this is the microcopy cleanup.

…, terse confirmations

Addresses the feedback from testing that the /provider use/auto confirmations
were 320-char paragraphs explaining that the pin 'takes effect on the NEXT
turn' and that users should check the token-usage line to confirm. That copy
compensated for uncertainty that no longer exists — three persistent surfaces
already do the confirming:

• Prompt indicator: [📌 name]> rendered one line down, persistent
• Per-turn footer badge: · 📌 pinned
• /provider status: full scope + usage caveat

The transition line was the least important of four surfaces and by far the
longest. This redesign reduces noise and applies progressive disclosure:

NEW BEHAVIOR (matches Option 4 from the design review):

First /provider use in a session (two lines, taught once):
  📌 pinned: anthropic-fable
     experimental · scope: this conversation only · /provider for details

Every subsequent pin (one line):
  📌 pinned: openai-fast

Already pinned to that provider (one line):
  📌 already pinned: openai-fast

Unpin when something was pinned (one line):
  unpinned (was openai-fast)

Unpin when nothing was pinned (one line):
  not pinned

CHANGES:

1. /provider use: 320 chars / 5 wrapped lines → 25 chars / 1 line (first pin
   also includes 2-line teach block, one time per session).

2. /provider auto: 284 chars / 4 wrapped lines → 26 chars / 1 line.

3. Three design decisions locked in code:

   a) DELIBERATE ASYMMETRY: use is confirmed by a signal APPEARING, auto by
      one DISAPPEARING (weaker evidence). Unpinning destroys the prompt
      indicator, the only other record of what was pinned. The (was X)
      clause is the single genuinely non-redundant fact in either message.
      Locked by a test with the reason documented.

   b) FORWARD-LOOKING TENSE IS BANNED: every string is past-tense or
      state-descriptive ('pinned', 'unpinned', 'already pinned', 'not pinned')
      — each one true at the instant it prints, because it describes what
      the system was TOLD, not what a model DID. Removed 'takes effect on
      NEXT turn' entirely rather than rewording it. Enforced by runtime
      sweeps and AST checks on the string constants.

   c) NO-OP HONESTY: /provider auto with nothing pinned previously printed
      'unpinned' (untrue), re-pinning an already-pinned provider printed a
      fresh 'pinned' (untrue). Both were plausible-but-false confirmations —
      exactly the failure class this feature exists to prevent. They now
      report 'not pinned' and 'already pinned: X'. The already-pinned path
      still calls pin() so an unmounted provider surfaces its loud error
      instead of a false confirmation.

4. Messages render dim (color carries weight, reads as a receipt not content).
   Provider names are markup-escaped so '[' can't open a style tag.

TESTS: 83 passed (was 71). Full suite: 1384 passed, 1 skipped, 13
deselected, 1 xfailed. All five states verified end-to-end in a real TUI
session; teach line correctly appears once per session; no old verbose text;
no de-emphasis attribute capture (pyte limitation) but luminance difference
measured at ~63% of normal (technically correct, visually dim).

Fixes follow-up to PR #267.

🤖 Generated with [Amplifier](https://github.com/microsoft/amplifier)

Co-Authored-By: Amplifier <240397093+microsoft-amplifier@users.noreply.github.com>
@bkrabach
Brian Krabach (bkrabach) force-pushed the feat/provider-microcopy-redesign branch from 638c421 to 0eff65e Compare August 13, 2026 09:41
@bkrabach
Brian Krabach (bkrabach) marked this pull request as ready for review August 13, 2026 09:44
@bkrabach
Brian Krabach (bkrabach) merged commit 9a3fdd0 into main Aug 13, 2026
7 checks passed
@bkrabach
Brian Krabach (bkrabach) deleted the feat/provider-microcopy-redesign branch August 13, 2026 09:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants