Add reproducible standalone dependencies and a source-grounded external conversation launch plan, gated until ACP subtree containment is implemented.
Signed-off-by: Logan Johnson <loganj@squareup.com>
## Summary
When an agent reports model-not-found, Buzz retries the unavailable
model and delays the failure reply until retries are exhausted. Stop
retrying this error and immediately post a threaded recovery notice. The
notice tells users to select a different model in agent settings, save,
restart the agent to apply the configuration, and re-send their request.
This adds one error-handling branch and regression coverage in
`buzz-acp`. It matches `-32002` errors containing `model not found`.
Other resource-not-found errors, such as stale sessions, retain the
existing retry behavior. Detailed error events remain available for
diagnosis. The existing restart policy is unchanged.
### Related issue
None found in existing issue/PR searches for model-not-found recovery.
### Testing
Playwright captured and visually checked the thread UI with seeded
conversation data and the exact recovery text. The check opens the
request's thread, confirms no reply before the failure, injects the
notice, and verifies the full text is visible. [Before/after
screenshots](https://github.com/block/buzz/pull/7538#issuecomment-5608196506)
show the corrected save-and-restart instructions. These are local test
captures, not a deployed provider recovery flow.
Generated with Codex
---------
Signed-off-by: Diem Nguyen <diem@squareup.com>
## Summary
Buzz considers codex-acp 1.6.2 current because the supported adapter
floor is still 1.1.7. That adapter bundles Codex 0.148.0, so updating a
separate Codex CLI to 0.153.4 leaves managed agents on the older runtime
and unable to use GPT-6 Astra.
Raise the supported adapter floor to the published 1.10.0 release, which
depends on `@openai/codex ^0.153.3`. Existing discovery and installation
code then classifies older adapters as outdated and offers the managed
reinstall path. Update the availability and install-plan regressions to
cover the observed 1.6.2 installation and the new minimum.
This follows the existing version-floor policy. It does not
automatically update a running installation: the user must complete
Buzz’s offered adapter upgrade. Future upstream compatibility changes
may require another floor update.
### Related issue
No exact duplicate found in searches for Astra, CODEX_PATH, bundled
Codex, outdated runtime, and codex-acp 1.10. Related: #3097 raised the
older floor to 1.1.7 (already present on main); #2422 covers lost error
details for runtime mismatches. Neither resolves this version gap.
Originating conversation:
buzz://message?channel=3286cd76-f83e-4c7d-8317-10a16580744d&id=8b79a73078217222b870fff144c27e7d27bcd5a67c966869c18fe726db716898
### Testing
- Isolated npm install of codex-acp 1.10.0 resolved bundled Codex
0.153.4, with no CODEX_PATH override.
- Live macOS ACP probe: initialize protocol v1 → session/new → select
gpt-6-astra[medium] → prompt. Received `OK` and `stopReason: end_turn`;
usage metadata confirms gpt-6-astra.
- Existing adapter 1.6.2 initialized but advertised no Astra model in
the same probe.
- Desktop Rust formatting and `git diff --check` pass.
- `just desktop-tauri-test`: 3,266 passed, 20 ignored, zero failures
across the Desktop workspace and integration tests.
- Workspace and Desktop Clippy, frontend static checks, and `just
file-size-check` pass.
- Repository `just ci`: still running the remaining
mobile/build/workspace-test stages.
The installed Buzz app and managed adapter were not replaced or
restarted. The live check validates the new adapter/runtime path; a
complete packaged Desktop upgrade workflow remains untested.
Signed-off-by: Stephen DeLorme <stephen@d.elor.me>
🤖
## Summary
- Channel members appear in the Members sidebar. A member who has never
set a display name is listed under an abbreviated form of their public
key (npub), and the sidebar previously sorted those unnamed members by
that short label. Short labels are not unique — different keys can share
one — so the order of unnamed members could look arbitrary or unstable.
Unnamed members now sort by their full public key, so the order is
deterministic.
- When two members display the same name, the previous tiebreak was
membership order (who joined first), which is not visible to a reader
and can shift as roster data loads in. The tiebreak is now the full
public key, so identical display names always land in the same order.
- Nothing gets noisier on screen: the full key is used only for sorting,
and the sidebar still shows the compact abbreviated form. Priorities are
unchanged — authored (custom) names still outrank fallback labels, and
role/current-user grouping still applies.
- Scope is the desktop app's Members sidebar and member management: the
two existing sort comparators. Mobile and other lists in the app are
untouched.
### Related issue
Based on #7495 (introduced the abbreviated npub labels this follows up
on). The original five presentation PRs remain independently reviewable.
No closer duplicate found.
### Testing
- 6469 desktop unit tests, typecheck, and check pass.
- The 3 existing consumer-seam E2E tests still pass; a new E2E test
asserts the sidebar lists unnamed members in full-key order, with
fixture members deliberately inserted in the opposite order so incoming
membership order cannot mask the sort.
- Negative check: reverting only this change makes the new ordering
assertion fail, so it genuinely binds the new sort.
- CI has not run on this PR yet.
Buzz provenance: channel 1f0e4a3d-7e01-4efe-bb16-843b357f85c9 / task
340c3de9b27dbedb8453c0c7652220f9080d30fcc70a7c4f6e27fdd4fa378056
---------
Signed-off-by: Logan Johnson <loganj@squareup.com>
Co-authored-by: Larry <627498bd4bd1f281a16431e3c6cce3b5c25b6692798c78672298aefbf2f8f8b5@buzz.block.builderlab.xyz>
🤖
## Summary
In the mobile app, anyone who hasn't set a display name shows up as a
raw 64-character hex key (e.g. `3a5d4f9c…`) — unreadable, and
unrecognizable as the same identity across screens. Profile and Settings
also let you copy that raw hex. Nostr public keys have a standard
readable form — `npub1…`, the same encoding other Nostr apps and our
desktop app already display. This PR makes every mobile identity surface
render npub instead:
- **Unnamed people everywhere** — message and thread authors, reactions,
typing indicators, member lists, channel details, DM headers and tiles,
inbox, search, forum cards, Pulse notes and reply context, mention
suggestions, and invite rows — now show a compact npub label: first 8 +
last 4 characters of the full npub joined by an ellipsis
(`npub1abcd…wxyz`), the same truncation desktop uses. Previously these
showed truncated raw hex.
- **DM fallback avatars and blank names** — 1:1 DM tiles and headers key
their fallback avatar to the same non-self counterpart the label names,
including self-first participant order; a self-DM keeps its
hex-key-derived initial. Blank or whitespace-only display names fall
back to the compact npub instead of rendering empty, while nonblank
authored names render verbatim (padding included).
- **Profile sheet → "Copy public key"** now copies the full canonical
npub — never raw hex. When the identity string isn't a valid public key,
the copy tile is disabled, so a malformed key never reaches the
clipboard.
- **Settings → Identity (pubkey)** displays and copies the full npub; an
invalid identity reads "Identity unavailable" with copy disabled.
- **Invalid identities never leak truncated raw hex** into the UI
anywhere — they render a neutral "Unknown identity" label.
- **Unchanged on purpose:** display names and verified handles (NIP-05 —
the `name@domain` badge) still render as before. Unnamed avatars keep
distinct per-key initials, derived from the underlying hex key rather
than the npub — otherwise every unnamed key would render the same "N"
initial. Event IDs are not public keys, so they keep their hex
truncation (in Pulse's "Replying to", the parent author shows npub while
an event-id fallback still shows hex). The nevent share link, private
keys, and internal hex storage are untouched. Inputs that accept a key
(invite/member entry) accept both hex and npub and keep working in hex
internally.
### Related issue
N/A. Searched open issues/PRs for npub identity display on mobile —
closest related: none found. Desktop's parallel npub standardization
lives in the stacked desktop PRs (#7488 foundation, #7489 controls,
#7495 display surfaces); this is the independent mobile slice (based
directly on `main`, not on those branches).
### Testing
At exact head `5a620e420a1fd57d9d8011ac26434eed32fcf765` (base: `main`
`44316ff72`; 40 files, +1,345/−154):
- Full mobile suite: 2,098 tests passing (`cd mobile && flutter test`);
`flutter analyze` clean; `dart format --set-exit-if-changed .` clean —
the same checks CI runs.
- Widget/unit coverage at production seams: compact labels and hex-keyed
avatar initials for DM headers/tiles, member rows, mention suggestions,
and Pulse reply context; DM fallback avatars keyed to the labeled
counterpart (self-first order and self-DMs); blank/whitespace
display-name npub fallback with nonblank authored labels verbatim,
including the Activity inbox sender and profile-sheet heading (each with
its own empty/whitespace production-seam regression); full-npub copy and
disabled-copy semantics in profile and settings; invalid-key
suppression; and hex↔npub input round-trips.
Verified via unit and widget tests — no device/simulator validation is
claimed.
### Task provenance
Buzz channel: `1f0e4a3d-7e01-4efe-bb16-843b357f85c9`
Task:
buzz://message?channel=1f0e4a3d-7e01-4efe-bb16-843b357f85c9&id=86b34eb4bd84a1472419e9af22636c011c0fe273e3c196f967d7a36996e149b6
---------
Signed-off-by: Logan Johnson <loganj@squareup.com>
Co-authored-by: Larry <627498bd4bd1f281a16431e3c6cce3b5c25b6692798c78672298aefbf2f8f8b5@buzz.block.builderlab.xyz>
